1. kafka概述

1.1 kafka簡介

Apache Kafka 是一個快速、可擴展的、高吞吐的、可容錯的分佈式“發佈-訂閱”消息系統，使用 Scala 與 Java 語言編寫，能夠將消息從一個端點傳遞到另一個端點，較之傳統的消息中間件(例如 ActiveMQ、RabbitMQ)，Kafka 具有高吞吐量、內置分區、支持消息副本和高容錯的特性，非常適合大規模消息處理應用程序。

Kafka 官網: http://kafka.apache.org/

Kafka主要設計目標如下：

以時間複雜度爲O(1)的方式提供消息持久化能力，即使對TB級以上數據也能保證常數時間的訪問性能。
高吞吐率。即使在非常廉價的商用機器上也能做到單機支持每秒100K條消息的傳輸。
支持Kafka Server間的消息分區，及分佈式消費，同時保證每個partition內的消息順序傳輸。
同時支持離線數據處理和實時數據處理。
支持在線水平擴展

Kafka通常用於兩大類應用程序：

建立實時流數據管道，以可靠地在系統或應用程序之間獲取數據
構建實時流應用程序，以轉換或響應數據流

要了解Kafka如何執行這些操作，讓我們從頭開始深入研究Kafka的功能。

首先幾個概念：

Kafka在一個或多個可以跨越多個數據中心的服務器上作爲集羣運行。
Kafka集羣將記錄流存儲在稱爲主題的類別中。
每個記錄由一個鍵，一個值和一個時間戳組成

1.2 kafka架構體系

1.3 kafka的應用場景

kafka的應用場景非常多, 下面我們就來舉幾個我們最常見的場景

1.3.1 用戶的活動跟蹤

用戶在網站的不同活動消息發佈到不同的主題中心，然後可以對這些消息進行實時監測、實時處理。當然，也可以加載到Hadoop或離線處理數據倉庫，對用戶進行畫像。像淘寶、天貓、京東這些大型電商平臺，用戶的所有活動都要進行追蹤的。

1.3.2 日誌收集

1.3.3 限流削峯

1.3.4 高吞吐率實現

Kafka與其他MQ相比，最大的特點就是高吞吐率。爲了增加存儲能力，Kafka將所有的消息都寫入到了低速大容量的硬盤。按理說，這將導致性能損失，但實際上，Kafka仍然可以保持超高的吞吐率，並且其性能並未受到影響。其主要採用如下方式實現了高吞吐率。

順序讀寫：Kafka將消息寫入到了分區partition中，而分區中的消息又是順序讀寫的。順序讀寫要快於隨機讀寫。
零拷貝：生產者、消費者對於Kafka中的消息是採用零拷貝實現的。
批量發送：Kafka允許批量發送模式。
消息壓縮：Kafka允許對消息集合進行壓縮。

1.4 kafka的優點

1. 解耦：

在項目啓動之初來預測將來項目會碰到什麼需求，是極其困難的。消息系統在處理過程中間插入了一個隱含的、基於數據的接口層，兩邊的處理過程都要實現這一接口。這允許你獨立的擴展或修改兩邊的處理過程，只要確保它們遵守同樣的接口約束。

2 冗餘:(副本)

有些情況下，處理數據的過程會失敗。除非數據被持久化，否則將造成丟失。消息隊列把數據進行持久化直到它們已經被完全處理，通過這一方式規避了數據丟失風險。許多消息隊列所採用的"插入-獲取-刪除"範式中，在把一個消息從隊列中刪除之前，需要你的處理系統明確的指出該消息已經被處理完畢，從而確保你的數據被安全的保存直到你使用完畢。

3 擴展性

因爲消息隊列解耦了你的處理過程，所以增大消息入隊和處理的頻率是很容易的，只要另外增加處理過程即可。不需要改變代碼、不需要調節參數。擴展就像調大電力按鈕一樣簡單。

4 靈活性&峯值處理能力

在訪問量劇增的情況下，應用仍然需要繼續發揮作用，但是這樣的突發流量並不常見；如果爲以能處理這類峯值訪問爲標準來投入資源隨時待命無疑是巨大的浪費。使用消息隊列能夠使關鍵組件頂住突發的訪問壓力，而不會因爲突發的超負荷的請求而完全崩潰。

