Kafka的原理和應用分析及和RabbitMQ的對比

1. kafka是什麼

Kafka 是一個分佈式消息流處理平臺，原本開發自 LinkedIn，用作 LinkedIn 的活動流（Activity Stream）和運營數據處理管道（Pipeline）的基礎。現在它已被多家公司作爲多種類型的數據管道和消息系統使用^{1 2}。

作爲一個消息處理平臺，kafka主要有以下功能²：

• 發佈和訂閱數據流，類似於消息隊列或企業級的消息分發系統
• 以容錯、持久化的方式存儲數據流
• 對數據流進行實時處理
• 在多個系統或應用之間建立實時的數據流管道
• 建立實時數據流應用，來對數據流傳輸和響應

kafka的功能示意圖如圖所示。

1.1 Topics

topics是一個分類，或者叫數據供給中心（feed），發佈者生產數據到topics，消費者從topics消費數據。kafka的topics總是有多個消費者，即0個，1個，或多個。
kafka的功能示意圖如圖所示。

一個topic有多個分片（partition），每個分片是一個有序的數據序列，而且分片是持續增長的。分片中的每一條記錄（record）有一個序號（offset），用來唯一標識該記錄在分片中的位置。
Kafka集羣使用一個可配置的時間週期來保存所有發佈的記錄，無論它們是否已經被消費。舉個例子，如果保留策略設置的是兩天，在數據記錄發佈後的兩天內，它是可以被消費的，但兩天後，它就會被丟棄以釋放空間。

1.2 Producers 和 Consumers

生產者自己選擇發佈數據到相應的topics。生產者發佈數據到Kafka集羣的服務器（broker），一般來說，Kafka集羣有多個broker，用來做負載均衡³。生產者發佈數據也可以採取簡單的循環方式進行負載均衡，也可以依據一定的分區策略（比如基於record中的key）。

由於broker本身是無狀態的，所以需要Zookeeper來維護服務器的狀態。Apache ZooKeeper是Apache軟件基金會的一個軟件項目，他爲大型分佈式計算提供開源的分佈式配置服務、同步服務和命名註冊（naming）⁴。Kafka提供默認、簡單的Zookeeper配置文件用於啓動一個本地的Zookeeper實例⁵。Zookeeper通知生產者和消費者Kafka集羣中新的服務器（broker）的出現或者某個服務器的失敗。

在Kafka裏把消費者按標籤分成消費者組（consumer group），每一條發佈到topic的記錄被髮送到一個消費者實例。消費者實例可以在不同的進程或不同的機器上。如果所有的消費者實例都在相同的組中，那麼數據記錄會以負載均衡的方式分配給消費者實例。如果消費者實例處在不同的組別中，每一個記錄會被廣播到所有的消費者組中的一個實例上²。如圖所示。

2. Kafka的架構

下圖展示了Kafka的整體架構。生產者發佈消息到topic，每個topic又分成多個partition，每臺服務器（broker）擁有0個或多個topic的partition。每個partition是一個有讀寫順序的log文件，存儲在硬盤上⁶。

相比於傳統的 發佈/訂閱 系統，Kafka中的消費者可以看做是一組合作的進程。topic中的每個partition傳送給消費者組中的一個消費者。因此，partition的個數是topic的並行個數，也決定了消費者的並行程度。而且，由於每個partition都有一個對應的消費者實例，消費者進程就可以被動的記下它讀取的位置（根據partition中的offset），不需要在讀到信息的同時就去標記它們的位置，這對於性能的提供有很大的幫助。

值得一提的是，在0.8.2以後的版本，Kafka的消費者擺脫了對Zookeeper的依賴，取而代之的是在broker內部的協調器。仍依賴ZooKeeper的是控制器和集羣的管理、topic和partition的管理、同步數據複製（in-sync data replication）和一些靜態配置（配額、ACLs）⁷。詳細信息如下：

Kafka uses Zookeeper for the following:

• Electing a controller. The controller is one of the brokers and is responsible for maintaining the leader/follower relationship for all
  the partitions. When a node shuts down, it is the controller that
  tells other replicas to become partition leaders to replace the
  partition leaders on the node that is going away. Zookeeper is used to
  elect a controller, make sure there is only one and elect a new one it
  if it crashes.
• Cluster membership - which brokers are alive and part of the cluster? this is also managed through ZooKeeper.
• Topic configuration - which topics exist, how many partitions each has, where are the replicas, who is the preferred leader, what
  configuration overrides are set for each topic
• (0.9.0) - Quotas - how much data is each client allowed to read and write
• (0.9.0) - ACLs - who is allowed to read and write to which topic
• (old high level consumer) - Which consumer groups exist, who are their members and what is the latest offset each group got from each
  partition.

3. Kafka的應用場景^{6 5 3}

