消息积压的直接原因,要从两个角度来看,分别是消费端和生产端,对于那么这两端,我们分别说下,如何处理这个消息,避免消息积压
如果是想要询问消息队列本身的能力,消息队列因为本身不和业务耦合
消息队列的处理能力也会远大于业务系统的处理能力
即使不行,还可以通过水平扩展Broker的实例数来成倍的提升处理能力
所以最终的还是在消息的发收两端,进行处理性能问题
1.发送端的性能
发送端的性能,和消息队列的关系不大,因为都是发送端在完成业务逻辑之后,在发送的消息,如果发送的性能低下,需要检查一下,是不是业务逻辑耗时较多
我们发送的过程中,一般都是Producer发送Broker,Broker收到响应,是一个完整的交互流程
我们需要提高我们的发送能力,我们可以选择批量发送或者增加发送的并发
关于这两种解决方案的选择,很简单,只要符合性能就可以了
比如,消息发送方是一个微服务,接收并处理在线业务,自然,我们直接发送就可以了,因为一般的RPC都直接支持并行的发送
再比如,如果是一个离线的分析系统,那么不关心时延,只关心整个系统的吞吐量,那么这种情况更加适合批量发,因为可以批量的从数据库读取数据,然后批量的发送消息,使用少量的并发获得高的吞吐量
2.消费端的性能
大部分的性能一般都出现在消费端,如果消费端的速度跟不上发送端的速度,那么就会消息积压,而长期的积压就是整个系统问题的来源,我们需要保证消费端的性能高于生产端
消费端的性能除了优化业务的逻辑,还可以通过水平扩容的方式,增加整体的并发数来提升性能,这样我们在扩容Consumer的数量的同时,同步扩容主题中的分区数量,保证两者数量相同,毕竟一个分区同时只能被一个消费者消费
还要避开一个雷区
这个雷区所示如上,有些代码经常是在接收到消息后,直接放在一个内存队列中,然后确认消费
这种问题,就是收消息的节点发生了宕机,在内存队列中还没来的及消费的消息就会丢失
那么在消费者消费的时候,我们需要排查积压的原因,能导致积压了一般要么是发送变快了,要么是消费方变慢了
一般,大部分的消息队列都内置了监控的功能,我们可以根据监控来查清是什么原因,如果是赶上大促,短时间不能可能优化消费端的代码,所以我们可以考虑扩容消费端的实例来进行提升总体的消费能力
如果短时间没有足够的服务器,我们还可以将系统降级,通过关闭一些不重要的业务,减少发送方的数据量,来维持服务
以及检查消费端,是不是出现了上面线程的死锁或者卡在某些资源上了
还有一种不常见的情况,就是两端的速度并没有什么变化,这时候就需要检查消费端,是不是出现了消费失败导致一条消息反复消费的情况
本章中,我们主要说了两个问题,一个是消息队列的收发两端优化问题,防止消息积压,一个是消息发生积压后,如何处理
优化消息收发消息,预防积压的手段有两种,增加批量或者增加并发,在发送端的两个方法都可以使用,在消费端需要注意的是,并发需要同步扩容分区数量
对于积压问题,最后还是通过水平扩容来增加Consumer的实例数量
是否可以通过批量消费的手段来提升消费性能,什么样场景适合这种方法?
可以使用批量消费的手段提升性能,但是需要消费端具有良好的事务回滚机制,或者说整体系统不介意丢失部分数据,所以一些日志类型的场景很适合利用批量消费来增加吞吐量