5. 可恢復性

系統的一部分組件失效時，不會影響到整個系統。消息隊列降低了進程間的耦合度，所以即使一個處理消息的進程掛掉，加入隊列中的消息仍然可以在系統恢復後被處理。

6. 順序保證

在大多使用場景下，數據處理的順序都很重要。大部分消息隊列本來就是排序的，並且能保證數據會按照特定的順序來處理。Kafka保證一個Partition內的消息的有序性。

7. 緩衝

在任何重要的系統中，都會有需要不同的處理時間的元素。例如，加載一張圖片比應用過濾器花費更少的時間。消息隊列通過一個緩衝層來幫助任務最高效率的執行———寫入隊列的處理會儘可能的快速。該緩衝有助於控制和優化數據流經過系統的速度。

8. 異步通信

很多時候，用戶不想也不需要立即處理消息。消息隊列提供了異步處理機制，允許用戶把一個消息放入隊列，但並不立即處理它。想向隊列中放入多少消息就放多少，然後在需要的時候再去處理它們。

1.5 kafka於其他MQ對比

1. RabbitMQ

RabbitMQ是使用Erlang編寫的一個開源的消息隊列，本身支持很多的協議：AMQP，XMPP, SMTP, STOMP，也正因如此，它非常重量級，更適合於企業級的開發。同時實現了Broker構架，這意味着消息在發送給客戶端時先在中心隊列排隊。對路由，負載均衡或者數據持久化都有很好的支持。

2. Redis

Redis是一個基於Key-Value對的NoSQL數據庫，開發維護很活躍。雖然它是一個Key-Value數據庫存儲系統，但它本身支持MQ功能，所以完全可以當做一個輕量級的隊列服務來使用。對於RabbitMQ和Redis的入隊和出隊操作，各執行100萬次，每10萬次記錄一次執行時間。測試數據分爲128Bytes、512Bytes、1K和10K四個不同大小的數據。實驗表明：入隊時，當數據比較小時Redis的性能要高於RabbitMQ，而如果數據大小超過了10K，Redis則慢的無法忍受；出隊時，無論數據大小，Redis都表現出非常好的性能，而RabbitMQ的出隊性能則遠低於Redis。

3. ZeroMQ

ZeroMQ號稱最快的消息隊列系統，尤其針對大吞吐量的需求場景。ZeroMQ能夠實現RabbitMQ不擅長的高級/複雜的隊列，但是開發人員需要自己組合多種技術框架，技術上的複雜度是對這MQ能夠應用成功的挑戰。ZeroMQ具有一個獨特的非中間件的模式，你不需要安裝和運行一個消息服務器或中間件，因爲你的應用程序將扮演這個服務器角色。你只需要簡單的引用ZeroMQ程序庫，可以使用NuGet安裝，然後你就可以愉快的在應用程序之間發送消息了。但是ZeroMQ僅提供非持久性的隊列，也就是說如果宕機，數據將會丟失。其中，Twitter的Storm 0.9.0以前的版本中默認使用ZeroMQ作爲數據流的傳輸（Storm從0.9版本開始同時支持ZeroMQ和Netty作爲傳輸模塊）。

4. ActiveMQ

ActiveMQ是Apache下的一個子項目。類似於ZeroMQ，它能夠以代理人和點對點的技術實現隊列。同時類似於RabbitMQ，它少量代碼就可以高效地實現高級應用場景。

5. Kafka/Jafka

Kafka是Apache下的一個子項目，是一個高性能跨語言分佈式發佈/訂閱消息隊列系統，而Jafka是在Kafka之上孵化而來的，即Kafka的一個升級版。具有以下特性：快速持久化，可以在O(1)的系統開銷下進行消息持久化；高吞吐，在一臺普通的服務器上既可以達到10W/s的吞吐速率；完全的分佈式系統，Broker、Producer、Consumer都原生自動支持分佈式，自動實現負載均衡；支持Hadoop數據並行加載，對於像Hadoop的一樣的日誌數據和離線分析系統，但又要求實時處理的限制，這是一個可行的解決方案。Kafka通過Hadoop的並行加載機制統一了在線和離線的消息處理。Apache Kafka相對於ActiveMQ是一個非常輕量級的消息系統，除了性能非常好之外，還是一個工作良好的分佈式系統。

