Kafka與RabbitMQ

一、什麼是kafka，什麼是rabbit

  Kafka是由Scala語言開發的一種分散式流處理框架，主要用於處理活躍的流式數據，以及大數據量的數據處理。它採用發佈-訂閱模型，支持消息的批量處理，數據的存儲和獲取是本地磁碟順序批量操作，這使得消息處理的效率較高，吞吐量較大。

  RabbitMQ則是由Erlang語言開發，主要用於實時的、對可靠性要求較高的消息傳遞。它採用AMQP（高級消息隊列協議）進行消息的傳遞，並且有一個broker（消息代理）作為中心，可以確認消息的傳遞。RabbitMQ支持消息的可靠的傳遞，支持事務，但並不支持批量操作，基於存儲的可靠性的要求存儲可以採用記憶體或硬碟，但吞吐量相對較小。

二、rabbit和kafka的特性

（1）Kafka的特性：

1. 大規模數據處理：Kafka的吞吐量巨大，其數據存儲和獲取是本地磁碟的批量處理，可以達到百萬/s。
2. 持久性消息存儲：Kafka是一個持久性消息存儲，在數據寫入後即使出現系統崩潰，也能夠保證數據的完整性。
3. 可靠性的支持：Kafka的broker支持主備模式，為數據的安全性提供了保障。

（2）RabbitMQ的特性：

1. 消息確認機制：RabbitMQ具有生產者confirm機制以及消費者的消息應答機制ack，可以保證消息的可靠傳遞。
2. 消息順序性：在RabbitMQ中，在一個隊列里的消息是嚴格順序的，按照先進先出。
3. 持久化支持：RabbitMQ支持持久化，可以把消息寫入到磁碟中，保證數據在記憶體不足時也不會丟失。
4. 高可用性：RabbitMQ使用了MirrorQueue的機制，可以將重要隊列“複製”到集群中的其他broker上，保證這些隊列的消息不會丟失。

（3）二者的相同點在於都是為瞭解決消息的傳遞問題，但在很多方面也有顯著的不同：

1. 架構模型：RabbitMQ遵循AMQP協議，由Exchange、Binding、queue組成，其中exchange和binding組成了消息的路由鍵；客戶端Producer通過連接channel和server進行通信，Consumer從queue獲取消息進行消費。而Kafka遵從一般的MQ結構，以producer、broker、consumer為中心。
2. 消息確認機制：Kafka並不具有應答機制，而RabbitMQ具有生產者confirm機制以及消費者的消息應答機制ack。
3. 消息的順序：在RabbitMQ中，在一個隊列裡面，rabbitmq的消息是嚴格順序的，按照先進先出。然而在Kafka中，雖然每個partition中的消息是有序的，但是因為Kafka將數據分佈在不同的partition中，所以總體是無序的。
4. 吞吐量：在不使用ACK機制的情況下，RabbitMQ的QPS可以達到6W+，而在雙方使用ACK機制的情況下，QPS降到了1W+。與此相反的是，Kafka具有巨大的吞吐量，數據的存儲以及獲取是本地磁碟的批量處理，可以達到百萬/s。
5. 可靠性： RabbitMQ使用了MirrorQueue的機制，也可以做到多個機器進行熱備。而Kafka的主備模式提供了另外一種可靠性保障。

總的來說，RabbitMQ和Kafka在特性和應用場景上各有優勢和劣勢。在選擇使用時需要考慮到自身需求以及兩者的特性和限制。

三、兩者使用場景，如何才能方便應用

  我們首先要明白kafka不是消息中間件的一種實現，他是分散式流系統，他的定位就是來處理日誌及大數據方面，吞吐量無疑是很高的。而rabbit他的push模式就導致了他得延時是較低的，但是場景上只支持主從，所以在本身的設計上就是比較小的，cpu消耗自然就更低。

從消息順序來講：

Kafka可以保證在單個分區中的消息順序是有序的，即按照消息的寫入順序進行消費。但是，當使用多個分區時，就不能保證消息的順序了，因為每個分區都是獨立的，消息的寫入順序和消費順序都是分區內部的順序，與其他分區無關，如果需要保證消息的順序，可以將所有的消息寫入到單個分區中，或者使用單個消費者或消費者組來消費消息。

而對於RabbitMQ，如果是單個消費者，那麼它先進先出的機制，可以保證消息的有序性，但是如果有多個消費者從同一個隊列中讀取消息，那麼就難以保證消息的順序。例如，一個消費者在處理消息後可能由於失敗等原因將消息放回隊列，這樣另一個消費者就可以繼續處理它，從而可能導致消息的順序錯亂。這種情況下，可以通過限制消費者併發數=1的方式來保證消息的有序性。

（1）Kafka的使用場景和例子：

1. 大規模數據流處理：Kafka可以處理大規模的數據流，並且具有高吞吐量和持久性特性，可以承受大量的數據。例如，一個大型的網路應用需要收集來自數百台伺服器的日誌數據，並將這些數據傳遞給分散式數據處理系統（如 Apache Spark）進行實時數據分析和儀錶板展示。 Kafka可以作為數據樞紐，伺服器將日誌消息發佈到Kafka Topic中，而 Spark 則通過消費者從 Kafka 中訂閱和處理這些消息。
2. 實時數據流處理：Kafka可以支持實時的數據流處理，並且具有低延遲的特性。例如，電商平臺需要實時處理訂單和庫存消息，當有新訂單生成時，需要通知庫存管理系統進行庫存調整。 Kafka可以用於傳遞這些實時的訂單和庫存消息，並支持低延遲的處理。

（2）RabbitMQ的使用場景和例子：

1. 消息路由：RabbitMQ可以通過消息路由的方式將消息發送到不同的消費者或者消費者組中。例如，一個電子商務平臺需要處理訂單和庫存管理，當有新訂單生成時，需要通知庫存管理系統進行庫存調整。 RabbitMQ可以將訂單消息路由到庫存管理系統，並通知其進行庫存調整。
2. 消息持久化：RabbitMQ可以保證消息的持久化存儲，以便在系統故障時能夠恢復消息。例如，在電子商務平臺中，如果訂單處理系統出現故障，RabbitMQ可以保證訂單消息不被丟失，併在系統恢復後繼續處理。

   總體來說，Kafka更適合大規模的數據流處理和實時數據處理場景，而RabbitMQ更適合消息路由和持久化存儲場景，要選擇適合自己項目的架構。

四、總結

  Kafka和RabbitMQ都是用於消息傳遞的工具，它們具有不同的特性和應用場景。Kafka適合處理大規模的實時數據流，並具有高吞吐量和持久性特性，而RabbitMQ更適合消息路由和持久化存儲，並具有消息確認機制和嚴格的消息順序。在選擇使用時，需要考慮到自身需求以及兩者的特性和限制。

  PS：可以結合使用：雖然Kafka和RabbitMQ具有不同的特性和應用場景，但它們可以結合使用，以獲得更好的效果。例如，可以使用Kafka來處理大規模的實時數據流，並使用RabbitMQ來處理消息路由和持久化存儲

  本文簡述一些特性以及區別，但是我們要應用於生產上的項目和結構還是要去看官方文檔，文檔里都有詳細的方案，從而助我們更好的分辨需要用什麼工具。本文如果有什麼錯誤點歡迎大家指正。