关于读者阅读“改良版雪花算法”后提出的几个共性问题的回复

你好呀，我是歪歪。

周一的时候不是发了《在开源项目中看到一个改良版的雪花算法，现在它是你的了。》这篇破文章嘛。

然后有好几个读者都提出了几个类似的问题，再写个续集，给大家解答一下。

我就喜欢这种和读者有来有回，相互拉扯的感觉。

突出一个“相互学习，共同进步。”

超前消费

首先大家都在纠结的一个点是，文章中提到的超前消费。

我还是把这个改良版本后的图拿过来：

我们先把“超前消费”这个问题框定在一个服务节点上。

假设序列号为 100 的服务节点上的序列号出现了“超前消费”的问题，这个 100 我是随便说的，反正就是代表我们整个系列号的中节点 ID 是固定的。

由于它是固定的，所以在接下来的讨论中，我们并不需要特别关注它。

当我们刨除了“节点ID”之后，那么只剩下 41 位的时间戳和 12 位的序列号：

时间戳在前面的文章中分析过，只是在服务启动的时候会获取一次。

那么我也假设当前的时间戳为 2023 年 08 月 11 日 10 点 55 分 00 秒 000 毫秒。

先说明一下，这个时间戳不考虑人为破坏，修改时区啥的动作，只考虑正常的时间回拨。

你要是考虑人为破坏了，那别玩了，你开玩笑，人心这玩意，是你程序能玩得过的？

好，基于现在的条件，请听题：

基于 Seata 改良版的雪花算法，节点 100 的初始 ID 是多少？

我们完全可以算出来嘛：

首先，第一位恒为 0，就不说了。

然后，节点ID（10位），100 的二进制：1100100。前面补 3 个 0，凑够 10 位，所以就是 0001100100。

接着，时间戳（41位），2023 年 08 月 11 日 10 点 55 分 00 秒 000 毫秒的时间戳为 1691722500000：

1691722500000-1588435200000=103287300000。

有的读者肯定就会问了：这个 1588435200000 是从哪里冒出来的呢？

别问，一问就不是真爱粉了。

前面的文章里面写了：

初始化的时候获取时间戳的代码是这样的：

总之，我们最终算出来的时间戳是 103287300000。

对应的二进制则是这样的：

1100000001100011001110001111110100000

这一串数字一共 37 位，在前面补 4 个 0，凑够 41 位就是这样的：

00001100000001100011001110001111110100000

最后，就是序列号了。

都说了是初始化的时候了，序列号肯定是 0 啊。

所以序列号就是 12 个 0：

000000000000

在程序里面的表现就是把时间戳左移 12 位，把序列号的位置给腾出来。

那么我们最终得到的一个 64 位的二进制就是这样的：

0000110010000001100000001100011001110001111110100000000000000000

歪师傅在给你上个图。

再把这个 64 位的二进制转化为 10 进制，就是这个数：

901142990254899200，就是节点 ID 为 100 的服务器在 2023 年 08 月 11 日 10 点 55 分 00 秒启动瞬间对应的初始化 ID。

听懂掌声。

有的读者肯定要说了：歪师傅，我们不是说超前消费的问题吗？

别急啊，前面不得给你铺垫铺垫，来得太猛我怕你受不了，现在正式说这个超前消费的问题。

现在铺垫完了，那么问题就来了：在我们此时的场景下，出现了什么情况，我们才说这是“超前消费”现象”？

是不是时间戳的最后一位变成了 1 的情况：

因为我们当前的时间是 2023 年 08 月 11 日 10 点 55 分 00 秒 000 毫秒。

但是分布式 ID 生成的时候，时间戳组成部分对应的时间是 2023 年 08 月 11 日 10 点 55 分 00 秒 001 毫秒。

快了 1 毫秒，超前消费 1 毫秒。

那么从程序的角度来看，什么时候会快上这 1ms 呢？

别问，问就不是真爱粉了。

前面的文章说过这个问题了：

就是说在序列号用完了的情况下。

那么序列号怎么才算是用完了呢？

也就是这种情况下，就算用完了：

但是需要注意的是，我们此时的真实时间还是 2023 年 08 月 11 日 10 点 55 分 00 秒 000 毫秒。

意思就是这一毫秒内，序列号从 0 递增到了 4095。

然后还是这一毫秒，还在继续申请 ID，那么序列号归 0，溢出位加到时间戳上，导致时间超前 1ms：

也就是说，只有 QPS 持续稳定在 4096/ms 之上，才有可能出现“超前消费”的情况。

4096/ms，注意我说的是 ms。

换算成秒是 409.6w/s。

QPS 持续稳定在 409.6w/s，你自己啥服务啊，有这么大流量吗，心里没点数？

而且，就算真的有这么大的流量，性能瓶颈一定不是在分布式 ID 生成器这里，前面一定有“高个子”顶着的。

也许你还是觉得看二进制不够直观，那我就给你来个直观的数据，让你感受一小小的震撼。

