目录
分布式唯一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,等时钟追上即可。或者做一层重试,然后上报报警系统,更或者是发现有时钟回拨之后自动摘除本身节点并报警