一文了解分布式系统ID生成策略
在分布式系统中，经常需要对大量的数据、消息、http请求等进行唯一标识，例如链路追踪traceId、身份标识号、订单流水号、操作记录流水号、优惠券id等等。
这个时候数据库自增主键已经不能满足需求，需要一个能够生成分布式ID的系统。
分布式ID的特性
-
全局唯一。不能出现重复的ID，这是最基本的要求。
-
递增。递增有利于关系数据库索引性能。除了常见的连续递增，如1001，1002，1003等等，分布式ID还存在趋势递增的形式，即保证下一个ID大于上一个ID但不连续。这样的好处可以防止关键信息被泄露，例如toc业务中暴露给用户的ID，可能会暴露用户数量。（订单id同理）
-
高可用。为多个服务提供ID服务，一旦宕机，会造成严重影响。
-
好接入。秉着拿来即用的设计原则，接入文档要尽可能的简单。
-
高性能：必须要在压测下表现良好，如果达不到要求则在高并发环境下会导致系统瘫痪。
-
灵活多变：每个业务场景对ID的要求也各不相同，ID生成要做到灵活多变可配置，尽可能多的满足需求。
解决方案
1. UUID
UUID是Universally Unique Identifier的缩写，包含32个16进制数字，以连字号分为五段，形式为8-4-4-4-12包含36个字符的字符串，例如：321dsa13-das2-d231-gfdd-213as8asd899
UUID经由一定的算法机器生成，为了保证UUID的唯一性，规范定义了包括网卡MAC地址、时间戳、名字空间、随机或伪随机数、时序等元素，以及从这些元素生成UUID的算法。
优点：
-
性能非常高，本地生成，没有网络消耗。
-
生成简单，没有高可用风险。
-
有利于信息安全，因为可读性差，无规律。
缺点：
-
太长，不易于存储。
-
无序，对MySQL索引不利，在InnoDB中，UUID的无序性可能会引起数据位置频繁变动，严重影响性能。
-
UUID不能标识业务含义，可读性差。
2. 数据库自增 ID
利用数据库自增ID的特性来生成，如MySQL的auto_increment。其优点是数字类型，并且可以自增。当然缺点就是并发场景下的性能瓶颈。
优点：
-
简单，利用数据库自有功能实现。
-
ID严格连续自增，可以实现一些对ID有特殊要求的业务。
缺点：
-
有重复发号的风险，例如MySQL数据库主从切换的场景。
-
发号性能限制于数据库性能。
-
强依赖数据库，当数据库异常时整个系统不可用。
进一步优化：
放弃主从复制的高可用架构，采用多主架构。每个主库设置不同的起始值和相同的步长，保证了号段的隔离。
3. Redis
Redis中的incr命令，可以实现原子自增。相比较数据库而言，Redis可支撑的并发量非常高，性能好。
但需要考虑下面两种情况造成的数据不一致问题：
-
宕机后重启恢复但存在未及时初始化。
-
主从切换，主从数据同步延迟。
优点：
-
简单，自有能力。
-
高并发环境下性能好，优于数据库。
缺点：
-
可能会重复发号。
-
需要保障Redis服务的高可用。
4. Zookeeper 实现
使用ZooKeeper作为分段节点协调工具，每台服务器首先从Zookeeper 获取一段号码，如[1,1000]的ID，此时Zookeeper上保存最大值 1000，每次获取的时候都会进行判断，如果ID <=1000，则更新本地的当前值，如果为1001，则会将Zookeeper 上的最大值更新至2000，本地缓存段更新为1001-2000，更新的时候使用分布式锁来实现。（相当于用Zookeeper实现了基于数据库的号段模式）
优点：
效率高。
缺点：
维护成本较高，不能同时满足多个系统对ID的需求，不够灵活。
5、基于数据库的号段模式
号段模式的思想是客户端每次从数据库中取出一批ID供程序使用，从表中获取本次ID值的范围，如[1,1000]，然后客户端将申请的号段[1,1000]加载到内存。表结构参考如下：
CREATE TABLE id_generator (
id int(10) NOT NULL,
max_id bigint(20) NOT NULL COMMENT '当前最大id',
step int(20) NOT NULL COMMENT '号段的布长',
biz_type int(20) NOT NULL COMMENT '业务类型',
version int(20) NOT NULL COMMENT '乐观锁版本号',
PRIMARY KEY (`id`)
)
等这批号段ID用完，再次向数据库申请新号段，对max_id字段做一次update操作（update id_generator set max_id = #{max_id+step}, version = version + 1 where version = # {version} and biz_type = XXX），update成功则说明新号段获取成功，新的号段范围是(max_id ,max_id +step]
进一步优化：
在号段消耗一半的时候，提前预留下一段号段。将预留号段时机提前，减少阻塞发生概率。一般称此为双Buffer机制。
不同业务可以设置不同的生成规则。
5.雪花算法
雪花算法（Snowflake）是twitter公司内部分布式项目采用的ID生成算法，开源后广受国内大厂的好评，在该算法影响下各大公司相继开发出各具特色的分布式生成器。
雪花算法，不依赖其它系统或数据库，以服务的方式部署，供其它服务调用，稳定性高，生成 ID 的性能也非常高。
给每台机器分配一个唯一标识，然后通过下面的结构实现全局唯一ID：
-
1位。未使用（二进制中最高位为1的都是负数，所以这个最高位固定是0）
-
41位。毫秒级时间（41 位的长度可以使用 69 年）
-
10位。包含5位datacenterId和5位workerId（10位的长度最多支持部署1024个节点）
-
12位。最后12位是毫秒内的计数（12位的计数顺序号支持每个节点每毫秒产生4096个ID序号）
由于在Java中64bit的整数是long类型，所以在Java中SnowFlake算法生成的id就是long来存储的。
优点：
-
生成性能高。
-
整体上按照时间自增排序。
缺点：
-
强依赖机器时钟，如果时钟回拨，可能会导致服务异常。
-
不能同时满足多个系统对ID的需求，不够灵活。
-
在单机上是递增的，但是由于涉及到分布式环境，每台机器上的时钟不可能完全同步，会出现不是全局递增的情况。
6.Tinyid
Tinyid是滴滴开源的分布式ID生成方案，开源地址见于参考文档1，只提供基于号段模式来生成ID（加入了双Buffer机制）。
7.Uidgenerator
UidGenerator是由百度技术部开发，开源地址见于参考文档2，基于Snowflake实现的优化算法。借用未来时间和双Buffer来解决时间回拨与生成性能等问题，同时结合MySQL进行ID分配。
8.Leaf
Leaf是美团开源的分布式ID生成方案，开源地址见于参考文档3。提供两种生成的ID的方式：雪花算法模式和号段模式。可通过配置文件来指定。
Leaf的雪花算法模式依赖于ZooKeeper，其workId的生成策略是基于ZooKeeper的顺序ID来生成的；号段模式也是基于数据库的号段模式+双Buffer机制实现的。
参考文档：
-
https://github.com/didi/tinyid
-
https://github.com/baidu/uid-generator
-
https://github.com/Meituan-Dianping/Leaf