1.6 kafka的幾種重要角色

1.6.1 kafka作爲存儲系統

任何允許發佈與使用無關的消息發佈的消息隊列都有效地充當了運行中消息的存儲系統。Kafka的不同之處在於它是一個非常好的存儲系統。

寫入Kafka的數據將寫入磁盤並進行復制以實現容錯功能。Kafka允許生產者等待確認，以便直到完全複製並確保即使寫入服務器失敗的情況下寫入也不會完成。

Kafka的磁盤結構可以很好地擴展使用-無論服務器上有50 KB還是50 TB的持久數據，Kafka都將執行相同的操作。

由於認真對待存儲並允許客戶端控制其讀取位置，因此您可以將Kafka視爲一種專用於高性能，低延遲提交日誌存儲，複製和傳播的專用分佈式文件系統。

1.6.2 kafka作爲消息傳遞系統

Kafka的流概念與傳統的企業消息傳遞系統相比如何？

傳統上，消息傳遞具有兩種模型：排隊和發佈-訂閱。在隊列中，一組使用者可以從服務器中讀取內容，並且每條記錄都將轉到其中一個。在發佈-訂閱記錄中廣播給所有消費者。這兩個模型中的每一個都有優點和缺點。排隊的優勢在於，它允許您將數據處理劃分到多個使用者實例上，從而擴展處理量。不幸的是，隊列不是多用戶的—一次進程讀取了丟失的數據。發佈-訂閱允許您將數據廣播到多個進程，但是由於每條消息都傳遞給每個訂閱者，因此無法擴展處理。

Kfka的消費者羣體概念概括了這兩個概念。與隊列一樣，使用者組允許您將處理劃分爲一組進程（使用者組的成員）。與發佈訂閱一樣，Kafka允許您將消息廣播到多個消費者組。

Kafka模型的優點在於，每個主題都具有這些屬性-可以擴展處理範圍，並且是多訂閱者-無需選擇其中一個。

與傳統的消息傳遞系統相比，Kafka還具有更強的訂購保證。

傳統隊列將記錄按順序保留在服務器上，如果多個使用者從隊列中消費，則服務器將按記錄的存儲順序分發記錄。但是，儘管服務器按順序分發記錄，但是這些記錄是異步傳遞給使用者的，因此它們可能在不同的使用者上亂序到達。這實際上意味着在並行使用的情況下會丟失記錄的順序。消息傳遞系統通常通過“專有使用者”的概念來解決此問題，該概念僅允許一個進程從隊列中使用，但是，這當然意味着在處理中沒有並行性。

Kafka做得更好。通過在主題內具有並行性（即分區）的概念，Kafka能夠在用戶進程池中提供排序保證和負載均衡。這是通過將主題中的分區分配給消費者組中的消費者來實現的，以便每個分區都由組中的一個消費者完全消費。通過這樣做，我們確保使用者是該分區的唯一讀取器，並按順序使用數據。由於存在許多分區，因此仍然可以平衡許多使用者實例上的負載。但是請注意，使用者組中的使用者實例不能超過分區。

1.6.3 kafka用作流處理

僅讀取，寫入和存儲數據流是不夠的，目的是實現對流的實時處理。

在Kafka中，流處理器是指從輸入主題中獲取連續數據流，對該輸入進行一些處理並生成連續數據流以輸出主題的任何東西。

例如，零售應用程序可以接受銷售和裝運的輸入流，並輸出根據此數據計算出的重新訂購和價格調整流。

可以直接使用生產者和消費者API進行簡單處理。但是，對於更復雜的轉換，Kafka提供了完全集成的Streams API。這允許構建執行非重要處理的應用程序，這些應用程序計算流的聚合或將流連接在一起。

該功能有助於解決此類應用程序所面臨的難題：處理無序數據，在代碼更改時重新處理輸入，執行狀態計算等。

流API建立在Kafka提供的核心原語之上：它使用生產者和使用者API進行輸入，使用Kafka進行狀態存儲，並使用相同的組機制來實現流處理器實例之間的容錯。

2. kafka中的關鍵術語解釋

2.1 Topic

