———— 引言
前一陣子接觸到 Pulsar 這么個新一代具有流原生特性的 MQ 中間件，當時因為項目需要，不得不深入了解一下 Pulsar 的一些特性以解決問題。至此，對 Pulsar 產生興趣，從未停止過關注。所以最近逐漸意識到前一陣子對于 Pulsar 的某些特性理解過于簡單，片面甚至是錯誤的。
1、Pulsar 與 云原生
云原生 ，這個詞語在近幾年的互聯網領域很火熱。以我目前的理解，對它的定義則是在云環境（ 私有、公有等 ）中可以部署運行可彈性擴展的應用。例如我們常用的微服務，那么 Pulsar 使用的也是云原生的架構，將 數據從 Borker ( 邏輯概念，下文介紹 ) 剝離，運用 Bookkeer 將消息存儲在 Bookie 集群中 ( 持久層 )，而 Borker 則負責一些調度、管理、復制消息分發等服務。這也就是其“計算儲存分離架構”了，據說也是目前非常流行的一種架構及趨勢。其實 Pulsar 不光是存儲模型的先進，消費模型的抽象也是很好的一種先進思想，后面會發個文章做出分析。那本篇就 Pulsar 是怎么做到分離架構這一點的呢 ？
2、Pulsar 之 Apache BookKeeper ( 下稱 “BK” )
其實在這之前我都沒聽過 BookKeeper ，也是基于 Pulsar 對其有了了解 ，可以說 Pulsar 的分層儲層特性也是 BookKeeper 的一大功勞。
官網： https://github.com/apache/bookkeeper
下面則對 Bookkeeper 一些重要的概念做下介紹 （ 主要和下文 Pulsar 有關 ）
- Entry：是儲存到 Bookkeeper 中的一條記錄，也是 BK 中最小的存儲單元
- Ledger： 是用來存儲 Entry 的，多個 Entry 組成一個 Ledger，在 Pulsar 中也叫日志段，另外一個叫日志流 Stream 下文介紹 。
- Bookie：在 BK 中其實就是一臺存儲節點，用來存儲 Ledger ，但是 Ledger 可能會被劃分為多段以分布式的方式存儲在多個 Bookie 上 （ 應該是為了分布式存儲在數據跨節點復制時考慮到其性能 ）。
- 元數據：用于儲存 Bookie 相關的元數據。
3、Pulsar 儲存模型
引用官網的一張典型的部署圖。如下圖所示， Pulsar 由 Borker 層 和 Bookie 層組成。另外在此處其實 Borker 只是一層邏輯的概念，下文會對其進行具體剖析。
- Borker 層 - 邏輯計算層 （ 個人理解 ）
在 Pulsar 中 Borker 是無狀態的，因為 Borker 并不像 Kafka 那樣會儲存消息。而更多的則是負責消息的復制與分發 與計算有關的邏輯結構。每個主題的分區 （ Topic Partition ）都會分配到某個 Borker 上，而 Porducer 和 Consumer 則會連接到 Borker，從而向主題分區代理發送消息、消費消息。消息數據則是存放在 Bookkeeper 中，這樣一來，當某個 Borker 掛了，或者說某個 Porducer、Consumer 所對應的分區改變了，不會有任何的數據復制發生，而只是一個代理 ( Borker ) 的變更 。
- 持久化層 -- Bookkeeper
在 Pulsar 中每個主題分區的日志都是存放在 BK 中的分布式日志，而每個分布式日志則又會被氛圍 Segment 段。注意，Segment 其實就是 BK 中的 Ledger ，上文有提到，其實 Ledger 是分段分布式存儲在多個 Bookie 上的。以此一來，就可以通過這種模式，主題分區的消息就可以均勻的分布在 Bookie 中，所以也就不會僅僅收到一個節點容量的限制，可以做到彈性的拓展，當然這取決于 Bookies 的數量。再借助于官網的一個圖，我覺得基于圖一，對其又進行一次更深層次的剖析。
其實我第一次看這個圖還是比較困惑的，后來根據官網提供的一些參數，親自配置試驗了一下。那么與上面這兩個圖關聯性最大的幾個配置下面也說明下，以便于更好的理解，當然這幾個配置也是 Bookkeeper Ledger 中的 （ 在Pulsar 中其實就是 基于 Segment 的 ）。如上圖所示，Parition 被分為了多個 Segment，每個 Segment 會寫入到4個 bookie 其中的3個中。比如 Segment 1 就寫入到了 Bookie 1 , 2 , 4 中，Segment 2 寫入到 Bookie 1 , 3 , 4 中 …
Ensemble Size ( Es )
Ensemble Size 決定了 Pulsar 寫入 Ledger 可用的 Bookies 池的大小。在 Borker 創建 Segment時，會選擇一組對應的 Bookies ， 每個 Segment / Ledger 都有著對應的 Bookies 列表，Write Quorum Size ( Qws )
該項配置決定了實際的 Bookies 的數量。Ack Quorum Size ( Qas )
該項配置是確認寫入 Bookies 的數量，當 Producer 生產一條消息時，Borker 需要將消息發送給客戶端，基于 BK 的強一致性， Qas 滿足 >= (Qws + 1) / 2 的 ACK 確認時才算成功。所以在寫入時是并行寫入到多個 Bookies 中的。
4、為何 Pulsar 可以做到彈性的擴容
其實在第 3 點鐘以及分析的很明確了。由于 Partition 中不同 Segment/Ledger 可以保存在 Bookeeper不同的 Bookies 上，當現有的集群 Bookie 存儲滿了時，可以快速的添加機器（ 添加 Bookie 節點 ）來解決問題，讓新的 Segment 尋找到合適的 Bookie （ 哈哈，官網有說是可以通過一些策略去進行負載的，例如可以通過磁盤空間的剩余最多或者負載情況等，當然這個還得確認下 ），進行寫入，從而實現彈性的擴展。
這其實還是得益于 Partition 以 Segment / Ledger 為粒度均勻的分布在 Bookies 的節點上，所以擴容其實也就是 調度 這么簡單。又借鑒于官網找了一張圖可以直觀的表達 Pulsar 實現 即時擴容而無需進行復制的過程。
當然在 Broker 掛了，那么 Pulsar 又會進行怎樣的一個 “數據轉移”呢？（ 記住上文說到的 “ 調度 ” 二字 ），如下圖
5、 Pulsar 如何保證數據的一致性的 （ 讀取 & 寫入分析 ）
基于上文第 3 點鐘說到的配置項的最后一點，借用官網一圖，畫的也是非常的直觀。
那么其實數據的可靠性已經得得到了保證，那么讀取呢？其實既然數據一致性在寫入時就已經維護得到了保證，所以在讀取的時候就不必大費周章，就類似與 MySQL 在插入時區維護他的索引，而讀取時直接用即可，不好意思.....偏題了。所以只需要從一個 Bookie 中讀取， 當然這塊涉及到一個 緩存機制，本編就不做介紹。大致也如下圖 ：
具體的配置項可以參考官網的教程，非本篇文章的介紹重點。
———— 寫在結尾
其實在了解 Pulsar 的過程中，層層剖析，對一些思想上還是有非常大的觀念轉變與進步的（ 特別是做架構的同學，哈哈 ~ ）。從而讓我更加的關注到類似于該類架構的一些中間件的。例如最近有關注到 tidb 開源分布式關系型數據庫也類似于這種架構體系。當然，回歸到本質，一種技術手段深入的了解才會更好的運用到極致，也更好的規避一些問題。
參考文獻
https://jack-vanlightly.com/blog/2018/10/2/understanding-how-apache-pulsar-works
