wordpress点注册后一直不出来,优化快速排名教程,手游推广渠道和推广方式,现在的网站怎样做推广雪花算法原理#xff08;设计原理、优缺点、如何改造它、以及应用#xff09; 雪花算法源码为什么雪花算法是 64 位#xff1f;为什么时间戳是41位#xff1f;占雪花算法的 43-47 bit 位为什么工作台最大只支持设置 31 #xff1f;工作台设置成了 63 会导致什么后果#… 雪花算法原理设计原理、优缺点、如何改造它、以及应用 雪花算法源码为什么雪花算法是 64 位为什么时间戳是41位占雪花算法的 43-47 bit 位为什么工作台最大只支持设置 31 工作台设置成了 63 会导致什么后果同机器位只支持最大 5 bit位同理数据累加位只支持最大 12 bit位雪花算法优点雪花算法缺点雪花算法改造小咸鱼的技术窝 雪花算法源码
雪花算法是一个开源的分布式生成唯一自增 Id 的这么一个工具类。主要的源码如下
/*** 常规雪花算法1-42bit位时间戳 共 42 位* 43-47 bit位数据中心ID 共 5 位最大支持 2 的 5 次方减 1 个数据中心* 48-52 bit位工作台ID 共 5 位最大支持 2 的 5 次方减 1 个工作台* 53-64 bit位累加数ID 共 12 位最大支持 2 的 12 次方*/
public synchronized long nextId() {long timestamp timeGen();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;}lastTimestamp timestamp;return ((timestamp - twepoch) 22)| (datacenterId 17)| (workerId 12)| sequence;
}都知道雪花算法结构如下不知道读者有没有想过 为什么雪花算法是 64 位的为什么工作机器最大为 5 位反正我第一次接触雪花算法的时候就想过这些问题。
1-42bit位时间戳 共 42 位43-47 bit位数据中心ID 共 5 位最大支持 2 的 5 次方减 1 个数据中心48-52 bit位工作台ID 共 5 位最大支持 2 的 5 次方减 1 个工作台53-64 bit位累加数ID 共 12 位最大支持 2 的 12 次方
为什么雪花算法是 64 位
因为雪花算法返回的是一个 long 类型的值换算成二进制就是最大 64 位
为什么时间戳是41位占雪花算法的 43-47 bit 位
随便一个时间戳转换成二进制就是 41 位
log.info(时间戳{} 位, Long.toBinaryString(System.currentTimeMillis()).length());且雪花算法中的时间戳左移了 22 位加上时间戳本身的 41 位加起来就有 63 位了加上第一位的符号位就是 64 位正好等于 long 类型的 64 位。完美利用 long 类型。
为什么工作台最大只支持设置 31
时间戳达到了最大值41 位时间戳 bit 位全是 1留了后 22 位全是 0由于或运算运算位有 1 就是 1所以说这个 22 位算是留给累加数、工作台、数据中心的有效左移位超过这个有效左移位就会出现生成重复 id 的情况出现。 111111111111111111111111111111111111111110000000000000000000000 工作台达到最大值 3131换二进制为11111左移22位后会得到如下一个二进制数位数不足63位前面用0补齐 000000000000000000000000000000000000000001111100000000000000000 最终得到的运算结果就是这个 111111111111111111111111111111111111111111111100000000000000000 工作台设置成了 63 会导致什么后果
63对应的二进制是 6个1111111参与的运算结果和工作台设置成31得到的结果一样就有产生的重复 id 的风险了。因此这也是工作台最大只支持 5 bit 位的原因
同机器位只支持最大 5 bit位
在时间戳、工作台按最大值运算后留给数据中心的有效运算位只有 17 位了然后数据中心又左移了12 位留给数据中心的参与运算的bit就只有5位了17-125。同理如果数据中心设置成63也会有生成重复id的风险出现
同理数据累加位只支持最大 12 bit位
在时间戳、机器位、工作台按最大值左移后留给累加数的有效位只有12bit位了63-41-5-512看我下图圈绿的地方这个就是有效bit位。
雪花算法优点
按照官方来说就是 不需要搭建服务集群代码逻辑非常简单同一毫秒内订单ID的序列号自增。同步锁只作用于本机机器之间互不影响每毫秒可以生成4百万个订单ID 对比Mysql自增主键 一般雪花算法用于生成订单ID相比于 Mysql 自增主键来说Mysql 自增ID是不是很容易看出你的销量做个差值计算就好了 对比UUID UUID是无序的订单ID都加索引在你插入数据的时候维护B树很好性能需要频繁的调整叶子结点的数据还会导致页分裂。简而言之就是性能不高而雪花算法性能高低延迟 雪花算法缺点
由于时间戳占生成id的41 bit位且这个时间戳是根据服务器时间生成的一旦服务器时间回拨了一下你就嗝屁了可能会生成重复的 id
雪花算法改造
基于基因法改造案例如下详情点击跳转 一文搞懂分库分表算法通俗易懂基因法、一致性 hash、时间维度 //41 bit 位时间戳5 bit 位数据中心5 bit 机器位5 bit累加位7 bit 用户基因位long orderId ((timestamp - twepoch) 22)| (datacenterId 17)| (workerId 12)| (sequence 7)| uid;小咸鱼的技术窝
关注不迷路分享更多技术干货B站、CSDN、微信公众号都是小咸鱼的技术窝更多详情在主页
