重溫 Apache Kafka

最新 07-03

1.核心概念

Kafka最初是由LinkedIn在2011年開發出來的，從那開始，Kafka逐漸發展成為一個完整的平台，允許你冗餘存儲難以置信的數據量，提供巨大吞吐量的消息匯流排(百萬級/秒)，以及對這些消息的實時流處理。

Kafka的核心可概括為：分散式(distributed)、水平擴展(horizontally-scalable)、容錯性(fault-tolerant)、持久性日誌(commit log)

分散式簡單說，就是把運算處理分布到多個機器上，這些機器作為一個集群協同工作，而對終端用戶而言，只是面對一個節點，而非一群機器。

水平擴展，簡單說就是加多多的機器參與運算，對應的，垂直擴展，是指給一台伺服器上加多多的內存 CPU和硬碟，對比來看，水平擴展是可以無限擴展的。

容錯性是由分散式的特點決定的，一個5個節點的Kafka集群，即使2個節點down掉，仍然可以正常工作，另外提一句，容錯和性能之間存在著一種平衡，你的系統容錯性越高，越影響性能(性能越低)。

持久性日誌，commit log，也可稱之為write-ahead log(預寫日誌) 或transaction log(事務日誌)。

從資料庫的角度講，write-ahead log 和transaction log 的提法比較普遍，WAL機制即指Write-Ahead Logging，是實現事務日誌的標準方法。WAL 的中心思想是先寫日誌，再寫數據，數據文件的修改必須發生在這些修改已經記錄在日誌文件中之後。本質上，是防止資料庫崩潰發生數據頁不完整的情況。

Kafka的commit log，從機制上講，與資料庫的WAL機制相似，是一種防止節點崩潰的機制，不同的是，對於Kafka來說，需要確保的不是數據頁，而是消息的完整，Kafka是一個基於副本的高可靠的消息系統，在消息可用前，Kafka保證消息已經提交到足夠多的副本中。

從數據上講，commit log是指Kafka存儲消息的文件，其數據結構式是固定順序的一組記錄(Record)，Offset+MessageSize+Message構成日誌中的每條記錄，日誌只支持append操作，且不允許修改和刪除

這樣存儲消息的特點是：讀寫操作都是O(1)的時間複雜度；讀寫操作互不干擾。其好處是帶來巨大的性能提升，這是因為文件的大小跟文件的讀寫性能解耦，無論伺服器上有100KB或者100TB的數據，Kafka的性能都不會受到影響。

2.工作方式

Kafka的工作流程可以解釋為：「生產者(producer)」發送「消息(message)」到「broker(Kafka 節點)」，消息存儲在某一個「topic(主題)」上，「消費者(consumer)」通過「訂閱(subscript)」主題，收到消息並且進行處理。

主題topic又分成多個分區(partition)，這樣可以提高性能和擴展性，消息最終是存儲在topic的某一個分區里，每個分區，就是一個commit log 文件，前面說過，日誌記錄(Record)=Offset+MessageSize+Message

Kafka奉行啞的broker和聰明的consumer的原則，就是說，Kafka不會理會消息是否被消費了，而進一步去決定是否刪除消息(一般的消息中間件是處理方式是：消息被消費即刪除)，Kafka會一直保存消息直到達到某個時間段、或某個上限值，而Kafka留給每個consumer中的唯一的元數據就是Offset，因此consumer可以通過控制offset，多次讀取並處理相同的消息。

需要明確的是，comsumer消費者，在Kafka中實際上指的是comsumer groups，消費者組，每個消費者組中包含一個或多個消費者進程或者消費者線程，消費者進程或者消費者線程統一稱為消費者實例-consumer instance。消費者實例可以分散到不同機器上。

換個說法，即consumer接收消息，是按照group來接收的，即去訂閱主題的是consumer group 而不是單個的消費者實例，並且同一個group中只有一個消費者實例可以消費消息，Kafka提供負載均衡機制在各個消費者實例間分發消息，如下圖，Consumer Group A 和 B都訂閱了同一個主題，Group A中兩個消費者實例，每個消費掉2個消息，而Group B中的四個消費者實例，每個消費一個。

從消息中間件MQ的規範講，比如傳統的JMS規範，消息處理需要支持兩種模式：點對點模式和發布訂閱模式，點對點模式即每個消息只能有一個消費者消費，多個消費者監聽一個消息隊列時，處於一種爭搶方式，被消費的消息隨即刪除；發布訂閱模式即多個消費者訂閱一個主題，消息生產者向主題發送消息，則每個消費者都可以收到消息。

通過Kafka的consumer group的概念，可以實現傳統消息的兩種模式，同一consumer group中的消費者實例，處於點對點模式之中；而多個consumer group訂閱同一個主題，則各個consumer group處於發布訂閱模式之中。

3.數據分發與複製

主題Topic的分區數據在Kafka集群的不同節點上保留副本，至於保留多少個副本，可以通過配置文件配置。

副本是怎麼分發到各個節點的呢，這裡需要引入分區leader和follower的概念：分區leader是生產者和消費者寫入和讀取數據的地方，當生產者發送消息到分區leader時，leader把消息副本分發給其他節點，這些節點可稱為follower

那麼生產者和消費者怎麼知道哪個分區是leader呢？Kafka把誰是分區leader這些元數據存儲在Zookeeper，各個節點去向zookeeper同步元數據，這樣集群中每個節點都知道誰是哪個分區的leader了(從Kafka 0.8版本開始，採用這種機制)

4.流式計算

Kafka從0.10版本開始，提供自己的流式計算Library-Kafka Stream，是Library，類庫，而不是流式計算框架

對比Spark Streaming和Apache Storm等流式處理框架，Kafka Stream只需要Kafka，不需要任何外部框架或者服務，使用時，可方便的集成到自己的工程中，Kafka Stream不是運行在Kafka節點上的，而是像消費者API一樣，可在其他應用上隨意擴展。

繼續下去之前，先介紹一下窗口的概念

窗口(windowing)是指流式處理過程中執行聚合(aggregation)操作的時間周期。窗口的定義很多，取決於特定的使用場景，基於時間的窗口將特定時間間隔內的事件分組，適合於回答類似於這樣的問題「上一分鐘產生了多少次交易」（摘自 O』REILLY 《流式架構 kafka與MapR Streams 數據流處理》）

流式計算除了可以充當ETL過程中T的角色，另外一個重要的作用就是回答窗口提出的問題，而回答問題的方式-比如執行聚合(aggregation)操作，又跟資料庫求解的方式相似，因此，Stream 和 Table 的概念之間需要引入一些聯繫

Stream-Table Duality 流和表的對偶性，即把流視為表，反之亦然，把表視為流

流作為表時，一個流可以認為是一個表的變更日誌，這是事件溯源(Event Sourcing)的概念，流中每個數據記錄著表每次的變化，表最終體現出流數據聚合的結果，用來回答窗口的提問