主題。在 Kafka 中，使用一個類別屬性來劃分消息的所屬類，劃分消息的這個類稱爲 topic。 topic 相當於消息的分類標籤，是一個邏輯概念

物理上不同Topic的消息分開存儲，邏輯上一個Topic的消息雖然保存於一個或多個broker上但用戶只需指定消息的Topic即可生產或消費數據而不必關心數據存於何處

##2.2 Partition

分區。topic 中的消息被分割爲一個或多個 partition，其是一個物理概念，對應到系統上就是一個或若干個目錄。partition 內部的消息是有序的，但 partition 間的消息是無序的。

2.3 Segment

段。將 partition 進一步細分爲了若干的 segment，每個 segment 文件的大小相等。

2.4 Broker

Kafka 集羣包含一個或多個服務器，每個服務器節點稱爲一個 broker。

broker存儲topic的數據。如果某topic有N個partition，集羣有N個broker，那麼每個broker存儲該topic的一個partition。

如果某topic有N個partition，集羣有(N+M)個broker，那麼其中有N個broker存儲該topic的一個partition，剩下的M個broker不存儲該topic的partition數據。

如果某topic有N個partition，集羣中broker數目少於N個，那麼一個broker存儲該topic的一個或多個partition。在實際生產環境中，儘量避免這種情況的發生，這種情況容易導致Kafka集羣數據不均衡。

2.5 Producer

生產者, 即消息的發佈者. 生產者將數據發佈到他們選擇的主題。生產者負責選擇將哪個記錄分配給主題中的哪個分區。即: 生產者生產的一條消息，會被寫入到某一個 partition。

##2.6 Consumer

消費者。可以從 broker 中讀取消息。

一個消費者可以消費多個 topic 的消息

一個消費者可以消費同一個 topic 中的多個 partition 中的消息

一個 partiton 允許多個 consumer 同時消費

2.7 Consumer Group

consumer group 是 kafka 提供的可擴展且具有容錯性的消費者機制。組內可以有多個消費者，它們共享一個公共的 ID，即 group ID。組內的所有消費者協調在一起來消費訂閱主題的所有分區。

Kafka 保證同一個 consumer group 中只有一個 consumer 會消費某條消息，實際上，Kafka 保證的是穩定狀態下每一個 consumer 實例只會消費某一個或多個特定的 partition，而某個 partition 的數據只會被某一個特定的 consumer 實例所消費。

下面我們用官網的一張圖, 來標識consumer數量和partition數量的對應關係

由兩臺服務器組成的Kafka羣集，其中包含四個帶有兩個使用者組的分區（P0-P3）。消費者組A有兩個消費者實例，組B有四個。

其實對於這個消費組, 以前一直搞不明白, 我自己的總結是:

topic中的partitoin到group是發佈訂閱的通信方式，即一條topic的partition的消息會被所有的group消費，屬於一對多模式；group到consumer是點對點通信方式，屬於一對一模式。

舉個例子: 不使用group的話，啓動10個consumer消費一個topic，這10個consumer都能得到topic的所有數據，相當於這個topic中的任一條消息被消費10次。

使用group的話，連接時帶上groupid，topic的消息會分發到10個consumer上，每條消息只被消費1次

2.8 Replizcas of partition

分區副本。副本是一個分區的備份，是爲了防止消息丟失而創建的分區的備份。

2.9 Partition Leader

每個 partition 有多個副本，其中有且僅有一個作爲 Leader，Leader 是當前負責消息讀寫的 partition。即所有讀寫操作只能發生於 Leader 分區上。

2.10 Partition Follower

所有Follower都需要從Leader同步消息，Follower與Leader始終保持消息同步。Leader 與 Follower 的關係是主備關係，而非主從關係。

2.11 ISR

ISR，In-Sync Replicas，是指副本同步列表。 ISR列表是由Leader負責維護。
AR，Assigned Replicas，指某個 partition 的所有副本, 即已分配的副本列表。
OSR，Outof-Sync Replicas, 即非同步的副本列表。
AR = ISR + OSR

2. 12 offset

偏移量。每條消息都有一個當前Partition下唯一的64字節的offset，它是相當於當前分區第一條消息的偏移量。

2.13 Broker Controller

Kafka集羣的多個broker中，有一個會被選舉controller，負責管理整個集羣中partition和replicas的狀態。

