首页
/ Apache Pulsar Key_Shared订阅模式的消息延迟与ACK空洞问题深度解析

Apache Pulsar Key_Shared订阅模式的消息延迟与ACK空洞问题深度解析

2025-05-15 02:10:52作者:裴锟轩Denise

背景概述

在Apache Pulsar的消息队列系统中,Key_Shared订阅模式是一种特殊的消费模式,它允许消息按照消息键(Key)的哈希值分配到不同的消费者,同时保证相同Key的消息会被同一个消费者顺序处理。这种模式在需要消息顺序性和负载均衡的场景中非常有用。然而,在实际使用过程中,我们发现当消费者存在积压(backlog)或处理速度跟不上生产者时,会出现两个严重问题:

  1. 消息延迟:后续消息的端到端延迟会出现异常峰值(测试中观察到超过50秒)
  2. ACK空洞问题:totalNonContiguousDeletedMessagesRange指标会超过managedLedgerMaxUnackedRangesToPersist默认值(10000),导致订阅状态在Broker重启或主题负载均衡时丢失

问题现象重现

通过一个精心设计的测试场景,我们可以稳定复现这个问题:

  1. 创建4个消费者的Key_Shared订阅
  2. 生产者发送100万条消息,每条消息带有随机Key
  3. 消费者处理时引入3%概率的100ms随机延迟(模拟真实场景中的处理波动)
  4. 所有消息按接收顺序确认(acknowledge)

测试结果显示:

  • 最大消息延迟差达到53秒
  • 最大ACK空洞数达到27103(远超默认限制10000)
  • 各消费者处理的消息量不均衡(约23万-26万条)

技术原理分析

Key_Shared订阅的工作机制

在Key_Shared模式下,Broker会维护每个消费者的消息分发状态,包括:

  • 当前分发给消费者的消息位置
  • 已确认的消息范围
  • 待重试的消息队列

当消费者处理速度不均衡时,系统需要维护复杂的ACK状态,特别是当某些消息需要重试时。

ACK空洞问题的本质

totalNonContiguousDeletedMessagesRange指标表示的是不连续的已确认消息范围数量。在理想情况下,这个值应该很小,因为大部分消息都是连续确认的。但当出现以下情况时,这个值会急剧增长:

  1. 消费者处理速度不一致导致某些消息被"跳过"
  2. 消息重试机制导致原始位置被保留
  3. 消费者确认顺序与接收顺序不一致

消息延迟的根本原因

高延迟的出现与ACK空洞问题密切相关。当ACK空洞过多时:

  1. Broker需要维护大量的消息状态
  2. 消息分发逻辑变得复杂,需要频繁检查每个空洞
  3. 系统资源被大量消耗在状态维护而非消息分发上

解决方案探索

临时解决方案

通过实验性修改(部分回滚PR #7105的变更),我们观察到:

  • 最大消息延迟降至922ms
  • 最大ACK空洞数降至711
  • 消息处理吞吐量保持稳定

这表明原始实现中的某些优化可能过度复杂化了ACK状态管理。

长期解决方案方向

更完善的解决方案应该考虑:

  1. 优化重试机制:对Key_Shared订阅实现更智能的重试策略,避免创建过多ACK空洞
  2. 改进状态管理:重新设计ACK状态的存储和查询方式,降低维护成本
  3. 动态流控:根据ACK空洞数量动态调整消息分发速率
  4. 均衡算法改进:优化Key到消费者的映射算法,减少处理速度不均衡

生产环境建议

对于正在使用Key_Shared订阅的用户,建议:

  1. 监控totalNonContiguousDeletedMessagesRange指标,确保其远低于10000
  2. 为关键业务设置告警,当消息延迟异常时及时介入
  3. 考虑增加managedLedgerMaxUnackedRangesToPersist的值(但需评估内存影响)
  4. 避免消费者处理逻辑中出现较大波动(如测试中的随机延迟)

未来展望

这个问题揭示了分布式消息系统中状态管理的复杂性。Apache Pulsar社区正在通过PIP-299等改进方案持续优化Key_Shared订阅的可靠性。理解这些底层机制不仅能帮助用户更好地使用Pulsar,也能为设计其他分布式系统提供宝贵经验。

对于开发者而言,这个问题也提醒我们:在追求功能丰富性的同时,必须仔细评估其对系统稳定性的影响,特别是在边缘场景下的表现。这正是开源社区协作的价值所在——通过真实场景的测试和反馈,共同打造更健壮的消息系统。

登录后查看全文
热门项目推荐
相关项目推荐

项目优选

收起
kernelkernel
deepin linux kernel
C
22
6
docsdocs
OpenHarmony documentation | OpenHarmony开发者文档
Dockerfile
202
2.17 K
ohos_react_nativeohos_react_native
React Native鸿蒙化仓库
C++
208
285
pytorchpytorch
Ascend Extension for PyTorch
Python
61
94
RuoYi-Vue3RuoYi-Vue3
🎉 (RuoYi)官方仓库 基于SpringBoot,Spring Security,JWT,Vue3 & Vite、Element Plus 的前后端分离权限管理系统
Vue
977
575
nop-entropynop-entropy
Nop Platform 2.0是基于可逆计算理论实现的采用面向语言编程范式的新一代低代码开发平台,包含基于全新原理从零开始研发的GraphQL引擎、ORM引擎、工作流引擎、报表引擎、规则引擎、批处理引引擎等完整设计。nop-entropy是它的后端部分,采用java语言实现,可选择集成Spring框架或者Quarkus框架。中小企业可以免费商用
Java
9
1
ops-mathops-math
本项目是CANN提供的数学类基础计算算子库,实现网络在NPU上加速计算。
C++
550
83
openHiTLSopenHiTLS
旨在打造算法先进、性能卓越、高效敏捷、安全可靠的密码套件,通过轻量级、可剪裁的软件技术架构满足各行业不同场景的多样化要求,让密码技术应用更简单,同时探索后量子等先进算法创新实践,构建密码前沿技术底座!
C
1.02 K
399
communitycommunity
本项目是CANN开源社区的核心管理仓库,包含社区的治理章程、治理组织、通用操作指引及流程规范等基础信息
393
27
MateChatMateChat
前端智能化场景解决方案UI库,轻松构建你的AI应用,我们将持续完善更新,欢迎你的使用与建议。 官网地址:https://matechat.gitcode.com
1.2 K
133