1. 为什么产生音讯沉积？
大多是因为 Consumer 出问题了，没有及时发现，或者故障复原须要较长的工夫，导致大量音讯积压在 MQ 中。
2. 音讯沉积会有什么结果呢？
2.1 音讯被抛弃
例如 RabbitMQ 有一个音讯过期工夫 TTL，过期的音讯会被扔掉，这样音讯就彻底没有了。
2.2 磁盘满了
如果沉积量太大，可能导致磁盘空间有余，那么新音讯就进不来了。
2.3 海量音讯待处理
如果音讯没过期，并且磁盘空间也够用，那么就是产生海量音讯期待被生产，Consumer 的噩梦。
3. 如何应答呢？
3.1 音讯被抛弃的状况
首先，要实现避免音讯过期问题，不应该设置过期工夫。
如果就是设置了过期工夫，导致了音讯失落，怎么补救呢？
那就只能在夜深人静，趁着访问量最低的时候，写一个长期程序来补音讯了。
例如有订单音讯丢了，那就须要找出哪些订单音讯丢了，而后从新发到队列。
3.2 磁盘有余的状况
零碎通常都是有监控的，达到空间阈值时就会发警报，这时就要马上解决了。
例如，在其余机器上创立长期的音讯队列，再写一个长期的 Consumer，作为音讯的直达，把音讯积压队列中的音讯取出来，放到长期队列外面去。
疾速疏散积压的音讯，让磁盘空间恢复正常程度。
3.3 疾速解决海量积压音讯
Consumer 恢复正常之后，面对堆积如山的音讯，怎么解决呢？
如何依照之前失常状况解决的话，猴年马月能力生产完，此过程中还有新音讯在一直进来。
例如，积压了 100 万条，有 3 个 Consumer，每一个每秒能解决 200 条，3 个 Consumer 每秒一共能解决 600 条。
大略须要一个多小时能力解决完。
这一个多小时又会积压多少新的音讯呢？
所以失常解决必定不行，须要提速。
例如 Kafka，这个音讯积压的 Topic 有 3 个 Partition，那最多就能用 3 个 Consumer，所以减少 Consumer 没有用。
还是能够应用 长期队列 的形式。
新建一个 Topic，设置为 20 个 Partition
Consumer 不再解决业务逻辑了，只负责搬运，把音讯放到长期 Topic 中
这 20 个 Partition 能够有 20 个 Consumer 了，它们来解决原来的业务逻辑。
这 20 个 Consumer 每秒一共能解决 4000 条了，这样几分钟就能够解决完积压的 100 万条。
这几分钟新来的音讯也不会太多，所以很快就能够恢复正常程度，之后，再把整体构造复原为原来的模式。
小结一下，音讯积压还是比拟麻烦的，最好是提前防备，做好硬件和音讯零碎的衰弱监控。如果呈现音讯失落，就要人工查找失落的音讯，而后补上。在生产不过去的时候，能够思考应用长期队列作为直达，晋升解决能力。
举荐浏览
OAuth2 图解
轻松了解 Kubernetes 的外围概念
开发者必须要理解的架构技术趋势：Service Mesh