案例实践 | 如何做好 Apache Pulsar 的运维？ASP 产品简介

本文整理自 Pulsar Meetup 深圳2024 大会，由来自 AscentStream 谙流科技技术合伙人魏祥臣带来的《如何做好 Apache Pulsar 的运维？ASP 产品简介》的演讲视频。

嘉宾｜魏祥臣， AscentStream 谙流科技技术合伙人

编辑｜社区志愿者 陈杰（crossoverJie），Teng Fu

Pulsar运维的四个阶段

- Four stages of Pulsar operation -

运维好 Pulsar 通常都要需要从技术预研、技术验证、部署上线和日常运营这四个阶段入手。

整体可参考下面的思维导图：

• 技术预研：从预研开始就要考虑到在线上出现紧急故障时如何处理？运维的核心心法：目标是应急，工作在平时。

• 技术验证：技术验证主要分为业务验证和压测两个方面。业务验证比较简单，主要看 Pulsar 的特性和自己业务模型的匹配度，常见的包括消费模型的匹配（Share、Key-Shared 还是Exclusive等），还有消息特性的匹配如延迟队列、死信队列等。从运维侧来说我们更关注的可能是压测。后文会注重描述如何做好一场压测。

• 部署上线：部署前需要消除单点，做好演练并补全监控。需要有完备的应急机制，同时要保留最后的“压箱石”手段。

• 日常运营：日常运营的核心目标就是要降低故障发生的概率。

做好压测

- Benchmark -

选择压测场景

现在基于 Pulsar 的压测结果非常多，但结果各不相同。造成这个问题的直接原因是，我们没有统一压测条件，我们在压测不同的场景。

最直接的影响条件，就是数据的可靠性。可靠性要求越高，磁盘占用也越多。不同的可靠性要求，直接影响了压测的性能。

4个可靠性等级

可靠性通常基于副本数量和刷盘策略来保障。刷盘策略又可以细分为副本的同步方式和数据写入磁盘的方式，这两种方式都有异步和同步两种可选。副本数量保持一致相对容易，刷盘策略的不同，其实对应了不同的应用场景，这里需要着重厘清。

我们根据不同的副本同步策略和数据写入磁盘策略，可以列出以下 4 个组合，组合的保障级别依次降低：

• L1：同步复制副本，同步写入磁盘

• L2：同步复制副本，异步写入磁盘

• L3：异步复制副本，同步写入磁盘

• L4：异步复制副本，异步写入磁盘

Pulsar 的默认配置是最严格的 Level 1，即要求所有副本都需要同步成功，同时内存中的数据也需要同步落盘成功。只有满足这个条件，才会认为一条消息是发送成功了。Pulsar默认执行了最严格的可靠性策略，最大程度保证消息不丢。

最松的 Level 4 ，只需要有一个副本成功写到消息代理的内存，即认为消息接收成功。这是相对松散但是性能最高的方案，毕竟一旦副本同步或者是落盘过程中出现问题，消息就有丢失的风险。

Kafka和 RocketMQ 和默认采用 level 4 的方案。

因此，在压测前我们首先需要明确自己的可靠性等级，将相应