MQ消息积压如何处理
优化性能避免消息积压
MQ本身的处理能力是远大于业务系统的处理能力的、主流消息队列的单个节点、消息收发的性能可以达到每秒几万到几十万的水平、水平扩展Broker的实例数可以成倍的提升处理能力、应该更多的关注在消息的收发两端、让业务代码和MQ配合、达到最佳性能
- 发送端性能优化
若代码发送消息的性能较弱、很可能是发MQ之前的逻辑太耗时导致、一般设置合理的并发和批量大小、就可以达到很好的性能
MQ的完整交互: P -> Broker -> R
假设单线程发送、每秒处理请求 1000ms/1ms*1条/1ms = 1000 条msg、并不能发挥MQ的实力
- 增加batch大小、2. 并发请求 都可以提升性能
对于关注延时的RPC系统、可以选择增加并发量
对于关注吞吐量的离线分析系统、它不关心时延、可以选择批量发送
- 消费端性能优化
若消费的速度跟不上msg生产的速度、MQ存储被填满之后就会造成无法提供服务、消息丢失、对于整个系统都是严重故障
消费端的性能优化除了优化消费业务逻辑之外、还可以通过简单的水平扩容来增加消费端的并发数来提高整体的消费性能
注意
在扩容consumer实例的同时、必须同步扩容主题中的分区(队列)数量、确保consumer的实例数和分区数相等、因为每个分区只支持单线程消费
- 消息积压了如何处理？
- 若单位时间内发送的消息增多、最快的办法就是通过扩容消费端的实例来提升总体的消费能力，或者可以通过系统降级、减少生产者发送数据
- 若是消费和生产速度都无明显变化、需要检查消费端、数不胜数消费失败导致反复消费
- 若是消费变慢、可以快速排查消费日志、看看消费线程是不是卡着不动了
疑问点记录
假如、有一个topic、Q为5、Broker为2
有3个生产者实例、如何对应到5个Q ?
不用对应、随便发或者指定Q选取规则每个消费组都是单独的订阅、拥有队列的全部消息、消费完后消息不会删除
多个消费组订阅同一个topic彼此不影响、
eg. 消费组G0 | G1 、G0挂掉、积压很多消息、对G1也没有任何影响消费位置
每个消费组会维护一组消费位置、每个队列对应一个消费位置、并且消费位置和消费者无关、保存在服务端如何实现单个队列的并行消费
eg. MQ中有10条消息、对应的编号是0-9、当前消费位置是5、同时有5、6、7三个消费者拉取消息、5、6、7三个消息给每个消费者一人一条、理想情况下、3个消费者成功响应、消费位置更新为8 实现并行消费
假如5卡着某个环节不动了、位置5就是消息空洞、为了避免整个队列卡住、将5复制到一个重试队列、然后更新消费位置、消费时优先给出重试队列的数据
这是实现并行消费的一种实现方式、但是开销很大、不应该作为常规手段、若需要增加消费者的并发数、还是需要扩容队列数