还是假设当前时间为 2023 年 08 月 11 日 10 点 55 分 00 秒 000 毫秒。

但是程序里面时间“超前消费”了一分钟，对应 2023 年 08 月 11 日 10 点 56 分 00 秒 000 毫秒。

那么按照前面我们的算法，此时对应的 64 位二进制为：

0000110010000001100000001100011010000000101000000000000000000000

对应 10 进制就是其 ID：

901142990500659200

用当前的这个 ID 减去我们之前算出来的 ID：

901142990500659200-901142990254899200=245760000

245,760,000，你自己数一数，2 亿多啊。

如果你想要把时间超前消费 1 分钟，需要持续在 409.6w/s 的流量下申请 2 亿多个流水号。

怎么样，有没有感受到一点点来自数据上的震撼。

所以，这个问题也就顺便回答了读者提出的另外一个问题。

如果当前真实时间是 2023-08 11 10:55:00:000。

而程序持续提前把时间消费到了 2023-08 11 10:56:00:000。

服务重启之后，时间是 2023-08 11 10:55:10:000。

那么由于获取到的时间戳是小于之前“提前消费”的时间戳，就是有可能生成之前重复的 ID。

是的，理论上可能，实际上，不可能会发生。

实际上可能会发生的时什么呢？

瞬时流量达到 4096/ms，出现毫秒级别的时间提前消费。

那么问题就来了：请问你能在毫秒级别完成重启吗？

听懂掌声。

时间戳和节点ID的位置

还有一个问的也很多的问题：为什么在改良版本里面，非要把时间戳和节点 ID 换位置，不换行不行？

看到这个问题的时候，我的回复是这样的：

我最开始想到的是，时间戳虽然只是在系统启动的时候获取一次，但是后续由于序列号一轮又一轮的摧残，还是会不断的被 +1。

那么把时间戳放在前面的话，会导致的现象就是时间戳一直在变化，中间的节点 id 又不会变化，会出现递增的时候 id 跨越非常大的情况出现吧。

比如就会出现这种情况：

节点 id 固定，固定的数据在前，id 跨度不会很大，更优雅一点，也就是这样的情况：

但是后来我想明白了，我的说法是错误的，因为在这种生成的 ID 不是单调递增的情况下：

中间跨度很大，很有可能有其他节点生成的序列号。

一旦在出现这种情况，那么就打破了 Seata 关于这次改造的底层设计，即页分裂的次数是有限次的，不考虑页合并的情况下，最多为 1024 次，整个过程最终是收敛的。

也就是这位同学在评论区提到这段话：

如果你看不懂这句话，说明你没看懂我前面发的《在开源项目中看到一个改良版的雪花算法，现在它是你的了。》这篇破文章，可以再瞅一眼。

为什么必须要有时间戳？

写到这里的时候，我突然又想明白了另外一个问题：

时间戳的 41 位初始值从 0 开始不行吗？

也就是这样：

我第一次看到这个问题想得是肯定不行，因为这是雪花算法的改良版本，雪花算法的基石就是基于时间，你连时间都不要了，这不是要革了命了吗？而且这样时间戳从 0 开始，那不就变成序列号了吗？

现在我突然想明白这个问题了。

为什么必须要有时间戳？

因为要考虑重启的情况啊。

你想，你第一次启动之后，如果没有时间戳在里面，从 0 开始一直递增，假设递增到了 999。

现在你的服务要重启了，请问，重启之后你的序列号是多少？

你的节点 ID 没变，也没有时间戳，只有个序列号，又没有地方存储重启之前的序列号是多少，那么这次是不是又得从 0 开始了。

哦豁，序列号重复。

谁看了不得说一句：哦豁，宝批龙，瓜起了涩。

啥，你问我“宝批龙”是什么意思？

没啥特别的，类似于“靓仔”。在川渝地区，就是打招呼，问好的一种意思。一般用来形容年轻的帅哥美女。比如你在重庆迷路了，问路的时候你就可以说：嘿宝批龙，你好，请问去朝天门怎么走。

代码

最后，Seata 里面的 IdWorker 类，加上注释一共也才 187 行，源码就在这里，你粘过去就能直接用：

https://github.com/seata/seata/blob/2.x/common/src/main/java/io/seata/common/util/IdWorker.java

另外你看文章的时候有没有感到一丝丝奇怪。

为什么我会把当前时间假设为 2023 年 08 月 11 日 10 点 55 分 00 秒 000 毫秒。

这个时间，有零有整的。

因为这个时间是五月天成都演唱会开始抢票的时间：

写篇文章就当许个愿吧，希望我能抢到两张票，和 Max 同学一起去看五月天。

然后，一起唱《干杯》、《突然好想你》、《知足》、《倔强》、《温柔》、《后来的我们》、《恋爱ing》、《志明与春娇》...

一起去找高中时劣质 MP3 中传出的全损音质和在 KTY 时一定要扯着嗓子唱的《噢买尬》和《终结孤单》。

求求了。

好了，如果本文对你有一点点帮助的话，点个免费的赞，求个关注，不过分吧？