Kafka 和 EMS 消息批量 ack 的实现

本文讨论了在高并发消息处理场景中使用批量ACK策略减少网络资源消耗的方法。针对Kafka和EMS两种消息系统,分析了不同消息接收模式下批量ACK可能遇到的问题及解决方案,特别是EMS的事件驱动模式下如何通过守护线程确保消息正确处理。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

我们现在用 kafka ems 两种方式来接收外部消息,之前没接收一条消息就 ack 系统当前消息量大概接近亿级每天,集中在工作时间的八到十个小时。这意味着每个消息都 ack 会消耗大量网络资源,拖慢消息处理速度。因此决定用批量 ack 来降低网络消耗。

实现过程中碰到一个问题,假设没10 ack 一次,那如果有37条数据,意味着前10条可以成功 ack,而后 7 条由于没有凑够 batchsize 有可能会一直不 ack

对于 kafkaconsumer 来说,consumer 调用 poll 方法主动从服务器获取消息,这个方法可以接受 timeout 参数。这时即使没有达到 batch size,依然有机会在 timeout act.

而对于 EMS 就有点麻烦。

EMS client 有两种消息接收方式。一种是 client 主动调用consume 方法从服务器上获取消息。这种方式和 kafka 一样,可以接受timeout 参数,因此不是问题。

问题在于另一种方式,onMessage()它是事件驱动的,不接受 timeout 参数。这样当最后7条消息收到以后它会一直等待后面的消息到来。 这时客户端已经接收并处理完前7条,但还没有机会 ack, 如果客户端这时挂掉,那么这7条处理过的消息再也没机会被 ack 这会导致消息重复处理。解决办法是开一个守护线程来定时做 ack,由于 EMS ack 依赖于具体消息,因此每次收到一条消息都要 cache 下来,并且几下最后接收到的时间,然后用这最后一条消息来做 ack

Kafka EMS 一样都支持最后一条消息 ack 时,前面的消息就自动 ack

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值