kafka 初识
引言
Kafka 起初是 由 LinkedIn 公司采用 Scala 語言開發的一個 多分區、多副本且基于 ZooKeeper 協調 的分布式消息系統，現已被捐獻給 Apache 基金會。目前 Kafka 已經定位為一個 分布式流式處理平臺，它以 高吞吐、可持久化 、可水平擴展、支持流數據處理 等多種特性而被廣泛使用。目前越來越多的開源分布式處理系統如 Cloudera、Storm、Spark、Flink 等都支持與 Kafka 集成。
kafka 應用面
目前 kafka 在企業應用中主要體現在三塊：消息系統，存儲系統，流式處理平臺；其中，消息系統和流式處理平臺應用最為廣泛。
消息系統
Kafka 和其他消息中間件（RabbitMQ，RocketMQ......）都具備 系統解耦、異步通信、流量削峰、 緩沖、冗余存儲、擴展性、可恢復性等功能。與此同時，Kafka 還提供了大多數消息系統難以實現的 消息順序性保障 及 回溯消費的功能 。
存儲系統
Kafka 把消息持久化到磁盤，相比于其他基于內存存儲的系統而言，有效地降低了數據丟失的風險。也正是得益于 Kafka 的 消息持久化功能 和 多副本機制 ，我們可以把 Kafka 作為長期的數據存儲系統來使用，只需要把對應的數據保留策略設置為“永久”或啟用主題的日志壓縮功能即可。
流式處理平臺
Kafka 不僅為每個流行的流式處理框架提供了可靠的數據來源，還提供了一個完整的流式處理類庫，比如窗口、連接、變換和聚合等各類操作。
kafka 基本組成
一個典型的 Kafka 體系架構包括 若干 Producer、若干 Broker、若干 Consumer，以及一個 ZooKeeper 集群，如下圖所示。
其中各個組成部分的作用分別是：
Zookeeper
ZooKeeper 是 Kafka 用來負責 集群元數據的管理、控制器的選舉 等操作的。
Producer
Producer 負責創建消息，然后將消息發送到 Broker。
Broker
Broker 負責將收到的消息存儲到磁盤中。對于 Kafka 而言，Broker 可以簡單地看作一個獨立的 Kafka 服務節點或者是一個 kafka 服務。一個或多個 Broker 組成了一個 Kafka 集群。
Consumer
Consumer 負責從 Broker 訂閱并消費消息。
整個 Kafka 體系結構中除了上面描述的幾個組成部分之外，還有兩個特別重要的概念— 主題（Topic） 與 分區（Partition） 。Kafka 中的消息以主題為單位進行歸類，生產者負責將消息發送到特定的主題（發送到 Kafka 集群中的每一條消息都要指定一個主題），而消費者負責訂閱主題并進行消費。
Topic & Partition
1、 主題是一個邏輯上的概念，它還可以細分為多個分區，一個分區只屬于單個主題。
2、 同一主題下的不同分區包含的消息是不同的，分區在存儲層面可以看作一個 可追加的日志（Log）文件，消息在被追加到分區日志文件的時候都會分配一個特定的偏移量（offset）。
3、 offset 是消息在分區中的唯一標識，Kafka 通過它來保證消息在分區內的順序性，不過 offset 并不跨越分區，也就是說， Kafka 保證的是分區有序 而不是主題有序。
如上圖所示，主題中有 4 個分區，消息被順序追加到每個分區日志文件的尾部。Kafka 中的分區可以分布在不同的服務器（broker） 上，也就是說，一個主題可以橫跨多個 broker ，以此來提供比單個 broker 更強大的性能。
每一條消息被發送到 broker 之前，會根據分區規則選擇存儲到哪個具體的分區。如果分區規則設定得合理，所有的消息都可以均勻地分配到不同的分區中。如果一個主題只對應一個文件，那么這個文件所在的機器 I/O 將會成為這個主題的性能瓶頸，而分區解決了這個問題。在創建主題的時候可以通過指定的參數來設置分區的個數，當然也可以在主題創建完成之后去修改分區的數量，通過增加分區的數量可以實現水平擴展。
Partition 的多副本機制
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 消費端的容災能力
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 集合中的副本則沒有任何機會（不過這個原則也可以通過修改相應的參數配置來改變）。
HW & LEO
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 個副本，即 1 個 leader 副本和 2 個 follower 副本，此時分區的 LEO 和 HW 都為 3。消息 3 和消息 4 從生產者發出之后會被先存入 leader 副本，如下圖所示。
在消息寫入 leader 副本之后，follower 副本會發送拉取請求來拉取消息 3 和消息 4 以進行消息同步（這里有一個疑問： follower 副本是定時去 leader 副本中拉數據進行同步，還是 leader 副本有新消息進入后通知 follower 副本來拉消息）。
在同步過程中，不同的 follower 副本的同步效率也不盡相同。如上圖所示，在某一時刻 follower1 完全跟上了 leader 副本而 follower 2 只同步了消息 3，如此 leader 副本的 LEO 為 5，follower 1 的 LEO 為 5，follower 2 的 LEO 為 4，那么當前分區的 HW 取最小值 4，此時消費者可以消費到 offset 為 0 至 3 之間的消息。
小貼士：消費者能夠消費到的消息一定是分區中 ISR 副本已經同步完成的消息，這種方式就很好了規避了有一些同步滯后的副本同步速度慢的問題，從而影響性能。
寫入消息（情形 4）如下圖所示，所有的副本都成功寫入了消息 3 和消息 4，整個分區的 HW 和 LEO 都變為 5，因此消費者可以消費到 offset 為 4 的消息了。
由此可見，Kafka 的復制機制既不是完全的同步復制，也不是單純的異步復制。事實上，同步復制要求所有能工作的 follower 副本都復制完，這條消息才會被確認為已成功提交，這種復制方式極大地影響了性能。而在異步復制方式下，follower 副本異步地從 leader 副本中復制數據，數據只要被 leader 副本寫入就被認為已經成功提交。在這種情況下，如果 follower 副本都還沒有復制完而落后于 leader 副本，突然 leader 副本宕機，則會造成數據丟失。Kafka 使用的這種 ISR 的 HW 和 LEO 方式 則有效地權衡了 數據可靠性和性能之間的關系 。
轉載于:https://www.cnblogs.com/tkzL/p/11414185.html
總結
- 上一篇： 程序员版《后浪》
- 下一篇： spring核心之IOC