分布式唯一 id： snowflake 算法思考

匠心零度 转载请注明原创出处，谢谢！

缘起

为什么会突然谈到分布式唯一 id 呢？原因是最近在准备使用 RocketMQ，看看官网介绍：

一句话，消息可能会重复，所以消费端需要做幂等。为什么消息会重复后续 RocketMQ 章节进行详细介绍，本节重点不在这里。

为了达到业务的幂等，必须要有这样一个 id 存在，需要满足下面几个条件：

• 同一业务场景要全局唯一。
• 该 id 必须是在消息的发送方进行产生发送到 MQ。
• 消费端根据该 id 进行判断是否重复，确保幂等。

在那里产生，和消费端进行判断等和这个 id 没有关系，这个 id 的要求就是局部唯一或者全局唯一即可，由于这个 id 是唯一的，可以用来当数据库的主键，既然要做主键那么之前刚刚好发过一篇文章：从开发者角度谈 Mysql （ 1 ）：主键问题，文章重点提到为什么需要自增、或者趋势自增的好处。（和 Mysql 数据存储做法有关）。

那么该 id 需有 2 个特性：

• 局部、全局唯一。
• 趋势递增。

如果有方法可以生成全局唯一（那么在局部也一定唯一了），生成分布式唯一 id 的方法有很多。大家可以看看分布式系统唯一 ID 生成方案汇总： http://www.cnblogs.com/haoxinyue/p/5208136.html （由于微信不是他的地址都显示不出来，所以把地址贴出来下），这个文章里面提到了很多以及各各的优缺点。 本文关注重点是 snowflake 算法，该算法实现得到的 id 就满足上面提到的 2 点。

snowflake 算法

snowflake 是 Twitter 开源的分布式 ID 生成算法，结果是一个 long 型的 ID。其核心思想是：使用 41bit 作为毫秒数，10bit 作为机器的 ID （ 5 个 bit 是数据中心，5 个 bit 的机器 ID ），12bit 作为毫秒内的流水号（意味着每个节点在每毫秒可以产生 4096 个 ID ），最后还有一个符号位，永远是 0。

该算法实现基本就是二进制操作，如果二进制不熟悉的可以看看我之前写的相关文章：java 二进制相关基础、二进制实战技巧。

这个算法单机每秒内理论上最多可以生成 1000*(2^12)，也就是 409.6 万个 ID，（吼吼，这个得了的快啊）。

java 实现代码基本上就是类似这样的（都差不多，基本就是二进制位操作）： 参考： https://www.cnblogs.com/relucent/p/4955340.html

