技术文档 | Apache Pulsar 如何满足金融级的容灾场景

本文整理自谙流科技技术合伙人刘德志在 Pulsar Meetup 上的演讲，一起来看 Pulsar 在金融级容灾场景下的实践方案。

容灾的核心诉求

在现代分布式系统架构中，容灾是确保业务连续性的基石。其核心目标是在系统遭遇灾难时，能够快速恢复业务并最大程度地减少损失，"快速"和"减少损失"是衡量容灾方案有效性的关键维度。灾难类型多样，主要包括自然灾害（如洪水、火灾导致机房物理损毁）、网络攻击（如云环境中的 DDoS 攻击）、硬件故障（如磁盘、CPU 的批次性问题）以及系统级故障（如操作系统或中间件升级引发的全局性服务中断）。

为应对这些风险，业界普遍采用冗余策略，从容灾层次来看：接入层 作为无状态服务，容灾实现相对简单；业务层 通常为无状态或轻状态，实现难度中等；最具挑战性的是数据层 ，尤其是在数据库双活、消息传输等场景下，保证数据一致性是跨层容灾的最大技术难点 。实现方式上，从分布式能力 （解决单机问题）、跨机房部署 （应对单机房故障）、跨 AZ 部署 （云环境可用区级容灾）到跨地域部署（城市级最高级别防护），防护能力与成本逐级攀升。

金融行业作为"离钱近"的领域，受监管严格约束，对容灾的要求最高。然而，高等级的容灾能力意味着高昂的成本，这需要业务层、设施层、团队等多部门协作，构成综合成本。最终，在成本开销与恢复时间要求之间存在着直接的权衡关系，跨地域数据零丢失方案成本最高，企业需根据自身业务连续性要求选择对应的抗风险级别。

Pulsar 单集群容错能力

Apache Pulsar 的云原生架构为其卓越的容灾能力奠定了坚实基础。其诞生于2012年的雅虎，结合了 Kafka 的架构优势与高可靠性设计，计算存储分离的理念使其天然适合容器化环境，有效避免了数据与节点的单点绑定问题，在数据扩缩容方面优于传统架构。

在单集群内，Pulsar的容错能力体现在多个层面：

计算层（Broker）的弹性：Broker 作为无状态组件，其上的 Topic 按分区级别动态分布在多个 Broker 上。当某个 Broker 发生故障时，Topic 会自动、迅速地（秒级）迁移到存活的 Broker 上。生产者和消费者在异常时会自动重连新 Broker，整个过程对业务影响极小，毫秒级即可完成。
存储层（Bookie）的可靠性 ：数据通过多副本机制 均衡分布在多个 Bookie 节点上，并采用分片条带化方式写入。这种设计避免了数据绑定在特定节点，新节点可快速加入集群参与数据分片。当某个Bookie节点异常时，读写请求会自动切换至正常副本，服务几乎不受影响，数据在后台异步恢复，相比传统架构（如Kafka）的分钟级恢复，Pulsar实现了秒级故障转移，优势明显。
无缝扩容与自愈：集群支持快速扩容，新 Bookie 节点加入后会自动参与数据写入，流量自动均衡到各节点，最终达到稳定状态。整个扩缩容过程业务流量波动极小，无需人工干预，展现了强大的故障自愈特性。

Pulsar 单集群灾备方案

为应对更大范围的故障，Pulsar 提供了超越单集群的部署能力。

跨机房部署

在跨机房部署场景下，Pulsar 充分利用其架构优势。无状态的 Broker 故障时可通过 Topic 迁移快速恢复，而数据层的容灾则通过机架感知 配置实现，确保 Bookie 的数据副本被分布到不同机房的节点上，从根本上避免了单机房故障导致的数据全部丢失。此外，系统还具备故障降级机制，在机房级故障发生时，系统可以降级为单机房写入模式，以确保服务持续可用，待故障恢复后自动切回多机房同步状态。

K8S部署

通过Pulsar Operator实现的，它负责管理单个Kubernetes集群内所有Pulsar相关资源（如ZooKeeper、Bookie、Broker）的创建和生命周期管理，并定义了相应的自定义资源（CRD）。Operator 实现了组件启动顺序控制和健康状态检查等自动化流程，相当于将传统虚拟机环境中的部署脚本转化为云原生的声明式管理方式，奠定了自动化、标准化部署的基石。

跨 K8S 部署

在云原生环境中，跨 K8S 集群部署成为金融客户（尤其是要求K8S集群部署于单机房内网的银行）的新需求。Pulsar 的解决方案采用**"1个管理集群 + 3个成员集群"** 的架构，通过专用的 Pulsar Multiple Operator、Karmada Operator（负责多集群统一控制与调度）和 Pulsar Operator（负责单集群资源管理）协同工作。此方案成功解决了跨集群网络互通、全局服务发现和有状态服务资源管理等核心挑战，并通过Operator编排实现跨集群的顺序启动控制，确保部署有序性。

跨K8S部署极大地提升了容灾等级，能够有效防范整个Kubernetes集群级别的故障。在此架构下，Pod 级别和 Operator 级别故障对所有服务无影响；Node 级别和 K8S 集群级别故障则要求 ZK/Bookie 保持半数以上副本，而 Broker/Proxy 服务不受影响。

Pulsar 多集群灾备方案

对于金融级关键业务所需的最高级别容灾------地域级防护，Pulsar提供了成熟的多集群灾备方案。

方案一原理直接，即建立多个元数据完全相同的Pulsar集群，生产时进行双写，消费时多集群同时消费。该方案架构简单，具备高可用性和快速切换的优势，但劣势在于故障集群的积压数据需等待恢复后才能处理，且资源消耗较高。

方案二 则利用 Pulsar 内置的 GEO 复制机制 ，这是更受推崇的方式。它支持 Topic、Namespace 等级别的同步配置，无需额外创建消费者订阅，直接通过 Broker 读取并写入数据，保证了消息的完整顺序性和可靠性。其核心在于高效的偏移量同步，采用批量同步算法，通过请求远端集群的生产位置进行比对更新，避免了维护集群间消息ID映射的传统高开销方案。但需注意，此方式可能存在少量重复消费，需要业务端做好幂等处理。

在灾备切换控制上，Pulsar 通过服务发现模块的 failover 机制监听地址变更，建议采用手动切换以保证决策的自主可控。切换回主集群时，可根据 Topic 维度差异化处理，并依赖运维辅助工具（如运行快照、监控告警）来帮助决策。整个服务发现和 GEO 同步配置可通过可视化页面管理，满足金融业对主从、汇聚、全联通等灵活复制模式的需求。

总结

综上所述，Pulsar 凭借其云原生存算分离架构，提供了一整套从微观到宏观的容灾解决方案：

单机房方案：提供机器级容灾，适合非关键业务场景。
跨机房/跨K8S方案：提供机房级或K8S集群级防护，服务与数据恢复速度快，可靠性中等，适合大多数企业应用。
灾备集群方案：提供地域级保护，是金融级关键业务的最优选择。其中，异步同步模式恢复快但可能有数据丢失；同步复制模式恢复较快且数据可靠性最高，完美支持两地三中心架构。

在选择容灾方案时，企业需综合考量成本效益、实施复杂度和业务需求。成本从单集群到灾备集群逐级升高，跨架构方案的复杂度也呈指数级增长。决策者应根据业务的连续性要求选择对应的抗风险级别，对于关键系统，建议采用数据同步的跨地域灾备部署，而对于测试环境等非核心场景，单集群或跨机房方案则是更具性价比的选择。