Recap|TGIP001PulsarBasics

Z时代
2024-01-10
分类：综合

️閲讀本文需 8 分鐘

上週日（2 月 9 日），Pulsar 開啟了 2020 年度第一次直播，也是小 Pu 成長路上的第一次線上直播，我們在 zoom 和 B 站同時進行了直播，也有很多朋友發彈幕和留言給我們，感謝各位的捧場！

Pulsar 的第一場線上直播，請來了 StreamNative 的 CEO 郭斯傑大佬，為我們帶來了一場關於「Pulsar Basics」的分享。

在正式進入內容前，郭斯傑也為大家介紹了什麼是 TGIP （Thank God It"s Pulsar），類似可以參考 :point_down|type_1_2:Thank God It"s Friday。

https://en.wikipedia.org/wiki/Thank_God_It%27s_Friday

同時更新了 Pulsar 的近況，主要是以下兩個：

Namespace level offloader
https://github.com/apache/pulsar/pull/6183

Supports evenly distribute topics count when splits bundle
https://github.com/apache/pulsar/pull/6241

後續大家還想了解關於 Pulsar 的任何問題，都可以去下邊這個 repo 下提 issue，沒準哪天你的提問就擴展為一期專門的直播啦！

:raising_hand:‍♂️ https://github.com/streamnative/tgip-cn

同時我們也公佈了一個需要國內用户幫忙填充的「Pulsar 用户調查問卷」，我們將根據此問卷，撰寫一份 Pulsar 的年度報吿，到時候也會發給大家。

如果你想為此報吿貢獻一點力量，可以複製鏈接在瀏覽器進行填寫： https://bit.ly/2Qtrrnf 。填寫者將有機會免費贏取「2020 Pulsar Summit」的入場券吼！

關於更加具體的細節，可以查看文末的回放視頻。

以下是本次直播的內容回顧。

>>> Event Streaming << <

Pulsar 在雅虎旗下被孵化出生時，其實就頂着一個「消息中間件」的任務前行着。隨着開源後，各行業各公司小夥伴們，根據不同的需求，為 Pulsar 賦予了很多更豐富的功能，所以目前它也不再只是中間件的功能，而是慢慢發展成為一個 Event Streaming Platform（事件流處理平台），具有 Connect（連接）、Store（存儲）和 Process（處理）功能。

>> Connect

在連接方面，Pulsar 具有自己單獨的 Pub/Sub 模型，可以同時滿足 Kafka 和 RocketMQ 的應用場景。同時 Pulsar IO 的功能，其實就是 Connector，可以讓你非常方便地將數據源導入到 Pulsar 或從 Pulsar 導出等。

在 Pulsar 2.5.0 中，我們新增了一個重要機制： Protocol handler。這個機制允許你在 broker 自定義添加額外的協議支持，這樣就可以保證在不更改原數據庫的基礎上，也能享用 Pulsar 的一些高級功能。所以 Pulsar 也延展出比如： KoP、ActiveMQ、Rest 等。

>> Store

Pulsar 提供了可以讓用户導入的途徑後，那就需要在 Pulsar 上進行存儲。 Pulsar 採用的是分佈式存儲，最開始是在 Apache BookKeeper 上進行。後來添加了更多的層級存儲，通過 JCloud 和 HDFS 等多種模式進行存儲的選擇。當然，層級存儲也受限於你的存儲容量。

>> Process

Pulsar 提供了一個無限存儲的抽象，方便第三方平台進行更好的批流融合的計算。這也就是 Pulsar 的數據處理能力。 Pulsar 的數據處理能力實際上是按照你數據計算的難易程度、實效性等進行了切分。

目前 Pulsar 包含以下幾類集成融合處理方式：

Pulsar Function ： Pulsar 自帶的函數處理，通過不同系統端的函數編寫，即可完成計算並運用到 Pulsar 中。

Pulsar-Flink connector 和 Pulsar-Spark connector ：作為批流融合計算引擎，Flink 和 Spark 都提供流計算的機制。如果你已經在使用他們了，那恭喜你。因為Pulsar 也全部支持這兩種計算，無需你再進行多餘的操作了。

Presto (Pulsar SQL) ：有的朋友會在應用場景中更多的使用 SQL，進行交互式查詢等。 Pulsar 與 Presto 有很好的集成處理，你可以用 SQL 在 Pulsar 進行處理。

所以以上概括來説，Pulsar 更像是是一個相對完善的信息流處理平台。你可以通過 Pulsar，把 Pulsar 的不同能力結合在一起，迸發出更高效的功能應用，去把項目打造的更多樣化。

>>> Pub/Sub <<<

Pulsar 整個體系裏有很多的組件，Pulsar 最初產生時就是一個消息中間件，前面也有提到過。所以郭斯傑用「拼樂高」的方式，融入 Pulsar 的一些概念講解，讓大家更容易的瞭解 Pulsar。

>> Producer

身為一個 Pub/Sub 系統，首先的存在要素必然是 Producer（生產者）。何為 producer？即消息生產方，所有消息調用生產方的接口，來將消息發送給 Pulsar。

Producer 的作用是與本身的應用程序有關。 Producer 往 Pulsar 裏發送消息時，相應的數據會帶上 schema 的信息。 Pulsar 會確保一個 producer 往 topic 發送的消息是滿足一定的 schema 格式。

>> Topic

