下游消费系统如果宕机了,导致几百万条消息在消息中间件里积压,此时怎么处理?
你们线上是否遇到过消息积压的生产故障?如果没遇到过,你考虑一下如何应对?
首先要找到是什么原因导致的消息堆积,是Producer太多了,Consumer太少了导致的还是说其他情况,总之先定位问题。然后看下消息消费速度是否正常,正常的话,可以通过上线更多consumer临时解决消息堆积问题。
如果Consumer和Queue不对等,上线了多台也在短时间内无法消费完堆积的消息怎么办?
• 准备一个临时的topic
• queue的数量是堆积的几倍
• queue分布到多Broker中
• 上线一台Consumer做消息的搬运工,把原来Topic中的消息挪到新的Topic里,不做业务逻辑处理,只是挪过去
• 上线N台Consumer同时消费临时Topic中的数据
• 改bug
• 恢复原来的Consumer,继续消费之前的Topic
堆积时间过长消息超时了?
RocketMQ中的消息只会在commitLog被删除的时候才会消失,不会超时。也就是说未被消费的消息不会存在超时删除这情况。
堆积的消息会不会进死信队列?
不会,消息在消费失败后会进入重试队列(%RETRY%+ConsumerGroup),
相关文章
- 01-14消息的存储-RocketMQ知识体系3
- 01-14python-如何在WSGI处理程序中捕获“ [Errno 32]损坏的管道”
- 01-14kafka分布式的情况下,如何保证消息的顺序?
- 01-14Kafka 如果丢了消息,怎么处理的?
- 01-14我的架构梦:(八十八)消息中间件之Kafka如何保证幂等性
- 01-14我的架构梦:(九十八)消息中间件之RocketMQ的高可用机制——消息发送高可用
- 01-14从入门到入土(三)RocketMQ 怎么保证的消息不丢失?
- 01-14android-如何在聊天应用上使用不同类型的消息来组织RecyclerView?
- 01-14如何捕获窗体获得焦点和失去焦点的消息? ( 积分: 50 )
- 01-14HTTP请求的URL中如何处理特殊字符