• 發佈/訂閱消息（Pub/Sub Messaging） 在兩個條件下，使用Kafka作爲發佈/訂閱系統比較合適：1）路由邏輯比較簡單，Kafka的topic就可以處理；2）每個topic的吞吐量超過了RabbitMQ可以處理的量；
• 可擴展的數據聚合系統（Scalable Ingestion System） 許多大數據處理平臺要求高吞吐量，在許多場景，如何高效加載數據到這些平臺是主要的瓶頸。Kafka爲這些場景提供了一個可擴展的解決方案。而且，像 Apache Spark 和 Apache Flink 等平臺已經把Kafka集成在內了。
• 數據層基礎設施（Data-Layer Infrastructure） 由於它的持久化和高效率的多播，Kafka可以作爲底層的數據基礎設施，用於連接流服務和應用。
• 捕獲變化源（Capturing Change Feeds） 變化源是一系列更新事件，它捕獲作用於初始狀態的所有變化（如數據表或數據表中某一列的變化）。
• 流處理（Stream Processing） 流處理開始於Kafka的0.10.0版本，它是一個輕量級的數據流處理庫。對於數據產生快、實時性強的數據流（股市分析、用戶行爲、氣象監測等）可以實現在線的計算和分析。Apache Samza是一個開源的數據流處理平臺，就是基於Kafka的。

典型案例：

• Twitter：用Kafka作爲流處理設施。
• LinkedIn：用於活動流和運營數據。這些數據被用於新聞推送、離線分析系統等產品。
• Yahho!: Yahho的媒體分析組用作實時數據分析。
• Netflix: 作爲數據收集網關，該應用每天收集十億級別的消息。

4. 和RabbitMQ的對比

4.1 RabbitMQ架構

RabbitMQ實現和擴展了AMQP協議，默認支持AMQP 0.9.1，可以通過插件支持到AMQP 1.0。如AMQP的架構圖所示，AMQP採用了模塊化的方案⁶：

• 交換器（Exchange）。本質上是一個路由，接受消息，按照一定的規則決定把消息路由到哪個消息隊列。
• 消息隊列（Message Queue）。消息隊列存儲消息並把消息發送到消費者。
  

把交換器和消息隊列聯繫起來的是綁定鍵（binding），它指定了交換器如何路由消息。對於一個AMQP連接，通道（channel）可以用來對消息流進行隔離。在一個多線程的環境裏，一般給各個線程分配獨立的channel。

4.2 使用場景對比

在第3節對Kafka的使用場景作了介紹。這裏說一下RabbitMQ的最佳使用場景。

• 發佈/訂閱系統（Pub/Sub Messaging）。由於這就是爲什麼RabbitMQ被創建出來的原因，所以它滿足大部分的使用需求。
• 請求-響應消息系統（Request-Response Messaging）。RabbitMQ藉助 correlation id 和 reply-to 特性來實現 RPC(Remote procedure call) 形式的通信。下圖可幫助理解這個過程，具體用法參考⁸。
  
• 運營數據跟蹤（Operational Metrics Tracking）。RabbitMQ也是用於實時數據處理不錯的選擇，特別是RabbitMQ可以提供更爲複雜的數據過濾和分類策略。
• 物聯網應用平臺的底層服務（Underlying Layer for IoT Applications Platform）。

4.3 不同的特性

4.3.1 Kafka獨有的特性

• 長時間的消息存儲。Kafka存儲消息到硬盤上。當在配置的週期過後，或消息存儲量超過topic的硬盤配額，消息纔會被清除。
• 消息回放（Message Replay）。由於Kafka的消費者是無狀態的，而且消息可以存儲較長時間，在需要的時候，消費者可以很容易的回放消息。這對於下游的系統的容錯是一個非常有用的特性。
• Kafka Connect。Kafka Connect是一個用於在Kafka和其他系統之間支持可擴展和可靠的數據流的框架。它爲Kafka和其它系統創建規模可擴展的、可信賴的流數據提供了一個簡單的模型，通過connectors可以將大數據從其它系統導入到Kafka中，也可以從Kafka中導出到其它系統。Kafka 0.9提供了這一特性⁹。下圖展示了這一框架的作用。
  
• 日誌壓縮（Log Compaction）。日誌壓縮至少保留單個主題分區的每個記錄鍵的最後已知值。壓縮日誌對於在崩潰或系統故障後恢復狀態非常有用¹⁰。

4.3.2 RabbitMQ獨有的特性

（1）標準協議。RabbitMQ使用了AMQP這一標準協議，這就決定了它可以很容易和其他兼容AMQP的系統一起工作，甚至比較容易替換。

（2）多協議支持。RabbitMQ支持一些工業界其他標準協議，只要有MQTT（IoT領域用的比較多）和STOMP。

