轉載請注明出處：
1.1 kafka簡介
Kafka 起初是由 Linkedin 公司采用 Scala 語言開發的一個多分區、多副本且基於 ZooKeeper協調的分布式消息系統，現己被捐獻給 Apache 基金會 。 目前 Kafka 已經定位為一個分布式流式處理平台，它以高吞吐、可持久化、可水平擴展、支持流數據處理等多種特性而被廣泛使用。
1.2 Kafka應用角色
目前越來越多的開源分布式處理系統如 Cloudera 、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 集合中 的一個子集 。 消息會先發送到 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 值加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 兩個角色。
深入理解Kafka核心設計及原理（六）：Controller選舉機制，分區副本leader選舉機制，再均衡機制