1. Kafka 簡介 Kafka是一種分散式的，基於發佈/訂閱的消息系統，起源於 LinkedIn，用作 LinkedIn 的活動流和運營數據處理管道的基礎。它有以下一些性能特性： 能夠以 O(1) 的時間複雜度提供消息持久化能力，即使對 TB 級以上的數據也能保證常熟時間複雜度的訪問性能； 高吞 ...
1. Kafka 簡介
Kafka是一種分散式的，基於發佈/訂閱的消息系統，起源於 LinkedIn，用作 LinkedIn 的活動流和運營數據處理管道的基礎。它有以下一些性能特性：
- 能夠以 O(1) 的時間複雜度提供消息持久化能力，即使對 TB 級以上的數據也能保證常熟時間複雜度的訪問性能；
- 高吞吐量，即使在非常廉價的商用機器上也能做到單機支持每秒 100k 條以上消息的傳輸；
- 支持 kafka Server 間的消息分區及分散式消費，同時能保證每個 partition 內的消息順序傳輸；
- 支持離線數據處理和實時數據處理；
- Scale out ： 支持線上水平擴展；
2. Kafka 的應用場景
- 消息隊列
kafka 可以用作消息中間件來代替傳統的消息系統。Kafka能提供較高的吞吐量，較低的端到端延遲，多副本，容錯功能以及強大的持久性保證。 - 日誌聚合
日誌搜集通常從伺服器收集物理日誌文件，並將它們集中放置（可能是文件伺服器或HDFS）以便後續處理。kafka抽象出文件的細節，並將日誌或事件數據作為消息流清晰地抽象出來。這可以為更低處理延遲提供支持，多數據源和分散式數據消費更容易支持。與以日誌為中心的系統（如Scribe或Flume）相比，Kafka性能同樣出色，由於副本機制確保了更強的耐用性保，並且端到端延遲更低。 - 監控測量
kafka經常用於運行監控數據。這涉及彙總分散式應用程式的統計數據，以產生操作運營數據的彙總數據。 - 網站行為跟蹤
Kafka經常被用來記錄web用戶或者app用戶的各種活動，如瀏覽網頁、搜索、點擊等活動，這些活動信息被各個伺服器發佈到kafka的topic中，然後訂閱者通過訂閱這些topic來做實時的監控分析，或者裝載到Hadoop、數據倉庫中做離線分析和挖掘 - 流處理
spark streaming和storm。保存收集流數據，以提供之後對接的Storm或其他流式計算框架進行處理。很多用戶會將那些從原始 topic 來的數據進行階段性處理，彙總，擴充或者以其他的方式轉換到新的 topic 下再繼續後面的處理。例如一個文章推薦的處理流程，可能是先從RSS數據源中抓取文章的內容，然後將其丟入一個叫做“文章”的topic中；後續操作可能是需要對這個內容進行清理，比如回覆正常數據或者刪除重覆數據，最後再將內容匹配的結果返還給用戶。這就在一個獨立的topic之外，產生了一系列的實時數據處理的流程。Strom和Samza是非常著名的實現這種類型數據轉換的框架。 - 事件源
事件源是一種應用程式設計的方式，該方式的狀態轉移被記錄為按時間順序排序的記錄序列。Kafka可以存儲大量的日誌數據，這使得它成為一個對這種方式的應用來說絕佳的後臺。比如動態彙總（News feed）。 - 提交日誌
Kafka可以為一種外部的持久性日誌的分散式系統提供服務。這種日誌可以在節點間備份數據，併為故障節點數據回覆提供一種重新同步的機制。具體來講，我們可以將資料庫的更新發佈到 Kafka 上，應用程式通過監控事件流來接收資料庫的實時更新。這種變更日誌也可以用於把資料庫的更新複製到遠程系統上，或者合併多個應用程式的更新到一個單獨的資料庫視圖上。數據持久化為變更日誌提供了緩衝區，如果消費者應用程式發生故障，可以通過重放這些日誌來恢復系統狀態。
3. Kafka 的結構與基本概念
3.1 Kafka 的拓撲結構
如下圖所示，為一個典型的kafka集群
一個kafka集群包含以下幾個部分：
- 若幹生產者 Producer
- 若幹用來存放消息的kafka伺服器 Broker
- 若幹消費者群組 Consumer Group，Consumer Group中由一個或多個 Consumer 組成
- 管理集群配置的 zookeeper
整個kafka集群工作模式為：Producer 使用 push 模式將消息發佈到 broker，comsumer 使用 pull 模式從 broker 訂閱並消費消息，整個集群基於 zookeeper 來進行集群管理，負載均衡等。這裡面涉及到這樣一些術語：
- Broker
kafka 集群包含一個或多個伺服器，每個獨立的 kafka 伺服器被稱為 broker。對於生產者，broker 接收來自生產者的消息，為消息設置 offset，並提交消息到磁碟保存。對於消費者，broker 為消費者讀取分區的請求作出響應，返回分區上的消息。 - Producer
負責發佈消息到 broker 上的對象。 - Comsumer
消息消費者，從 broker 上訂閱消息並處理這些消息 。 - Comsumer Group
若幹 Comsumer 組成的一個消費者集合，與傳統的發佈-訂閱消息系統不同，kafka 是將消息廣播到各個 Comsumer Group 上，而不是單個的 Comsumer 上。 - Topic
kafka 為消息做的邏輯歸類，一個消息類別就是一個 topic。可以認為 topic 是一個邏輯上 queue，每條消息都必須制定它的 topic，生產者與消費者也要通過 topic name 來 push 或者 pull 消息。 - Partition
topic 是一個邏輯上的抽象概念，它具體是由 partition 作物理呈現。一個 topic 被分成多個 partition 存放在不同的伺服器上，一個 partition 在伺服器上對應的是一個具體的文件目錄，目錄下存放的是消息文件和索引文件。 - Segment
kafka 還將 partition 進一步分割成多個段（segment），一個段對應一個伺服器上的log文件。這樣分割好處之一就是在清理過期的消息時，可以對整個段的文件作刪除操作，從而避免對文件的隨機寫操作，提高吞吐量。
3.2 Topic、Partition、Segment 的關係
Kafka 中的消息是以 topic 來進行分類的，一個 topic 又被分成多個 partition，而 partition 還可以被進一步細分為若幹個 segment。那麼這三者具體的呈現是什麼呢？下麵是這三者之間的一個示意圖：
- Topic
Topic是一個消息投遞目標的名稱，它是一個邏輯上的概念。生產者通過 topic 向 broker 發送消息，消費者通過訂閱相應的 topic， 讀取特定一類的消息。 - Partition
Partition 是 topic 的物理層面上的具體分組，每個 partition 為一個目錄，其命名規範為 topicName + 有序序號，序號從 0 開始。每個 partition 都是一個順序的、不可變的消息隊列，每發佈到該 partition 一條消息就追加到其 log 文件的尾部。並且，partition 中的每條消息都被分了一個序列號，這個序列號稱之為偏移量（offset）。offset 是一個 long 型的數字，它唯一標記一條消息。消費者通過控制 offset 來定位讀取 partition 中所要消息。
Kafka 將 topic 拆分成多個 partition 主要有兩個目的：- 支持水平擴展，可以將不同的 partition 放在不同的伺服器上，這樣的話，消息文件的體積將不再受限於單個伺服器的磁碟容量，一個topic可以處理任意數量的數據。
- partition 可以作為並行單元，使得消息可以被多個 comsumer 並行處理（只要將comsumer分佈於不同的 group），可以系統效率。
- Segment
Segment 是對 partition 的進一步細分，它物理上對應到 partition 目錄下的具體 log 文件，以 19 位數字命名規則為：第一個 segment 命名為全0，後續的 segment 文件名為最後一條消息的 offset 值（位數不足左補0）。每個 segment 文件最大存儲量是固定的，可以在配置文件中進行配置。當一個 segment 文件超出設定最大存儲量時，就會創建下一個 segment 文件來存放下一條消息。每個 segment 由兩部分組成： 消息數據文件(.log) 和 索引(.index) 。將 partition 分割成多個 segment 文件可以很方便的清理過期的消息（直接刪除過期的segment文件，而不用再去隨機寫磁碟上的log文件）。
3.3 Comsumer 與 Comsumer Group
傳統的消息有兩種模式：隊列和發佈訂閱。
- 隊列模式：消費者池從伺服器讀取消息（每個消息只被其中一個讀取）。
- 發佈-訂閱模式：消息廣播給所有的消費者。
這兩種模式都有優缺點，隊列的優點是允許多個消費者瓜分處理數據，這樣可以擴展處理。但是，隊列不像多個訂閱者，一旦消息者進程讀取後故障了，那麼消息就丟了。而發佈和訂閱允許你廣播數據到多個消費者，由於每個訂閱者都訂閱了消息，所以沒辦法縮放處理。
kafka 將這兩者做了結合與抽象，提出了消費者組（Comsumer Group）的概念。每個 comsumer 都有一個自己的消費者組名標識，因此多個相同標識的 comsumer 就組成了一個 comsumer group。一個 partition 和一個消費組中一個消費者綁定（保證partition 內消息的有序性），每一條該 partition 上消息是被投遞到訂閱了該 topic 的 comsumer group 上，交由組內的這個 comsumer 實例進行消費。當所有的 comsumer 都在同一個 group中時，這就變成了”隊列模式“，而當每個 comsumer group 中都只有一個 comsumer 時，這就又變成了”發佈-訂閱模式“。實際上， kafka 這種消費者組的模式仍然屬於發佈-訂閱模式範疇，只是訂閱者由單個的消費者實例變成了消費者組。
Kafka的設計理念之一就是同時提供離線處理和實時處理，而 comsumer group 的這種設計就能夠滿足這種特性，為消息的多元化處理提供了支持。它既能夠提供以分區為粒度的並行能力，同時又能保證消息在分區內的有序性。比如，我們可以使用Storm這種實時流處理系統對消息進行實時線上處理，同時使用Hadoop這種批處理系統進行離線處理，還可以同時將數據實時備份到另一 個數據中心，只需要保證這三個操作所使用的consumer在不同的consumer group即可。