上文提到了，producer 會往 topic 裏發送消息。那什麼是 topic 呢？它是一個消息的集合，所有生產者的消息，都會歸屬到指定的 topic 裏。所有在 topic 裏的消息，會按照一定的規則，被切分成不同的分區（Partition）。一個分區會落靠在某一個服務器上，原理類似於 Kafka Topic Partition。

>> Broker

分區落靠的服務器，就是 Broker。 Broker 用來接收與發送消息，生產方連接到 broker 去生產消息，消費方連接到 broker 去消費消息。

數據不會真正存儲在 broker，這就是 Pulsar 與其他中間棧的區別： Pulsar 裏的 broker 是沒有存儲狀態的。

>> Subscription

以上積木流程搭下來後，生產者產出的消息到了某一個 broker 上，就應該出現另一端的消費者（Consumer）了。

Consumer 作為消息的接收方，連接到 broker 接收消息。在 Pulsar 裏將 consumer 接收消息的過程稱之為： Subscription（訂閲），類似於 Kafka 的 consumer group。一個訂閲裏的所有 consumer，會作為一個整體去消費這個 topic 裏的所有消息。

:raising_hand:‍♂️Subscription Mode

Pulsar 裏每一個訂閲都會有不同的模式。目前 Pular 的訂閲模式主要是以下四種：

Exclusive：獨佔訂閲

Failover：故障轉移訂閲

Shared：共享訂閲

Key_Shared：Key 保序共享訂閲

比如上圖中，不管有多少個 consumer 同時存在，只會有一個 consumer 是活躍的，也就是隻有這一個 consumer 可以接收到這個 topic 的所有消息。這種模式就為 Pulsar 訂閲模式中的獨佔訂閲（Exclusive）。

Failover（故障轉移訂閲）則是多個 consumer 可以附加到同一訂閲。但是，對於給定的主題分區，將選擇一個 consumer 作為該主題分區的主使用者，其他 consumer 將被指定為故障轉移消費者，當主消費者斷開連接時，分區將被重新分配給其中一個故障轉移消費者，而新分配的消費者將成為新的主消費者。發生這種情況時，所有未確認的消息都將傳遞給新的主消費者，這類似於 Apache Kafka 中的使用者分區重新平衡。

Shared（共享訂閲）是可以將所需數量的 consumer 附加到同一訂閲。消息以多個 consumer 的循環嘗試分發形式傳遞，並且任何給定的消息僅傳遞給一個 consumer。當消費者斷開連接時，所有傳遞給它並且未被確認的消息將被重新安排，以便發送給該訂閲上剩餘的 consumer。

Key_Shared 訂閲模式是 2.4.0 以後一個新訂閲模式。類似於共享訂閲，但又不是按照循環模式，是按照 key 進行分發，比如同一特徵（奇數、偶數等）。總的來説是融合了 Failover 的有序性和 Shared 的消費擴展性、更均衡的一種訂閲模式。

:raising_hand:‍♂️Partition

前邊我們提到了 topic 裏的分區，其實每個分區就是一個 stream（無窮無盡的數據流）。 Pulsar 給用户提供了 partition 的邏輯抽象，底層物理存儲將邏輯的 partition 劃分為多個分片（Segment），均勻存儲在所有節點上。利用 Apache BookKeeper 的存儲，按照一定的規則生成新的 segment，比較靈活。

Segment 由多條 entry 組成，entry 就是真正意義上組織和存儲的力度，entry 裏是由更多的消息（Message）通過匹配進行批量組成的，從下圖的架構層級就可以更容易地看出，需要從哪個層面進行相應的處理。

而最底層的 message 通常包含 Message ID ，字段則一般由這幾個：ledger-id（在哪個 segment）、entry-id（entry 在這個 segment 的位置）、batch-id（消息被匹配後的位置）、partition-index（消息在 topic 的哪個 partition）。

:raising_hand:‍♂️ Cursor

Cursor 在消費者端，代表了每個訂閲組的消費狀態。所有訂閲狀態的管理，都給到了 broker，追蹤每個訂閲消費到了哪裏，並存儲到 cursor。然後提供到客户端接口 Acknowledge Cumulatively，後續再進行相應的操作，比如移動或重置。

:raising_hand:‍♂️ Reader

Cursor 相當於 Pulsar 管理你的消費狀態，但是有時你不需要 Pulsar 幫你管理，所以就引入了 Reader 這個概念（Non-durable Cursor），即它的消費狀態不被持久化的消費者進行消費。它的消費狀態只在內存裏出現，比如當服務器重啟時不會丟失。

>> Tenant & Namespace

Pulsar 與其他中間件還不一樣的地方，就是它是一個層級化管理結構，也就是 Tenant，Tenant 下有 namespace（命名空間），然後再往下走就是 topic。就像金字塔一樣，層級鑲嵌。

三層的結構有利於把 Pulsar 做成多租户系統進行管理公司等需要多層結構的組織。這些策略的組織成為後期 Pulsar 運維和管理上更巧妙的一種方式。

Pulsar 為了支持統一化的消息平台，引入了 Topic Domain 的概念，默認消息是可持久化的。所以通過這種層級化結構，可以使 Pulsar 更適配不同的應用場景。

>>> 總結 <<<

本期直播介紹了 Pulsar 近期研發進展和基礎概念，希望大家可以通過此次直播更加了解 Pulsar。

詳細的直播回放，可以查看下方視頻：

直播中涉及的 Slide，可以點擊「閲讀原文」獲取。