目錄

Kafka設計動機

Kafka特點

Kafka設計架構

基本架構

Kafka各組件詳解

Kafka關鍵技術點

典型應用場景

---

? ? ? 在大數據數據收集環(huán)節(jié)，需要構建數據流水線，其中一種方式可以通過消息隊列實現。在實際應用中，不同服務器產生的日志，比如指標監(jiān)控數據，用戶搜索日志，用戶點擊日志等，需要同時傳送到多個系統(tǒng)中以便進行相應的邏輯處理和挖掘。

? ? ? 消息隊列位于生產者和消費者之間的“中間件”，解除了生產者和消費者的直接依賴關系，使得軟件架構更容易擴展和伸縮；能夠緩沖生產者產生的數據，防止消費者無法及時處理生產者產生的數據。

---

Kafka設計動機

數據流水演化

隨著業(yè)務復雜度和產生數據量不斷增加，逐漸演化成上圖數據收集模式，并將收集到數據直接寫入后端，則會產生以下幾個潛在問題：

• 數據生產者和消費者耦合度過高
• 生產者和消費者間數據處理速率不對等
• 大量并發(fā)的網絡連接對后端消費者不夠友好

為了解決以上問題，引入“中間件”，從這個角度理解Kafka 如下圖所示（Kafka在數據流中扮演的角色）：

• 消息中間件：避免生產者和消費者直接相互產生的彼此高度依賴，使得兩者中任何一個由變化，都不會影響另一方。
• 消息隊列：緩存生產者產生的數據，使得消費者可以重復消費歷史數據；平滑生產者產生數據速度和消費處理數據速度的不對等。
• 發(fā)布訂閱系統(tǒng)：消費者訂閱某類主題的數據，當生產者產生對應主題的數據后，所有訂閱者會快速獲取到數據。隨時增加新的消費者而無需進行任何系統(tǒng)層面的修改。
• 消息總線：所有收集到的數據會流經 Kafka，之后由Kafka分流后，進入各個消費者系統(tǒng)。

Kafka在數據流中扮演的角色

---

Kafka特點

Kafka是在大數據背景下產生，能應對海量數據的處理系統(tǒng)。具有以下特點：

• 高性能：相比RabbitMQ等消息隊列，Kafka 具有更高的性能和吞吐率。
• 良好擴展性：采用分布式設計架構，數據經分片后寫入多個節(jié)點，既可以突破單節(jié)點數據存儲和處理的瓶頸，也可以實現容錯等功能。
• 數據持久化：數據消息均會持久化到磁盤上，并通過多副本策略避免數據丟失，采用順序寫，順序讀，和批量寫等機制，提升磁盤操作的效率。

---

Kafka設計架構

1. 基本架構

Kafka 架構由 Producer，Broker 和 Consumer?三類組件構成。

• Producer 將數據寫入Broker，Consumer 從 Broker上讀取數據進行處理，Broker構成了連接 Producer?和?Consumer 的“緩沖區(qū)”。
• Broker?和 Cunsumer?通過?Zookeeper?做協(xié)調和服務發(fā)現。
• 多個?Broker?構成一個可靠的分布式消息存儲系統(tǒng)，避免數據丟失。
• Broker?中的消息被劃分成若干個 topic ，同屬于一個?topic?的所有數據按照某種策略被分成多個?partition?以實現負載分攤和數據并行處理。
• 采用 push-pull，即 Producer 將數據直接 “push” 給 Broker, 而 Consumer 從Broker?“pull”數據，這種架構優(yōu)勢帶來以下兩點：
• Consumer 可以根據自己的實際負載和需求獲取數據（自己主動去拉取消息進行消費）

• Consumer 自己維護已讀取消息的?offset 而不是由Broker 端維護，大大緩解 Broker 的壓力，使得它更加輕量級。?

Kafka 基本架構

2. Kafka各組件詳解

1.producer

