疯狂星期四，来看百胜中国如何玩转 Pulsar～

本文整理自 Chunxiang Yan 在 Pulsar Summit 上的演讲《Awesome Pulsar in YumChina》。背景介绍Chunxiang Yan百胜中国后端工程师自2021年起负责维护和演进百胜中国的 Pulsar PaaS 集群在使用Pulsar过程中积累了丰富的实践经验和专业知识。百胜中国是中国最大的餐饮企业拥有 12,000 多家餐厅覆盖 1,700 多个城市员工超过 40 万名年服务顾客超过 20 亿人次。其研发中心位于上海、南京和西安旗下品牌包括必胜客、KFC、黄记煌等知名餐饮品牌。选择Pulsar的原因2019年百胜中国需要构建一个内部的消息队列 PaaS 平台。由于业务流量难以准确预估且希望尽可能降低运维成本因此对消息中间件的选型提出了较高要求。在与 Kafka 和 RabbitMQ 的对比中Pulsar 在水平扩展性和运维成本方面表现出明显优势。Pulsar 具备无缝的水平扩展能力支持独占、共享和故障转移等多种订阅类型通过 Apache BookKeeper 实现持久化消息存储保证了消息投递的可靠性。同时Pulsar 拥有极低的发布和端到端延迟并支持跨集群的无缝消息复制。最终选择 Pulsar 后使用体验良好完全满足了业务需求。使用案例两类集群为了兼顾不同业务场景的需求百胜中国部署了两类Pulsar 集群业务数据集群BIZ和运营数据集群OPS。业务数据集群BIZ用于核心业务数据其关键指标是数据完整性、吞吐量和发布延迟。集群配置了 26 个节点采用同步发送方式写仲裁数设置为 3确认仲裁数设置为 2并启用了日志同步磁盘写入journalSyncDatatrue以确保至少有 2 个副本的数据持久化保障数据可靠性。运营数据集群OPS主要用于处理监控指标数据这类数据天然具有临时性允许一定的数据丢失。该集群仅配置了 10 个节点采用异步发送方式写仲裁和确认仲裁均设为 1日志不强制写入磁盘journalSyncDatafalse通过牺牲数据持久性来换取更高的吞吐量。两类集群的关键区别体现在硬件规模、发送方式、仲裁设置和日志同步策略上BIZ 集群使用 26 个节点、强一致性、同步写入磁盘OPS集群使用 10 个节点、弱一致性、异步写入操作系统页面缓存。架构百胜中国的 Pulsar 部署采用多可用区架构在 4 个可用区AZ分别部署了完整的系统每个可用区内均包含 BIZ 和 OPS 双集群。业务集群之间通过跨区复制命名空间连接实现数据同步。1NightingaleNightingale 是一个用于接收 Prometheus remote_write 数据的组件。它首先对数据进行速率限制例如随机丢弃样本然后执行解析和标签重组最后将数据转换为 Protobuf 格式写入 Pulsar。通过3个节点夜莺实现了每秒 20 万消息的吞吐量。2PigeonholePigeonhole 组件的设计目标是在 Kafka、RabbitMQ 和 Pulsar 之间同步消息。开发者只需实现 Pulsar 消费者接口即可完成消息的跨系统迁移。该组件采用与 Nightingale 相同的优化逻辑单节点吞吐量达到 5 万消息每秒。3SonicSonic 的工作机制是接收客户端发送的 Redis 命令并将其写入 Pulsar 的双向复制主题随后各个可用区的 Sonic 实例消费这些主题并在本地 Redis 中执行命令。基于 Pulsar 的地理复制特性实现了命令的广播延迟成为关键性能指标需要匹配 Redis 原生的处理速度。4EventbridgeEventbridge 由三个组件构成预处理器负责接收事件并写入 Pulsar Eventbridge 主题规则引擎消费该主题匹配订阅规则后将事件写入发送主题事件处理器消费发送主题并将事件分发给订阅者。针对不同的事件类型采用了多种订阅模式有序事件使用同步发送加 Key 共享模式无序事件使用异步发送加共享模式临时事件使用异步发送加读取器模式。性能调优实践调低发布延迟高发布延迟时检查位置1硬盘选择硬盘类型对发布延迟影响显著。实测表明SSD 比物理硬盘性能高 5 倍企业级 SATA 硬盘延迟可达 20ms而高端消费级 NVMe SSD 仅需 3.8ms。通过 fio 工具进行基准测试命令示例fio --rwwrite --ioenginesync --fdatasync1 --size220m --bs4096可以准确评估硬盘性能。在某次优化案例中将网络磁盘切换为本地 SSD 后最大发布延迟从 300ms 降至 5ms。2JVM 优化使用 Grafana 仪表盘监控 GC 暂停时间发现Pulsar 默认采用吞吐量优先的 JVM 设置导致新生代空间过大、GC 线程并发度高造成较长的暂停。优化措施包括启用 G1GC 并设置最大 GC 暂停时间为10ms-XX:UseG1GC -XX:MaxGCPauseMillis10取消对新生代空间的硬性要求并减少GC线程并发度。优化后GC 暂停从 150ms 降至 10ms发布延迟从 500ms 降至 100ms。3日志检查和压缩BookKeeper每周自动执行数据完整性检查CheckAllLedgers可能影响正常业务。解决方案是通过bin/bookkeeper shell forceauditchecks 命令将检查任务调整到夜间执行。日志压缩过程中GC 线程会整理交错存储的 entry log 文件产生大量磁盘 I/O。通过启用节流参数 isThrotleByBytestrue 和 compactionRateByBytes1024102410可以有效控制压缩对系统的影响。BookKeeper写入机制BookKeeper 采用双写机制Journal 文件作为事务日志写入是异步过程Ledger 实际存储消息写入是同步过程。关键延迟点在于 fsync 系统调用的性能其耗时取决于硬盘速度。配置项 journalSyncData 控制是否对每次写入执行 fsync在追求低延迟的场景下需谨慎设置。其他优化建议在 GC 调优方面避免设置固定的新生代大小让 G1GC 自动调整启用并行引用处理-XX:ParallelRefProcEnabled禁用显式 GC-XX:DisableExplicitGC。系统监控应重点关注硬盘延迟波动、GC 暂停时间以及后台进程的活动周期。调高吞吐量吞吐量公式吞吐量受限于网络往返时间RTT同步消息的吞吐量公式为最大吞吐量 1 / RTT。例如当RTT为5ms时最大吞吐量约为200消息/秒。即使使用异步处理吞吐量仍受网络RTT的制约。应用案例消息批处理配置通过合理配置批处理参数可以大幅提升吞吐量。设置最大待处理消息数MaxPendingMessages为 1000批处理最大发布延迟BatchingMaxPublishDelay为 1ms批处理最大消息数BatchingMaxMessages为 100×1024批处理最大尺寸BatchingMaxSize为 10MB并启用 LZ4 压缩压缩级别high。实际测试中单节点吞吐量达到 46,000 消息/秒。调优建议从默认配置开始逐步测试找到最优设置。GOTCHAS被阻塞的消费者问题现象HTTP 触发的消费者在消息积压时意外挂起。根本原因是消息滞留在本地队列未被及时消费。解决方案是明确关闭不再需要的消费者。崩溃的消费者问题现象服务启动时出现 OOM 错误。根本原因是默认接收队列大小1000条消息在消息体积较大时消耗过多内存。当消息大小为 1MB 时队列可能占用 1GB 内存。预防措施是在高负载场景下特别注意队列大小的配置。未来计划Pulsar On K8S百胜中国正规划将 Pulsar 迁移到 Kubernetes 平台实现云原生转型。实施过程中需逐步将现有虚拟机部署的关键服务迁移至 K8S 环境确保业务平稳过渡。Pulsar IaC基础设施即代码IaC是未来方向之一计划建立 Pulsar 配置管理系统实现配置的版本化、自动化管理。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