原创：Sijie Guo

翻译：翟佳

之前的文章，咱们形容了 Apache Pulsar 可能成为企业级流和音讯零碎的起因。Pulsar 的企业个性包含音讯的长久化存储，多租户，多机房互联互备，加密和安全性等。咱们常常被问到的一个问题是 Apache Pulsar 和 Apache Kafka 有什么不同。

在本系列的 Pulsar 和 Kafka 比拟文章中，咱们将疏导您意识和理解音讯零碎中一些重要关注点，比方健壮性，高可用性和高带宽低提早等。

在用户抉择一个音讯零碎时，音讯模型是用户首先思考的事件。音讯模型应涵盖以下 3 个方面：

1. 音讯生产 – 如何发送和生产音讯；
2. 音讯确认（ack）– 如何确认音讯；
3. 音讯保留 – 音讯保留多长时间，触发音讯删除的起因以及怎么删除；

音讯生产模型

在实时流式架构中，消息传递能够分为两类：队列（Queue）和流（Stream）。

队列（Queue）模型

队列模型次要是采纳无序或者共享的形式来生产音讯。通过队列模型，用户能够创立多个消费者从单个管道中接管音讯；当一条音讯从队列发送进去后，多个消费者中的只有一个（任何一个都有可能）接管和生产这条音讯。音讯零碎的具体实现决定了最终哪个消费者理论接管到音讯。

队列模型通常与无状态应用程序一起联合应用。无状态应用程序不关怀排序，但它们的确须要可能确认（ack）或删除单条音讯，以及尽可能地扩大生产并行性的能力。典型的基于队列模型的音讯零碎包含 RabbitMQ 和 RocketMQ。

流式（Stream）模型

相比之下，流模型要求音讯的生产严格排序或独占音讯生产。对于一个管道，应用流式模型，始终只会有一个消费者应用和生产音讯。消费者依照音讯写入管道的确切程序接管从管道发送的音讯。

流模型通常与有状态应用程序相关联。有状态的应用程序更加关注音讯的程序及其状态。音讯的生产程序决定了有状态应用程序的状态。音讯的程序将影响利用程序处理逻辑的正确性。

在面向微服务或事件驱动的体系结构中，队列模型和流模型都是必须的。

Pulsar 的音讯生产模型

Apache Pulsar 通过“订阅”，形象出了对立的: producer-topic-subscription-consumer 生产模型。Pulsar 的音讯模型既反对队列模型，也反对流模型。

在 Pulsar 的音讯生产模型中，Topic 是用于发送音讯的通道。每一个 Topic 对应着 Apache BookKeeper 中的一个分布式日志。发布者公布的每条音讯只在 Topic 中存储一次；存储的过程中，BookKeeper 会将音讯复制存储在多个存储节点上；Topic 中的每条音讯，能够依据消费者的订阅需要，屡次被应用，每个订阅对应一个消费者组（Consumer Group）。

主题（Topic）是生产音讯的实在起源。只管音讯仅在主题（Topic）上存储一次，然而用户能够有不同的订阅形式来生产这些音讯：

• 消费者被组合在一起以生产音讯，每个生产组是一个订阅。
• 每个 Topic 能够有不同的生产组。
• 每组消费者都是对主题的一个订阅。
• 每组消费者能够领有本人不同的生产形式：独占（Exclusive），故障切换（Failover）或共享（Share）。

Pulsar 通过这种模型，将队列模型和流模型这两种模型联合在了一起，提供了对立的 API 接口。这种模型，既不会影响音讯零碎的性能，也不会带来额定的开销，同时还为用户提供了更多灵活性，不便用户程序以最匹配模式来应用音讯零碎。

独占订阅（Stream 流模型）

顾名思义，独占订阅中，在任何工夫，一个消费者组（订阅）中有且只有一个消费者来生产 Topic 中的音讯。下图是独占订阅的示例。在这个示例中有一个有订阅 A 的沉闷消费者 A -0，音讯 m0 到 m4 按程序传送并由 A-0 生产。如果另一个消费者 A-1 想要附加到订阅 A，则是不被容许的。

故障切换（Stream 流模型）

应用故障切换订阅，多个消费者（Consumer）能够附加到同一订阅。然而，一个订阅中的所有消费者，只会有一个消费者被选为该订阅的主消费者。其余消费者将被指定为故障转移消费者。

当主消费者断开连接时，分区将被重新分配给其中一个故障转移消费者，而新调配的消费者将成为新的主消费者。产生这种状况时，所有未确认（ack）的音讯都将传递给新的主消费者。这相似于 Apache Kafka 中的 Consumer partition rebalance。

