分布式唯一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算法

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

java实现代码基本上就是类似这样的（都差不多，基本就是二进制位操作）：

参考：https://www.cnblogs.com/relucent/p/4955340.html

优点：

快（哈哈，天下武功唯快不破）。

没有啥依赖，实现也特别简单。

知道原理之后可以根据实际情况调整各各位段，方便灵活。

缺点：

只能趋势递增。（有些也不叫缺点，网上有些如果绝对递增，竞争对手中午下单，第二天在下单即可大概判断该公司的订单量，危险！！！）

依赖机器时间，如果发生回拨会导致可能生成id重复。

下面重点讨论时间回拨问题。

snowflake算法时间回拨问题思考

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

分析时间回拨产生原因

第一：人为操作，在真实环境一般不会有那个傻逼干这种事情，所以基本可以排除。

第二：由于有些业务等需要，机器需要同步时间服务器（在这个过程中可能会存在时间回拨，查了下我们服务器一般在10ms以内（2小时同步一次））。

解决方法

由于是分布在各各机器自己上面，如果要几台集中的机器（并且不做时间同步），那么就基本上就不存在回拨可能性了（曲线救国也是救国，哈哈），但是也的确带来了新问题，各各结点需要访问集中机器，要保证性能，百度的uid-generator产生就是基于这种情况做的（每次取一批回来，很好的思想，性能也非常不错）https://github.com/baidu/uid-generator。

如果到这里你采纳了，基本就没有啥问题了，你就不需要看了，如果你还想看看零度自己的思考可以继续往下看看（零度的思考只是一种思考 可能也不一定好，期待你的交流。），uid-generator我还没有细看，但是看测试报告非常不错，后面有空的确要好好看看。

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

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

当回拨时间小于15ms，就等时间追上来之后继续生成。

当回拨时间大于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挂了怎么办，怎么同步，的确值得商榷。可能会引入会引入很多新的小问题）。

总结

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