分库分表 序列号耗尽 数据堆积

简介: 【7月更文挑战第15天】

有一个问题,不管你怎么设计雪花算法,你的序列号长度都有可能不够。比如前面标准的是12比特,那么有没有可能并发非常高,以至于12比特在某一个特定的时刻机器上的比特全部用完了吗?

解决方案:

  • 如果12比特不够,你就给更多比特,这部分比特可以从时间戳里面拿出来
  • 如果还不够,那么就让业务方等待一下,到下一个时刻,自然又可以生成新的ID了,也就是时间戳变了,这也算是一种变相的限流

所以可以这样回答:

一般来说可以考虑加长序列号的长度,比如缩减时间戳,然后挪给序列号ID。当然也可以更加粗暴地将64位地ID改成96位地ID,那么序列号ID就可以有三四十位。不过彻底地兜底方案还是要有地,我们可以考虑引入类似限流地做法,在当前时刻地ID已经耗尽以后,可以让业务方等一下。我们的时间戳一般都是毫秒数,那么业务方最多就会等一毫秒。

这里也有个问题就是:如果业务方等一下会有什么问题?

业务方等待算是一个比较危险的方案,因为这可能导致大量业务方阻塞住,导致线程耗尽或协程耗尽之类的问题,不过如果是偶发性的序列号不够,那么问题不大,因为阻塞的业务方很快就能拿到ID。
那么如果序列号耗尽不是偶发性一个问题,是长期的问题,还是要考虑从业务角度切割,不同业务使用不同的ID生成,就不要共享了。又或者,逼不得已还是用96或128位的。

设想一个场景:分库分表是按照ID除以32的余数来进行的,那么如果你的业务非常低频,以至于每个时刻都只生成了尾号为1的ID,那么是不是所有的数据都分到了一张表里呢?

解决方案也很简单:

  • 某一个时刻使用随机数作为起点,而不是每次从0开始计数
  • 使用上一个序列号作为起点,比如上一个序列只分到了3,那么下一个时刻的序列号就从4开始
目录
打赏
0
7
8
1
108
分享
相关文章
服务Down机了,线程池中的数据如何保证不丢失?
在分布式系统与高并发应用开发中,服务的稳定性和数据的持久性是两个至关重要的考量点。当服务遭遇Down机时,如何确保线程池中处理的数据不丢失,是每一位开发者都需要深入思考的问题。以下,我将从几个关键方面分享如何在这种情况下保障数据的安全与完整性。
86 2
服务重启了,如何保证线程池中的数据不丢失?
【8月更文挑战第30天】为确保服务重启时线程池数据不丢失,可采用数据持久化(如数据库或文件存储)、使用可靠的任务队列(如消息队列或分布式任务队列系统)、状态监测与恢复机制,以及分布式锁等方式。这些方法能有效提高系统稳定性和可靠性,需根据具体需求选择合适方案并进行测试优化。
293 5
异步任务处理系统问题之实现负载随机分片的问题如何解决
异步任务处理系统问题之实现负载随机分片的问题如何解决
消息队列 MQ产品使用合集之Broker内存瞬间增大一倍一般是什么导致的
阿里云消息队列MQ(Message Queue)是一种高可用、高性能的消息中间件服务,它允许您在分布式应用的不同组件之间异步传递消息,从而实现系统解耦、流量削峰填谷以及提高系统的可扩展性和灵活性。以下是使用阿里云消息队列MQ产品的关键点和最佳实践合集。
中间件数据丢失与重复消费
中间件数据丢失与重复消费
60 1
高并发缓存队列防止溢出解决方案
高并发缓存队列防止溢出解决方案
275 0
MQ-消息堆积-业务线程阻塞案例分析
使用arthas定位【MQ-消息堆积】的原因
262 1
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等