博文推荐 | Apache Pulsar 延迟消息投递解析

ApachePulsar
English
本文作者张超,原载于公众号『腾讯云中间件』,已获得转载授权,较原文有微调。

关于 Apache Pulsar

Apache Pulsar 是 Apache 软件基金会顶级项目,是下一代云原生分布式消息流平台,集消息、存储、轻量化函数式计算为一体,采用计算与存储分离架构设计,支持多租户、持久化存储、多机房跨区域数据复制,具有强一致性、高吞吐、低延时及高可扩展性等流数据存储特性。
GitHub 地址:http://github.com/apache/pulsar/

Apache Pulsar 是一个多租户、高性能的服务间消息传输解决方案,支持多租户、低延时、读写分离、跨地域复制、快速扩容、灵活容错等特性。腾讯数据平台部 MQ 团队对 Pulsar 做了深入调研以及大量的性能和稳定性方面优化,目前已经在腾讯云消息队列 TDMQ 落地上线。本文主要介绍 Pulsar 延迟消息投递的实现,希望与大家一同交流。

什么是延迟消息投递

延迟消息投递在 MQ 应用场景中十分普遍,它是指消息在发送到 MQ 服务端后并不会立马投递,而是根据消息中的属性延迟固定时间后才投递给消费者,一般分为定时消息和延迟消息两种:

  • 定时消息:Producer 将消息发送到 MQ 服务端,但并不期望这条消息立马投递,而是推迟到在当前时间点之后的某一个时间投递到 Consumer 进行消费。
  • 延迟消息:Producer 将消息发送到 MQ 服务端,但并不期望这条消息立马投递,而是延迟一定时间后才投递到 Consumer 进行消费。

目前在业界,腾讯云的 CMQ 和阿里云的 RocketMQ 也都支持延迟消息投递:

  • CMQ:将消息延迟期间定义为”飞行状态“,可通过设置 DelaySeconds 配置延迟范围,取值范围为 0 - 3600 秒,即消息最长不可见时长为 1 小时。
  • RocketMQ:开源版本延迟消息临时存储在一个内部主题中,支持特定的 level,例如定时 5s,10s,1m 等,商业版本支持任意时间精度。

开源的 NSQ、RabbitMQ、ActiveMQ 和 Pulsar 也都内置了延迟消息的处理能力。虽然每个 MQ 项目的使用和实现方式不同,但核心实现思路都一样:Producer 将一个延迟消息发送到某个 Topic 中,Broker 将延迟消息放到临时存储进行暂存,延迟跟踪服务(Delayed Tracker Service)会检查消息是否到期,将到期的消息进行投递。

图片

延迟消息投递的使用场景

延迟消息投递是要暂缓对当前消息的处理,在未来的某个时间点再触发投递,实际的应用场景非常多,比如异常检测重试、订单超时取消、预约提醒等。

  • 服务请求异常,需要将异常请求放到单独的队列,隔 5 分钟后进行重试;
  • 用户购买商品,但一直处于未支付状态,需要定期提醒用户支付,超时则关闭订单;
  • 面试或者会议预约,在面试或者会议开始前半小时,发送通知再次提醒;

最近所在业务产品有个使用 Pulsar 延迟消息的 Case:业务要对两套系统的日志消息进行关联,其中一套系统由于查询 Hbase 可能会超时或失败,需要将失败的关联任务在集群空闲的时候再次调度。

如何使用 Pulsar 延迟消息投递

Pulsar 最早是在 2.4.0 引入了延迟消息投递的特性,在 Pulsar 中使用延迟消息,可以精确指定延迟投递的时间,有 deliverAfter 和 deliverAt 两种方式。其中 deliverAt 可以指定具体的时间戳;deliverAfter 可以指定在当前多长时间后执行。两种方式的本质是一样的,Client 会计算出时间戳送到 Broker。

  1. deliverAfter 发送
producer.newMessage()
        .deliverAfter(long time, TimeUnit unit)
        .send();
  1. deliverAt 发送
producer.newMessage()
        .deliverAt(long timestamp)
        .send();

在 Pulsar 中,可以支持跨度很大的延时消息,比方说一个月、半年;同时在一个 Topic 里,既支持延时消息,也支持非延时消息。下图展示了 Pulsar 中延迟消息的具体过程:

