### 什么是Producer、Consumer、Broker、Topic、Partition？ Kafka 將生產者發布的消息發送到 **Topic（主題）** 中，需要這些消息的消費者可以訂閱這些 **Topic（主題）**，如下圖所示：  上面這張圖也為我們引出了，Kafka 比較重要的幾個概念： 1. **Producer（生產者）** : 產生消息的一方。 2. **Consumer（消費者）** : 消費消息的一方。 3. **Broker（代理）** : 可以看作是一個獨立的 Kafka 實例。多個 Kafka Broker 組成一個 Kafka Cluster。 同時，你一定也注意到每個 Broker 中又包含了 Topic 以及 Partition 這兩個重要的概念： - **Topic（主題）** : Producer 將消息發送到特定的主題，Consumer 通過訂閱特定的 Topic(主題) 來消費消息。 - **Partition（分區）** : Partition 屬于 Topic 的一部分。一個 Topic 可以有多個 Partition ，并且同一 Topic 下的 Partition 可以分布在不同的 Broker 上，這也就表明一個 Topic 可以橫跨多個 Broker 。這正如我上面所畫的圖一樣。 > 劃重點：**Kafka 中的 Partition（分區） 實際上可以對應成為消息隊列中的隊列。這樣是不是更好理解一點？** 我們把生產者和消費者統稱為**客戶端(Clients)**。你可以同時運行多個 生產者和消費者實例，這些實例會不斷地向Kafka集群中的多個主題生產和消費消息 有客戶端自然也就有服務器端。Kafka的服務器端由被稱為**Broker**的服務進程構成，即一個Kafka集群由多個Broker組成，Broker負責接收和處理客戶端發送過來的請求，以及對消息進行持久化。 實現高可用的另一 個手段就是備份機制(Replication)。備份的思想很簡單，就是把相同的數據拷貝到多臺 機器上，而這些相同的數據拷貝在Kafka中被稱為副本(Replica)。好吧，其實在整個分布式系統里好像都 叫這個名字。副本的數量是可以配置的，這些副本保存著相同的數據，但卻有不同的角色和作用。Kafka定 義了兩類副本:領導者副本(Leader Replica)和追隨者副本(Follower Replica)。前者對外提供服務，這 里的對外指的是與客戶端程序進行交互;而后者只是被動地追隨領導者副本而已，不能與外界進行交互。當 然了，你可能知道在很多其他系統中追隨者副本是可以對外提供服務的，比如MySQL的從庫是可以處理讀 操作的，但是在Kafka中追隨者副本不會對外提供服務。對了，一個有意思的事情是現在已經不提倡使用 Master-Slave來指代這種主從關系了，畢竟Slave有奴隸的意思，在美國這種嚴禁種族歧視的國度，這種表 述有點政治不正確了，所以目前大部分的系統都改成Leader-Follower了。 副本的工作機制也很簡單:生產者總是向領導者副本寫消息;而消費者總是從領導者副本讀消息。至于追隨 者副本，它只做一件事:向領導者副本發送請求，請求領導者把最新生產的消息發給它，這樣它能保持與領 導者的同步。 講到這里，你可能有這樣的疑問:剛才提到的副本如何與這里的分區聯系在一起呢?實際上，副本是在分區 這個層級定義的。每個分區下可以配置若干個副本，其中只能有1個領導者副本和N-1個追隨者副本。生產 者向分區寫入消息，每條消息在分區中的位置信息由一個叫位移(Offset)的數據來表征。分區位移總是從 0開始，假設一個生產者向一個空分區寫入了10條消息，那么這10條消息的位移依次是0、 1、2、、9。 ***** 至此我們能夠完整地串聯起Kafka的三層消息架構: ●**第一層是主題層**，每個主題可以配置M個分區，而每個分區又可以配置N個副本 ●**第二層是分區層**，每個分區的N個副本中只能有一個充當領導者角色，對外提供服務;其他N-1個副本是 追隨者副本，只是提供數據冗余之用。 ●**第三層是消息層**，分區中包含若干條消息，每條消息的位移從0開始，依次遞增。 ●**最后**，客戶端程序只能與分區的領導者副本進行交互。 ***** #### KafkaBroker的持久化 講完了消息層次，我們來說說KafkaBroker是如何持久化數據的。 總的來說，Kafka使用**消息日志(Log)**來保存數據，一個日志就是磁盤上一個只能**追加寫(Append-only)消息**的物理文件。**因為只能追加寫入，故避免了緩慢的隨機I/O操作，改為性能較好的順序I/0寫操作，這也是實現Kafka高春吐量特性的一個重要手段**。不過如果你不停地向一個日志寫入消息，最終也會耗盡所有的磁盤空間，因此Kafka必然要定期地刪除消息以回收磁盤。怎么刪除呢?簡單來說就是通過**日志段LogSegment)機制**。在Kafka底層，一個日志又近一步細分成多個日志段，消息被追加寫到當前最新的日志段中，當寫滿了一個日志段后，Kafka會自動切分出一個新的日志段，并將老的日志段封存起來。Kafka在后臺還有定時任務會定期地檢查老的日志段是否能夠被刪除，從而實現回收磁盤空間的目的。 ***** #### 消息模型 我們知道有兩種消息模型，即點對點模型(Peer to Peer,P2P)和發布訂閱模型。這里面的點對點指的是同一條消息只能被下游的一個消費者消費，其他消費者則不能染指。在Kafka中實現這種P2P模型的方法就是引入了**消費者組(Consumer Group)。所謂的消費者組，指的是多個消費者實例共同組成一個組來消費一組主題。這組主題中的每個分區都只會被組內的一個消費者實例消費，其他消費者實例不能消費它。為什么要引入消費者組呢?主要是為了提升消費者端的吞吐量**。多個消費者實例同時消費，加速整個消費端的吞吐量(TPS)。我會在專欄的后面詳細介紹消費者組機制，所以現在你只需要了解消費者組是做什么的即可。另外這里的消費者實例可以是運行消費者應用的進程，也可以是一個線程，它們都稱為一個消費者實例(Consumer Instance)。 消費者組里面的所有消費者實例不僅“瓜分”訂閱主題的數據，而且更酷的是它們還能彼此協助。假設組內 某個實例掛掉了，Kafka能夠自動檢測到，然后把這個Failed實例之前負責的分區轉移給其他活著的消費 者。這個過程就是Kafka中大名鼎鼎的“**重平衡”(Rebalance)**。