目錄
一 爲什麼要用Kafka？
1.1 寫在前面–什麼是中間件？
中間件概念很廣泛，這裏只介紹一般性概念，即：
- 中間件位於操作系統與應用軟件之間，用於連接系統軟件（例如：操作系統）和應用軟件（例如：app），便於軟件之間通訊；中間件是爲應用軟件服務的。
- 常用的中間件如：Tomcat（服務器中間件）、RabbitMQ（消息中間件）、Redis（緩存中間件）等
而Kafka則屬於消息中間件一類。
1.2 Kafka的發展歷史簡介
最早由LinkedIn孕育開發。由於需要收集大量的集合日誌、跟蹤站點事件、某些業務需要隊列的功能等，LinkedIn主導開發出了分佈式發佈-訂閱平臺Kafka。
Kafka設計原則是：爲生產者和消費者提供簡單的API、高吞吐量、支持橫向擴展。
1.3 什麼時候應該用Kafka？
- 實時數據傳輸
在如今推薦系統盛行的情況下，如何做到實時爲用戶推送感興趣的內容？這裏面涉及到大數據分析，推薦算法等，但是大數據分析的前提是如何獲取和傳輸大量數據，並且是實時傳輸？
早在2010年前後，LinkedIn公司也致力於解決類似問題，於是有了Kafka。 - 網站行爲追蹤
將用戶行爲數據，網頁瀏覽數據發送到Kafka，下游系統從Kafka獲取數據並進行實時分析。 - 日誌收集
Kafka用於從多個服務收集日誌。 - 流式處理
Spark Streaming這樣的大數據框架從Kafka獲取數據進行實時處理並把處理結果發送到Kafka中，以供用戶或應用程序使用。
1.4 Kafka的優缺點
1.4.1 優點
- 高吞吐量：支持每秒數千條消息的處理
- 低延遲：能夠在毫秒內處理消息
- 容錯
- 持久化：支持消息持久化，可以設置消息的保存時間
- 分佈式
- 消費者友好型：可以集成各種類型的消費者，包括不同語言編寫的消費者客戶端
- 實時處理：Kafka的流處理API支持實時處理數據
1.4.2 缺點
- 沒有完整的管理監控工具
- 不支持通配符的topic選擇
- 消息大小增加，性能降低：消息增大時，Kafka會壓縮和解壓消息，降低吞吐量
- 當集羣中隊列數量增加時，它變得比較慢
- 消息傳遞模式比較單一：沒有點對點、請求/應答等模式
1.5 Kafka vs. 傳統消息隊列
- 設計理念
Kafka：已客戶端爲中心，客戶端接管了Broker的很多事，換來的好處是一個輕量級、易於擴展的Broker。
消息隊列：以Broker爲中心，負責消息的分發等，而客戶端只需要擔心消息的發送與接收。 - 擴展性
Kafka：增加更多分區可以實現橫向擴展
消息隊列：不能橫向擴展 - 性能
Kafka：不會隨着消費者的增加而性能下降
消息隊列：性能隨着消費者的增加而下降 - 消息發佈方式
Kafka：訂閱/發佈和點對點消息發佈模式都用topic來解決
消息隊列：同時支持訂閱/發佈和點對點消息發佈模式 - 日誌
Kafka：每個topic對應一個日誌
消息隊列：所有消息存放在一個日誌裏 - 消息投遞失敗
Kafka：客戶端負責重新獲取消息，因爲消息保存在broker不會被刪除
消息隊列：broker負責重新分發消息 - 消息的完整性
Kafka：支持完整性校驗
消息隊列：不支持完整性校驗 - 消息的重新獲取
Kafka：支持消息的重新獲取，因爲消息在Kafka中是持久化的
消息隊列：不支持消息重新獲取，因爲消息被成功消費後會從隊列中刪除，不會保留下來
二 Kafka的架構設計
2.1 核心架構設計
簡要解釋：zookeeper負責kafka broker leader的選舉和kafka集羣的服務發現。
2.2 topic分區、消費者組、生產者等詳細設計
一個topic對應多個分區，消息的Key值不同會被放到不同的分區，有一個映射算法進行映射操作。圖片最右邊是消費者組，一個消費者組由多個消費者組成，每個消費者消費一個分區的消息，如果消費者數量小於分區數量，則某些消費者消費不止一個分區的消息；如果消費者數量大於分區數量，則某些消費者會閒置起來。
不同的消費者組會記錄自己停止消費的offset以便下次從該offset繼續讀取消息，生產者將消息追加到分區末尾。