一、架構概述
【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簡單的跨域賦值、擴容簡單，數據處理快；