由用戶使用 Kafka 提供的?SDK?開發(fā)的，Producer 將數據轉化成 “消息”，并通過網絡發(fā)送給 Broker。每條消息表示為一個三元組： <topic, key, message>

• topic：表示該條消息所屬的 topic，劃分消息的邏輯概念。一個 topic 可以分布到多個不同的 Broker 上。
• key：表示該消息的主鍵。根據主鍵將同一個 topic 下消息劃分成不同的分區(qū) ( partition )，默認基于哈希取模算法，用戶可以自行設置分區(qū)算法。如下圖演示 Producer 寫消息的過程，假設 topic A 共分為 4 個 partition (創(chuàng)建 topic 時靜態(tài)制定)。
• message：消息值，其類型為字節(jié)數組，可以是普通字符串，JSON對象，或者 JSON, Acro,Thrift或Protobuf等序列化框架序列化后的對象。

Kafka Producer 寫消息過程

2. Broker

主要職責是接受 Producer 和 Consumer 的請求，并把消息持久化到本地磁盤。Broker一般有多個，組成一個分布式高容錯的集群。

Kafka Broker 集群

• Broker 以 topic 為單位將消息分成不同的分區(qū) （partition），每個分區(qū)可以有多個副本，通過數據冗余的方式實現容錯。當 partition 存在多個副本時，其中一個是 leader，對外提供讀寫請求，其余均是 follower，僅僅同步 leader 中的數據，并在 leader 出現問題時，通過選舉算法將其中的某一個提升為 leader。
• Broker 能夠保證同一個 topic 在同一個 partition 內部的消息是有序的，但無法保證 partition 之間的消息全局有序。在實際應用中，合理利用分區(qū)內部有序這一特征即可完成時序相關的需求。
• Broker 中保存數據是有有效期，一旦超過了有效期，對應的數據被移除以釋放磁盤空間。在有效期期內，消息可以重復讀取而不受限制。
• Broker 以追加的方式將消息寫到磁盤文件中，且每個分區(qū)中消息被賦予了唯一整數標識，稱之為 “offset” （偏移量）。
• Broker 僅提供基于 offset 的讀取方式 ，不會維護各個 Consumer 當前已消費的 offset 值，而是由?Consumer 各自維護當前讀取的進度。Consumer 讀取數據時告訴 Broker 請求消息的起始 offset 值，Broker將之后的消息流式發(fā)送過去。如下圖所示：

Kafka Broker 數據分區(qū)

3.Consumer

• 主動從 Broker 拉取（pull）消息進行處理，這個機制大大降低了 Broker 的壓力，使得 Broker 吞吐率很高。
• 每個Consumer 自己維護最后一個已讀取消息的 offset，并在下次請求從這個 offset 開始的消息。
• 多個Consumer 構成一個Consumer Group，共同讀取同一個?topic?中的數據，提高數據讀取效率。Kafka 可自動為同一個Group 中的 Consumer 分攤負載，從而實現消息的并發(fā)讀取，在某個Consumer發(fā)生故障時，自動將它處理的 partition 轉移給同 Group 中的 Consumer 處理。

Kafka Consumer Group 原理

4.Zookeeper

在?Kafka 集群中，Zookeeper 擔任分布式服務協(xié)調作用，Broker 和 Consumer 直接依賴于 Zookeeper 才能工作。

• Broker 與 Zookeeper：所有 Broker 會向 Zookeeper 注冊，將自己的位置，健康狀況，維護的 topic，partition等信息寫入 Zookeeper ,以便其他 Consumer 可以發(fā)現和獲取這些數據。
• Consumer 與 Zookeeper：Consumer Group 通過Zookeeper 保證內部各個 Consumer 的負載均衡，在某個 Consumer 或 Broker 出現故障時，重新分攤負載。Consumer （僅限于 height-level API，如果是 low-level API，用戶需要自己保存和恢復offset）會將最近獲取消息的 offset 寫入 Zookeeper，以便出現故障重啟后，能夠接著故障前的斷點繼續(xù)讀取數據。

