Apache Pulsar之为什么要用Apahce Pulsar

重点介绍Pulsar的关键特性。

在之前的博客文章中，我们介绍了几个Pulsar的概念和术语。Pulsar集群由一组brokers和bookies以及用于协调和配置管理的Apache ZooKeeper集合组成。broker是接收、存储和传递消息的组件。bookies来自Apache BookKeeper，它为消息提供持久存储，直到消息被使用。架构图：

灵活的消息传递模型

有两种传统的消息传递模型：队列和发布-订阅。

• 队列是一种点到点的通信模型——一组消费者可以从服务器读取数据，并将每条消息传递给其中的一条——允许在多个消费者实例上划分数据处理并扩展。
• 发布-订阅是一种广播通信模型——消息被广播给所有消费者。

Pulsasr通过一个统一的消息传递API概括了这两个消息传递概念，即生产者将消息发布到主题，消息广播到不同的订阅。然后消费者可以通过订阅来消费消息。相同订阅中的使用者可以选择一种灵活的方式来使用消息——独占、共享和故障转移。与队列一样，使用循环传递的共享订阅允许应用程序在相同的订阅中对消费者进行处理。与其他消息传递系统不同，Pulsar允许将活动消费者的数量扩展到主题中分区的数量之上。

由于Pulsar使用Apache BookKeeper作为流存储，它还通过流读取器API公开底层日志，允许应用程序从任何早期位置开始消费。

灵活的部署模式

• 可以灵活地部署在不同的环境中。
• 可以在裸机上运行，Kubernetes集群on prem和云中运行，谷歌Kubernetes引擎和AWS上运行。
• 可以在单个节点中下载和使用Pulsar，也可以用于开发和测试。

在这种情况下，整个Pulsar Broker、BookKeeper和ZooKeeper 都在一个进程中运行。

多租户

从一开始，Pulsar就被设计为作为私有和公共云的托管服务进行部署，而任何可用的开源系统都没有提供这种服务。对于大中型组织，共享一个Pulsar集群比要求每个团队操作自己的消息传递解决方案要划算得多。虽然每个团队都可能发现设置和部署自己的消息传递解决方案非常容易，但是操作这些解决方案通常要困难得多，因为它们通常需要对系统内部的知识有深入的了解，才能有效地配置、监视和故障排除这些解决方案。此外，通过在整个组织中共享单个集群，它是具有成本效益的，因为集群服务器得到了更好的利用，多个团队共享一个devops团队，并使用预期的高峰使用量和预期的增长进行有效的容量规划。

异地备份，数据完整性保证

与其他消息传递系统不同，Pulsar提供了一流的replication功能。

用户可以轻松地在集群之间启用消息数据的复制，方法是配置需要复制哪些主题的replication，然后Pulsar自动处理其余的内容。数据被连续地复制到其他的Pulsar集群。在跨数据中心的网络故障情况下，数据将被存储并重试，直到复制成功。

可以同时将数据复制到位于不同地区的多个数据中心的其他Pulsar集群。在Yahoo，key-value store Sherpa使用Pulsar复制其预写日志(WALs)。日志最多复制10个地区，以实现键值存储的最终一致性。

地理复制可以灵活地部署在几种配置中。可以在组织的私有云之间、私有云与公共云之间、公共云之间，甚至从边缘数据中心复制到私有云或公共云。

希望迁移到云的大型组织可以跨不同的云提供商部署Pulsar，并在它们之间复制数据，而无需将自己绑定到专有的云提供商api。

持久性

Pulsar在接收到数据并确认(“ack”)，它就能保证数据在发生错误、断电等情况下不会丢失。

持久性，由存储数据的磁盘数量决定，可根据所需的9个磁盘数量进行配置。 

Pulsar使用运行在存储节点上的bookies来实现持久性。当Pulsar Broker接收到消息时，它将消息发送给一组bookie节点。当消息数据被bookie接收时，它会在内存中保存一个副本，并将数据写入WAL。在发送确认之前，此日志被强制保存在稳定的存储中。与数据库事务类似，WAL确保即使机器发生故障并comes back again，数据也不会丢失。通过重放日志，机器将通过重放WAL来恢复数据。

除此之外，Pulsar messages还可以在多个节点故障中存活下来。将每条信息复制到多个bookies。在配置了多个副本成功地将消息写入bookies之后，Pulsar向生产者发送一个确认。这保证了Pulsar即使在存在多个硬件故障的情况下也能保证零数据丢失。

即使有这些强大的持久性保证，由于BookKeeper内部IO实现，Pulsar提供了非常高的吞吐量和低延迟。

小结1

Pulsar是新一代的发布/订阅消息系统，从头开始设计，以解决开放源码消息系统中的不足。在第一篇博文中，我们重点介绍了灵活的消息传递模型，它将队列和发布-订阅都通用到一个API中。我们讨论了多租户、异地备份和强持久性保证的企业级特性。

