【中间件】大数据之分布式消息队列Kafka
目錄
Kafka設計動機
Kafka特點
Kafka設計架構
基本架構
Kafka各組件詳解
Kafka關鍵技術點
典型應用場景
? ? ? 在大數據數據收集環節，需要構建數據流水線，其中一種方式可以通過消息隊列實現。在實際應用中，不同服務器產生的日志，比如指標監控數據，用戶搜索日志，用戶點擊日志等，需要同時傳送到多個系統中以便進行相應的邏輯處理和挖掘。
? ? ? 消息隊列位于生產者和消費者之間的“中間件”，解除了生產者和消費者的直接依賴關系，使得軟件架構更容易擴展和伸縮；能夠緩沖生產者產生的數據，防止消費者無法及時處理生產者產生的數據。
Kafka設計動機
數據流水演化隨著業務復雜度和產生數據量不斷增加，逐漸演化成上圖數據收集模式，并將收集到數據直接寫入后端，則會產生以下幾個潛在問題：
- 數據生產者和消費者耦合度過高
- 生產者和消費者間數據處理速率不對等
- 大量并發的網絡連接對后端消費者不夠友好
為了解決以上問題，引入“中間件”，從這個角度理解Kafka 如下圖所示（Kafka在數據流中扮演的角色）：
- 消息中間件：避免生產者和消費者直接相互產生的彼此高度依賴，使得兩者中任何一個由變化，都不會影響另一方。
- 消息隊列：緩存生產者產生的數據，使得消費者可以重復消費歷史數據；平滑生產者產生數據速度和消費處理數據速度的不對等。
- 發布訂閱系統：消費者訂閱某類主題的數據，當生產者產生對應主題的數據后，所有訂閱者會快速獲取到數據。隨時增加新的消費者而無需進行任何系統層面的修改。
- 消息總線：所有收集到的數據會流經 Kafka，之后由Kafka分流后，進入各個消費者系統。
Kafka特點
Kafka是在大數據背景下產生，能應對海量數據的處理系統。具有以下特點：
- 高性能：相比RabbitMQ等消息隊列，Kafka 具有更高的性能和吞吐率。
- 良好擴展性：采用分布式設計架構，數據經分片后寫入多個節點，既可以突破單節點數據存儲和處理的瓶頸，也可以實現容錯等功能。
- 數據持久化：數據消息均會持久化到磁盤上，并通過多副本策略避免數據丟失，采用順序寫，順序讀，和批量寫等機制，提升磁盤操作的效率。
Kafka設計架構
1. 基本架構
Kafka 架構由 Producer，Broker 和 Consumer?三類組件構成。
- Producer 將數據寫入Broker，Consumer 從 Broker上讀取數據進行處理，Broker構成了連接 Producer?和?Consumer 的“緩沖區”。
- Broker?和 Cunsumer?通過?Zookeeper?做協調和服務發現。
- 多個?Broker?構成一個可靠的分布式消息存儲系統，避免數據丟失。
- Broker?中的消息被劃分成若干個 topic ，同屬于一個?topic?的所有數據按照某種策略被分成多個?partition?以實現負載分攤和數據并行處理。
- 采用 push-pull，即 Producer 將數據直接 “push” 給 Broker, 而 Consumer 從Broker?“pull”數據，這種架構優勢帶來以下兩點：
- Consumer 可以根據自己的實際負載和需求獲取數據（自己主動去拉取消息進行消費）
-
Consumer 自己維護已讀取消息的?offset 而不是由Broker 端維護，大大緩解 Broker 的壓力，使得它更加輕量級。?
2. Kafka各組件詳解
1.producer
由用戶使用 Kafka 提供的?SDK?開發的，Producer 將數據轉化成 “消息”，并通過網絡發送給 Broker。每條消息表示為一個三元組： <topic, key, message>
- topic：表示該條消息所屬的 topic，劃分消息的邏輯概念。一個 topic 可以分布到多個不同的 Broker 上。
- key：表示該消息的主鍵。根據主鍵將同一個 topic 下消息劃分成不同的分區 ( partition )，默認基于哈希取模算法，用戶可以自行設置分區算法。如下圖演示 Producer 寫消息的過程，假設 topic A 共分為 4 個 partition (創建 topic 時靜態制定)。
- message：消息值，其類型為字節數組，可以是普通字符串，JSON對象，或者 JSON, Acro,Thrift或Protobuf等序列化框架序列化后的對象。
2. Broker
主要職責是接受 Producer 和 Consumer 的請求，并把消息持久化到本地磁盤。Broker一般有多個，組成一個分布式高容錯的集群。
Kafka Broker 集群- Broker 以 topic 為單位將消息分成不同的分區 （partition），每個分區可以有多個副本，通過數據冗余的方式實現容錯。當 partition 存在多個副本時，其中一個是 leader，對外提供讀寫請求，其余均是 follower，僅僅同步 leader 中的數據，并在 leader 出現問題時，通過選舉算法將其中的某一個提升為 leader。
- Broker 能夠保證同一個 topic 在同一個 partition 內部的消息是有序的，但無法保證 partition 之間的消息全局有序。在實際應用中，合理利用分區內部有序這一特征即可完成時序相關的需求。
- Broker 中保存數據是有有效期，一旦超過了有效期，對應的數據被移除以釋放磁盤空間。在有效期期內，消息可以重復讀取而不受限制。
- Broker 以追加的方式將消息寫到磁盤文件中，且每個分區中消息被賦予了唯一整數標識，稱之為 “offset” （偏移量）。
- Broker 僅提供基于 offset 的讀取方式 ，不會維護各個 Consumer 當前已消費的 offset 值，而是由?Consumer 各自維護當前讀取的進度。Consumer 讀取數據時告訴 Broker 請求消息的起始 offset 值，Broker將之后的消息流式發送過去。如下圖所示：
3.Consumer
- 主動從 Broker 拉取（pull）消息進行處理，這個機制大大降低了 Broker 的壓力，使得 Broker 吞吐率很高。
- 每個Consumer 自己維護最后一個已讀取消息的 offset，并在下次請求從這個 offset 開始的消息。
- 多個Consumer 構成一個Consumer Group，共同讀取同一個?topic?中的數據，提高數據讀取效率。Kafka 可自動為同一個Group 中的 Consumer 分攤負載，從而實現消息的并發讀取，在某個Consumer發生故障時，自動將它處理的 partition 轉移給同 Group 中的 Consumer 處理。
4.Zookeeper
在?Kafka 集群中，Zookeeper 擔任分布式服務協調作用，Broker 和 Consumer 直接依賴于 Zookeeper 才能工作。
- Broker 與 Zookeeper：所有 Broker 會向 Zookeeper 注冊，將自己的位置，健康狀況，維護的 topic，partition等信息寫入 Zookeeper ,以便其他 Consumer 可以發現和獲取這些數據。
- Consumer 與 Zookeeper：Consumer Group 通過Zookeeper 保證內部各個 Consumer 的負載均衡，在某個 Consumer 或 Broker 出現故障時，重新分攤負載。Consumer （僅限于 height-level API，如果是 low-level API，用戶需要自己保存和恢復offset）會將最近獲取消息的 offset 寫入 Zookeeper，以便出現故障重啟后，能夠接著故障前的斷點繼續讀取數據。
3. Kafka關鍵技術點
1. 可控的可靠性級別
Producer 通過兩種方式向 Broker 發送數據：同步 與 異步。異步方式通過批處理的方式，可大大提高數據寫入效率。這兩種方式均支持通過控制消息應答方式，在寫性能與可靠性之間做一個較好的權衡。目前支持三種消息應答方式，通過request.required.ack 控制：
- 0：無需對消息進行確認，性能最高，但不能確保消息被成功接收并寫入磁盤。
- 1：需要等到 leader partition 寫成功后才會返回，但對應的 follower partition 不一定寫成功。在性能與可靠性之間進行折中。
- -1：需要等到所有 partition 均寫成功后才會返回。性能較低，但可靠性最高。
2. 數據多副本
Broker 允許為每個 topic 中的數據存放多個副本，以達到容錯的目的。Kafka 采用強一致的數據復制策略。
Kafka Broker 多副本放置3. 高效的持久化機制
直接將消息持久化到磁盤而不是內存中，這要求必須采用高效的數據寫入和存儲方式。Kafka Broker 將收到的數據順序寫入磁盤，并結合基于 offset 的數據組織方式，能達到高效的讀速度和寫速度。
4. 數據傳輸優化：批處理與zero-copy技術
為了優化 Broker 與 Consumer?之間的網絡數據傳輸效率，Kafka引入了大量優化技術，典型的兩個代表：
- 批處理：發送是將多條消息進行組裝，同時對數據格式統一設計，避免數據格式轉換帶來開銷。
- zero-copy技術：一般情況下，一條存儲在磁盤的數據從讀取到發送出去需要經過四次拷貝（內核狀態 read buffer? > 用戶態應用程序?buffer? > 內核態 socket buffer? > 網卡NIC buffer）和兩次系統調用。經過zero-copy技術優化后，數據只需三次拷貝（少了 用戶態應用程序?buffer），且無需使用任何系統調用，大大提高數據發送效率。如下圖所示：
5. 可控的消息傳遞語義
根據接受者受到重復消息的次數，將消息傳遞語義分為三種：
- at most once：不需要等待確認，消息可能被消費者成功接收，也可能丟失。
- at least once：需要等待確認，如未收到確認則會重發；保障消費者收到消息，但可能會收到多次。
- exactly once：消費者會且只會處理一次同一條消息。
實現第三種語義，常用技術手段有：
- 兩段鎖協議：分布式中常用的一致性協議。
- 在支持冪等操作下，使用 at least once 語義。Producer 與 Broker,? Broker 與 Consumer 之間，均存在消息傳遞語義問題。
典型應用場景
1. 消息隊列
與 RabbitMQ 和 ZeroMQ 等開源消息隊列相比，Kafka 具有高吞吐率，自動分區，多副本以及良好容錯性等特點，使得它非常適合大數據應用場景。
2. 流式計算框架的數據源
在流式計算框架，為了保證數據不丟失，具備“at least once”數據發送語意，通常在數據源中使用具有高性能的消息隊列。
3. 分布式日志收集系統中Source或Sink
可與日志收集組件 Flume 或 Logstash 組合使用，擔任 Source 或 Sink 的角色。
4. Lambda Architecture 中的 Source
同時為批處理和流式處理兩條流水線提供數據源
?
注：內容主要整理自書本《大數據技術體系詳解 原理、架構與實踐》 董西成
與50位技術專家面對面20年技術見證，附贈技術全景圖總結
以上是生活随笔為你收集整理的【中间件】大数据之分布式消息队列Kafka的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 【项目管理】专用中英文术语词汇 205
- 下一篇： 【科普】一图区分 IAAS + PAAS