为什么要选择 Apache Pulsar（一）

Apache Pulsar 是由 Yahoo 开发并开源的下一代发布订阅消息系统。Pulsar 用于解决现有开源消息系统的不足，并已在 Yahoo 的生产环境中运行了三年多时间，助力 Yahoo 的主要应用，如 Yahoo Mail、Yahoo Finance、Yahoo Sports、Flickr、Gemini 广告平台和 Yahoo 的分布式键值存储系统 Sherpa。Pulsar 于 2016 年底开源，目前是 Apache 软件基金会的孵化器项目。在这篇文章里，我们将介绍 Pulsar 的一些主要特性。

在上一篇文章中，我们介绍了Pulsar 的一些组件概念和术语。Pulsar 集群主要由三部分组成：broker 集群，bookie 集群，以及用于协调配置管理的ZooKeeper 集群。Pulsar broker 组件用于接收、保存和传递消息。bookie 是Apache BookKeeper 服务器，为Pulsar 提供持久性的存储，一直到消息被消费掉。架构图如下所示。

图1 Pulsar 集群架构图

灵活的消息模型

传统的消息模型有两种：队列模型和发布 / 订阅模型。队列是一种点到点的通信模型——可能有多个消费者从服务器上读取消息，而每个消息只会被发给其中的一个消费者——因此，数据的处理可以被分摊给多个消费者，从而获得伸缩性。发布/ 订阅是一种广播式的通信模型——消息被广播给所有的消费者。

Pulsar 通过统一的 API 实现了这两种模型——生产者向主题 (topic) 发布消息，消息被广播给不同的订阅者，消费者订阅主题以便消费消息。消费者可以灵活地选择消费消息的方式——独享方式、共享方式或失效备援方式。对于队列模型来说，如果采用共享方式，并使用了轮询策略，那么应用程序就可以将负载分摊给消费者。与其他消息系统不同的是，Pulsar 允许活跃消费者的数量超过主题分区的数量。

因为 Pulsar 使用 BookKeeper 作为流式存储组件，所以它也对外提供了一组流式 Reader API 来读取底层的日志，应用程序可以调用这组 API 从任意位置开始消费消息。

灵活的部署模型

Pulsar 可以被灵活地部署到不同的环境里，它可以运行在裸机上、本地或云端的 Kubernetes 集群上、Google Container Engine 和 AWS 上。Pulsar 也可以作为单独节点运行，用于开发和测试。在这种情况下，Pulsar broker、bookie 和 ZooKeeper 都以独立进程的方式运行。

多租户

Pulsar 在一开始就被设计成可以在私有云和公有云上部署的托管服务，其他的开源消息系统都没有提供这种特性。对于大中型企业来说，共享一个 Pulsar 集群要比让每个团队都使用自己的集群成本低得多。虽然每个团队可以自己部署集群，但这要求他们对系统内部原理非常了解，知道如何配置、监控和诊断问题。另外，在整个组织内共享一个集群可以降低成本，因为集群资源可以得到更好的利用，只需要一个 DevOps 团队就足以应付所有的工作，而且可以根据负载高峰期和项目增长作出容量规划。

多地域复制

与其他消息系统不一样的是，Pulsar 将多地域复制作为首要特性。用户只需要配置好区域，并启用跨集群消息复制，剩下的事情由 Pulsar 来完成。数据会持续不断地被复制到远程的 Pulsar 集群上。如果数据中心之间发生网络故障，数据会被保存下来并进行重试，直到复制成功为止。

Pulsar 可以在不同地理区域的多个数据中心上进行并行的数据复制。Yahoo 的键值存储系统 Sherpa 使用 Pulsar 来复制预写式日志（WAL），日志被复制到十个不同的地理区域，实现最终一致性。多地域复制方式也很灵活，可以在私有云之间复制，也可以在私有云和公有云之间复制，或者在公有云之间复制，甚至在数据中心和私有云（或公有云）之间复制。对于想要迁移到云端的大型组织来说，他们可以将 Pulsar 部署到多个不同的云上，然后在多个云之间复制数据。

持久性

Pulsar 在收到消息并进行确认之后，它可以保证数据不会因为各种故障而丢失掉。持久性保证强度由保存数据的磁盘数量来决定，而磁盘数量则由配置的“9”的个数来决定。Pulsar 使用 bookie 来保证持久性，在收到一个消息之后，它将消息发送给多个 bookie 节点。bookie 节点在收到消息后，将它保存到内存里，同时也往 WAL 里写入一份。bookie 在向 broker 发送确认之前会将日志强制写入稳定的存储。与数据库的事务类似，WAL 可以保证数据不会丢失，即使机器出现故障。在重启机器后，通过重放 WAL 就可以恢复数据。

除此之外，即使有多个节点发生故障，消息仍然不会丢失。Pulsar 将每个消息复制给多个 bookie 节点，并在若干个 bookie（根据配置的复制系数）写入成功之后才会向生产者发送确认。这样可以保证在发生多个节点故障的情况下，仍然不会丢失数据。

得益于 BookKeeper 内部 IO 机制的优化，在保证强持久性的同时，Pulsar 仍然能够提供很高的吞吐量和很低的延迟。

总结

Pulsar 是下一代发布订阅消息系统，弥补了其他开源消息系统的不足。在这篇文章里，我们介绍了 Pulsar 仅通过一套 API 实现了灵活的消息模型——队列和发布订阅，还介绍了企业级的多租户特性、多地域复制和强持久性保证。在下一篇文章里，我们将介绍更多的特性，比如 IO 的读写隔离、伸缩性、安全和运维成熟度。

查看英文原文： Why Apache Pulsar? Part 1

感谢杜小芳对本文的审校。