/** * Twitter_Snowflake<br> * SnowFlake 的结构如下(每部分用-分开):<br> * 0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000 <br> * 1 位标识，由于 long 基本类型在 Java 中是带符号的，最高位是符号位，正数是 0，负数是 1，所以 id 一般是正数，最高位是 0<br> * 41 位时间截(毫秒级)，注意，41 位时间截不是存储当前时间的时间截，而是存储时间截的差值（当前时间截 - 开始时间截) * 得到的值），这里的的开始时间截，一般是我们的 id 生成器开始使用的时间，由我们程序来指定的（如下下面程序 IdWorker 类的 startTime 属性）。41 位的时间截，可以使用 69 年，年 T = (1L << 41) / (1000L * 60 * 60 * 24 * 365) = 69<br> * 10 位的数据机器位，可以部署在 1024 个节点，包括 5 位 datacenterId 和 5 位 workerId<br> * 12 位序列，毫秒内的计数，12 位的计数顺序号支持每个节点每毫秒(同一机器，同一时间截)产生 4096 个 ID 序号<br> * 加起来刚好 64 位，为一个 Long 型。<br> * SnowFlake 的优点是，整体上按照时间自增排序，并且整个分布式系统内不会产生 ID 碰撞(由数据中心 ID 和机器 ID 作区分)，并且效率较高，经测试，SnowFlake 每秒能够产生 26 万 ID 左右。 */ public class SnowflakeIdWorker { // ==============================Fields=========================================== /** 开始时间截 (2015-01-01) */ private final long twepoch = 1420041600000L; /** 机器 id 所占的位数 */ private final long workerIdBits = 5L; /** 数据标识 id 所占的位数 */ private final long datacenterIdBits = 5L; /** 支持的最大机器 id，结果是 31 (这个移位算法可以很快的计算出几位二进制数所能表示的最大十进制数) */ private final long maxWorkerId = -1L ^ (-1L << workerIdBits); /** 支持的最大数据标识 id，结果是 31 */ private final long maxDatacenterId = -1L ^ (-1L << datacenterIdBits); /** 序列在 id 中占的位数 */ private final long sequenceBits = 12L; /** 机器 ID 向左移 12 位 */ private final long workerIdShift = sequenceBits; /** 数据标识 id 向左移 17 位(12+5) */ private final long datacenterIdShift = sequenceBits + workerIdBits; /** 时间截向左移 22 位(5+5+12) */ private final long timestampLeftShift = sequenceBits + workerIdBits + datacenterIdBits; /** 生成序列的掩码，这里为 4095 (0b111111111111=0xfff=4095) */ private final long sequenceMask = -1L ^ (-1L << sequenceBits); /** 工作机器 ID(0~31) */ private long workerId; /** 数据中心 ID(0~31) */ private long datacenterId; /** 毫秒内序列(0~4095) */ private long sequence = 0L; /** 上次生成 ID 的时间截 */ private long lastTimestamp = -1L; //==============================COnstructors===================================== /** * 构造函数 * @param workerId 工作 ID (0~31) * @param datacenterId 数据中心 ID (0~31) */ public SnowflakeIdWorker(long workerId, long datacenterId) { if (workerId > maxWorkerId || workerId < 0) { throw new IllegalArgumentException(String.format("worker Id can't be greater than %d or less than 0", maxWorkerId)); } if (datacenterId > maxDatacenterId || datacenterId < 0) { throw new IllegalArgumentException(String.format("datacenter Id can't be greater than %d or less than 0", maxDatacenterId)); } this.workerId = workerId; this.datacenterId = datacenterId; } // ==============================Methods========================================== /** * 获得下一个 ID (该方法是线程安全的) * @return SnowflakeId */ public synchronized long nextId() { long timestamp = timeGen(); //如果当前时间小于上一次 ID 生成的时间戳，说明系统时钟回退过这个时候应当抛出异常 if (timestamp < lastTimestamp) { throw new RuntimeException( String.format("Clock moved backwards. Refusing to generate id for %d milliseconds", lastTimestamp - timestamp)); } //如果是同一时间生成的，则进行毫秒内序列 if (lastTimestamp == timestamp) { sequence = (sequence + 1) & sequenceMask; //毫秒内序列溢出 if (sequence == 0) { //阻塞到下一个毫秒,获得新的时间戳 timestamp = tilNextMillis(lastTimestamp); } } //时间戳改变，毫秒内序列重置 else { sequence = 0L; } //上次生成 ID 的时间截 lastTimestamp = timestamp; //移位并通过或运算拼到一起组成 64 位的 ID return ((timestamp - twepoch) << timestampLeftShift) // | (datacenterId << datacenterIdShift) // | (workerId << workerIdShift) // | sequence; } /** * 阻塞到下一个毫秒，直到获得新的时间戳 * @param lastTimestamp 上次生成 ID 的时间截 * @return 当前时间戳 */ protected long tilNextMillis(long lastTimestamp) { long timestamp = timeGen(); while (timestamp <= lastTimestamp) { timestamp = timeGen(); } return timestamp; } /** * 返回以毫秒为单位的当前时间 * @return 当前时间(毫秒) */ protected long timeGen() { return System.currentTimeMillis(); } //==============================Test============================================= /** 测试 */ public static void main(String[] args) { SnowflakeIdWorker idWorker = new SnowflakeIdWorker(0, 0); for (int i = 0; i < 1000; i++) { long id = idWorker.nextId(); System.out.println(Long.toBinaryString(id)); System.out.println(id); } } } 

优点：

• 快（哈哈，天下武功唯快不破）。
• 没有啥依赖，实现也特别简单。
• 知道原理之后可以根据实际情况调整各各位段，方便灵活。

缺点：

• 只能趋势递增。（有些也不叫缺点，网上有些如果绝对递增，竞争对手中午下单，第二天在下单即可大概判断该公司的订单量，危险！！！）
• 依赖机器时间，如果发生回拨会导致可能生成 id 重复。 下面重点讨论时间回拨问题。

snowflake 算法时间回拨问题思考

由于存在时间回拨问题，但是他又是那么快和简单，我们思考下是否可以解决呢？ 零度在网上找了一圈没有发现具体的解决方案，但是找到了一篇美团不错的文章：Leaf 美团点评分布式 ID 生成系统（ https://tech.meituan.com/MT_Leaf.html ）文章很不错，可惜并没有提到时间回拨如何具体解决。下面看看零度的一些思考：

分析时间回拨产生原因

第一：人物操作，在真实环境一般不会有那个傻逼干这种事情，所以基本可以排除。 第二：由于有些业务等需要，机器需要同步时间服务器（在这个过程中可能会存在时间回拨，查了下我们服务器一般在 10ms 以内（ 2 小时同步一次））。

解决方法

1. 由于是分布在各各机器自己上面，如果要几台集中的机器（并且不做时间同步），那么就基本上就不存在回拨可能性了（曲线救国也是救国，哈哈），但是也的确带来了新问题，各各结点需要访问集中机器，要保证性能，百度的 uid-generator 产生就是基于这种情况做的（每次取一批回来，很好的思想，性能也非常不错） https://github.com/baidu/uid-generator。 如果到这里你采纳了，基本就没有啥问题了，你就不需要看了，如果你还想看看零度自己的思考可以继续往下看看（零度的思考只是一种思考 可能也不一定好，期待你的交流。），uid-generator 我还没有细看，但是看测试报告非常不错，后面有空的确要好好看看。

2. 下面谈谈零度自己的思考，之前也大概和美团 Leaf 作者交流了下，的确零度的这个可以解决一部分问题，但是引入了一些其他问题和依赖。是零度的思考，期待更多的大佬给点建议。

时间问题回拨的解决方法：

1. 当回拨时间小于 15ms，就等时间追上来之后继续生成。
2. 当时间大于 15ms 时间我们通过更换 workid来产生之前都没有产生过的来解决回拨问题。

首先把 workid 的位数进行了调整（ 15 位可以达到 3 万多了，一般够用了） Snowflake 算法稍微调整下位段：

• sign(1bit) 固定 1bit 符号标识，即生成的畅途分布式唯一 id 为正数。
• delta seconds (38 bits) 当前时间，相对于时间基点"2017-12-21"的增量值，单位：毫秒，最多可支持约 8.716 年
• worker id (15 bits) 机器 id，最多可支持约 3.28 万个节点。
• sequence (10 bits) 每秒下的并发序列，10 bits，这个算法单机每秒内理论上最多可以生成 1000*(2^10)，也就是100W的 ID，完全能满足业务的需求。

由于服务无状态化关系，所以一 workid 也并不配置在具体配置文件里面，看看我这篇的思考，为什么需要无状态化。高可用的一些思考和理解，这里我们选择 redis 来进行中央存储（ zk、db ）都是一样的，只要是集中式的就可以。

下面到了关键了： 现在我把 3 万多个 workid 放到一个队列中（基于 redis ），由于需要一个集中的地方来管理 workId，每当节点启动时候，（先在本地某个地方看看是否有 借鉴弱依赖 zk 本地先保存），如果有那么值就作为 workid，如果不存在，就在队列中取一个当 workid 来使用（队列取走了就没了 ），当发现时间回拨太多的时候，我们就再去队列取一个来当新的 workid 使用，把刚刚那个使用回拨的情况的 workid 存到队列里面（队列我们每次都是从头取，从尾部进行插入，这样避免刚刚 a 机器使用又被 b 机器获取的可能性）。

有几个问题值得思考：

• 如果引入了 redis 为啥不用 redis 下发 id ？（查看分布式系统唯一 ID 生成方案汇总会获得答案，我们这里仅仅是用来一致性队列的，能做一致性队列的基本都可以)。

• 引入 redis 就意味着引入其他第三方的架构，做基础框架最好是不要引用（越简单越好，目前还在学习提高）。

• redis 一致性怎么保证？（ redis 挂了怎么办，怎么同步，的确值得商榷。可能会引入会引入很多新的小问题）。

总结

所以选择类似百度的那种做法比较好，集中之后批取，零度的思考虽然思考了，但是从基础组件来看并不是特别合适，但是也算一种思路吧。期待与大佬们的交流。

如果读完觉得有收获的话，欢迎点赞、关注、加公众号 [匠心零度] ，查阅更多精彩历史！！！