深入理解Kafka核心設計及原理（一）：初始Kafka
轉載請註明出處：
1.1 kafka簡介
Kafka 起初是由 Linkedin 公司採用 Scala 語言開發的一個多分割槽、多副本且基於 ZooKeeper協調的分散式訊息系統，現己被捐獻給 Apache 基金會 。 目前 Kafka 已經定位為一個分散式流式處理平臺，它以高吞吐、可持久化、可水平擴充套件、支援流資料處理等多種特性而被廣泛使用。
1.2 Kafka應用角色
目前越來越多的開源分散式處理系統如 C loudera 、Storm 、Spark 、Flink 等都支援與 Kafka 整合 。Kafka 之所以受到越來越多 的青睞，與它所“扮演 ”的三大角色是分不開的 ：
訊息系統： Kafka 和傳統的訊息系統（也稱作訊息中介軟體〉都具備系統解稿、冗餘儲存、流量削 峰、緩衝、非同步通訊、擴充套件性、 可恢復性等功能。與此同時，Kafka 還提供了大多數訊息系統難以實現的訊息順序性保障及回溯消費 的功能 。
儲存系統： Kafka 把訊息持久化到磁碟，相比於其他基於記憶體儲存的系統而言，有效地降低了資料丟失的風險 。 也正是得益於 Kafka 的訊息持久化功能和多副本機制，我們可以把 Kafka 作為長期的資料儲存系統來使用，只需要把對應的資料保留策略設定為“永久”或啟用主題的日誌壓縮功能即可 。
流式處理平臺： Kafka 不僅為每個流行的流式處理框架提供了可靠的資料來源，還提供了一個完整的流式處理類庫，比如視窗、連線、變換和聚合等各類操作 。
1.3 Kafka體系結構——Producer/Consumer/Broker
整個 Kafka 體系結構中引入了以下 3 個術語。：
( 1 ) Producer ：生產者，也就是傳送訊息的一方。生產者負責建立訊息 ， 然後將其投遞到Kafka 中 。
( 2) Consumer：消費者，也就是接收訊息的一方。消費者連線到 Kafka 上並接收訊息，進而進行相應的業務邏輯處理 。
(3) Broker：服務代理節點。對於 Kafka 而言，Broker 可以簡單地看作一個獨立的 Kafka服務節點或 Kafka 服務例項。大多數情況下也可以將 Broker 看作一臺 Kafka 伺服器，前提是這臺伺服器上只部署了一個 Kafka 例項。一個或多個 Broker 組成了 一個 Kafka 叢集 。一般而言，我們更習慣使用首字母小寫的 broker 來表示服務代理節點。
1.4 Kafka高可用，高可靠——主題/分割槽/副本
在 Kafka 中還有兩個特別重要的概念一一主題（ Topic ）與分割槽（ Partition ）。 Kafka 中的訊息以主題為單位進行歸類，生產者負責將訊息傳送到特定的主題（傳送到 Kafka 叢集中的每一 條訊息都要指定一個主題），而消費者負責訂閱主題並進行消費。 主題是一個邏輯上的概念，它還可以細分為多個分割槽，一個分割槽只屬於單個主題，很多時候也會把分割槽稱為主題分割槽（ Topic-Partition ）。同一主題下的不同分割槽包含的訊息是不同的，分割槽在儲存層面可以看作一個可追加的日誌（ Log ）檔案，訊息在被追加到分割槽日誌、檔案的時候都會分配一個特定的偏移量（ offset ）。offset 是訊息在分割槽中的唯一標識，Kafka 通過它來保證訊息在分割槽內的順序性，不過 offset 並不跨越分割槽，也就是說，Kafka 保證的是分割槽有序而不是主題有序。
每一條訊息被髮送到 broker 之前，會根據分割槽規則選擇儲存到哪個具體的分割槽 。 如果分割槽規則設定得合理，所有的訊息都可以均勻地分配到不同的分割槽中 。 如果一個主題只對應一個檔案，那麼這個檔案所在的機器I/O 將會成為這個主題的效能瓶頸，而分割槽解決了這個問題 。 在建立主題的時候可以通過指定的引數來設定分割槽的個數，當然也可以在主題建立完成之後去修改分割槽的數量，通過增加分割槽的數量可以實現水平擴充套件。 Kafka 為分割槽引入了多副本（ Replica ） 機制，通過增加副本數量可以提升容災能力。同一分割槽的不同副本中儲存的是相同的訊息（在同一時刻，副本之間並非完全一樣），副本之間是“ 一主多從”的關係，其中 leader 副本負責處理讀寫請求 ，follower 副本只負 責與 leader 副本的訊息同步，很多時候 follower 副本中的訊息相對 leader副本而言會有一定的滯後。副本處於不同的 broker 中 ，當 leader 副本出現故障時，從 fo llower 副本中重新選舉新的 leader 副本對外提供服務。 Kafka 通過多副本機制實現了故障的自動轉移，當 Kafka 叢集中某個 broker 失效時仍然能保證服務可用 。
Kafka 消費端也具備一定 的容災能力。Consumer 使用拉（ Pull ）模式從服務端拉取訊息，並且儲存消費 的具體位置 ，當消費者看機後恢復上線時可以根據之前儲存的消費位置重新拉取需要的訊息進行消 費 ，這樣就不會造成訊息丟失 。 分割槽中 的所有副本統稱為 AR (Assigned Replicas ）。 所有與 leader 副本保持一定程度同步的副本（包括 leader 副本在內〕組成 ISR On-Sync Replicas ) , ISR 集合是 AR 集合中 的一個子集 。 訊息會先發送到 lead巳r 副本，然後 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 值加l 。分割槽 ISR 集合中的每個副本都會維護自身的 LEO ，而 ISR 集合中最小的 LEO即為分割槽的 HW ，對消費者而言只能消費 HW 之前的訊息 。（高水位可理解為多個副本中最小的offset位移量）
1.5 Kafka 與 zookeeper
ZooKeeper 是一個開源的分散式協調服務，是 Google Chubby 的一個開源實現。分散式應用程式可 以基於 ZooKeeper 實現諸如資料釋出／訂閱 、負載均衡、 命名 服務、分散式協調／通知 、 叢集管理、 Master 選舉、配置維護等功能。在 ZooKeeper 中共有 3 個角色： leader 、 follower 和 obsever ;同一時刻ZooKeeper 叢集中只會有一個 leader，其他的都是 follower 和 obsever ;obsever 不參與投票，預設情況下ZooKeeper 中只有 leader 和follower 兩個角色。