1. 為什么介紹Kafka

1.高吞吐量：單機每秒處理十萬級的消息量。即使存儲了許多TB的消息，它也保持穩定的性能。

2.高性能：單節點支持上千個客戶端，并保證零停機和零數據丟失。

• 利用Linux的頁緩存
• 順序讀，順序寫
• 零拷貝

3.持久化數據存儲：將消息持久化到磁盤。通過將數據持久化到硬盤以及replication防止數據丟失。

4.分布式系統: 易于向外擴展。所有的Producer、Broker和Consumer都會有多個，均為分布式的。無需停機即可擴展機器。多個Producer、Consumer可能是不同的應用。

5.可靠性: Kafka是分布式，分區，復制和容錯的。

6.客戶端狀態維護：消息被處理的狀態是在Consumer端維護，而不是由server端維護。當失敗時能自動平衡。

7.支持online和offline的場景。

8.支持多種客戶端語言。Kafka支持Java、.NET、PHP、Python等多種語言。

2. Kafka應用場景

2.1. 消息隊列

Kafka 最常見的應用場景就是作為消息隊列。 Kafka 提供了一個可靠且可擴展的消息隊列，可以處理大量數據。

Kafka 可以實現不同系統間的解耦和異步通信，如訂單系統、支付系統、庫存系統等。在這個基礎上 Kafka 還可以緩存消息，提高系統的可靠性和可用性，并且可以支持多種消費模式，如點對點或發布訂閱。

2.2. 日志處理與分析(最常用的場景)

公司可以用Kafka可以收集各種服務的Log，典型就是 ELK（Elastic-Logstash-Kibana）。Kafka 有效地從每個實例收集日志流。

圖片

2.3. 推薦數據流

流式處理是 Kafka 在大數據領域的重要應用場景之一，其與流處理框架（如Spark Streaming、Storm、Flink等）框架進行集成。主要內容包括：

Kafka作為流式處理平臺的數據源或數據輸出：Kafka可以作為流數據的中介，將實時數據發送到Kafka中，同時也可以從Kafka中讀取數據進行處理和分析。 推薦系統的工作流程：以淘寶、京東等線上商城網站的推薦系統為例，描述了推薦系統的工作流程。主要包括：

• 將用戶的點擊流數據發送到Kafka中。
• 使用Flink等流處理框架讀取Kafka中的流數據，進行實時聚合處理。
• 機器學習算法使用來自數據湖的聚合數據進行訓練，同時算法工程師也會對推薦模型進行調整。
• 推薦系統持續改進對每個用戶的推薦相關性。

圖片

2.4. 系統監控與報警

與日志分析系統類似，我們需要收集系統指標以進行監控和故障排除。不同之處在于，指標是結構化數據，而日志是非結構化文本。指標數據被發送到 Kafka 中，并在 Flink 中進行聚合。下圖展示了常見監控報警系統的工作流程：

• 采集器讀取購物車指標發送到 Kafka 中
• Flink 讀取 Kafka 中的指標數據進行聚合處理
• 實時監控系統和報警系統讀取聚合數據作展示以及報警處理

圖片

2.5. CDC（數據變更捕獲）

CDC(Change data capture) 將數據庫更改流式傳輸到其他系統，以便進行復制或緩存/索引更新。例如，在下圖中，事務日志被發送到 Kafka，并由 ElasticSearch、Redis 和輔助數據庫引入。

圖片

2.6. 系統遷移

Kafka 可以用來作為老系統升級到新系統過程中的消息傳遞中間件（Kafka），以此來降低遷移風險。 在下圖中，為了升級下圖中的訂單服務，我們更新了舊版訂單服務，以使用 Kafka 的輸入并將結果寫入 ORDER 主題。新的訂單服務使用相同的輸入，并將結果寫入 ORDERNEW 主題，對帳服務比較 ORDER 和 ORDERNEW。如果它們相同，則新服務通過測試。

圖片

3. Kafka核心概念

3.1. 生產者(Producer)

生產者: 創建消息,將消息發布到Kafka的topic中。broker接收到生產者發送的消息后，broker將該消息追加到當前用于追加數據的 segment 文件中 一般情況下，一個消息會被發布到一個特定的主題上。

• 默認情況下通過輪詢把消息均衡地分布到主題的所有分區上。
• 在某些情況下，生產者會把消息直接寫到指定的分區。這通常是通過消息鍵和分區器來實現的，分區器為鍵生成一個散列值，并將其映射到指定的分區上。這樣可以保證包含同一個鍵的消息會被寫到同一個分區上。
• 生產者也可以使用自定義的分區器，根據不同的業務規則將消息映射到分區。

3.2. 消費者（Consumer）

消費者讀取消息。

• 消費者訂閱一個或多個主題，并按照消息生成的順序讀取它們。
• 消費者通過檢查消息的偏移量來區分已經讀取過的消息。偏移量是另一種元數據，它是一個不斷遞增的整數值，在創建消息時，Kafka 會把它添加到消息里。在給定的分區里，每個消息的偏移量都是唯一的。消費者把每個分區最后讀取的消息偏移量保存在Zookeeper 或Kafka上，如果消費者關閉或重啟，它的讀取狀態不會丟失。
• 消費者是消費組的一部分。群組保證每個分區只能被一個消費者使用。
• 如果一個消費者失效，消費組里的其他消費者可以接管失效消費者的工作，再平衡，分區重新分配。

3.3.  Broker

一個獨立的Kafka 服務器被稱為broker。

broker 為消費者提供服務，對讀取分區的請求作出響應，返回已經提交到磁盤上的消息。

• 如果某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集群數據不均衡。

broker 是集群的組成部分。每個集群都有一個broker 同時充當了集群控制器的角色（自動從集群的活躍成員中選舉出來）控制器負責管理工作，包括將分區分配給broker 和監控broker 在集群中，一個分區從屬于一個broker，該broker 被稱為分區的首領。

圖片

3.4. Topic

每條發布到Kafka集群的消息都有一個類別，這個類別被稱為Topic。

物理上不同Topic的消息分開存儲。

Topic就好比數據庫的表，尤其是分庫分表之后的邏輯表。

3.5. 分區(Partition)

• Topic可以被分為若干個分區，一個分區就是一個提交日志
• 消息以追加方式寫入分區，然后以先入先出的順序讀取
• 無法在整個主題范圍內保證消息的順序，但可以保證消息在單個分區內的順序
• Kafka 通過分區來實現數據冗余和伸縮性
• 在需要嚴格保證消息的消費順序的場景下，需要將partition數目設為1

圖片