分布式唯一ID生成企业级方案（含时钟回拨生产级解决）

分布式唯一ID要求

常见的几种方案

一. 数据库自增主键

二. UUID

三. SnowFlow算法

四. Redis自增机制

五. flickr 雅虎公司方案

六. flickr方案的高并发优化

时钟回拨解决方案

Leaf——美团点评分布式ID生成系统

Leaf-segment数据库方案

Leaf-snowflake方案

分布式唯一ID要求

① 唯一性：生成的ID全局唯一，在特定范围内冲突概率极小。

② 有序性：生成的ID按某种规则有序，便于数据库插入及排序递增

③ 可用性：可保证高并发下的可用性, 确保任何时候都能正确的生成ID。

④ 自主性：分布式环境下不依赖中心认证即可自行生成ID。

⑤ 安全性：不暴露系统和业务的信息, 如：订单数,用户数等。

常见的几种方案

一. 数据库自增主键

实现逻辑：专门搞个表用于生成全局的id，插入一条数据返回对应的主键id，作为分布式id。
优点：简单
缺点：单库单表，无法支撑高并发，还要定时去删除数据。
适用场景：并发低，数据量少，但是这种场景真的需要单独做唯一ID吗？生产不用该方案

二. UUID

实现逻辑：就是用uuid生成
优点：简单，没有并发
缺点：长，作为主键会经常造成页分裂，影响性能
适用场景：不作为主键的其他唯一值，分布式ID不考虑该方案

三. SnowFlow算法

实现逻辑：64个bit位，41位放时间（最多使用69年），10位放机器标识（最多把snowflake程序部署在1024台机器上），12位放序号（每毫秒，每台机器，可以顺序生成4096个ID），最高位1个bit是0，绝对够用了。
优点：高性能，高并发，分布式，可伸缩，最多扩展1024台机器
缺点：开源算法，有时钟回拨等问题（下面会介绍解决方案），如要要解决，还需要开发很多，需独立部署
适用场景：中大型公司，有极高并发需求，多地多机房多机方案

四. Redis自增机制

实现逻辑：利用redis的自增，实现唯一
优点：简单，一般都有redis，无需单独部署
缺点：单独适用自增还不够，需要进行改造，结果时间日期等，需要进行代码编写
适用场景：利用时间戳+业务id+自增id其实能满足大部分的场景

五. flickr 雅虎公司方案

该方案和方案一有点像，都是基于自增id实现的唯一优化就是用replace into替代了insert into，避免表数据量过大，缺点也在于数据库并发能力不高，所以适用场景，就是分库分表的时候，低并发，用这个方案生成唯一id，低并发场景下可以用于生产。

CREATE TABLE `uid_sequence` (  `id` bigint(20) unsigned NOT NULL auto_increment,  `stub` char(10) NOT NULL default '',  PRIMARY KEY  (`id`),  UNIQUE KEY `stub` (`stub`)
) ENGINE=MyISAM;REPLACE INTO uid_sequence (stub) VALUES ('test');
SELECT LAST_INSERT_ID();

replace into语法替代insert into，避免表行数过大，一张表就一行数据，然后再select获取这个表的最新id，last_insert_id()函数是connection级别的，就你这个连接的最近insert生成的id，多个客户端之间没影响。

六. flickr方案的高并发优化

优化点：每次调用replace into获取到的id做成一个号段，比如1 代表1-10000，2代表10000-200000，号段维护到jvm内存里，每次获取直接内存加1。当超过最大号段时，再调用replace into进行号段的刷新。这样做就解决了高并发的问题。

缺点：

每次启动都要刷新内存号段，浪费了部分号段，解决就是每次销毁做持久化
瞬时量特别大，比如10000一下就没了，就得不停的去数据库换号段，那数据库还能支持吗？大部分场景是没问题的
始终会依赖数据库，数据库的高可用、扩容等本身也是一个问题。

适用场景：大部分生产是可以使用的，对与瞬时量不是特别特别大的还是可以使用

时钟回拨解决方案

关闭时钟同步，不现实，不能采取。
记录上一次生成id的时间，如果发现本次小于上一次说明回拨了。本次等待时间追上来了再生成新id，若时间回拨太多，该方案不可取，可以设置一个阀值，比如超过10s钟就主动下线，并邮件告警
记录最近一段时间的id的生成最大值，当回拨的时候，继续在原来的基础上继续生成，当超过最近的记录的最大值，就转移到另一个实例，并下线当前实例，邮件告警。

Leaf——美团点评分布式ID生成系统

GitHub - Meituan-Dianping/Leaf: Distributed ID Generate Service

Leaf-segment数据库方案

该方案就类似于flickr，只是在原来的基础上做了优化。

优化点：双buffer优化

Leaf服务内部有两个号段缓存区segment。当前号段已下发10%时，如果下一个号段未更新，则另启一个更新线程去更新下一个号段。当前号段全部下发完后，如果下个号段准备好了则切换到下个号段为当前segment接着下发，循环往复。

Leaf-snowflake方案

Leaf-snowflake方案完全沿用snowflake方案的bit位设计，即是“1+41+10+12”的方式组装ID号。对于workerID的分配，当服务集群数量较小的情况下，完全可以手动配置。Leaf服务规模较大，动手配置成本太高。所以使用Zookeeper持久顺序节点的特性自动对snowflake节点配置wokerID。Leaf-snowflake是按照下面几个步骤启动的：

启动Leaf-snowflake服务，连接Zookeeper，在leaf_forever父节点下检查自己是否已经注册过（是否有该顺序子节点）。
如果有注册过直接取回自己的workerID（zk顺序节点生成的int类型ID号），启动服务。
如果没有注册过，就在该父节点下面创建一个持久顺序节点，创建成功后取回顺序号当做自己的workerID号，启动服务。

解决时钟问题：

参见上图整个启动流程图，服务启动时首先检查自己是否写过ZooKeeper leaf_forever节点：

若写过，则用自身系统时间与leaf_forever/{self}节点记录时间做比较，若小于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}。

由于强依赖时钟，对时间的要求比较敏感，在机器工作时NTP同步也会造成秒级别的回退，建议可以直接关闭NTP同步。要么在时钟回拨的时候直接不提供服务直接返回ERROR_CODE，等时钟追上即可。或者做一层重试，然后上报报警系统，更或者是发现有时钟回拨之后自动摘除本身节点并报警