关于 Apache PulsarApache Pulsar 是 Apache 软件基金会顶级项目，是下一代云原生分布式消息流平台，集消息、存储、轻量化函数式计算为一体，采用计算与存储分离架构设计，支持多租户、持久化存储、多机房跨区域数据复制，具有强一致性、高吞吐、低延时及高可扩展性等流数据存储特性。
当前已有众多国内外大型互联网和传统行业公司采用 Apache Pulsar，案例分布在人工智能、金融、电信运营商、直播与短视频、物联网、零售与电子商务、在线教育等多个行业，如美国有线电视网络巨头 Comcast、Yahoo！、腾讯、中国电信、中国移动、BIGO、VIPKID 等。
TGIP CN 028 主题灵感源自 GitHub @Shoothzj[1] 在 GitHub TGIP-CN[2] 的提议，希望更多了解 Apache Pulsar 延时队列的设计与实现，并期待了解延时队列的适用场景、非适用场景，并且希望了解精度、可靠性如何保障。
12 月 13 日， StreamNative 工程师、Apache Pulsar PMC 成员李鹏辉在 TGIP 活动中分享了 Pulsar 延时队列话题。下面，跟随我们的脚步，回顾一下 TGIP CN 28 期的精彩分享吧！
在分享开始，按照惯例分享了 Pulsar 社区近期重要功能开发建议。
04:04 - 20:43 技术动态
•2.6.3 版本马上出炉
•PIP 70[3]添加轻量级 broker 端 entry 的 metadata
PIP 70 的实现有助于解决以下场景的问题：
•客户端生成消息的 publish time 需要递增；•Pulsar 目前依赖 Prometheus 收集指标，在内存里统计消息 count。一旦 topic 重启或者 topic owner 发生转移，count 会丢失；•Backlog 统计的是 entry 数量， 而非具体消息数量；•自定义 Reset 位置。
•PIP 73[4]指定读取消息的优先级
延迟队列的设计与实现PIP 73 有助于提升灵活性，保证BookKeeper 数据的稳定性和安全性。
20:44 - 26:46 理解 Pulsar 内部的延时消息
26:47 - 27:25 如何使用延时消息
27:26 - 33:39 延时消息的实现
33:40 - 37:03 当前存在的弊端
•延迟 index 存储的限制•重建延迟 index•index 仅可用于订阅
37:04 - 44:52 中间问答环节
Pulsar 在物联网的案例：华为、涂鸦智能、EMQ等，详情可回顾 Pulsar Summit Asia[5] 相关演讲
44:53 - 53:34 延时消息的设计
53:35 - 54:27 设计优势
•更有效地加载延迟 index•减少延迟 index 的内存使用•避免通过重放过多 entry 来重建 index
54:28 - 64:37 面临的挑战
•清理数据•安全地开始读取订阅的位置•过多的单个 ack 导致大量内存开销
64:38 - END 问答环节
如果对 tracker 中的消息到期、rebuild 等相关问题有疑问，一定不要忽略问答环节哦～
