匠心零度 转载请注明原创出处,谢谢!
缘起
为什么会突然谈到分布式唯一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挂了怎么办,怎么同步,的确值得商榷。可能会引入会引入很多新的小问题)。
总结
所以选择类似百度的那种做法比较好,集中之后批取,零度的思考虽然思考了,但是从基础组件来看并不是特别合适,但是也算一种思路吧。期待与大佬们的交流。
领取专属 10元无门槛券
私享最新 技术干货