十分钟了遣散布式系统中生成惟一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）