Kakfa在大資料訊息引擎領域，絕對是沒有爭議的國民老公。
這是kafka系列的第一篇文章。預計共出20篇系列文章，全部原創，從0到1，跟你一起死磕kafka。
本文盤點了 Kafka 的各種術語並且進行解讀，術語可能比較枯燥，但真的是精髓中的精髓！
瞭解Kafka之前我們必須先掌握它的相關概念和術語，這對於後面深入學習 Kafka 各種功能將大有裨益。所以，枯燥你也得給我看完！
大概是有這麼些東西要掌握，不多不多，預計20分鐘可以吃透：
主題層
主題層有三個兒子，分別叫做:Topic、Partition、Replica。既然我說是三個兒子，那你懂了，是不可分割的整體。
Topic（主題）
Kafka 是分散式的訊息引擎系統，它的主要功能是提供一套完備的訊息（Message）釋出與訂閱解決方案。
在 Kafka 中，釋出訂閱的物件是主題（Topic），你可以為每個業務、每個應用甚至是每類資料都建立專屬的主題。
一個Topic是對一組訊息的歸納。也可以理解成傳統資料庫裡的表，或者檔案系統裡的一個目錄。
Partition（分割槽）
一個Topic通常都是由多個partition組成的，建立topic時候可以指定partition數量。
? 分割槽優勢
為什麼需要將Topic分割槽呢？如果你瞭解其他分散式系統，你可能聽說過分片、分割槽域等說法，比如 MongoDB 和 Elasticsearch 中的 Sharding、HBase 中的 Region，其實它們都是相同的原理。
試想，如果一個Topic積累了太多的資料以至於單臺 Broker 機器都無法容納了，此時應該怎麼辦呢？
一個很自然的想法就是，能否把資料分割成多份儲存在不同的機器上？這不就是分割槽的作用嗎？其實就是解決伸縮性的問題，每個partition都可以放在獨立的伺服器上。
當然優勢不僅於此，也可以提高吞吐量。kafka只允許單個partition的資料被一個consumer執行緒消費。因此，在consumer端，consumer並行度完全依賴於被消費的分割槽數量。綜上所述，通常情況下，在一個Kafka叢集中，partition的數量越多，意味著可以到達的吞吐量越大。
? partition結構
每個partition對應於一個資料夾，該資料夾下儲存該partition的資料和索引檔案。
如圖所示,可以看到兩個資料夾，都對應著一個叫做asd的topic，在該臺伺服器上有兩個分割槽，0和2，那麼1呢？在其他伺服器上啦！畢竟是分散式分佈的！
我們進去asd-0目錄中看看是什麼？有字尾為.index和.log的檔案，他們就是該partition的資料和索引檔案：
現在先不管它們是何方神聖，因為我會在【分割槽機制原理】這篇文章中詳細描述。
? partition順序性
現在，我需要你睜大眼睛看看關於分割槽非常重要的一點：
【每個partition內部保證訊息的順序。但是分割槽之間是不保證順序的】
這一點很重要，例如kafka中的訊息是某個業務庫的資料，mysql binlog是有先後順序的，10:01分我沒有付款，所以pay_date為null，而10:02分我付款了，pay_date被更新了。
但到了kafka那，由於是分散式的，多分割槽的，可就不一定能保證順序了，也許10:02分那條先來，這樣可就會引發嚴重生產問題了。因此，一般我們需要按表+主鍵來分割槽。保證同一主鍵的資料傳送到同一個分割槽中。
如果你想要 kafka 中的所有資料都按照時間的先後順序進行儲存，那麼可以設定分割槽數為 1。
Replica （副本）
每個partition可以配置若干個副本。Kafka 定義了兩類副本：領導者副本（Leader Replica）和追隨者副本（Follower Replica）。只能有 1 個領導者副本和 N-1 個追隨者副本。
為啥要用副本？也很好理解，反問下自己為什麼重要的檔案需要備份多份呢？備份機制（Replication）是實現高可用的一個手段。
需要注意的是：僅Leader Replica對外提供服務，與客戶端程式進行互動，生產者總是向領導者副本寫訊息，而消費者總是從領導者副本讀訊息。而Follower Replica不能與外界進行互動，它只做一件事：向領導者副本傳送請求，請求領導者把最新生產的訊息發給它，保持與領導者的同步。
如果對於剛剛所說的主題、分割槽、副本還有疑惑，那麼結合下面這張圖再思考一下，我相信你就可以玩轉它了：
下圖所示，TopicA，具有三個partition，每個partion都有1 個leader副本和 1 個follower者副本。為了保證高可用性，一臺機器當機不會有影響，因此leader副本和follower副本必然分佈在不同的機器上。
訊息層
Kafka的官方定義是message system，由此我們可以知道Kafka 中最基本的資料單元無疑是訊息message，它可理解成資料庫裡的一條行或者一條記錄。訊息是由字元陣列組成。關於訊息你必須知道這幾件事：
? 訊息key
傳送訊息的時候指定 key，這個 key 也是個字元陣列。key 用來確定訊息寫入分割槽時，進入哪一個分割槽。你可以用有明確業務含義的欄位作為key，比如使用者號，這樣就可以保證同一個使用者號進入同一個分割槽。
? 批量寫入
為了提高效率， Kafka 以批量batch的方式寫入。
一個 batch 就是一組訊息的集合， 這一組的資料都會進入同一個 topic 和 partition（這個是根據 producer 的配置來定的） 。
每一個訊息都進行一次網路傳輸會很消耗效能，因此把訊息收集到一起再同時處理就高效的多。
當然，這樣會引入更高的延遲以及吞吐量：batch 越大，同一時間處理的訊息就越多。batch 通常都會進行壓縮，這樣在傳輸以及儲存的時候效率都更高一些。
? 位移
生產者向分割槽寫入訊息，每條訊息在分割槽中的位置資訊由一個叫位移（Offset）的資料來表徵。分割槽位移總是從 0 開始，假設一個生產者向一個空分割槽寫入了 10 條訊息，那麼這 10 條訊息的位移依次是 0、1、2、…、9。
服務端
Kafka 的伺服器端由被稱為 Broker 的服務程式構成，即一個 Kafka 叢集由多個 Broker 組成，Kafka支援水平擴充套件，broker數量越多，叢集吞吐量越高。在叢集中每個broker都有一個唯一brokerid，不得重複。Broker 負責接收和處理客戶端傳送過來的請求，以及對訊息進行持久化。
一般會將不同的 Broker 分散執行在不同的機器上，這樣如果叢集中某一臺機器當機，kafka可以自動選舉出其他機器上的 Broker 繼續對外提供服務。這其實就是 Kafka 提供高可用的手段之一。
? controller
Kafka叢集中會有一個或者多個broker，其中有且僅有一個broker會被選舉為控制器（Kafka Controller），它負責管理整個叢集中所有分割槽和副本的狀態。
當某個分割槽的leader副本出現故障時，由控制器負責為該分割槽選舉新的leader副本。當檢測到某個分割槽的ISR集合發生變化時，由控制器負責通知所有broker更新其後設資料資訊。當為某個topic增加分割槽數量時，同樣還是由控制器負責分割槽的重新分配。
這幾句話可能會讓你覺得困惑不要方 只是突出下控制器的職能很多，而這些功能的具體細節會在後面的文章中做具體的介紹。
Kafka中的控制器選舉的工作依賴於Zookeeper，成功競選為控制器的broker會在Zookeeper中建立/controller這個臨時（EPHEMERAL）節點，此臨時節點的內容參考如下：
其中version在目前版本中固定為1，brokerid表示稱為控制器的broker的id編號，timestamp表示競選稱為控制器時的時間戳。
兩種客戶端
Kafka有兩種客戶端。生產者和消費者。我們把生產者和消費者統稱為客戶端（Clients）。
向主題Topic釋出訊息Message的客戶端應用程式稱為生產者（Producer），生產者程式通常持續不斷地向一個或多個主題傳送訊息。
而訂閱這些主題訊息的客戶端應用程式就被稱為消費者（Consumer）。和生產者類似，消費者也能夠同時訂閱多個主題的訊息。
Producer
Producer 用來建立Message。在釋出訂閱系統中，他們也被叫做 Publisher 釋出者或 writer 寫作者。
通常情況下，會發布到特定的Topic，並負責決定釋出到哪個分割槽（通常簡單的由負載均衡機制隨機選擇，或者通過key，或者通過特定的分割槽函式選擇分割槽。）
Producer分為Sync Producer 和 Aync Producer。
Sync Producer同步的生產者，即一定要某條訊息成功才會傳送下一條。所以它是低吞吐率、一般不會出現資料丟失。
Aync Producer非同步的生產者，有個佇列的概念，是直接傳送到佇列裡面，批量傳送。高吞吐率、可能有資料丟失的。
Consumer 和 Consumer Group
? 消費者
Consumer 讀取訊息。在釋出訂閱系統中，也叫做 subscriber 訂閱者或者 reader 閱讀者。消費者訂閱一個或者多個主題，然後按照順序讀取主題中的資料。
? 消費位移
消費者需要記錄消費進度，即消費到了哪個分割槽的哪個位置上，這是消費者位移（Consumer Offset）。注意，這和上面所說的訊息在分割槽上的位移完全不是一個概念。上面的“位移”表徵的是分割槽內的訊息位置，它是不變的，即一旦訊息被成功寫入到一個分割槽上，它的位移值就是固定的了。
而消費者位移則不同，它可能是隨時變化的，畢竟它是消費者消費進度的指示器嘛。通過儲存最後消費的 Offset，消費者應用在重啟或者停止之後，還可以繼續從之前的位置讀取。儲存的機制可以是 zookeeper,或者 kafka 自己。
? 消費者組
ConsumerGroup：消費者組，指的是多個消費者例項組成一個組來消費一組主題，分割槽只能被消費者組中的其中一個消費者去消費，組員之間不能重複消費。
為什麼要引入消費者組呢？主要是為了提升消費者端的吞吐量。多個消費者例項同時消費，加速整個消費端的吞吐量（TPS）。
當然它的作用不僅僅是瓜分訂閱主題的資料，加速消費。它們還能彼此協助。假設組內某個例項掛掉了，Kafka 能夠自動檢測到，然後把這個 Failed 例項之前負責的分割槽轉移給其他活著的消費者，這個過程稱之為重平衡(Rebalance)。
你務必先把這個詞記住，它是kafka大名鼎鼎的重平衡機制，生產出現的異常問題很多都是由於它導致的。後續我會在【kafka大名鼎鼎又臭名昭著的重平衡】文章中詳細分析。
Zookeeper
zookeeper目前在kafka中扮演著舉重輕重的角色和作用~是kafka不可缺少的一個元件。
目前，Apache Kafka 使用 Apache ZooKeeper 來儲存它的後設資料，比如brokers資訊、分割槽的位置和主題的配置等資料就是儲存在 ZooKeeper 叢集中。
注意我的用詞，我只說是目前。why？在 2019 年社群提出了一個計劃，以打破這種依賴關係，並將後設資料管理引入 Kafka 本身。因為擁有兩個系統會導致大量的重複。
在之前的設計中，我們至少需要執行三個額外的 Java 程式，有時甚至更多。事實上，我們經常看到具有與 Kafka 節點一樣多的 ZooKeeper 節點的 Kafka 叢集！此外，ZooKeeper 中的資料還需要快取在 Kafka 控制器上，這導致了雙重快取。
更糟糕的是，在外部儲存後設資料限制了 Kafka 的可伸縮性。當 Kafka 叢集啟動時，或者一個新的控制器被選中時，控制器必須從 ZooKeeper 載入叢集的完整狀態。隨著後設資料數量的增加，載入過程需要的時間也會增加，這限制了 Kafka 可以儲存的分割槽數量。
最後，將後設資料儲存在外部會增加控制器的記憶體狀態與外部狀態不同步的可能性。
因此，未來，Kafka 的後設資料將儲存在 Kafka 本身中，而不是儲存在 ZooKeeper 之類的外部系統中。可以持續關注kafka社群動態哦！
總結
一個典型的kafka叢集包含若干個producer（向主題釋出新訊息），若干consumer（從主題訂閱新訊息，用Consumer Offset表徵消費者消費進度），cousumergroup（多個消費者例項共同組成的一個組，共同消費多個分割槽），若干broker（伺服器端程式）。還有zookeeper。
kafka釋出訂閱的物件叫主題，每個Topic下可以有多個Partition，Partition中每條訊息的位置資訊又叫做訊息位移(Offset)，Partition有副本機制，使得同一條訊息能夠被拷貝到多個地方以提供資料冗餘，副本分為領導者副本和追隨者副本。
可以用下面這張圖來形象表達kafka的組成：
另外，再po一張思維導圖助你回顧本文所述的術語。
重要！！關注【胖滾豬學程式設計】公眾號傳送"kafka"。獲取本文所有架構圖以及Kafka全系列思維導圖！
本文來源於公眾號：【胖滾豬學程式設計】。一枚集顏值與才華於一身，不算聰明卻足夠努力的女程式媛。用漫畫形式讓程式設計so easy and interesting！求關注！