只有 Broker Controller 會向 zookeeper 中註冊 Watcher，其他 broker 及分區無需註冊。即 zookeeper 僅需監聽 Broker Controller 的狀態變化即可。

2.14 HW與LEO

HW，HighWatermark，高水位，表示 Consumer 可以消費到的最高 partition 偏移量。HW 保證了 Kafka 集羣中消息的一致性。確切地說，是保證了 partition 的 Follower 與 Leader 間數據的一致性。
LEO，Log End Offset，日誌最後消息的偏移量。消息是被寫入到 Kafka 的日誌文件中的，這是當前最後一個寫入的消息在 Partition 中的偏移量。
對於 leader 新寫入的消息，consumer 是不能立刻消費的。leader 會等待該消息被所有 ISR 中的 partition follower 同步後纔會更新 HW，此時消息才能被 consumer 消費。

我相信你看完上面的概念還是懵逼的, 好吧, 下面我們就用圖來形象話的表示兩者的關係吧

2.15 zookeeper

Zookeeper 負責維護和協調 broker，負責 Broker Controller 的選舉。

在 kafka0.9 之前版本，offset 是由 zk 負責管理的。

總結:zk 負責 Controller 的選舉，Controller 負責 leader 的選舉。

2.16 Coordinator

Coordinator一般指的是運行在每個broker上的group Coordinator進程，用於管理Consumer Group中的各個成員，主要用於offset位移管理和Rebalance。一個Coordinator可以同時管理多個消費者組。

2. 17 Rebalance

當消費者組中的數量發生變化，或者topic中的partition數量發生了變化時，partition的所有權會在消費者間轉移，即partition會重新分配，這個過程稱爲再均衡Rebalance。

再均衡能夠給消費者組及broker帶來高性能、高可用性和伸縮，但在再均衡期間消費者是無法讀取消息的，即整個broker集羣有小一段時間是不可用的。因此要避免不必要的再均衡。

##2.18 offset commit

Consumer從broker中取一批消息寫入buffer進行消費，在規定的時間內消費完消息後，會自動將其消費消息的offset提交給broker，以記錄下哪些消息是消費過的。當然，若在時限內沒有消費完畢，其是不會提交offset的。

3. kafka的工作原理和過程

3.1 消息寫入算法

消息發送者將消息發送給broker, 並形成最終的可供消費者消費的log, 是已給比較複雜的過程

producer先從zookeeper中找到該partition的leader
producer將消息發送給該leader
leader將消息接入本地的log, 並通知ISR的followers
ISR中的followers從leader中pull消息, 寫入本地log後向leader發送ack
leader收到所有ISR中的followers的ack後, 增加HW並向producer發送ack, 表示消息寫入成功

3.2 消息路由策略

在通過 API 方式發佈消息時，生產者是以 Record 爲消息進行發佈的。Record 中包含 key 與 value，value 纔是我們真正的消息本身，而 key 用於路由消息所要存放的 Partition。消息要寫入到哪個 Partition 並不是隨機的，而是有路由策略的。

若指定了 partition，則直接寫入到指定的 partition;
若未指定 partition 但指定了 key，則通過對 key 的 hash 值與 partition 數量取模，該取模

結果就是要選出的 partition 索引;
若 partition 和 key 都未指定，則使用輪詢算法選出一個 partition。

3.3 HW截斷機制

如果 partition leader 接收到了新的消息， ISR 中其它 Follower 正在同步過程中，還未同步完畢時 leader 宕機。此時就需要選舉出新的 leader。若沒有 HW 截斷機制，將會導致 partition 中 leader 與 follower 數據的不一致。

當原 Leader 宕機後又恢復時，將其 LEO 回退到其宕機時的 HW，然後再與新的 Leader進行數據同步，這樣就可以保證老 Leader 與新 Leader 中數據一致了，這種機制稱爲 HW 截斷機制。

3.4 消息發送的可靠性

生產者向 kafka 發送消息時，可以選擇需要的可靠性級別。通過 request.required.acks參數的值進行設置。

0值

異步發送。生產者向 kafka 發送消息而不需要 kafka 反饋成功 ack。該方式效率最高，但可靠性最低。其可能會存在消息丟失的情況。

