腾讯超大 Apache Pulsar 集群的客户端性能调优实践

近期，腾讯 TEG 数据平部 MQ 团队开发部署了一套底层运维指标性能分析系统（本文简称 Data 项目） ，目前作为通用基础设施服务整个腾讯集团。该系统旨在收集性能指标、上报数据以用于业务的运维监控，后续也将延用至前后端实时分析场景。

腾讯 Data 项目选用 Apache Pulsar 作为消息系统，其服务端采用 CVM 服务器（Cloud Virtual Machine，CVM）部署，并将生产者和消费者部署在 Kubernetes 上，该项目 Pulsar 集群是腾讯数据平台部 MQ 团队接入的消息量最大的 Pulsar 集群。在整个项目中，我们在 Apache Pulsar 大规模集群运维过程中遇到了一些问题和挑战。本文将对这些问题展开描述分析，并分享对应处理方案，同时也会解析涉及到的相关 Apache Pulsar 设计原理。

希望本文能够对面临同类场景的用户与开发者提供参考。

业务消息量大，对生产与消费耗时指标敏感

Data 项目的业务场景，具有非常明显的特点。首先，业务系统运行过程中，消息的生产、消费量都非常大，而且生产消息的 QPS（每秒查询率）波动性不明显，即业务会在近乎固定的 QPS 生产和消费数据。

其次，业务方对系统的可靠性、生产耗时、消费耗时这几个指标项比较敏感，需要在比较低的延迟基础上完成业务处理流程。像 Data 项目这样的业务场景和需求，对集群的部署、运营和系统稳定性都提出了非常高的要求。

Data 项目集群最大的特点是消息量大、节点多，一个订阅里可高达数千消费者。虽然 Data 项目当前 Topic 总量并不多，但单个 Topic 对应的客户端比较多，每个分区要对应 100+ 个生产者和 10000+ 个消费者。在对消息系统选型时，团队将消息系统的低延迟、高吞吐设为关键指标。经过综合对比市面上常见的消息系统，Apache Pulsar 凭借其功能和性能胜出。

Apache Pulsar 提供了诸多消费模型如独占、故障转移、共享（Shared）和键共享（Key_Shared），其中在 Key_Shared 和 Shared 订阅下可以支撑大量消费者节点。其他消息流系统如 Kafka，因为消费者节点受限于分区个数，导致其在多分区时性能相对较低。（编者注：Pulsar 和 Kafka 的最新性能测评，敬请期待 StreamNative 即将发布的 2022 版报告）

超大 Pulsar 集群：单分区最大消费者数量超 8K

目前 Data 项目业务数据接入两套 Pulsar 集群，分为 T-1 和 T-2。其中，T-1 对接的业务的客户端 Pod（分为生产者和消费者，且不在同一个 Pod 上，部署在腾讯云容器化平台 (STKE) ，与 Pulsar 集群在相同机房；T-2 对接业务的客户端 Pod 与 Pulsar 集群不在相同的机房（注：机房之间的数据时延相比同机房内部略高）。

服务器侧相关参数

 

业务侧相关参数

Data 项目业务侧使用 Go 语言开发，接入 Pulsar 集群使用 Pulsar Go Client 社区 Master 分支的最新版本。使用云梯 STKE 容器方式部署。

 

本文接下来将介绍 Pulsar 客户端在多种场景下的性能调优，分别针对项目在使用 Pulsar 的过程中遇到的客户端生产超时、客户端频繁断开等情况进行原因解析，并提供我们的解决方案，供大家参考。

客戶端性能调优：问题与方案

调优一：客户端生产超时，服务器端排查

在大集群下，导致客户端生产消息耗时较长或生产超时的原因有很多，我们先来看几个服务器端的原因，包括：

• 消息确认信息过大（确认空洞）

• Pulsar-io 线程卡死

• Ledger 切换耗时过长

• BookKeeper-io 单线程耗时过长

• D