有一个问题,不管你怎么设计雪花算法,你的序列号长度都有可能不够。比如前面标准的是12比特,那么有没有可能并发非常高,以至于12比特在某一个特定的时刻机器上的比特全部用完了吗?
解决方案:
- 如果12比特不够,你就给更多比特,这部分比特可以从时间戳里面拿出来
- 如果还不够,那么就让业务方等待一下,到下一个时刻,自然又可以生成新的ID了,也就是时间戳变了,这也算是一种变相的限流
所以可以这样回答:
一般来说可以考虑加长序列号的长度,比如缩减时间戳,然后挪给序列号ID。当然也可以更加粗暴地将64位地ID改成96位地ID,那么序列号ID就可以有三四十位。不过彻底地兜底方案还是要有地,我们可以考虑引入类似限流地做法,在当前时刻地ID已经耗尽以后,可以让业务方等一下。我们的时间戳一般都是毫秒数,那么业务方最多就会等一毫秒。
这里也有个问题就是:如果业务方等一下会有什么问题?
业务方等待算是一个比较危险的方案,因为这可能导致大量业务方阻塞住,导致线程耗尽或协程耗尽之类的问题,不过如果是偶发性的序列号不够,那么问题不大,因为阻塞的业务方很快就能拿到ID。
那么如果序列号耗尽不是偶发性一个问题,是长期的问题,还是要考虑从业务角度切割,不同业务使用不同的ID生成,就不要共享了。又或者,逼不得已还是用96或128位的。
设想一个场景:分库分表是按照ID除以32的余数来进行的,那么如果你的业务非常低频,以至于每个时刻都只生成了尾号为1的ID,那么是不是所有的数据都分到了一张表里呢?
解决方案也很简单:
- 某一个时刻使用随机数作为起点,而不是每次从0开始计数
- 使用上一个序列号作为起点,比如上一个序列只分到了3,那么下一个时刻的序列号就从4开始