图片

producer 发送的 m1/m3/m4/m5 有不同的延迟时间,m2 是不需要延迟投递的正常消息,consumer 消费时会根据不同的延迟时间进行 ack。

Pulsar延迟消息投递实现原理

从上面的使用方式可以看出,Pulsar 支持的是秒级精度的延迟消息投递,不同于开源 RocketMQ 支持固定时间 level 的延迟。

图片

Pulsar 实现延迟消息投递的方式比较简单,所有延迟投递的消息会被 Delayed Message Tracker 记录对应的 index。index 是由 timestamp | LedgerID | EntryID 三部分组成,其中 LedgerID | EntryID 用于定位该消息,timestamp 除了记录需要投递的时间,还用于 delayed index 优先级队列排序。

Delayed Message Tracker 在堆外内存维护着一个 delayed index 优先级队列,根据延迟时间进行堆排序,延迟时间最短的会放在头上,时间越长越靠后。consumer 在消费时,会先去 Delayed Message Tracker 检查,是否有到期需要投递的消息,如果有到期的消息,则从 Tracker 中拿出对应的 index,找到对应的消息进行消费;如果没有到期的消息,则直接消费正常的消息。

如果集群出现 Broker 宕机或者 topic 的 ownership 转移,Pulsar 会重建 delayed index 队列,来保证延迟投递的消息能够正常工作。

Pulsar 延迟消息投递面临的挑战

从 Pulsar 的延迟消息投递实现原理可以看出,该方法简单高效,对 Pulsar 内核侵入性较小,可以支持到任意时间的延迟消息。但同时发现,Pulsar 的实现方案无法支持大规模使用延迟消息,主要有以下两个原因:

  1. delayed index 队列受到内存限制

一条延迟消息的 delayed index 由三个 long 组成,对于小规模的延迟消息来说,内存开销并不大。但由于 index 队列是 subscription 级别,对于 topic 的同一个 partition 来说,有多少个 subscription 就需要维护多少个 index 队列;同时,由于延迟消息越多、延迟的时间越长,index 队列内存占用也会更多。

  1. delayed index 队列重建时间开销

上面有提到,如果集群出现 Broker 宕机或者 topic 的 ownership 转移,Pulsar 会重建 delayed index 队列。对于跨度时间长的大规模延迟消息,重建时间可能会到小时级别。为了减小 delayed index 队列重建时间,虽然可以给 topic 分更多的 partition 提高重建的并发度,但没有彻底解决重建时间开销问题。

Pulsar 延迟消息投递未来工作

Pulsar 目前的延迟消息投递方案简单高效,但处理大规模延迟消息时仍然存在风险。关于延迟消息投递,Pulsar 社区和腾讯数据平台部 MQ 团队下一步将聚焦在支持大规模延迟消息。目前讨论的方案是在 delayed index 队列加入时间分区,Broker 只加载当前较近的时间片 delayed index 到内存,其余时间片分区持久化磁盘,示例图如下图所示:

图片

上图中,我们按 5 分钟的间隔对 delayed index 队列进行分区,m5 和 m1 放在了 time partition 1,由于延迟时间最近,放在了内存;m4 和 m3 在 time partition 2,延迟时间比较靠后,index 存储在了磁盘。该方案不仅可以减少 delayed index 队列重建时间开销,还可以降低对内存的依赖。

结语

本文为大家介绍了延迟消息投递的相关概念和使用场景,并详细拓展了 Apache Pulsar 的实现原理。Pulsar 目前方案简单高效,支持秒级精度的延迟消息投递,但在处理大规模延迟消息时还有一些局限。Pulsar 社区和腾讯数据平台部 MQ 团队下一步也将聚焦在支持大规模延迟消息上。

相关阅读

图片

点击 链接 ,查看原文内容

阅读 388

ApachePulsar
Apache Pulsar 是 Apache 软件基金会顶级项目,是下一代云原生分布式消息流平台,集消息、存储、轻量化...

Apache软件基金会顶级项目,下一代云原生分布式消息系统

165 声望
902 粉丝
0 条评论

Apache软件基金会顶级项目,下一代云原生分布式消息系统

165 声望
902 粉丝
文章目录
宣传栏