1.问题背景
kafka百万消息积压告警,通过监控观测到实时数据topic的16个分区的消息积压量基本都在百万级别,并且也收到了多个企业的反馈,实时订单数据推送延迟在两三个小时左右。
2.问题分析
首先查看服务器日志,观察消息是否在正常消费,是否存在报错或者请求超时的情况。如果存在大量的请求超时或异常报错会导致服务器处理消息的能力减弱。排查了日志发现消费是在正常进行。其次在观察消息积压的时间段是否与订单的高峰期时间段吻合,结果发现积压的时间是吻合的。基本上可以确定是由于业务量的突增、订单数据的增大,以及对接的第三方企业逐渐增多,消息的生产端产量增加,生产速率与消费速率无法取得动态平衡,导致消息积压。
3.问题解决
3.1.服务器扩容
目前现状:服务器的节点是8个,kafka的分区是16个。
由于一个消费者实例只能消费一个分区,所以服务器扩容的最大节点数是16个,服务器扩容可以提高一倍的消费速率,但这就是从节点数来提高消费能力的极限了。临时通过动态扩容可以解决消息积压的问题。
3.2.消费端的优化
3.2.1.从kafka拉取消息是批量的,通过消息监听机制拿到的消息是逐条来消费,消费成功之后提交ack偏移量,注意这个提交是同步提交的。由于我们系统的kafka的版本比较老,并不支持ack异步提交的api,所以需要考虑使用别的方式来达成异步提交ack的目的。由此产生的优化点一就是将逐条提交ack优化成为批量异步提交ack,这样可以减少跟kafka的网络通信,从而提高消费速率。
3.2.2.消费逻辑是查询、组装数据、以http方式推送数据,查询的feign接口都加了缓存层,响应速度是很高的,为了进一步提高响应速度,可以再加一层本地缓存。唯一的没有加缓存的是查询实时的电流电压值的接口,因为电流电压是动态变化的,此接口也无法缓存。最后http推送的方式是同步的,会将第三方接口的响应日志打印出来。正常调用的情况下,第三方接口的响应是毫秒级的。但是,由于网络延迟等原因,有可能导致接口的响应速度变慢。所以,http请求的方式可以优化成异步的,这样也可以提高消费速率。
3.2.3.批量获取到消息之后,可以使用多线程来优化。将批次拉取到的消息拆分,交给线程池来执行。等待所有线程执行完成后再提交批量偏移量。
kafka消息积压解决之道
于 2025-02-26 14:30:04 首次发布