本文向讀者介紹兩個優秀的分布式消息流平台：Kafka與Pulsar。
Apache Kafka（簡稱Kafka）是由LinkedIn公司開發的分布式消息流平台，于2011年開源。Kafka是使用Scala和Java編寫的，當下已成為最流行的分布式消息流平台之一。Kafka基于釋出/訂閱模式，具有高吞吐、可持久化、可水準擴充、支援流資料處理等特性。
Apache Pulsar（簡稱Pulsar）是雅虎開發的“下一代雲原生分布式消息流平台”，于2016年開源，目前也在快速發展中。Pulsar集消息、存儲、輕量化函數式計算為一體，采用計算與存儲分離架構設計，支援多租戶、持久化存儲、多機房跨區域資料複制，具有強一緻性、高吞吐、低延時及高可擴充性等流資料存儲特性。
Kafka與Pulsar都是優秀的分布式消息流平台，它們都提供了以下基礎功能：
（1）消息系統：Kafka與Pulsar都可以實作基于釋出/訂閱模式的消息系統，消息系統可以實作由消息驅動的程式—生産者負責産生并發送消息到消息系統，消息系統将消息投遞給消費者，消費者收到消息後，執行自己的邏輯。
這種消息驅動機制具有以下優點：
- 系統解耦：生産者與消費者邏輯解耦，互不幹預。如果需要對消息添加新的處理邏輯，則隻需要添加新的消費者即可，非常友善。
- 流量削峰：消息系統作為消息緩沖區，以低成本将上遊服務（生産者）的流量洪峰緩存起來，下遊服務（消費者）按照自身處理能力從消息隊列中讀取資料并進行處理，避免下遊服務由于大量的請求流量而崩潰。
- 資料備援：消息系統将資料緩存起來，直到資料被處理，避免下遊服務由于崩潰下線、網絡阻塞等原因無法及時處理資料而導緻資料丢失。
（2）存儲系統：Kafka與Pulsar可以存儲大量資料，并且用戶端控制自己讀取資料的位置，是以它們也可以作為存儲系統，存儲大量曆史資料。
（3）實時流資料管道：Kafka與Pulsar可以建構實時流資料管道，流資料管道從MySQL、MongoDB等資料源加載資料到Kafka與Pulsar中，其他系統或應用就可以穩定地從Kafka與Pulsar中擷取資料，而不需要再與MySQL等資料源對接。為此，Kafka提供了Kafka Connect子產品，Pulsar提供了Pulsar IO子產品，它們都可以建構實時流資料管道。
（4）流計算應用：流計算應用不斷地從Kafka與Pulsar中擷取流資料，并對資料進行處理，最後将處理結果輸出到Kafka與Pulsar中（或其他系統）。流計算應用通常需要根據業務需求對流資料進行複雜的資料變換，如流資料聚合或者join等。為此，Kafka提供了Kafka Streams子產品，Pulsar提供了Pulsar Functions子產品，它們都可以實作流計算應用。另外，Kafka與Pulsar也可以與流行的Spark、Flink等分布式計算引擎結合，建構實時流應用，實時處理大規模資料。
Kafka與Pulsar都具有（或追求）以下特性
- 高吞吐、低延遲：它們都具有高吞吐量處理大規模消息流的能力，并且能夠低延遲處理消息。這也是大多數消息流平台追求的目标。
- 持久化、一緻性：Kafka與Pulsar都支援将消息持久化存儲，并提供資料備份（副本）功能，保證資料安全及資料一緻性，它們都是優秀的分布式存儲系統。
- 高可擴充性（伸縮性）：Kafka與Pulsar都是分布式系統，會将資料分片存儲在一組機器組成的叢集中，并支援對叢集進行擴容，進而支援大規模的資料。
- 故障轉移（容錯）：Kafka與Pulsar支援故障轉移，即叢集中某個節點因故障下線後，并不會影響叢集的正常運作，這也是優秀的分布式系統的必備功能。
Kafka與Pulsar雖然提供的基礎功能類似，但它們的設計、架構、實作并不相同，本書将深入分析Kafka與Pulsar如何實作一個分布式、高擴充、高吞吐、低延遲的消息流平台。另外，本書也會介紹Kafka與Pulsar中連接配接器、流計算引擎等功能的應用實踐。
Kafka與Pulsar涉及的基礎概念
将Kafka與Pulsar都視為一個簡單的消息系統，消息流轉流程如下圖所示。
圖中展示了消息系統中的4個基本概念。它們在Kafka與Pulsar中都存在，并且含義相同。
- 消息Message：Kafka與Pulsar中的資料實體。
- 生産者Producer：釋出消息的應用。
- 消費者Consumer：訂閱消息的應用。
- 主題Topic：Kafka與Pulsar将某一類消息劃分到一個主題，主題是消息的邏輯分組，不同主題的消息互不幹預。
下面結合一個例子說明上述概念。假如存在一個使用者服務，該使用者服務建立了一個主題“userTopic” 每當有新使用者注冊時，使用者服務都會将一個消息發送到該主題中，消息内容為“新使用者注冊”。目前有兩個服務訂閱了該主題的消息：權益服務和權限服務。權益服務收到消息後，負責給新使用者建立權益。權限服務收到消息後，負責給新使用者配置設定權限。該例子中的消息即使用者服務發送的資料實體，生産者是使用者服務。消費者是權益服務與權限服務。
下面介紹Kafka的一些基礎概念。
- Kafka消費組：Kafka将多個消費者劃分到一個邏輯分組中，該分組即一個消費組。這個概念比較重要，結合上面的例子進行說明，在Kafka中，權益服務所有的消費者都可以加入一個權益消費組rightsGroup，而權限服務所有的消費者都可以加入一個權限消費組guthorityGroup。不同消費者之間消費消息互不幹預。
- Broker：Kafka服務節點，可以将Broker了解為一個Kafka的服務節點或者服務程序（下面将其統稱為Broker節點），多個Broker節點可以組成一個Broker叢集。
- 分區Partition：Kafka定義了分區的概念，一個主題由一個或多個分區組成，Kafka将一個主題的消息劃分到不同的分區，并将不同分區存儲到不同的Broker，進而實作分布式存儲（典型的資料分片思想），每個分區都有對應的下标，下标從0開始。
- 副本Replica：Kafka中每個分區都有一個或多個副本，其中有1個leader副本，0個或多個follow副本，每個副本都儲存了該分區全部的内容。Kafka會将一個分區的不同副本儲存到不同的Broker節點中，以保證資料的安全。本書後面會詳細分析Kafka副本同步機制。
- AR（Assigned Replicas）：分區的副本清單，即一個分區所有副本所在Broker的清單。
- ISR：分區中所有與leader副本保持一定程度同步（即不能落後太多）的副本會組成ISR（In-Sync Replicas）集合。ISR集合中包括leader副本，可以将其了解為已同步副本（不一定完全同步，但不會落後太多）。
- ACK機制：ACK（消息确認）機制是消息系統中的一個很重要的機制，消息系統ACK機制與HTTP的ACK機制非常類似。消息系統ACK機制可以分為兩部分：
mBroker收到生産者發送的消息并成功存儲這些消息後，傳回成功響應（可以将該成功響應了解為一種ACK）給生産者，這時生産者可以認為消息已經發送成功，否則生産者可能需要做一些補償操作，如重發消息。
m消費者收到Broker投遞的消息并成功處理後，傳回消費成功響應給Broker，Broker收到這些消費成功響應後，可以認為消費者已經成功消費了消息，否則Broker可能需要做一些補償操作，如重新投遞消息。該場景下消費者通常需要将消費成功的消息位置（或者消息Id等）發送給Broker，并且Broker需要存儲這些消費成功的位置，以便後續消費者重新開機後從該位置繼續消費。該場景也是我們關注的重點。
在Kafka中，每個消息都存在一個偏移量offset，如果将一個Kafka主題了解為一個簡單的消息數組，那麼可以将消息偏移量了解為該消息在該數組中的索引。消費者會将最新消費成功的消息的下一個偏移量發送給Broker（代表該偏移量前面的消息都已經消費成功），Broker會存儲這些偏移量，以記錄消費者的最新消費位置。為了友善描述，本書後面将消費者送出ACK資訊中的偏移量稱為ACK偏移量。
另外，Kafka與Pulsar都使用ZooKeeper存儲中繼資料，完成分布式協作等操作，ZooKeeper是一種分布式協作服務，專注于協作多個分布式程序之間的活動，可以幫助開發人員專注于應用程式的核心邏輯，而不必擔心應用程式的分布式特性。本書後面會詳細分析ZooKeeper為Kafka與Pulsar提供了哪些服務。Kafka 2.8開始提供KRaft子產品，支援Kafka脫離ZooKeeper獨立運作部署，本書後面也會詳細分析該子產品的設計與實作。
下圖展示了Kafka叢集的基礎架構
下面介紹Pulsar的基礎概念
- Pulsar訂閱組：Pulsar可以将多個消費者綁定到一個訂閱組中，類似于Kafka的消費組。同樣使用前面“使用者服務”的例子進行說明，在Pulsar中，權益服務所有的消費者都可以綁定一個權益訂閱組rightsSubscription，而權限服務所有的消費者都可以綁定一個權限訂閱組guthoritySubscription，不同訂閱組之間消費消息互不幹預。
- 非分區主題、分區主題：Kafka中每個分區都與一個Broker綁定，而Pulsar中每個主題都與一個Broker綁定，某主題的消息固定發送給相應的Broker節點。而Pulsar中也有“分區主題”的概念，分區主題由一組非分區的内部主題組成（下面将Pulsar中組成分區主題的非分區内部主題簡稱為内部主題），每一個内部主題都與一個Broker綁定，這樣一個分區主題可以将消息發送到多個Broker，避免Pulsar單個主題的性能受限于單個Broker節點。
- Broker：Pulsar叢集中的服務節點。需要注意，Pulsar由于采用計算、存儲分離的架構，是以Pulsar Broker節點隻負責計算，并不負責存儲，Pulsar Broker節點會完成資料檢驗、負載均衡等工作，并将消息轉發給Bookie節點。
- Bookie：Pulsar利用BookKeeper服務實作存儲功能，BookKeeper中的節點被稱為Bookie節點。BookKeeper架構是一個分布式日志存儲服務架構，本書後面會詳細分析它。Pulsar中的Bookie節點負責完成消息存儲工作。
- Ledger：BookKeeper的資料集合，生産者會将資料寫入Ledger，而消費者從Ledger中讀取資料。為了資料安全，BookKeeper會将一個Ledger的資料存儲到多個Bookie節點中，實作資料備份。
- Entry：Ledger中的資料單元，Ledger中的每個資料都是一個Entry。可以将Ledger了解為一個賬本，Entry則是賬本中的一個條目。
- 租戶、命名空間：Pulsar定義了租戶、命名空間的概念，Pulsar是一個多租戶系統，它給不同的租戶配置設定不同的資源，并保證不同租戶之間的資料互相隔離，互不幹預，這樣可以支援多團隊、多使用者同時使用一個Pulsar服務。每個租戶還可以建立多個命名空間，命名空間為主題的邏輯分組。可以将Pulsar了解為一個大房子，每個租戶是房子裡的一個房間，并且這個房間的空間劃分為不同的區域（命名空間），不同區域存放不同的物件。例如，使用者服務可以建立一個租戶“user”，存儲使用者服務的消息。該租戶可以按自己的業務場景，建立多個命名空間，存放不同的主題，如下圖所示。
- Cluster叢集：Pulsar為叢集定義了一個Cluster概念，每個Pulsar Broker節點都運作在一個Cluster叢集下，不同的Cluster叢集之間可以互相複制資料，進而實作跨地域複制。
- ACK機制：與Kafka類似，Pulsar同樣需要完成“Broker存儲消息後傳回成功響應給生産者”“消費者成功處理消息後發送ACK給Broker”。Pulsar中的每個消息都有一個消息Id，Pulsar消費者會将消費成功的消息Id作為ACK請求内容發送給Broker。
下圖展示了Pulsar叢集的基礎架構。
本文介紹了Kafka與Pulsar的起源發展與系統特性，以及Kafka與Pulsar中最基本的核心概念。
原文連結：https://mp.weixin.qq.com/s/kDz-33e1RrFUfeghEBEAsw