在傳輸過程中會出現消息丟失。
在broker內部會出現消息丟失。
會出現寫入到kafka中的消息的順序與生產順序不一致的情況。

1值

同步發送。生產者發送消息給 kafka，broker 的 partition leader 在收到消息後馬上發送成功 ack(無需等等 ISR 中的 Follower 同步)，生產者收到後知道消息發送成功，然後會再發送消息。如果一直未收到 kafka 的 ack，則生產者會認爲消息發送失敗，會重發消息。

該方式對於 Producer 來說，若沒有收到 ACK，一定可以確認消息發送失敗了，然後可以重發;但是，即使收到了 ACK，也不能保證消息一定就發送成功了。故，這種情況，也可能會發生消息丟失的情況。

-1值

同步發送。生產者發送消息給 kafka，kafka 收到消息後要等到 ISR 列表中的所有副本都同步消息完成後，才向生產者發送成功 ack。如果一直未收到 kafka 的 ack，則認爲消息發送失敗，會自動重發消息。該方式會出現消息重複接收的情況。

3.5 消費者消費過程解析

生產者將消息發送到topitc中, 消費者即可對其進行消費, 其消費過程如下:

consumer向broker提交連接請求，其所連接上的broker都會向其發送broker controller的通信URL，即配置文件中的listeners地址；
當consumer指定了要消費的topic後，會向broker controller發送消費請求；
broker controller會爲consumer分配一個或幾個partition leader，並將該partition的當前offset發送給consumer；
consumer會按照broker controller分配的partition對其中的消息進行消費；
當consumer消費完該條消息後，consumer會向broker發送一個消息已經被消費反饋，即該消息的offset；
在broker接收到consumer的offset後，會更新相應的__consumer_offset中；
以上過程會一直重複，知道消費者停止請求消費；
Consumer可以重置offset，從而可以靈活消費存儲在broker上的消息。

3.6 Partition Leader選舉範圍

當leader宕機後，broker controller會從ISR中挑選一個follower成爲新的leader。如果ISR中沒有其他副本怎麼辦？可以通過unclean.leader.election.enable的值來設置leader選舉範圍。

false

必須等到ISR列表中所有的副本都活過來才進行新的選舉。該策略可靠性有保證，但可用性低。

true

在ISR列表中沒有副本的情況下，可以選擇任意一個沒有宕機的主機作爲新的leader，該策略可用性高，但可靠性沒有保證。

3.7 重複消費問題的解決方案

同一個consumer重複消費

當Consumer由於消費能力低而引發了消費超時，則可能會形成重複消費。

在某數據剛好消費完畢，但是正準備提交offset時候，消費時間超時，則broker認爲這條消息未消費成功。這時就會產生重複消費問題。

其解決方案：延長offset提交時間。

不同的consumer重複消費

當Consumer消費了消息，但還沒有提交offset時宕機，則這些已經被消費過的消息會被重複消費。

其解決方案：將自動提交改爲手動提交。

3.8 從架構設計上解決kafka重複消費的問題

其實在開發的時候, 我們在設計程序的時候, 比如考慮到網絡故障等一些異常的情況, 我們都會設置消息的重試次數,

可能還有其他可能出現消息重複, 那我們應該如何解決呢?

下面提供三個方案:

3.8.1 方案一: 保存並查詢

給每個消息都設置一個獨一無二的uuid, 所有的消息, 我們都要存一個uuid, 我們在消費消息的時候, 首先去持久化系統中查詢一下, 看這個看是否以前消費過, 如沒有消費過, 在進行消費, 如果已經消費過, 丟棄就好了, 下圖, 表明了這種方案

3.8.2 方案二: 利用冪等

冪等（Idempotence）在數學上是這樣定義的，如果一個函數 f(x) 滿足：f(f(x)) = f(x)，則函數 f(x) 滿足冪等性。

這個概念被拓展到計算機領域，被用來描述一個操作、方法或者服務。一個冪等操作的特點是，其任意多次執行所產生的影響均與一次執行的影響相同。一個冪等的方法，使用同樣的參數，對它進行多次調用和一次調用，對系統產生的影響是一樣的。所以，對於冪等的方法，不用擔心重複執行會對系統造成任何改變。

我們舉個例子

帶你逆襲kafka之路