一、什麼是kafka，什麼是rabbit
Kafka是由Scala語言開發的一種分散式流處理框架，主要用於處理活躍的流式資料，以及巨量資料量的資料處理。它採用釋出-訂閱模型，支援訊息的批次處理，資料的儲存和獲取是本地磁碟順序批次操作，這使得訊息處理的效率較高，吞吐量較大。
RabbitMQ則是由Erlang語言開發，主要用於實時的、對可靠性要求較高的訊息傳遞。它採用AMQP（高階訊息佇列協定）進行訊息的傳遞，並且有一個broker（訊息代理）作為中心，可以確認訊息的傳遞。RabbitMQ支援訊息的可靠的傳遞，支援事務，但並不支援批次操作，基於儲存的可靠性的要求儲存可以採用記憶體或硬碟，但吞吐量相對較小。
二、rabbit和kafka的特性
（1）Kafka的特性：
- 大規模資料處理：Kafka的吞吐量巨大，其資料儲存和獲取是本地磁碟的批次處理，可以達到百萬/s。
- 永續性訊息儲存：Kafka是一個永續性訊息儲存，在資料寫入後即使出現系統崩潰，也能夠保證資料的完整性。
- 可靠性的支援：Kafka的broker支援主備模式，為資料的安全性提供了保障。
（2）RabbitMQ的特性：
- 訊息確認機制：RabbitMQ具有生產者confirm機制以及消費者的訊息應答機制ack，可以保證訊息的可靠傳遞。
- 訊息順序性：在RabbitMQ中，在一個佇列裡的訊息是嚴格順序的，按照先進先出。
- 持久化支援：RabbitMQ支援持久化，可以把訊息寫入到磁碟中，保證資料在記憶體不足時也不會丟失。
- 高可用性：RabbitMQ使用了MirrorQueue的機制，可以將重要佇列「複製」到叢集中的其他broker上，保證這些佇列的訊息不會丟失。
（3）二者的相同點在於都是為了解決訊息的傳遞問題，但在很多方面也有顯著的不同：
- 架構模型：RabbitMQ遵循AMQP協定，由Exchange、Binding、queue組成，其中exchange和binding組成了訊息的路由鍵；使用者端Producer通過連線channel和server進行通訊，Consumer從queue獲取訊息進行消費。而Kafka遵從一般的MQ結構，以producer、broker、consumer為中心。
- 訊息確認機制：Kafka並不具有應答機制，而RabbitMQ具有生產者confirm機制以及消費者的訊息應答機制ack。
- 訊息的順序：在RabbitMQ中，在一個佇列裡面，rabbitmq的訊息是嚴格順序的，按照先進先出。然而在Kafka中，雖然每個partition中的訊息是有序的，但是因為Kafka將資料分佈在不同的partition中，所以總體是無序的。
- 吞吐量：在不使用ACK機制的情況下，RabbitMQ的QPS可以達到6W+，而在雙方使用ACK機制的情況下，QPS降到了1W+。與此相反的是，Kafka具有巨大的吞吐量，資料的儲存以及獲取是本地磁碟的批次處理，可以達到百萬/s。
- 可靠性： RabbitMQ使用了MirrorQueue的機制，也可以做到多個機器進行熱備。而Kafka的主備模式提供了另外一種可靠性保障。
總的來說，RabbitMQ和Kafka在特性和應用場景上各有優勢和劣勢。在選擇使用時需要考慮到自身需求以及兩者的特性和限制。
三、兩者使用場景，如何才能方便應用
我們首先要明白kafka不是訊息中介軟體的一種實現，他是分散式流系統，他的定位就是來處理紀錄檔及巨量資料方面，吞吐量無疑是很高的。而rabbit他的push模式就導致了他得延時是較低的，但是場景上只支援主從，所以在本身的設計上就是比較小的，cpu消耗自然就更低。
從訊息順序來講：
Kafka可以保證在單個分割區中的訊息順序是有序的，即按照訊息的寫入順序進行消費。但是，當使用多個分割區時，就不能保證訊息的順序了，因為每個分割區都是獨立的，訊息的寫入順序和消費順序都是分割區內部的順序，與其他分割區無關，如果需要保證訊息的順序，可以將所有的訊息寫入到單個分割區中，或者使用單個消費者或消費者組來消費訊息。
而對於RabbitMQ，如果是單個消費者，那麼它先進先出的機制，可以保證訊息的有序性，但是如果有多個消費者從同一個佇列中讀取訊息，那麼就難以保證訊息的順序。例如，一個消費者在處理訊息後可能由於失敗等原因將訊息放回佇列，這樣另一個消費者就可以繼續處理它，從而可能導致訊息的順序錯亂。這種情況下，可以通過限制消費者並行數=1的方式來保證訊息的有序性。
（1）Kafka的使用場景和例子：
- 大規模資料流處理：Kafka可以處理大規模的資料流，並且具有高吞吐量和永續性特性，可以承受大量的資料。例如，一個大型的網路應用需要收集來自數百臺伺服器的紀錄檔資料，並將這些資料傳遞給分散式資料處理系統（如 Apache Spark）進行實時資料分析和儀表板展示。 Kafka可以作為資料樞紐，伺服器將紀錄檔訊息釋出到Kafka Topic中，而 Spark 則通過消費者從 Kafka 中訂閱和處理這些訊息。
- 實時資料流處理：Kafka可以支援實時的資料流處理，並且具有低延遲的特性。例如，電商平臺需要實時處理訂單和庫存訊息，當有新訂單生成時，需要通知庫存管理系統進行庫存調整。 Kafka可以用於傳遞這些實時的訂單和庫存訊息，並支援低延遲的處理。
（2）RabbitMQ的使用場景和例子：
- 訊息路由：RabbitMQ可以通過訊息路由的方式將訊息傳送到不同的消費者或者消費者組中。例如，一個電子商務平臺需要處理訂單和庫存管理，當有新訂單生成時，需要通知庫存管理系統進行庫存調整。 RabbitMQ可以將訂單訊息路由到庫存管理系統，並通知其進行庫存調整。
- 訊息持久化：RabbitMQ可以保證訊息的持久化儲存，以便在系統故障時能夠恢復訊息。例如，在電子商務平臺中，如果訂單處理系統出現故障，RabbitMQ可以保證訂單訊息不被丟失，並在系統恢復後繼續處理。
總體來說，Kafka更適合大規模的資料流處理和實時資料處理場景，而RabbitMQ更適合訊息路由和持久化儲存場景，要選擇適合自己專案的架構。
四、總結
Kafka和RabbitMQ都是用於訊息傳遞的工具，它們具有不同的特性和應用場景。Kafka適合處理大規模的實時資料流，並具有高吞吐量和永續性特性，而RabbitMQ更適合訊息路由和持久化儲存，並具有訊息確認機制和嚴格的訊息順序。在選擇使用時，需要考慮到自身需求以及兩者的特性和限制。
PS：可以結合使用：雖然Kafka和RabbitMQ具有不同的特性和應用場景，但它們可以結合使用，以獲得更好的效果。例如，可以使用Kafka來處理大規模的實時資料流，並使用RabbitMQ來處理訊息路由和持久化儲存
本文簡述一些特性以及區別，但是我們要應用於生產上的專案和結構還是要去看官方檔案，檔案裡都有詳細的方案，從而助我們更好的分辨需要用什麼工具。本文如果有什麼錯誤點歡迎大家指正。