Apache Pulsar 框架簡介


一、架構概述

【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關系架構圖:

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 負責各種與配置和協調相關的任務;

Pulsar集群架構圖

【3】Pulsar訂閱模式圖

Producer發布消息到topic,Consumer可訂閱這些topic,處理發布過來的消息,在處理完成后發送確認。

(一旦訂閱被創建,所有的消息都將被Pulsar保留,即使consumer斷開連接。 只有在consumer確認消息被成功處理后,保留下來的消息才會被丟棄。)

Producer-Topic (Broker)-Consumer

  • Producer是如何生產消息,發送到對應的Broker???
  • Broker是如何處理消息,將高效的持久化以及查詢???
  • Consumer是如何進行消費消息???

二、訂閱模式:producer-topic-subscription-consumer

Topic支持多種訂閱模式: 獨占(exclusive), 共享(shared)和災備(failover),key共享(key_shared);

【1】四種訂閱模式:

Pulsar四種訂閱模式

  • 【獨占模式(默認)】:訂閱中只能有一個消費者訂閱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的不同

Kafka與Pulsar

  • pulsar是流式處理(kafka)和隊列的合體;
  • 都支持分區,但pulsar不是必須;
  • pulsar的broker是無狀態的,而kafka是有狀態的;
  • pulsar簡單的跨域賦值、擴容簡單,數據處理快;


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM