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