---

3. Kafka關鍵技術點

1. 可控的可靠性級別

Producer 通過兩種方式向 Broker 發(fā)送數據：同步 與 異步。異步方式通過批處理的方式，可大大提高數據寫入效率。這兩種方式均支持通過控制消息應答方式，在寫性能與可靠性之間做一個較好的權衡。目前支持三種消息應答方式，通過request.required.ack 控制：

• 0：無需對消息進行確認，性能最高，但不能確保消息被成功接收并寫入磁盤。
• 1：需要等到 leader partition 寫成功后才會返回，但對應的 follower partition 不一定寫成功。在性能與可靠性之間進行折中。
• -1：需要等到所有 partition 均寫成功后才會返回。性能較低，但可靠性最高。

---

2. 數據多副本

Broker 允許為每個 topic 中的數據存放多個副本，以達到容錯的目的。Kafka 采用強一致的數據復制策略。

Kafka Broker 多副本放置

---

3. 高效的持久化機制

直接將消息持久化到磁盤而不是內存中，這要求必須采用高效的數據寫入和存儲方式。Kafka Broker 將收到的數據順序寫入磁盤，并結合基于 offset 的數據組織方式，能達到高效的讀速度和寫速度。

---

4. 數據傳輸優(yōu)化：批處理與zero-copy技術

為了優(yōu)化 Broker 與 Consumer?之間的網絡數據傳輸效率，Kafka引入了大量優(yōu)化技術，典型的兩個代表：

• 批處理：發(fā)送是將多條消息進行組裝，同時對數據格式統(tǒng)一設計，避免數據格式轉換帶來開銷。
• zero-copy技術：一般情況下，一條存儲在磁盤的數據從讀取到發(fā)送出去需要經過四次拷貝（內核狀態(tài) read buffer? > 用戶態(tài)應用程序?buffer? > 內核態(tài) socket buffer? > 網卡NIC buffer）和兩次系統(tǒng)調用。經過zero-copy技術優(yōu)化后，數據只需三次拷貝（少了 用戶態(tài)應用程序?buffer），且無需使用任何系統(tǒng)調用，大大提高數據發(fā)送效率。如下圖所示：

application-copy 與 zero-copy 對比

---

5. 可控的消息傳遞語義

根據接受者受到重復消息的次數，將消息傳遞語義分為三種：

• at most once：不需要等待確認，消息可能被消費者成功接收，也可能丟失。
• at least once：需要等待確認，如未收到確認則會重發(fā)；保障消費者收到消息，但可能會收到多次。
• exactly once：消費者會且只會處理一次同一條消息。

實現第三種語義，常用技術手段有：

• 兩段鎖協(xié)議：分布式中常用的一致性協(xié)議。
• 在支持冪等操作下，使用 at least once 語義。Producer 與 Broker,? Broker 與 Consumer 之間，均存在消息傳遞語義問題。

---

典型應用場景

1. 消息隊列

與 RabbitMQ 和 ZeroMQ 等開源消息隊列相比，Kafka 具有高吞吐率，自動分區(qū)，多副本以及良好容錯性等特點，使得它非常適合大數據應用場景。

---

2. 流式計算框架的數據源

在流式計算框架，為了保證數據不丟失，具備“at least once”數據發(fā)送語意，通常在數據源中使用具有高性能的消息隊列。

---

3. 分布式日志收集系統(tǒng)中Source或Sink

可與日志收集組件 Flume 或 Logstash 組合使用，擔任 Source 或 Sink 的角色。

---

4. Lambda Architecture 中的 Source

同時為批處理和流式處理兩條流水線提供數據源

?

注：內容主要整理自書本《大數據技術體系詳解 原理、架構與實踐》 董西成

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的【中间件】大数据之分布式消息队列Kafka的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。