（3）分佈式拓撲模型（Distributed Topology Modes）。federation是rabbitmq官方提供的插件，federation插件允許我們針對exchange和queue做federation，從而形成federated exchange或者federated queue。federation插件可以在brokers或者cluster之間傳輸消息，連接的雙方可以使用不同的users和virtual hosts，或者雙方的rabbitmq和erlang的版本不一致，federation插件使用AMQP協議通訊，可以接受不連續的傳輸¹¹。federation如何使用在這裏¹²。而且，RabbitMQ也提供了另一個插件Shovel，可以方便的把brokers或clusters連接起來¹³。

（4）非常好用的管理和監控工具。RabbitMQ提供了好用的UI來管理和監控RabbitMQ的方方面面：(i) connections, (ii) queues, (iii) exchanges, (iv) clustering, federation and shoveling, (v) packet tracing, (vi) resource consumption⁶.

（5）多用戶和隔離性（Multi-tenancy and Isolation）。RabbitMQ實現了AMQP的Virtual Hosts的概念，使得單個服務器可以有多個隔離的環境。

（6）跟蹤消費者的狀態。對於隊列來說，RabbitMQ保存消費者的狀態，確切的必到哪個消費者在什麼時候消費了什麼消息。

（7）硬盤空間的低使用量。如果不需要持久化的話，RabbitMQ不需要使用硬盤空間來路由分發數據包。這對於嵌入式的應用和資源有限制的環境來說是一個很好的選擇。RabbitMQ也成功的部署在了樹莓派上¹⁴。

（8）流量控制（Flow Control）。RabbitMQ 使用了一種基於 credit 的算法來限制 message 被 publish 的速率¹⁵。

（9）Message TTL. 消息可以設置一個生存時間（Time To Live），如果它超出了生存時間，將不會被髮送給消費者。

4.4 Kafka和RabbitMQ的結合使用

有一些使用場合，單獨使用Kafka或RabbitMQ的話不能應付，那麼可以考慮把它們兩個結合起來使用。
（1）RabbitMQ --> Kafka. RabbitMQ在前，Kafka在後。RabbitMQ在前可以保證低延遲性，同時以較細粒度來選擇需要長時間存儲的消息。

（2）Kafka -->RabbitMQ . Kafka在前，RabbitMQ在後。如果整個系統的吞吐量比較高，而對於每個topic的吞吐量需求，一個RabbitMQ的服務器又是可以處理，這樣的需求可以選擇這個方案。 Kafka在前，保證吞吐量，RabbitMQ在後，處理複雜的路由邏輯。

AMQP-Kafka Bridge可以實現Kafka和RabbitMQ之間的交互。

參考：

---

1. Apache kafka 工作原理介.https://www.ibm.com/developerworks/cn/opensource/os-cn-kafka/index.html ↩︎

2. Introduction. https://kafka.apache.org/intro ↩︎ ↩︎ ↩︎

3. Hiraman B R, Abhijeet C K. A Study of Apache Kafka in Big Data Stream Processing[C]//2018 International Conference on Information, Communication, Engineering and Technology (ICICET). IEEE, 2018: 1-3. ↩︎ ↩︎

4. Apache ZooKeeper. https://zh.wikipedia.org/wiki/Apache_ZooKeeper ↩︎

5. Thein K M M. Apache kafka: Next generation distributed messaging system[J]. International Journal of Scientific Engineering and Technology Research, 2014, 3(47): 9478-9483. ↩︎ ↩︎

6. Dobbelaere P, Esmaili K S. Kafka versus RabbitMQ: A comparative study of two industry reference publish/subscribe implementations: Industry Paper[C]//Proceedings of the 11th ACM International Conference on Distributed and Event-based Systems. ACM, 2017: 227-238. ↩︎ ↩︎ ↩︎ ↩︎

7. https://www.quora.com/What-is-the-actual-role-of-Zookeeper-in-Kafka-What-benefits-will-I-miss-out-on-if-I-don’t-use-Zookeeper-and-Kafka-together ↩︎

8. Remote procedure call (RPC). https://www.rabbitmq.com/tutorials/tutorial-six-java.html ↩︎

9. Kafka Connect簡介. https://colobu.com/2016/02/24/kafka-connect/ ↩︎

10. Kafka Architecture: Log Compaction. http://cloudurable.com/blog/kafka-architecture-log-compaction/index.html ↩︎

11. Rabbitmq學習之路4-Federation. https://my.oschina.net/guol/blog/186436 ↩︎

12. Federation Plugin. https://www.rabbitmq.com/federation.html ↩︎

13. Shovel Plugin. https://www.rabbitmq.com/shovel.html ↩︎

14. T. Abarbanell. Benchmarking RabbitMQ on Raspberry Pi, 2015. URL http://blog.abarbanell.de/raspberry/2015/05/17/benchmarking-rabbitmq-on-raspberry/. ↩︎

15. RabbitMQ-流量控制. https://www.good21.com/2015/12/02/rabbitmq-flowcontrol/ ↩︎