张氏万家网站建设,海淀做企业网站的公司,百度搜索关键词排名人工优化,qq邮箱怎么在手机qq上打开wordpress本文整理自 刘思楠#xff08;Denovo1998#xff09; 在 Pulsar Developer Day 2025 上的主题演讲#xff0c;一起来看 Apache Pulsar 如何通过混合架构突破延迟消息的性能与功能瓶颈#xff01; 01 延迟消息的应用场景与定义 在现代分布式系统中#xff0c;延迟消息是一个…本文整理自 刘思楠Denovo1998 在 Pulsar Developer Day 2025 上的主题演讲一起来看 Apache Pulsar 如何通过混合架构突破延迟消息的性能与功能瓶颈01 延迟消息的应用场景与定义在现代分布式系统中延迟消息是一个非常经典的场景。例如电商订单下单 30 分钟未支付自动取消、定时任务触发、或者买家收货后一定天数自动打款等。相比于传统的 “数据库 定时扫描” 方案所带来的性能瓶颈和维护成本消息队列的延迟消息提供了一种更优雅的解法当系统接收到消息后先将其设置为“不可见”待达到预设的时间点后再将消息变为可见供消费者消费。02 延迟消息的两大实现思路实现延迟消息主要涉及数据暂存和让消息可见两个环节。在技术实现上主要分为两种截然不同的思路这也正是 Pulsar 原生实现与外部服务如 Chronos的核心区别。思路一延迟生产Delayed Publishing原理 消息先被写入一个临时存储如内置 Topic 或 KV 存储由独立的定时线程或扫描器不断检测。一旦消息到期系统自动将其重新写入到目标 Topic消费者像消费普通消息一样消费它。代表 Chronoshttps://github.com/didi/DDMQ。特点 对消费端透明逻辑简单适合长延迟但高并发下可能因扫描延迟导致触发不准。思路二延迟可见Delayed Delivery/Visibility原理 消息发送时直接写入日志但在消费端拉取时进行拦截。Broker 会维护一个索引在消息分发Dispatch阶段判断消息是否到期未到期的消息会被过滤直到时间到达才推送给消费者。代表 Pulsar 原生实现。特点 时间精度极高省去了定时轮询线程但对消费流程侵入性大且索引维护对内存和性能要求极高。03 Pulsar 原生实现的演进Pulsar 选择了延迟可见这条路为了解决该模式下索引维护的成本经历了从 InMemory 到 Bucket 的架构演进。InMemory 实现早期InMemoryDelayedDeliveryTracker 基于内存的时间分桶和优先级队列维护索引。优势是精度高、速度快缺点是内存占用大且 Broker 重启需全量回放日志重建索引恢复慢。Bucket 实现PIP-195为了支持海量延迟消息Pulsar 引入了 BucketDelayedDeliveryTracker。其核心思想是将绝大部分索引从内存卸载到 BookKeeper 中实现了索引的持久化和懒加载Lazy Loading。这不仅降低了内存消耗还将恢复时间从数小时缩短至秒级。04 Pulsar 原生实现的痛点与挑战尽管 Bucket 机制优化了存储但由于“延迟可见”模式需要在分发端做大量计算Pulsar 原生实现仍面临三大挑战性能瓶颈锁粒度较粗Synchronized在高并发下读写互相阻塞。细节参阅https://github.com/apache/pulsar/issues/23190https://github.com/apache/pulsar/pull/24542资源消耗延迟追踪器是订阅级别Subscription-level的多订阅场景下内存会成倍膨胀。细节参阅PIP-448: Topic-level Delayed Message Tracker for Memory Optimizationhttps://github.com/apache/pulsar/pull/24928https://github.com/apache/pulsar/pull/24927功能缺失难以支持取消消息、修改延迟时间等“可变”操作因为消息一旦写入 Log 就不可变而“延迟可见”模式很难高效地处理针对单条消息的状态变更。细节参阅PIP-423: Add a new admin API to acknowledge a single messagehttps://github.com/apache/pulsar/pull/24370https://github.com/apache/pulsar/pull/2390705 解决方案Chronos 与“延迟生产”为了填补上述短板可引入 DDMQ 中的 Chronos。它采用延迟生产的思路与 Pulsar 形成了完美的互补基于 RocksDB 的时间轮 Chronos 利用 RocksDB 的 Key 有序性构建了一个持久化的巨大“时间轮”。高效调度 消息按触发时间排序存储Push Worker 更是通过 seek 操作精准定位到当前秒级需要触发的消息将其“生产”回 Pulsar 目标 Topic。灵活控制 得益于独立的 KV 存储Chronos 可以通过写入“墓碑”记录轻松实现消息的取消这是 Pulsar 原生难以做到的。06 迈向混合架构未来Pulsar 的延迟消息架构应该是一种结合了“延迟可见”与“延迟生产”的混合架构短延迟秒~分钟级 简单场景 继续走 Pulsar 原生延迟可见。优先利用其 In-Memory 的高性能和高精度处理绝大多数即时性要求高的任务。长延迟小时~天级 灵活控制 走 Chronos延迟生产。对于需要取消、修改时间或超长周期的消息在客户端或 Broker 侧拦截并转交给 Chronos。Chronos 负责持久化存储和调度到期后再将消息生产回 Pulsar。通过这种混合架构既保留了 Pulsar 原生的高吞吐与低延迟优势又补齐了在复杂业务场景下对长延迟消息的灵活管控能力。现场 Q A 摘要交流环节针对延迟消息的落地细节与混合架构的实战问题展开了深入探讨。Q1关于 Chronos 的投递机制如果消息发送过来时已经过期或即将过期处理逻辑是怎样的A Chronos 做了针对性的优化。如果接收到的延迟消息已经到期或者延迟时间非常短系统会判断不需要将其写入 RocksDB 持久化而是触发“直投模式”直接将其推送到目标 Topic。这样既保证了即时性又避免了不必要的存储 IO 开销。Q2关于 Chronos 中延迟消息的取消机制如果标记了取消墓碑但原始消息尚未到达或根本不存在会产生“孤儿数据”吗系统如何清理A 是的这种情况是有专门的清理机制来兜底的。Chronos 的取消和清理逻辑设计如下取消逻辑墓碑机制当收到 CANCEL 请求时Chronos 会在 RocksDB 默认 Column Family 中写入一条“墓碑”记录MsgTypes.TOMBSTONE。这条记录的 Key 包含原消息的时间戳Value 包含被取消消息的 uniqDelayMsgId。扫描拦截当 Push Worker 扫描 RocksDB 时如果在同一秒seekTimestamp内先扫描到了“墓碑”记录会将其 ID 放入内存中的 needCancelMap。后续如果扫描到对应的原始消息则直接跳过投递孤儿记录如果原始消息一直没来或者用户取消了一个不存在的消息这条“墓碑”记录确实会暂时留在 RocksDB 中占用空间。清理逻辑DeleteBgWorkerChronos 内部有一个 DeleteBgWorker 组件配置 deleteOn: true 开启。它会周期性执行默认每 10 分钟根据当前系统的处理进度MetaService.getSeekTimestamp()计算一个截止时间点endKey seekTimestamp - saveHours * 3600。然后调用 RocksDB 的 deleteRange([MIN_TIMESTAMP, endKey))批量标记删除截止时间点之前的所有历史数据包括已投递的消息和孤儿墓碑。真正的物理空间回收则依赖 RocksDB 后续的 Compaction 过程。Q3在 Pulsar 原生 Bucket 实现中lastMutableBucket 的固化触发条件如消息数量、Ledger 范围应该如何合理配置A 这需要根据具体的业务场景进行压测来决定核心是寻找内存占用与IO 频率的平衡点配置过小会导致 Bucket 频繁密封Seal产生大量的小 Snapshot 和 Segment这会增加元数据管理的压力并导致频繁的小 IO 操作影响吞吐量。配置过大会导致大量的延迟索引积压在 Broker 的堆内存中Heap Memory。如果发生 Broker 宕机或 Topic 迁移恢复重建的时间会变长且存在 OOM 的风险。建议观察 Broker 的堆内存大小建议在保证内存安全的前提下适当调大阈值以减少碎片化。具体的数值需要结合生产环境的平均消息大小和延迟跨度通过压测消费端的性能表现来调整。Q4原生实现中延迟消息的 Bucket 固化Sealing过程对消费有多大影响A 影响比较显著。因为消费侧的消息分发Dispatch和读取更多 Entry 的操作强依赖于延迟追踪器Tracker的状态。目前 BucketDelayedDeliveryTracker 的实现中大量使用了 synchronized 同步锁。当触发 Bucket 固化时涉及到创建快照、切分 Segment 并写入 BookKeeper 等重操作这会阻塞读操作导致消费端出现短暂的停顿或延迟抖动。这也是演讲中提到的“性能瓶颈”问题社区目前已有相关的优化方案正在进行中详见 Issue-23190 和 PR-24542旨在细化锁粒度解耦读写路径。Q5Chronos 强依赖 RocksDB在海量延迟消息写入场景下如何避免磁盘 IO 成为瓶颈A 虽然我们没有对 RocksDB 本身做深度的内核级优化但我们可以从架构设计层面解决这个问题。Chronos 主要面向的是长延迟小时/天级场景。这类消息对“写入时效性”要求不高只要在消息需要被触发的“未来时刻”之前写入 RocksDB 即可。可以在 Chronos 的入口处Pull Worker对消费上游 Inner Topic 的 Consumer 实施限流策略。通过控制写入速率将流量削峰填谷避免瞬时流量压垮 RocksDB 的磁盘 IO利用长延迟的时间窗口换取系统的稳定性。Apache Pulsar 作为一个高性能、分布式的发布-订阅消息系统正在全球范围内获得越来越多的关注和应用。如果你对分布式系统、消息队列或流处理感兴趣欢迎加入我们Github:https://github.com/apache/pulsar扫码加入 Pulsar 社区交流群最佳实践互联网腾讯BiFang | 腾讯云 | 微信 | 腾讯 | BIGO | 360 | 滴滴 | 腾讯互娱 | 腾讯游戏 | vivo | 科大讯飞 | 新浪微博 | 金山云 | STICORP | 雅虎日本 | Nutanix Beam | 智联招聘 | 达达 | 小红书华为终端金融/计费腾讯计费中原银行 | 平安证券 | 拉卡拉 | Qraft | 甜橙金融电商Flipkart | 谊品生鲜 | Narvar | Iterable机器学习腾讯Angel PowerFL | Discord物联网/芯片制造应用材料云兴科技智慧城市 | 科拓停车 | 华为云 | 清华大学能源互联网创新研究院 | 涂鸦智能通信江苏移动 | 移动云教育网易有道 | 传智教育推荐阅读免费可视化集群管控 | 资料合集 | 实现原理 | BookKeeper储存架构解析 | Pulsar运维 | MQ设计精要 | Pulsar vs Kafka | 从RabbitMQ 到 Pulsar | 内存使用原理 | 从Kafka到Pulsar | 跨地域复制 | Spring Pulsar | Doris Pulsar | SpringBoot Pulsar