一、架构概述
【1】Pulsar租户架构图
【2】Pulsar集群架构
【3】Pulsar订阅模式图
二、订阅模式介绍
【1】四种订阅模式
【2】Producer
【3】Consumer
【4】Topic
【5】多Topic订阅
【6】数据分区
【7】路由模式
【8】消息存留、过期、去重
三、对比Kafka
具 体 内 容
一、Pulsar框架介绍
Apache Pulsar将高性能流式处理（Apache Kafka所追求的）和灵活的传统队列（RabbitMQ所追求的）结合到一个统一的消息传递模型和API中，Pulsar使用统一的API提供一个流式处理和队列系统，具有相同的高性能。
【1】Pulsar关系架构图：
-
property：一个property代表一个租户，一个property可包含多个namesapce；假设部署了一个Pulsar集群来支持多个应用程序，在企业中每个property都可以代表一个团队，一个核心的功能，或者一个产品线；
-
namespace：是Pulsar的基本管理单元，在namaspace级别可设置权限permission，备份fine-tune，跨集群管理消息数据的地理复制geo-replication、消息TTL等；一个namaspace里的所有topic都继承相同的设置；
-
topic：一种通道，用作从producer到consumer传输消息：持久（默认，硬盘）和非持久（仅内存）；
【2】Pulsar集群架构及术语
Pulsar ~= Broker 集群（计算） + Bookkeeper集群（存储）
BookKeeper 有状态集群，负责消息数据的持久化存储；
Broker 集群属于无状态集群，只处理业务逻辑；
ZooKeeper 负责各种与配置和协调相关的任务；
【3】Pulsar订阅模式图
Producer发布消息到topic，Consumer可订阅这些topic，处理发布过来的消息，在处理完成后发送确认。
（一旦订阅被创建，所有的消息都将被Pulsar保留，即使consumer断开连接。 只有在consumer确认消息被成功处理后，保留下来的消息才会被丢弃。）
- Producer是如何生产消息，发送到对应的Broker？？？
- Broker是如何处理消息，将高效的持久化以及查询？？？
- Consumer是如何进行消费消息？？？
二、订阅模式：producer-topic-subscription-consumer
Topic支持多种订阅模式: 独占（exclusive）, 共享（shared）和灾备（failover）,key共享（key_shared）；
【1】四种订阅模式：
-
【独占模式（默认）】：订阅中只能有一个消费者订阅topic；
-
【灾备模式】：多个consumer可以绑定到同一个订阅。
Consumer按字典序排序，第一个consumer被初始化为唯一接受消息的消费者，这个consumer被称为master
consumer。当master consumer断开时，所有的消息（未被确认和后续进入的）将会被分发给队列中的下一个consumer。
-
【共享模式】：多个消费者可以绑定到同一个订阅上。 消息通过round
robin轮询机制分发给不同的消费者，且每个消息仅会被分发给一个消费者。当消费者断开连接，所有被发送给他，但没有被确认的消息将被重新安排，分发给其它存活的消费者。（有两点需注意，1、不保证消息顺序；
2、不能使用累计确认）； -
【Key-shared模式】: 多个消费者可以关联到同一订阅。 消息以分布式在消费者之间传递，具有相同key/orderingKey
的消息仅传递给一个consumer。无论消息被重发多少次，它都发给同一个消费者。当consumer连接或断开连接时，将导致某些消息的key的consumer变更。（该模式限制:消息必须指定key/orderingKey;不能使用累计确认;该模式目前是测试版,可以在broker.config禁用）；
【2】Producer：
- 发送模式：同步或异步
- 压缩：消息在发送中可压缩来节省带宽；
- 批处理：生产者将在单个请求中发送批量消息
- 分块（批处理需禁用）：消息分块发送至broker（一P对一C、多P对一C）
【3】Consumer:
- 接收模式：同步或异步
- 监听：客户端库为consumers提供listener的实现，（例如Java客户端，提供MesssageListener接口，实现该接口，一旦接受到新的消息，received方法将被调用。
- 确认: 当consumer 成功消费掉一条消息后,会发送一个确认请求到broker,broker会丢弃这条消息,否则保存这条消息。单条确认 或 累计确认（共享模式不支持）；
- 取消确认：当consumer 在一定时间内没有成功消费消息，想再次消费该消息，这个consumer就可以发送一个否定确认到broker，然后broker重发这条消息。（独占消费模式和灾备订阅模式中，消费者仅仅只能对收到的最后一条消息进行取消确认）。单条取消确认+累积取消模式；
- 确认超时：未确认消息会自动重新交付
【4】Topic：
- 持久topic（默认）：
Pulsar保存所有没有确认的消息到多个BookKeeper的bookies中，持久性topic上的消息数据可以在 broker
重启和订阅者故障转移之后继续存在。 - 非持久topic：消息数据仅存活在内存。 如果broker挂掉或者因其他情况不能从内存取到，消息数据就可能丢失。
- 死信(Dead letter)topic：死信topic使您能够在消费者无法成功消费某些消息时消费新消息。在这种机制中，无法成功消费的消息存储在单独的topic，称为死信topic---仅仅适用于共享模式；
【5】多topic订阅(不能保证顺序性)：
- 正则表达式（所有的主题必须在同一个namespace）；
- 明确指定topic列表;
【6】数据分区
通常一个topic仅被一个broker服务，这限制了topic的最大吞吐量。 分区topic是特殊的topic类型，他可以被多个broker处理，这让topic有更高的吞吐量。分区的topic通过N个内部topic实现，N是分区的数量。 当向分区的topic发送消息，每条消息被路由到其中一个broker。 Pulsar自动处理跨broker的分区分布。
Topic1有5个分区（P0到P4）,分布在3个broker上。因为分区数量多于broker数量，其中有两个broker每个处理两个分区,第三个broker则只处理一个。
这个topic的消息被广播给两个consumer，路由模式决定哪个broker处理哪个partition，订阅模式决定哪条消息发送到哪个consumer；
【7】路由模式：消息应该发布到哪个分区
- roundRobinPartition（默认）：message无key则轮询，有key则hash(key)指定分区
- SinglePartition：无key，producer将会随机选择一个分区，把所有的消息发往该分区。
如果为message指定了key，分区的producer会把key做hash，然后分配消息到指定的分区。 - CustomPartition：使用客制化消息路由实现，可以决定特定的消息进入指定的分区。
【8】消息存留/到期/去重（namesapce级别管理）
消息的顺序与路由模式和消息的key有关；
- 按key分区：相同key的消息有序，并被发送到相同的partition（非客户自定义路由）
- 按producer：来自相同producer的消息有序，（singlepartition） Broker默认：
Broker默认：
- 立即删除所有已被consumer确认过的消息；
- 以消息backlog的形式，持久保存所有未被确认的消息;
存留：可以保存被consumer确认过的消息；
过期：可以给未被确认的消息设置TTL
去重：pulsar保证消息仅持久化一次（避免生产者幂）
三、与Kafka的不同
- pulsar是流式处理（kafka）和队列的合体；
- 都支持分区，但pulsar不是必须;
- pulsar的broker是无状态的，而kafka是有状态的；
- pulsar简单的跨域赋值、扩容简单，数据处理快；