一 Kafka 概述
1.1 Kafka 是什么
在流式計算中，Kafka 一般用來緩存數據，Storm 通過消費 Kafka 的數據進行計算。
1）Apache Kafka 是一個開源消息系統（微信公眾號、QQ、微信等群），由 Scala 寫成。
是由 Apache 軟件基金會開發的一個開源消息系統項目。
2）Kafka 最初是由 LinkedIn 公司開發，並於 2011 年初開源。2012 年 10 月從 Apache
Incubator 畢業。該項目的目標是為處理實時數據提供一個統一、高通量、低延時的平台。
3）Kafka 是一個分布式消息隊列。Kafka 對消息保存時根據 Topic 進行歸類，發送消息
者稱為 Producer，消息接受者稱為 Consumer，此外 kafka 集群有多個 kafka 實例組成，每個
實例(server)成為 broker。Redis 分布式界內的小鋼炮!!!!
4）無論是 kafka 集群，還是 producer 和 consumer 都依賴於 zookeeper 集群保存一些
meta 信息，來保證系統可用性。
1.2 消息隊列內部實現原理
（1）點對點模式（一對一，消費者主動拉取數據，消息收到后消息清除）
點對點模型通常是一個基於拉取或者輪詢的消息傳送模型，這種模型從隊列中請求信
息，而不是將消息推送到客戶端。這個模型的特點是發送到隊列的消息被一個且只有一個接
收者接收處理，即使有多個消息監聽者也是如此。
（2）發布/訂閱模式（一對多，數據生產后，推送給所有訂閱者）
發布訂閱模型則是一個基於推送的消息傳送模型。發布訂閱模型可以有多種不同的訂閱
者，臨時訂閱者只在主動監聽主題時才接收消息，而持久訂閱者則監聽主題的所有消息，即
使當前訂閱者不可用，處於離線狀態。
為什么需要消息隊列
1）解耦：
允許你獨立的擴展或修改兩邊的處理過程，只要確保它們遵守同樣的接口約束。
2）冗余：
消息隊列把數據進行持久化直到它們已經被完全處理，通過這一方式規避了數據丟失風
險。許多消息隊列所采用的"插入-獲取-刪除"范式中，在把一個消息從隊列中刪除之前，需
要你的處理系統明確的指出該消息已經被處理完畢，從而確保你的數據被安全的保存直到你
使用完畢。
3）擴展性：
因為消息隊列解耦了你的處理過程，所以增大消息入隊和處理的頻率是很容易的，只要
另外增加處理過程即可。
4）靈活性 & 峰值處理能力：
在訪問量劇增的情況下，應用仍然需要繼續發揮作用，但是這樣的突發流量並不常見。
如果為以能處理這類峰值訪問為標准來投入資源隨時待命無疑是巨大的浪費。使用消息隊列
能夠使關鍵組件頂住突發的訪問壓力，而不會因為突發的超負荷的請求而完全崩潰。
5）可恢復性：
系統的一部分組件失效時，不會影響到整個系統。消息隊列降低了進程間的耦合度，所
以即使一個處理消息的進程掛掉，加入隊列中的消息仍然可以在系統恢復后被處理。
6）順序保證：
在大多使用場景下，數據處理的順序都很重要。大部分消息隊列本來就是排序的，並且
能保證數據會按照特定的順序來處理。（Kafka 保證一個 Partition 內的消息的有序性）
7）緩沖：
有助於控制和優化數據流經過系統的速度，解決生產消息和消費消息的處理速度不一致
的情況。
8）異步通信：
很多時候，用戶不想也不需要立即處理消息。消息隊列提供了異步處理機制，允許用戶
把一個消息放入隊列，但並不立即處理它。想向隊列中放入多少消息就放多少，然后在需要
的時候再去處理它們。
1.4 Kafka 架構
1）Producer ：消息生產者，就是向 kafka broker 發消息的客戶端。
2）Consumer ：消息消費者，向 kafka broker 取消息的客戶端
3）Topic ：可以理解為一個隊列。
4）Consumer Group （CG）：這是kafka用來實現一個topic消息的廣播（發給所有的consumer）
和單播（發給任意一個 consumer）的手段。一個 topic 可以有多個 CG。topic 的消息會復制-
給 consumer。如果需要實現廣播，只要每個 consumer 有一個獨立的 CG 就可以了。要實現
單播只要所有的 consumer 在同一個 CG。用 CG 還可以將 consumer 進行自由的分組而不需
要多次發送消息到不同的 topic。
5）Broker ：一台 kafka 服務器就是一個 broker。一個集群由多個 broker 組成。一個 broker
可以容納多個 topic。
6）Partition：為了實現擴展性，一個非常大的 topic 可以分布到多個 broker（即服務器）上，
一個 topic 可以分為多個 partition，每個 partition 是一個有序的隊列。partition 中的每條消息
都會被分配一個有序的 id（offset）。kafka 只保證按一個 partition 中的順序將消息發給
consumer，不保證一個 topic 的整體（多個 partition 間）的順序。
7）Offset：kafka 的存儲文件都是按照 offset.kafka 來命名，用 offset 做名字的好處是方便查
找。例如你想找位於 2049 的位置，只要找到 2048.kafka 的文件即可。當然 the first offset 就
是 00000000000.kafka
1.5 分布式模型
Kafka 每個主題的多個分區日志分布式地存儲在 Kafka 集群上，同時為了故障容錯，每
個分區都會以副本的方式復制到多個消息代理節點上。其中一個節點會作為主副本
（Leader），其他節點作為備份副本（Follower，也叫作從副本）。主副本會負責所有的客
戶端讀寫操作，備份副本僅僅從主副本同步數據。當主副本出現故障時，備份副本中的一個
副本會被選擇為新的主副本。因為每個分區的副本中只有主副本接受讀寫，所以每個服務器
端都會作為某些分區的主副本，以及另外一些分區的備份副本，這樣 Kafka 集群的所有服務
端整體上對客戶端是負載均衡的。
Kafka 的生產者和消費者相對於服務器端而言都是客戶端。
Kafka 生產者客戶端發布消息到服務端的指定主題，會指定消息所屬的分區。生產者發
布消息時根據消息是否有鍵，采用不同的分區策略。消息沒有鍵時，通過輪詢方式進行客戶
端負載均衡；消息有鍵時，根據分區語義（例如 hash）確保相同鍵的消息總是發送到同一
分區。
Kafka 的消費者通過訂閱主題來消費消息，並且每個消費者都會設置一個消費組名稱。
因為生產者發布到主題的每一條消息都只會發送給消費者組的一個消費者。所以，如果要實
現傳統消息系統的“隊列”模型，可以讓每個消費者都擁有相同的消費組名稱，這樣消息就
會負責均衡到所有的消費者；如果要實現“發布-訂閱”模型，則每個消費者的消費者組名
稱都不相同，這樣每條消息就會廣播給所有的消費者。
分區是消費者現場模型的最小並行單位。如下圖（圖 1）所示，生產者發布消息到一台
服務器的 3 個分區時，只有一個消費者消費所有的 3 個分區。在下圖（圖 2）中，3 個分區
分布在 3 台服務器上，同時有 3 個消費者分別消費不同的分區。假設每個服務器的吞吐量時
300MB，在下圖（圖 1）中分攤到每個分區只有 100MB，而在下圖（圖 2）中，集群整體的
吞吐量有 900MB。可以看到，增加服務器節點會提升集群的性能，增加消費者數量會提升
處理性能。
同一個消費組下多個消費者互相協調消費工作，Kafka 會將所有的分區平均地分配給所
有的消費者實例，這樣每個消費者都可以分配到數量均等的分區。Kafka 的消費組管理協議
會動態地維護消費組的成員列表，當一個新消費者加入消費者組，或者有消費者離開消費組，
都會觸發再平衡操作。
Kafka 的消費者消費消息時，只保證在一個分區內的消息的完全有序性，並不保證同一
個主題匯中多個分區的消息順序。而且，消費者讀取一個分區消息的順序和生產者寫入到這
個分區的順序是一致的。比如，生產者寫入“hello”和“Kafka”兩條消息到分區 P1，則消
費者讀取到的順序也一定是“hello”和“Kafka”。如果業務上需要保證所有消息完全一致，
只能通過設置一個分區完成，但這種做法的缺點是最多只能有一個消費者進行消費。一般來
說，只需要保證每個分區的有序性，再對消息假設鍵來保證相同鍵的所有消息落入同一分區，
就可以滿足絕大多數的應用。
二 Kafka 集群部署