下图是故障切换订阅的示例。消费者 B-0 和 B-1 通过订阅 B 订阅生产音讯。B-0 是主消费者并接管所有音讯。B-1 是故障转移消费者，如果消费者 B-0 呈现故障，它将接管生产。

共享订阅（Queue 队列模型）

应用共享订阅，在同一个订阅背地，用户依照利用的需要挂载任意多的消费者。订阅中的所有音讯以循环散发模式发送给订阅背地的多个消费者，并且一个音讯仅传递给一个消费者。

当消费者断开连接时，所有传递给它然而未被确认（ack）的音讯将被重新分配和组织，以便发送给该订阅上残余的残余消费者。

下图是共享订阅的示例。消费者 C-1，C-2 和 C-3 都在同一主题上生产音讯。每个消费者接管大概所有音讯的 1/3。

如果想进步生产的速度，用户不须要不减少分区数量，只须要在同一个订阅中增加更多的消费者。

三种订阅模式的抉择

独占和故障切换订阅，仅容许一个消费者来应用和生产，每个对主题的订阅。这两种模式都按主题分区程序应用音讯。它们最实用于须要严格音讯程序的流（Stream）用例。

共享订阅容许每个主题分区有多个消费者。同一订阅中的每个消费者仅接管主题分区的一部分音讯。共享订阅最实用于不须要保障音讯程序的队列（Queue）的应用模式，并且能够依照须要任意扩大消费者的数量。

Pulsar 中的订阅实际上与 Apache Kafka 中的 Consumer Group 的概念相似。创立订阅的操作很轻量化，而且具备高度可扩展性，用户能够依据利用的须要创立任意数量的订阅。对同一主题的不同订阅，也能够采纳不同的订阅类型。比方用户能够在同一主题上能够提供一个蕴含 3 个消费者的故障切换订阅，同时也提供一个蕴含 20 个消费者的共享订阅，并且能够在不扭转分区数量的状况下，向共享订阅增加更多的消费者。下图描述了一个蕴含 3 个订阅 A，B 和 C 的主题，并阐明了音讯如何从生产者流向消费者。

除了对立音讯 API 之外，因为 Pulsar 主题分区实际上是存储在 Apache BookKeeper 中，它还提供了一个读取 API（Reader），相似于消费者 API（但 Reader 没有游标治理），以便用户齐全管制如何应用 Topic 中的音讯。

Pulsar 的音讯确认（ACK）

因为分布式系统的个性，当应用分布式音讯零碎时，可能会产生故障。比方在消费者从音讯零碎中的主题生产音讯的过程中，生产音讯的消费者和服务于主题分区的音讯代理（Broker）都可能产生谬误。音讯确认（ACK）的目标就是保障当产生这样的故障后，消费者可能从上一次进行的中央复原生产，保障既不会失落音讯，也不会反复解决曾经确认（ACK）的音讯。在 Apache Kafka 中，复原点通常称为 Offset，更新复原点的过程称为音讯确认或提交 Offset。

在 Apache Pulsar 中，每个订阅中都应用一个专门的数据结构 – 游标（Cursor）来跟踪订阅中的每条音讯的确认（ACK）状态。每当消费者在主题分区上确认音讯时，游标都会更新。更新游标可确保消费者不会再次收到音讯。

Apache Pulsar 提供两种音讯确认办法，单条确认（Individual Ack）和累积确认（Cumulative Ack）。通过累积确认，消费者只须要确认它收到的最初一条音讯。主题分区中的所有音讯（包含）提供音讯 ID 将被标记为已确认，并且不会再次传递给消费者。累积确认与 Apache Kafka 中的 Offset 更新相似。

Apache Pulsar 能够反对音讯的单条确认，也就是选择性确认。消费者能够独自确认一条音讯。被确认后的音讯将不会被从新传递。下图阐明了单条确认和累积确认的差别（灰色框中的音讯被确认并且不会被从新传递）。在图的上半局部，它显示了累计确认的一个例子，M12 之前的音讯被标记为 acked。在图的下半局部，它显示了独自进行 acking 的示例。仅确认音讯 M7 和 M12 – 在消费者失败的状况下，除了 M7 和 M12 之外，其余所有音讯将被从新传送。

独占订阅或故障切换订阅的消费者可能对音讯进行单条确认和累积确认；共享订阅的消费者只容许对音讯进行单条确认。单条确认音讯的能力为解决消费者故障提供了更好的体验。对于某些利用来说，解决一条音讯可能须要很长时间或者十分低廉，避免从新传送曾经确认的音讯十分重要。

