博客推荐｜详解 Apache Pulsar 2.10 新特性——自动化集群故障转移

本文源自 StreamNative 博客《Failure Is Not an Option; It Is a Given.》。作者 David Kjerrumgaard，StreamNative 布道师，Apache Pulsar Committer，《Apache Pulsar in Actions》作者。

摘要：目前，Pulsar 客户端只能与单个 Pulsar 集群交互，无法检测和响应集群级别的故障事件。为了增加 Pulsar 弹性以达到更高可用性，Pulsar 2.10 版本新增内置故障转移功能——自动化集群故障转移。

“故障总是在意料之外，情理之中发生。”

——亚马逊 CTO Werner Vogels

Apache Pulsar Committer、《Apache Pulsar in Action》作者 David Kjerrumgaard 拥有十多年的大型分布式系统工作职业经历，他以亲身经历证实：失败是此类系统不可避免的现实——现代分布式系统中涉及的组件数量众多，几乎不可能实现 100% 正常运行时间。因此，在 Apache Pulsar 等大型系统之上构建应用程序时，在架构中构建弹性非常重要。构建弹性应用程序的必要先决条件是选择可靠的软件系统作为应用技术栈的基础组件，而 Pulsar 肯定满足这一要求。

开发高可用性应用程序需要的不仅仅是在软件技术栈中搭建 Apache Pulsar 等类似容错服务等，还需要实时检测和解决故障，包括在数据中心中断时进行内置故障转移。

截至目前已发布版本，Pulsar 客户端只能与单个 Pulsar 集群交互，无法检测和响应集群级别的故障事件。在集群完全故障的情况下，这些客户端无法自动将其消息重新路由到辅助/备用集群。因为客户端无法建立与活跃集群的连接，任何使用 Pulsar 客户端的应用程序都容易受到长时间中断的影响，并可能会导致数据丢失和失掉业务 SLA。

随着 Pulsar 2.10 的发布，自动化集群故障转移功能已添加到 Pulsar 客户端库中。本博客将介绍如何在应用程序更改代码来运行此新功能。

Pulsar 弹性

Apache Pulsar 的架构包含了几个容错特性：组件冗余、数据复制，以及连接感知客户端库，它会自动检测出客户端与服务层中的一个 broker 断开连接并将其恢复。连接故障检测和恢复完全在 Pulsar 客户端内部处理，对应用程序完全可见。

图 1: Pulsar 客户端提供透明的重新连接和/或连接故障转移到另一个 broker，使应用程序开发人员免受瞬态网络故障（transient network failures）的影响。

正如前文所说，在使用复杂的分布式系统时，故障是不可避免的。这就是 Pulsar 客户端存在的意义。Pulsar 的自动负载均衡会定期将 topic 重新分配给不同的 broker，以更均匀地分配传入的客户端流量，客户端对重新分配的 topic 的所有读/写将自动断开。

在这种情况下，依靠客户端的自动恢复功能来重新连接到新分配的 broker 并继续处理不会错过任何时间节点。从应用程序的角度来看，这种从一个 broker 到另一个 broker 的转换是透明的，不会引发需要由应用程序处理的异常。