下面，除了操作成熟度之外，我们将重点介绍关于读写之间的I/O隔离、可伸缩性和它的安全模型、多语言API、易于操作。

读写之间的I/O隔离

在大多数消息传递系统中，消费者延迟可能导致总体性能下降。

如果某个主题上的消费者开始滞后，这可能会影响到其他消费者，这些消费者可能会跑得更快，并一直排在队列的最前面。发生这种情况的原因是，缓慢的消费者迫使消息传递系统从存储介质检索数据，这将导致磁盘I/O，并导致非常低的吞吐量。这减慢了消费速度，他们的数据需要在被服务之前被带入内存。这是因为读和写共享一个执行路径。

Pulsar使用Apache BookKeeper作为消息存储系统，解决了上述问题。通过使用BookKeeper，Pulsar能够通过使用不同的读写执行路径在读写之间提供I/O隔离。常规的读取由Pulsar Broker直接提供，而持久的写操作是对BookKeeper的提前写日志(WALs)进行的，而后续的读取操作是由BookKeeper的稳定存储完成的。

在所有情况下，为发布应用程序提供可预测的延迟非常重要。使用I/O隔离，即使磁盘由于繁重的读取导致磁盘压力上涨，也可以实现更低且更可预测的发布延迟。

可扩展性

在消息传递系统中，随着越来越多的数据涌入系统，能够进行扩展非常重要。发布-订阅系统的可扩展性体现在多个维度：

• High throughput：通过驱动磁盘接近其最大I/O带宽来实现高吞吐量。吞吐量可以根据消息大小而变化。

例如，对于一条1kb的消息，Pulsar以每秒120 MB的速度读取。但是对于非常小的消息，比如10字节，我们测量了每秒180万条消息的吞吐量。在这两种情况下，都是一个发布者编写一个主题，该主题只有一个分区，发布延迟低于5ms，为99pct。

• Number of topics：主题可伸缩性是发布-订阅系统支持大量主题的能力，范围从数亿个主题到数百万个主题，同时继续提供一致的性能。扩展主题数量的关键在于如何在稳定的存储中组织底层数据。如果主题的数据存储在专用文件或目录中，则会有伸缩性问题，因为I/O将分散在磁盘上，因为这些文件将定期从页面缓存刷新到磁盘。但是由于Pulsar数据存储在bookies(BookKeeper服务器)中，来自不同主题的消息被聚合、排序，并存储在大型文件中，然后是索引。使Pulsar可以扩展Topic的数量。

安全性

支持可插入的身份验证机制，客户端可以使用该机制对自己进行身份验证。还可以配置为支持多个身份验证提供者。身份验证提供者的目的是建立客户机的标识并为客户机分配角色令牌。此令牌用于确定客户端被授权执行哪些操作。

Pulsar支持两个开箱即用的身份验证提供者:TLS Client Authentication和Athenz (Yahoo创建的基于角色的身份验证系统)。

多语言API

应用程序可以使用多种语言与Pulsar交互。Pulsar有三个流行语言的官方客户端库:c++、Java和Python。这使用户能够用自己选择的语言编写应用程序，并在生产环境中运行。这些客户端API在各个语言的使用都是直观一致的。此外，官方的Pulsar客户端同时支持同步和异步读写操作，以适应不同的应用程序风格。对于同步和异步操作，语义是完全相同的:要么API方法阻塞直到操作完成，要么返回一个可用于跟踪完成的未来对象。

运营

容易管理。

• 在系统运行时，可以通过添加更多的broker节点和storage节点轻松地扩展容量。如果存储节点done了，则自动将其包含的所有条目标记为“replicated”，并自动触发后台进程将数据从可用副本复制到新存储节点。
• Pulsar提供了多种管理集群的方法，使用admin CLI工具、Java管理库和其他使用admin REST API的方法。

后者提供了编写自己的外部工具或将某些操作合并到现有工具中的灵活性。

企业级

Pulsar是Yahoo为解决现有开源系统中的一些缺陷而设计的。一些案例需要处理数千亿条消息的能力，这些消息具有高吞吐量、强持久性保证和低延迟。

目前已经在Yahoo使用了三年，服务140万个主题，提供一致的发布延迟小于5ms，部署在全球10多个数据中心，具有完整的异地复制，迄今已处理了100多万亿条消息。

小结2

Pulsar是下一代的发布-订阅消息系统，从头开始设计，以解决开放源码消息系统中的许多空白。在这个系列文章中，我们重点介绍了各种Pulsar特性，并详细说明了Pulsar如何使用Borker(服务节点)和BookKeeper(存储节点)实现I/O分离，以及它如何支持持久性、多租户、异地复制、高消息吞吐量和主题可伸缩性等企业级特性。