最近在研究分布式框架的组件和整体设计思路。所有的问题,一旦涉及分布式难度就呈几何倍数的提升。包括最常见的ID生成也是,单机情况下,使用数据库自增ID、UUID都是简单易行的选择
目前创新互联公司已为超过千家的企业提供了网站建设、域名、虚拟空间、绵阳服务器托管、企业网站设计、温岭网站维护等服务,公司将坚持客户导向、应用为本的策略,正道将秉承"和谐、参与、激情"的文化,与客户和合作伙伴齐心协力一起成长,共同发展。
但在分布式环境下,就需要考虑同业务部署多套以后,ID重复的问题。使用数据库则数据库容易成为瓶颈,使用UUID又没有顺序,数据库集成又会遇到递增步长等问题。最后,数据库(也可使用redis)号段生成器和snowFlake就成为了目前分布式ID生成器的主流
我所知大部分互联网公司的分布式ID生成器,其实都是一个网络服务或集群,单独部署。其他应用程序通过网络去获取分布式的全局唯一ID。使用网络服务的方式,好处显而易见,就是方便集中管理,只要生成器设计的没问题,基本ID就能保证整体趋势是递增的。坏处就是获取效率被明显降低了
另外针对我司来说,由于项目的性质,采用分布式ID生成器,对开发和上线部署及其后期的运维都会带来一定的麻烦。毕竟上线后,项目的管理权就不在我们手上了,所以为了保证分布式ID生成器的稳定性,尽量不采取分布式ID生成中心的策略。于是,留给我的选择就只剩下了SnowFlakeID(雪花ID)了。
SnowFlake是twitter公司内部分布式项目采用的ID生成算法,开源后广受国内大厂的好评。由这种算法生成的ID,我们就叫做SnowFlakeID
SnowFlakeID的最大的特性就是天然去中心化,通过时间戳、工作机器编号两个变量进行配置后,通过SnowFlake算法会生成唯一的递增ID。在任何机器上,只要保证工作机器编号不同,就可以确保生成的ID唯一,且整体趋势是递增的
Snowflake的结构如下(每部分用-分开):
0 - 0000000000 0000000000 0000000000 0000000000 0 - 0000000000 - 000000000000
第一段1位为未使用,永远固定为0
第二段41位为毫秒级时间(41位的长度可以使用69年)
第三段10位为workerId(10位的长度最多支持部署1024个节点)
第三段12位为毫秒内的计数(12位的计数顺序号支持每个节点每毫秒产生4096个ID序号)
如果按照1024的满节点(1个节点就是1个部署的服务)计算,每毫秒可生成的ID序号有1024*4096=4194304个,足以满足现在绝大多数的业务情况
算法的核心如下
((当前时间 - 服务时间) << timestampLeftShift)
| (机器ID << workerIdShift)
| sequence;
服务时间指的是服务的开发时间,即第一个正式ID产生的时间。由于SnowFlakeID最长可用69年(因为只有41个bit,41个bit的最大值换算成年就是69年)。所以服务时间越贴近上线时间,则该算法可用时间越长。
其中sequence为递增序列,当前时间戳和上一ID生成时间戳一致时,sequence就递增1,直到4096为止。
SnowFlake很好,分布式、去中心化、无第三方依赖。但它并不是完美的,由于SnowFlake强依赖时间戳,所以时间的变动会造成SnowFlake的算法产生错误。
时钟回拨:最常见的问题就是时钟回拨导致的ID重复问题,在SnowFlake算法中并没有什么有效的解法,仅是抛出异常。时钟回拨涉及两种情况①实例停机→时钟回拨→实例重启→计算ID ②实例运行中→时钟回拨→计算ID
手动配置:另一个就是workerId(机器ID)是需要部署时手动配置,而workerId又不能重复。几台实例还好,一旦实例达到一定量级,管理workerId将是一个复杂的操作。
ID生成器一旦不可用,可能造成所有数据库相关新增业务都不可用,影响太大。所以时钟回拨的问题必须解决。
造成时钟回拨的原因多种多样,可能是闰秒回拨,可能是NTP同步,还可能是服务器时间手动调整。总之就是时间回到了过去。针对回退时间的多少可以进行不同的策略改进。一般有以下几种方案:
if (refusedSeconds <= 5) {
try {
//时间偏差大小小于5ms,则等待两倍时间
wait(refusedSeconds << 1);//wait
} catch (InterruptedException e) {
e.printStackTrace();
}
currentSecond = getCurrentSecond();
}else {//时钟回拨较大
//用其他策略修复时钟问题
}
List<Long> uidList = uidProvider.provide(lastSecond.incrementAndGet());
实例运行中→时钟回拨→计算ID
的情况。而实例停机→时钟回拨→实例重启→计算ID
的情况,可以通过实例启动的时候,采用未使用过的workerId来完成。只要workerId和此前生成ID的workerId不一致,即便时间戳有误,所生成的ID也不会重复。UidGenerator采取的就是这种方案,但这种方案又必须依赖一个存储中心,不管是redis、MySQL、zookeeper都可以,但必须存储着此前使用过的workerId,不能重复。尤其是在分布式部署Id生成器的情况下,更要注意用一个存储中心解决此问题。其实该处的方案和时钟回拨的第四个方案是一致的,每次重启实例的时候,自动的查找workerId使用,不依赖手动配置。且自查找的workerId不会重复。方便管理。
文章标题:分布式SnowFlakeID(雪花ID)原理和改进优化
本文链接:https://www.cdcxhl.com/article2/jcihic.html
成都网站建设公司_创新互联,为您提供网站策划、品牌网站设计、面包屑导航、服务器托管、响应式网站、网站排名
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联