这个治理 Ack 的专门的数据结构 – 游标（Cursor），由 Broker 来治理，利用 BookKeeper 的 Ledger 提供存储，在前面的文章中咱们会介绍更多的对于游标（Cursor）的细节。

Apache Pulsar 提供了灵便的音讯生产订阅类型和音讯确认办法，通过简略的对立的 API，就能够反对各种音讯和流的应用场景。

Pulsar 的音讯保留（Retention）

在音讯被确认后，Pulsar 的 Broker 会更新对应的游标。当 Topic 外面中的一条音讯，被所有的订阅都确认 ack 后，能力删除这条音讯。Pulsar 还容许通过设置保留工夫，将音讯保留更长时间，即便所有订阅曾经确认生产了它们。下图阐明了如何在有 2 个订阅的主题中保留音讯。订阅 A 在 M6 和订阅 B 曾经耗费了 M10 之前的所有音讯之前曾经耗费了所有音讯。这意味着 M6 之前的所有音讯（灰色框中）都能够平安删除。订阅 A 仍未应用 M6 和 M9 之间的音讯，无奈删除它们。如果主题配置了音讯保留期，则音讯 M0 到 M5 将在配置的时间段内放弃不变，即便 A 和 B 曾经确认生产了它们。

在音讯保留策略中，Pulsar 还反对音讯生存工夫（TTL）。如果音讯未在配置的 TTL 时间段内被任何消费者应用，则音讯将主动标记为已确认。音讯保留期音讯 TTL 之间的区别在于：音讯保留期作用于标记为已确认并设置为已删除的音讯，而 TTL 作用于未 ack 的音讯。下面的图例中阐明了 Pulsar 中的 TTL。例如，如果订阅 B 没有流动消费者，则在配置的 TTL 时间段过后，音讯 M10 将主动标记为已确认，即便没有消费者理论读取该音讯。

Pulsar VS. Kafka

通过以上几个方面，咱们对 Pulsar 和 Kafka 在音讯模型方面的不同点进行一个总结。

模型概念

Kafka：Producer – topic – consumer group – consumer；

Pulsar：Producer – topic – subscription – consumer。

生产模式

Kafka：次要集中在流（Stream）模式，对单个 partition 是独占生产，没有共享（Queue）的生产模式；

Pulsar：提供了对立的音讯模型和 API。流（Stream）模式 — 独占和故障切换订阅形式；队列（Queue）模式 — 共享订阅的形式。

音讯确认（Ack）

Kafka：应用偏移 Offset；

Pulsar：应用专门的 Cursor 治理。累积确认和 Kafka 成果一样；提供单条或选择性确认。

音讯保留

Kafka：依据设置的保留期来删除音讯。有可能音讯没被生产，过期后被删除。不反对 TTL。

Pulsar：音讯只有被所有订阅生产后才会删除，不会失落数据。也容许设置保留期，保留被生产的数据。反对 TTL。

比照总结：

Apache Pulsar 将高性能的流（Apache Kafka 所谋求的）和灵便的传统队列（RabbitMQ 所谋求的）联合到一个对立的音讯模型和 API 中。Pulsar 应用对立的 API 为用户提供一个反对流和队列的零碎，且具备同样的高性能。

总结

在这篇博客文章中，咱们介绍了 Apache Pulsar 的音讯模型，该模型将队列和流式传输对立到一个 API 中。应用程序能够将此对立的 API 用于高性能队列和流式传输，而无需保护两套零碎：RabbitMQ 进行队列解决，Kafka 进行流式解决。心愿这篇文章能让您理解 Apache Pulsar 中的音讯模型，音讯生产，删除和保留是如何工作的；理解 Pulsar 和 Kafka 音讯模型之间的区别。在前面一篇文章中，咱们将向您介绍 Apache Pulsar 的架构细节以及 Pulsar 与 Apache Kafka 在数据散发，复制，可用性和持久性方面的差别。

如果对 Pulsar 感兴趣，可通过下列形式参加 Pulsar 社区：

• Pulsar Slack 频道：https://apache-pulsar.slack.com/

  可自行在这里注册：https://apache-pulsar.herokua…

• Pulsar 邮件列表: http://pulsar.incubator.apach…

无关 Apache Pulsar 我的项目的惯例信息，请拜访官网：http://pulsar.incubator.apach… 此外也可关注 Twitter 帐号 @apache_pulsar。