Kafka 起初是 由 LinkedIn 公司採用 Scala 語言開發的一個多分區、多副本且基於 ZooKeeper 協調的分佈式消息系統，現已被捐獻給 Apache 基金會。目前 Kafka 已經定位為一個分佈式流式處理平臺，它以高吞吐、可持久化、可水平擴展、支持流數據處理等多種特性而被廣泛使用。目前越來越多的開源分佈式處理系統如 Cloudera、Storm、Spark、Flink 等都支持與 Kafka 集成。
Kafka 之所以受到越來越多的青睞，與它所“扮演”的三大角色是分不開的：
- 消息系統： Kafka 和傳統的消息系統（也稱作消息中間件）都具備系統解耦、冗餘存儲、流量削峰、緩衝、異步通信、擴展性、可恢復性等功能。與此同時，Kafka 還提供了大多數消息系統難以實現的消息順序性保障及回溯消費的功能。
- 存儲系統： Kafka 把消息持久化到磁盤，相比於其他基於內存存儲的系統而言，有效地降低了數據丟失的風險。也正是得益於 Kafka 的消息持久化功能和多副本機制，我們可以把 Kafka 作為長期的數據存儲系統來使用，只需要把對應的數據保留策略設置為“永久”或啟用主題的日誌壓縮功能即可。
- 流式處理平臺： Kafka 不僅為每個流行的流式處理框架提供了可靠的數據來源，還提供了一個完整的流式處理類庫，比如窗口、連接、變換和聚合等各類操作。
基本概念
一個典型的 Kafka 體系架構包括若干 Producer、若干 Broker、若干 Consumer，以及一個 ZooKeeper 集群，如下圖所示。其中 ZooKeeper 是 Kafka 用來負責集群元數據的管理、控制器的選舉等操作的。Producer 將消息發送到 Broker，Broker 負責將收到的消息存儲到磁盤中，而 Consumer 負責從 Broker 訂閱並消費消息。
整個 Kafka 體系結構中引入了以下3個術語：
- Producer： 生產者，也就是發送消息的一方。生產者負責創建消息，然後將其投遞到 Kafka 中。
- Consumer： 消費者，也就是接收消息的一方。消費者連接到 Kafka 上並接收消息，進而進行相應的業務邏輯處理。
- Broker： 服務代理節點。對於 Kafka 而言，Broker 可以簡單地看作一個獨立的 Kafka 服務節點或 Kafka 服務實例。大多數情況下也可以將 Broker 看作一臺 Kafka 服務器，前提是這臺服務器上只部署了一個 Kafka 實例。一個或多個 Broker 組成了一個 Kafka 集群。一般而言，我們更習慣使用首字母小寫的 broker 來表示服務代理節點。
在 Kafka 中還有兩個特別重要的概念—主題（Topic）與分區（Partition）。Kafka 中的消息以主題為單位進行歸類，生產者負責將消息發送到特定的主題（發送到 Kafka 集群中的每一條消息都要指定一個主題），而消費者負責訂閱主題並進行消費。
主題是一個邏輯上的概念，它還可以細分為多個分區，一個分區只屬於單個主題，很多時候也會把分區稱為主題分區（Topic-Partition）。同一主題下的不同分區包含的消息是不同的，分區在存儲層面可以看作一個可追加的日誌（Log）文件，消息在被追加到分區日誌文件的時候都會分配一個特定的偏移量（offset）。
offset 是消息在分區中的唯一標識，Kafka 通過它來保證消息在分區內的順序性，不過 offset 並不跨越分區，也就是說，Kafka 保證的是分區有序而不是主題有序。
如上圖所示，主題中有4個分區，消息被順序追加到每個分區日誌文件的尾部。Kafka 中的分區可以分佈在不同的服務器（broker）上，也就是說，一個主題可以橫跨多個 broker，以此來提供比單個 broker 更強大的性能。
每一條消息被髮送到 broker 之前，會根據分區規則選擇存儲到哪個具體的分區。如果分區規則設定得合理，所有的消息都可以均勻地分配到不同的分區中。如果一個主題只對應一個文件，那麼這個文件所在的機器I/O將會成為這個主題的性能瓶頸，而分區解決了這個問題。在創建主題的時候可以通過指定的參數來設置分區的個數，當然也可以在主題創建完成之後去修改分區的數量，通過增加分區的數量可以實現水平擴展。
Kafka 為分區引入了多副本（Replica）機制，通過增加副本數量可以提升容災能力。
同一分區的不同副本中保存的是相同的消息（在同一時刻，副本之間並非完全一樣），副本之間是“一主多從”的關係，其中 leader 副本負責處理讀寫請求，follower 副本只負責與 leader 副本的消息同步。副本處於不同的 broker 中，當 leader 副本出現故障時，從 follower 副本中重新選舉新的 leader 副本對外提供服務。Kafka 通過多副本機制實現了故障的自動轉移，當 Kafka 集群中某個 broker 失效時仍然能保證服務可用。
如上圖所示，Kafka 集群中有4個 broker，某個主題中有3個分區，且副本因子（即副本個數）也為3，如此每個分區便有1個 leader 副本和2個 follower 副本。生產者和消費者只與 leader 副本進行交互，而 follower 副本只負責消息的同步，很多時候 follower 副本中的消息相對 leader 副本而言會有一定的滯後。
Kafka 消費端也具備一定的容災能力。Consumer 使用拉（Pull）模式從服務端拉取消息，並且保存消費的具體位置，當消費者宕機後恢復上線時可以根據之前保存的消費位置重新拉取需要的消息進行消費，這樣就不會造成消息丟失。
分區中的所有副本統稱為 AR（Assigned Replicas）。所有與 leader 副本保持一定程度同步的副本（包括 leader 副本在內）組成ISR（In-Sync Replicas），ISR 集合是 AR 集合中的一個子集。消息會先發送到 leader 副本，然後 follower 副本才能從 leader 副本中拉取消息進行同步，同步期間內 follower 副本相對於 leader 副本而言會有一定程度的滯後。
前面所說的“一定程度的同步”是指可忍受的滯後範圍，這個範圍可以通過參數進行配置。與 leader 副本同步滯後過多的副本（不包括 leader 副本）組成 OSR（Out-of-Sync Replicas），由此可見，AR=ISR+OSR。在正常情況下，所有的 follower 副本都應該與 leader 副本保持一定程度的同步，即 AR=ISR，OSR 集合為空。
leader 副本負責維護和跟蹤 ISR 集合中所有 follower 副本的滯後狀態，當 follower 副本落後太多或失效時，leader 副本會把它從 ISR 集合中剔除。如果 OSR 集合中有 follower 副本“追上”了 leader 副本，那麼 leader 副本會把它從 OSR 集合轉移至 ISR 集合。默認情況下，當 leader 副本發生故障時，只有在 ISR 集合中的副本才有資格被選舉為新的 leader，而在 OSR 集合中的副本則沒有任何機會（不過這個原則也可以通過修改相應的參數配置來改變）。
ISR 與 HW 和 LEO 也有緊密的關係。HW 是 High Watermark 的縮寫，俗稱高水位，它標識了一個特定的消息偏移量（offset），消費者只能拉取到這個 offset 之前的消息。
如上圖所示，它代表一個日誌文件，這個日誌文件中有9條消息，第一條消息的 offset（LogStartOffset）為0，最後一條消息的 offset 為8，offset 為9的消息用虛線框表示，代表下一條待寫入的消息。日誌文件的 HW 為6，表示消費者只能拉取到 offset 在0至5之間的消息，而 offset 為6的消息對消費者而言是不可見的。
LEO 是 Log End Offset 的縮寫，它標識當前日誌文件中下一條待寫入消息的 offset，上圖中 offset 為9的位置即為當前日誌文件的 LEO，LEO 的大小相當於當前日誌分區中最後一條消息的 offset 值加1。分區 ISR 集合中的每個副本都會維護自身的 LEO，而 ISR 集合中最小的 LEO 即為分區的 HW，對消費者而言只能消費 HW 之前的消息。
注意要點：很多資料中誤將上圖中的 offset 為5的位置看作 HW，而把 offset 為8的位置看作 LEO，這顯然是不對的。
為了讓讀者更好地理解 ISR 集合，以及 HW 和 LEO 之間的關係，下面通過一個簡單的示例來進行相關的說明。如上圖所示，假設某個分區的 ISR 集合中有3個副本，即一個 leader 副本和2個 follower 副本，此時分區的 LEO 和 HW 都為3。消息3和消息4從生產者發出之後會被先存入 leader 副本，如下圖所示。
在消息寫入 leader 副本之後，follower 副本會發送拉取請求來拉取消息3和消息4以進行消息同步。
在同步過程中，不同的 follower 副本的同步效率也不盡相同。如上圖所示，在某一時刻 follower1 完全跟上了 leader 副本而 follower2 只同步了消息3，如此 leader 副本的 LEO 為5，follower1 的 LEO 為5，follower2 的 LEO 為4，那麼當前分區的 HW 取最小值4，此時消費者可以消費到 offset 為0至3之間的消息。
寫入消息（情形4）如下圖所示，所有的副本都成功寫入了消息3和消息4，整個分區的 HW 和 LEO 都變為5，因此消費者可以消費到 offset 為4的消息了。
由此可見，Kafka 的複製機制既不是完全的同步複製，也不是單純的異步複製。事實上，同步複製要求所有能工作的 follower 副本都複製完，這條消息才會被確認為已成功提交，這種複製方式極大地影響了性能。而在異步複製方式下，follower 副本異步地從 leader 副本中複製數據，數據只要被 leader 副本寫入就被認為已經成功提交。在這種情況下，如果 follower 副本都還沒有複製完而落後於 leader 副本，突然 leader 副本宕機，則會造成數據丟失。Kafka 使用的這種 ISR 的方式則有效地權衡了數據可靠性和性能之間的關係。
關注我，私信回覆“資料”獲取面試寶典《Java核心知識點整理.pdf》“，覆蓋了JVM、鎖、高併發、反射、Spring原理、微服務、Zookeeper、數據庫、數據結構等等”，還有Java208道面試題（含答案）的免費領取方式！
閱讀更多 互聯網Java填坑之路 的文章
