其他

为什么要选择Apache Pulsar

2017-12-15 AI前线


策划|Matteo Merli & Karthik Ramasamy
译者|薛命灯
编辑|Emily

AI 前线导读:Apache Pulsar 是由 Yahoo 开发并开源的下一代发布订阅消息系统。Pulsar 用于解决现有开源消息系统的不足,并已在 Yahoo 45 29442 45 13246 0 0 5190 0 0:00:05 0:00:02 0:00:03 5190生产环境中运行了三年多时间,助力 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 的读写隔离、伸缩性、安全和运维成熟度。

查看英文原文:

https://streaml.io/blog/why-apache-pulsar/

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存