1. 首页 > 娱乐

十分钟了解分布式系统中生成唯一ID

分布式系统中生成唯一ID在后台开发是经常遇到的架构设计,当然方案有很多,比如通过redis或者数据库实现自增。但是如果依赖redis或者数据库,会导致单点问题,在架构上反而需要考虑点更多,那怎么解决呢?

首先分布式唯一ID需要支持如下:

方案:

单机生成方式

UUID(Universally Unique Identifier,即通用唯一标识码)算法的目的是生成某种形式的全局唯一ID来标识系统中的任一元素,尤其是在分布式环境下,UUID可以不依赖中心认证即可自动生成全局唯一ID。UUID的标准形式为32个十六进制数组成的字符串,且分割为五个部分,例如:执行:cat /proc/sys/kernel/random/uuid,输出:70048d49-6ef3-4ba6-84c4-1e6e37ec2f4a。

缺点:

2、Snowflake

snowflake(雪花算法)是一个开源的分布式ID生成算法,结果是一个long型的ID。snowflake算法将64bit划分为多段,分开来标识机器、时间等信息,其中格式如下:

bit bit时间戳 bit机器号bit序列递增

snowflake算法优势是支持递增,可以根据自己的算法改造使用bit位,不过存在如下缺点:

第三方模块生成方式

通过mysql,redis,zk或者ticket server实现架构如下:

前面提到依赖mysql也可以实现序列号,mysql的auto_increment可以保证全局唯一,不过需要依赖数据库,性能上会有影响。

当然提升性能的方式就是将mysql设置主从模式,但是只是为了序列号生成,部署多个mysql实例确实有些浪费。

redis同样可以实现递增,而且可以保证原子,比如通过incr或者incrby,虽然性能比mysql要好很多,我测试下来4c8g情况下可以支持10W+qps,不过存在单点维护问题。

3、Zookeeper

利用zookeeper的znode也可以生成序列号,可以生成32位和64位的数据版本号,客户端可以使用这个版本号来作为唯一的序列号,不过zk的性能比较差,在高并发场景下基本不建议采用。

4、Ticket Server

Ticket Server类似单独的票据服务,可以通过自己的逻辑生成唯一序列号,比如实现上可以使用原子递增,或者根据各个业务的特性进行适配。

不过要实现完整的容灾体系下可持久的服务工作量是不小的,对于没有太多特殊需求的场景,更建议依赖redis或者mysql。

号段生成方式

1、大厂方案:美团Leaf-segment和Leaf-snowflake方案

1.1 Leaf-segment

具体技术介绍:。Leaf-segment主要解决思路是:对直接用数据库自增ID充当分布式ID的一种优化,减少对数据库的访问频率,每次获取不是获取一个ID,而是获取一个号段,同时获取号段,将数据持久化到数据库中,这样可以解决分布式的抢占或者持久化问题,即使DB出现问题,也可以通过Master-Slave来解决。

1.2 Leaf-snowflake

Leaf-snowflake继续使用snowflake方案,主要解决了时钟不同步的问题,其中中间10bit机器号定义为WorkerID,Leaf-snowflake是按照下面几个步骤启动的:

若写过,则用自身系统时间与leaf_forever/节点记录时间做比较,若小于{self}时间则认为机器时间发生了大步长回拨,服务启动失败并报警;

若未写过,证明是新服务节点,直接创建持久节点leaf_forever/${self}并写入自身系统时间,接下来综合对比其余Leaf节点的系统时间来判断自身系统时间是否准确,具体做法是取leaf_temporary下的所有临时节点(所有运行中的Leaf-snowflake节点)的服务IP:Port,然后通过RPC请求得到所有节点的系统时间,计算sum(time)/nodeSize;

若abs( 系统时间-sum(time)/nodeSize ) < 阈值,认为当前系统时间准确,正常启动服务,同时写临时节点leaf_temporary/${self} 维持租约;

否则认为本机系统时间发生大步长偏移,启动失败并报警;

每隔一段时间(3s)上报自身系统时间写入leaf_forever/${self};

2、大厂方案:滴滴Tinyid和百度UidGenerator

2.1 滴滴Tinyid

开源方案:。Tinyid和美团的Leaf-segment方案类似,从数据库批量的获取自增ID,每次从数据库取出一个号段范围,例如:(1,1000]代表1000个ID,业务服务将号段在本地生成1~1000的自增ID并加载到内存。Tinyid会将可用号段加载到内存中,并在内存中生成ID,可用号段在首次获取ID时加载,如当前号段使用达到一定比例时,系统会异步的去加载下一个可用号段,以此保证内存中始终有可用号段,以便在发号服务宕机后一段时间内还有可用ID。

2.2 百度UidGenerator

百度UidGenerator是基于snowflake方案改造,旨在解决时钟回拨,workerid不够等问题。

RingBuffer:UidGenerator不再在每次取ID时都实时计算分布式ID,而是利用RingBuffer数据结构预先生成若干个分布式ID并保存,引入boostPower可以控制每秒生成ID的上限能力;

时间递增:UidGenerator的时间类型是AtomicLong,且通过incrementAndGet()方法获取下一次的时间,从而脱离了对服务器时间的依赖,也就不会有时钟回拨的问题;

3、大厂方案:容灾

微信内部也是通过独立的seqsvr提供序列号生成,主要面对场景是微信中的消息版本,其中特性和挑战如下。

(1)两个特性:

(2)面临两个挑战:

如何解决分布式场景下的问题?

提供两层:StoreSvr和AllocSvr,分别是存储层和缓存中间层,分层后就能利用堆机器就可以解决问题;

每秒千万级别的QPS?

实现方案和美团Leaf-segment类似,每次提供一批seqid,这样从千万级别的qps就变成千级别的qps,不过不保证序列号是连续的,但是能保证是递增的。

每个Uin都需要存储max-seqid,存储量大?

每个用户需要加载一个max_seq(32bit),如果uin是2^32个,则需要存储数据大小为16GB,这样系统启动时候加载就会很慢,微信如何解决?通过区分Set,同一批共享同一个max_seqid,这样就减少加载的数据量。

容灾如何实现?

seqsvr服务虽然简单,解决了上述高性能的问题,但是要保证高可靠性还是非常难,我查了一下内部资料和infoQ一样,实现架构可以参考:。seqsvr最核心的点是什么呢?每个 uin 的sequence申请要递增不回退,但是约束条件是:任意时刻任意 uin 有且仅有一台 AllocSvr 提供服务,就可以比较容易地实现sequence递增不回退的要求。

(1)容灾1.0

但是上述面临问题:

(2)容灾2.0

通过提供 Client 路由表方式解决访问 AllocSvr 切换的问题,执行步骤如下:

总结

以上就是一些场景下生成分布式唯一ID的方案选择,分布式唯一ID的架构虽然简单,但是如果要实现高性能高可用,还是需要根据业务场景来考虑。所以说简单的事情要做好并非易事,但是在这些年的工作中总是会有很多人为了追求效率,总想找到捷径而放弃架构的基本演进路径方法论....

参考

(1)(2)(3)

本网站的文章部分内容可能来源于网络和网友发布,仅供大家学习与参考,如有侵权,请联系站长进行删除处理,不代表本网站立场,转载者并注明出处:https://jmbhsh.com/yule/33584.html

联系我们

QQ号:***

微信号:***

工作日:9:30-18:30,节假日休息