Apache Pulsar - 技术栈

- exactly-once

高可用、高扩展性、易运维
支持跨地域复制

|-----------|--------------------------------------------------------|--------------------------------------------------------|
| | Kafka | Pulsar |
| 模型概念 | producer->topic->consumer group -> consumer | producer->topic->subscription->consumer |
| 消息消费模式 | 主要集中在流(Stream) 模式, 对单个partition是独占消费, 没有共享(Queue)的消费模式 | 主要集中在流(Stream) 模式, 对单个partition是独占消费, 没有共享(Queue)的消费模式 |
| 消息确认(ack) | 使用offset | 使用专门的cursor管理。累积确认和kafka效果一样; 提供单条或选择性确认 |
| 消息保留 | 根据设置的保留期来删除消息, 有可能消息没被消费, 过期后被删除。 | 消息只有被所有订阅消费后才会删除, 不会丢失数据,也运行设置保留期, 保留被消费的数据。 |

Pulsar消息发送、消费架构概述-鸿蒙开发者社区-51CTO.COM

从12个方面详细解读Pulsar的主题与订阅-鸿蒙开发者社区-51CTO.COM

1. Topic

1.1 NameSpace

1.2 Subscription Types

1.2.1 独占模式（Exclusive）

1.2.2 主备/故障转移模式（Failover）

1.2.3 共享/轮询模式(Shared)

1.2.4 基于Key的共享模式(Key_Shared)

Apache Kafka和Apache Pulsar都有类似的消息概念。客户端°通过主题与消息系统进行交互。每个主题都可以分为多个分区。然而，Apache Pulsar和Apache Kafka之间的根本区别在于ApacheKafka是以分区为存储中心，而Apache Pulsar是以Segment为存储中心。

Pulsar使用分层结构，将存储机制与broker隔离开来。此体系结构为Pulsar提供以下好处：

1、独立扩展broker，负责处理Producer发来的消息并分发给消费者。通过一个全局的ZK集群来处理多种协作式任务，例如说基于地理位置的复制。并将消息存储到BookKeeper中，同时单个集群内也需要有一套ZK集群，来存储一些元数据。

2、独立扩展存储（Bookies）

3、更容易容器化Zookeeper, Broker and Bookies

4、ZooKeeper提供集群的配置和状态存储

亮点如下：

1、负载均衡器：Pulsar内置负载均衡器，可在内部将负载分配给所有broker

2、服务发现：Pulsar具有内置的服务发现功能，可以识别在何处以及如何连接到broker。

3、全局复制器：可以在为同一个命名空间配置的N个borker之间复制数据。

4、全局ZK：全局ZK用于实现跨地域复制

其中，BookKeeper可以理解为一个NoSQL的存储系统，默认使用RockDB存储索引数据。

一个批次中所有消息被确认后会删除。那pulsar是如何支持消息回溯的呢？

Pulsar支持消息消费重试，消费者在消费消息的过程中如果处理失败，可以将这些消息存储在消费者对应的重试主题中，以便后续再次重新消费，消费者会自动订阅重试主题。达到最大消费重试次数后如果还是失败，则会将消息存储在死信队列，死信队列中的消息需要人工手动去处理。

性能对比:

Pulsar表现最出色的就是性能，Pulsar的速度比Kafka 快得多，美国德克萨斯州一家名为GigaOm (logo)的技术研究和分析公司对Kafka和Pulsar的性能做了比较，并证实了这一点。

扩展说明: kafka目前存在的痛点

Kafka很难进行扩展，因为Kafka把消息持久化在 broker中，迁移主题分区时，需要把分区的数据完全复制到其他 broker 中，这个操作非常耗时。
当需要通过更改分区大小以获得更多的存储空间时，会与消息索引产生冲突，打乱消息顺序。因此，如果用户需要保证消息的顺序，Kafka就变得非常棘手了。
如果分区副本Q不处于ISR(同步)状态，那么leader选取可能会紊乱。一般地，当原始主分区出现故障时，应该有一个ISR副本被征用，但是这点并不能完全保证。若在设置中并未规定只有ISR副本可被选为leader时，选出一个处于非同步状态的副本做leader，这比没有broker服务该partition的情况更糟糕。
使用Kafka时，你需要根据现有的情况并充分考虑未来的增量计划，规划 broker、主题、分区和副本的数量，才能避免Kafka扩展导致的问题。这是理想状况，实际情况很难规划，不可避免会出现扩展需求。
Kafka 集群的分区再均衡会影响相关生产者和消费者的性能。
发生故障时，Kafka 主题无法保证消息的完整性（特别是遇到第3点中的情况，需要扩展时极有可能丢失消息)。
使用Kafka 需要和offset打交道，这点让人很头痛，因为 broker并不维护consumer的消费状态。
如果使用率很高，则必须尽快删除旧消息，否则就会出现磁盘空间-不够用的问题。
众所周知，Kafka原生的跨地域复制机制(MirrorMaker)有问题，即使只在两个数据中心也无法正常使用跨地域复制。因此，甚至Uber都不得不创建另一套解决方案来解决这个问题，并将其称为uReplicator (eng.uber.com/ureplicato...)。
要想进行实时数据分析，就不得不选用第三方工具，如Apache Storm、Apache Heron或Apache Spark。同时，你需要确保这些第三方工具足以支撑传入的流量。
Kafka没有原生的多租户功能来实现租户的完全隔离，它是通过使用主题授权等安全功能来完成的。
从消息队列走向发布与订阅（Pub/Sub）

不存储、不保留、不管消费状态
阅后即焚：发布一条、消费一条、删除一条

Message Broker 分区分而治之

Kafka的经典与挑战

更加彻底的去中心化
存储计算分离
无状态的Pulsar Broker负责处理生产和消费
存储交给Apache Bookeeper
元数据管理交给ZK

较为复杂的结构提高了使用门槛

Kafka的分区与broker的强耦合问题遭遇Pulsar的"拆解"

Kafka横向扩展的困难遭遇Pulsar的极强的云原生弹性伸缩

场景1：Broker扩缩容问题