为什么要选择Apache Pulsar（二）-InfoQ

这是介绍 Apache Pulsar 关键特性系列文章的第二篇。Pulsar 是由 Yahoo 开发并开源的下一代发布订阅消息系统。在第一篇文章里，我们介绍了Pulsar 对消息模型的灵活支持、多租户、多地域复制和持久性。在这一篇文章里，我们将继续介绍Pulsar 的IO 隔离机制、伸缩性、安全模型、多语言API 和易操作性。

读写IO 隔离

在大多数消息系统里，消费者的速度延迟会导致性能下降。同一个主题的消费者，如果其中一个出现速度延迟，就会影响到其他速度更快的消费者。这是因为慢消费者强制要求消息系统从存储里获取数据，导致IO 出现抖动，降低吞吐量。那些需要将数据先加载到内存里的消费者就会受到影响。导致这一问题的原因主要是读操作和写操作共享同一个执行路径。

Pulsar 通过使用 BookKeeper 作为存储系统解决了这一问题。有了 BookKeeper，Pulsar 就可以为读操作和写操作提供不同的执行路径，实现 IO 隔离。常规的读操作直接由 Pulsar broker 处理，写操作使用 BookKeeper 的预写式日志（WAL），Catch-up 读使用 BookKeeper 的后端存储设备。

对于系统中消息的发布，在任何情况下都能提供可控的，可预计的延迟是十分重要的。有了 IO 隔离，即使在磁盘承受高负载的读操作时，仍然能够保证消息的发布延迟是很低的、可以预计的。

伸缩性

消息系统的可伸缩性也是很重要的。发布订阅消息系统的伸缩性可以从以下几个维度来衡量：

高吞吐量——Pulsar 的高吞吐量，通过最大限度的使用磁盘带宽（IOPS）来实现。吞吐量取决于消息的大小，例如，如果消息的大小为 1KB，那么 Pulsar 可以达到每秒 120MB 的吞吐量。但如果消息很小，比如只有 10 个字节，那么吞吐量可能只有 1.8M 每秒。这两种结果都是基于单个发布者向一个主题（topic）分区写入消息而得出的，99% 的写入延迟都在 5 毫秒以内。
主题数量——主题伸缩性是发布订阅消息系统用以支持海量主题的一项能力。Pulsar 可以支持从几百到百万级别的主题数量的扩展，同时还能一直保持良好的性能。主题的伸缩性取决于数据的组织和存储方式。如果一个主题的数据被保存在单独的文件或目录里，就会影响伸缩性，因为磁盘的 IO 是分散的，这些文件会定期从页面缓存冲刷到磁盘上。不过 Pulsar 的数据保存在 bookie（BookKeeper 服务器）上，不同主题的消息被聚合起来，经过排序，保存到大文件里，并进行索引。Pulsar 也因此能够支持大量的主题。

安全

Pulsar 支持可插拔的认证机制，可以通过配置使用多种认证实现。认证的目的是为了建立客户端标识，并为客户端分配一个角色令牌。这个令牌被用来判断一个客户端可以做哪些操作。Pulsar 提供了两个默认的认证实现：TLS 客户端认证和 AthenZ （由 Yahoo 开发的一种基于角色的认证系统）。

多语言 API

应用程序可以通过多种编程语言与 Pulsar 发生交互。Pulsar 为三种主流语言提供了官方的客户端： C++ 、 Java 和 Python 。用户可以根据实际需要选择一种客户端。这些客户端 API 非常直观，而且在不同语言之间保持了一致性。另外，Pulsar 的官方客户端还为不同风格的应用程序提供了同步和异步两种读写操作。同步和异步的语义是一样的：要么阻塞方法等待操作完成，要么返回一个 Future 对象用于追踪操作是否完成。

运维成熟度

Pulsar 易于管理，你可以在系统运行的同时加入新的 broker 节点和存储节点来扩展容量。如果一个存储节点宕机，后台进程会自动将宕机节点所包含的数据从其他节点上的可用副本中复制到可用的存储节点上。Pulsar 为集群管理提供了多种方式，可以使用命令行工具，也可以使用 Java 库或 REST API。后者提供了更大灵活性，你可以基于它们开发自己的管理工具或者与已有的工具结合在一起使用。

企业级

Yahoo 设计 Pulsar 是为了解决现有开源消息系统存在的一些问题和场景。满足了高吞吐量（处理数千亿个消息）、强持久性保证和低延迟的需求。Pulsar 已经在 Yahoo 运行了三年，支持着 140 万个主题，99% 延迟低于 5 毫秒，部署在 10 多个数据中心（启用了全网格复制），已经处理了超过 100 万亿个消息。