住房和建设厅官方网站,滨州网站建设求职简历,视频网站建设技术方案书,网站建设和安全管理制度uuid#xff0c;jdk自带#xff0c;但是数据库性能差#xff0c;32位呀。 mysql数据库主键越短越好#xff0c;Btree产生节点分裂#xff0c;大大降低数据库性能#xff0c;所以uuid不建议。
redis的自增#xff0c;但是要配置维护redis集群#xff0c;就为了一个idjdk自带但是数据库性能差32位呀。 mysql数据库主键越短越好Btree产生节点分裂大大降低数据库性能所以uuid不建议。
redis的自增但是要配置维护redis集群就为了一个id还要引入一套redis。费事成本高。 如果有序自增别人就知道你的业务量多少了。
雪花算法
分布式自增id算法snowflake京东还有好多大厂使用这个。 经测试每秒能产生26w个自增可以排序的id 1.生成id能按照时间有序生成 2.生成id结果是一个64bit大小的整数为一个Long型转换成字符串长度最多19 3.分布式系统内不会产生id碰撞由datacenter和worderId作区分并且效率高。
雪花算法几个核心组成部分 1bit符号位不用因为二进制中最高位是符号位1表示负0表示正。生成的id是正数所以是0. 5位机房id5位机器id 一毫秒内只能生成4095如果超过只能到下一秒了需要获取下一个时间戳
雪花算法的原理就是生成一个的 64 位比特位的 long 类型的唯一 id。
最高 1 位固定值 0因为生成的 id 是正整数如果是 1 就是负数了。 接下来 41 位存储毫秒级时间戳2^41/(1000606024365)69大概可以使用 69 年。 再接下 10 位存储机器码包括 5 位 datacenterId 和 5 位 workerId。最多可以部署 2^101024 台机器。 最后 12 位存储序列号。同一毫秒时间戳时通过这个递增的序列号来区分。即对于同一台机器而言同一毫秒时间戳下可以生成 2^124096 个不重复 id。
如何使用整合springboot即可 hutool工具包
雪花算法源码
判断是否时钟回拨回拨抛异常不做处理 如果是这个时间第一次sequence0如果同一个时间有其他进入则sequence1 sequenceMask计算这个计算就是和12个1做与运算当你小于4095时后还是你自己当大于的时候比方是4096计算后就是0如果并发特别高1毫秒产生的大于4096阻塞到下一毫秒。通过while循环等一下等到下一毫秒然后变成下一个时间段了。
真正自己代码会减掉一个自己的系统初始时间可以让我们时间更长 通过zookeeper生成机器id 雪花服务注册到nacos注册中心
时钟回拨问题
雪花算法源码里面通过判断时间大小来判断是否发生时间回拨如果发生抛异常拒绝生成。这里没有做任何时钟回拨处理所以线上机器不要动。
如何处理时钟回拨问题呢
雪花算法源码没有解决真的线上不能使用需要修改。才能达到高并发高可用高可扩展。
第一种解决方法我们可以加个容忍时间设置3ms如果发生时钟回拨我们用LockSupport锁来睡一下睡上最大容忍时间3ms然后再去看一下有没有时钟回拨问题。如果还是有问题呢我们要通过人为干预解决了
第二种解决方法雪花算法10位机器是可以控制的我们用备用机解决
回拨时间长短如果短等待一会儿。 如果时间适中可以将最近的数据时间段每一毫秒的maxId数据保存起来在他最后面开始。 如果时间再长雪花算法10位机器是可以控制的我们用备用机解决重试其他机器换一台机器。下次再走到已经过了时间没有回拨问题了。 如果时间更长机器下线不能用了人为解决吧。调用nacos服务下限api将这台机器直接下线。同步发送短信告知运维。
百度开源的 UidGenerator 是基于Java语言实现的唯一ID生成器是在雪花算法 snowflake 的基础上做了一些改进解决了时钟回拨问题。
美团Leaf
基于雪花算法进行修改封装。
工作进程怎么办1024台怎么维护 分布式主键中间件获取id由他区分工作进程用美团的Leaf服务Leaf也是高可用负载均衡 保证leaf也是不同id0-1023zookeeper有序节点启动leaf一直能扩展到1023.
Leaf需要依赖zookeeper顺序节点通过RPC去Leaf中获取id
还有就是解决时钟回拨问题
Leaf-snowflake 方案
Leaf-segment 方案可以生成趋势递增的 ID同时 ID 号是可计算的不适用于订单 ID 生成场景比如竞对在两天中午 12 点分别下单通过订单 id 号相减就能大致计算出公司一天的订单量这个是不能忍受的。面对这一问题我们提供了 Leaf-snowflake 方案。
Leaf-snowflake不同于原始snowflake算法地方主要是在workId的生成上Leaf-snowflake依靠Zookeeper生成workId也就是上边的机器ID占5比特 机房ID占5比特。Leaf中workId是基于ZooKeeper的顺序Id来生成的每个应用在使用Leaf-snowflake时启动时都会都在Zookeeper中生成一个顺序Id相当于一台机器对应一个顺序节点也就是一个workId。
Leaf-snowflake 方案完全沿用 snowflake 方案的 bit 位设计即是 “1411012” 的方式组装 ID 号。对于 workerID 的分配当服务集群数量较小的情况下完全可以手动配置。Leaf 服务规模较大动手配置成本太高。所以使用 Zookeeper 持久顺序节点的特性自动对 snowflake 节点配置 wokerID。Leaf-snowflake 是按照下面几个步骤启动的
启动 Leaf-snowflake 服务连接 Zookeeper在 leaf_forever 父节点下检查自己是否已经注册过是否有该顺序子节点。
如果有注册过直接取回自己的 workerIDzk 顺序节点生成的 int 类型 ID 号启动服务。
如果没有注册过就在该父节点下面创建一个持久顺序节点创建成功后取回顺序号当做自己的 workerID 号启动服务。 弱依赖 ZooKeeper 除了每次会去 ZK 拿数据以外也会在本机文件系统上缓存一个 workerID 文件。当 ZooKeeper 出现问题恰好机器出现问题需要重启时能保证服务能够正常启动。这样做到了对三方组件的弱依赖。一定程度上提高了 SLA
启动Leaf-snowflake模式也比较简单启动本地ZooKeeper修改一下项目中的leaf.properties文件关闭leaf.segment模式启用leaf.snowflake模式即可。
leaf.namecom.sankuai.leaf.opensource.test
leaf.segment.enablefalse
leaf.snowflake.enabletrue
leaf.snowflake.zk.address127.0.0.1
leaf.snowflake.port2181注意在启动项目之前请保证已经正常启动zookeeper
解决时钟问题
因为这种方案依赖时间如果机器的时钟发生了回拨那么就会有可能生成重复的 ID 号需要解决时钟回退的问题。 参见上图整个启动流程图服务启动时首先检查自己是否写过 ZooKeeper leaf_forever 节点
若写过则用自身系统时间与 leaf_forever/ s e l f 节点记录时间做比较若小于 l e a f f o r e v e r / {self} 节点记录时间做比较若小于 leaf_forever/ self节点记录时间做比较若小于leafforever/{self} 时间则认为机器时间发生了大步长回拨服务启动失败并报警。
若未写过证明是新服务节点直接创建持久节点 leaf_forever/${self} 并写入自身系统时间接下来综合对比其余 Leaf 节点的系统时间来判断自身系统时间是否准确具体做法是取 leaf_temporary 下的所有临时节点 (所有运行中的 Leaf-snowflake 节点) 的服务 IPPort然后通过 RPC 请求得到所有节点的系统时间计算 sum (time)/nodeSize。
若 abs (系统时间 - sum (time)/nodeSize ) 阈值认为当前系统时间准确正常启动服务同时写临时节点 leaf_temporary/${self} 维持租约。
否则认为本机系统时间发生大步长偏移启动失败并报警。
每隔一段时间 (3s) 上报自身系统时间写入 leaf_forever/${self}。
由于强依赖时钟对时间的要求比较敏感在机器工作时 NTP 同步也会造成秒级别的回退建议可以直接关闭 NTP 同步。要么在时钟回拨的时候直接不提供服务直接返回 ERROR_CODE等时钟追上即可。或者做一层重试然后上报报警系统更或者是发现有时钟回拨之后自动摘除本身节点并报警如下
//发生了回拨此刻时间小于上次发号时间 if (timestamp lastTimestamp) { long offset lastTimestamp - timestamp; if (offset 5) { try { //时间偏差大小小于5ms则等待两倍时间wait(offset 1);//waittimestamp timeGen(); if (timestamp lastTimestamp) { //还是小于抛异常并上报throwClockBackwardsEx(timestamp);} } catch (InterruptedException e) { throw e;}} else { //throwthrowClockBackwardsEx(timestamp);}} //分配ID从上线情况来看在 2017 年闰秒出现那一次出现过部分机器回拨由于 Leaf-snowflake 的策略保证成功避免了对业务造成的影响。
