幾個訊息中介軟體的分析
ZeroMQ：c語言實現，不能資料持久化。 ActiveMQ：容易丟訊息，最大併發4000。 redis：可以用，但是非主流，案例很少，不方便擴充套件。 RocketMQ：阿里巴巴的中介軟體，資料很少。 **
RabbitMQ：擁有erlang語言本身的併發優勢，效能好，管理端頁面功能豐富，訊息延遲微秒級，支援多種語言，支援訊息事務。
** 在實際應用中，可能會發生消費者收到Queue中的訊息，但沒有處理完成就宕機（或出現其他意外）的情況，這種情況下就可能會導致訊息丟失。為了避免這種情況發生，我們可以要求消費者在消費完訊息後傳送一個回執給RabbitMQ，RabbitMQ收到訊息回執（Message acknowledgment）後才將該訊息從Queue中移除；如果RabbitMQ沒有收到回執並檢測到消費者的RabbitMQ連線斷開，則RabbitMQ會將該訊息傳送給其他消費者（如果存在多個消費者）進行處理。 這裡不存在timeout概念，一個消費者處理訊息時間再長也不會導致該訊息被髮送給其他消費者，除非它的RabbitMQ連線斷開。 這裡會產生另外一個問題，如果我們的開發人員在處理完業務邏輯後，忘記傳送回執給RabbitMQ，這將會導致嚴重的bug
另外pub message是沒有ack的。
如果我們希望即使在RabbitMQ服務重啟的情況下，也不會丟失訊息，我們可以將Queue與Message都設定為可持久化的（durable），這樣可以保證絕大部分情況下我們的RabbitMQ訊息不會丟失。但依然解決不了小概率丟失事件的發生（比如RabbitMQ伺服器已經接收到生產者的訊息，但還沒來得及持久化該訊息時RabbitMQ伺服器就斷電了），如果我們需要對這種小概率事件也要管理起來，那麼我們要用到事務。
Kafka： Kafka 的定位主要在日誌等方面， 因為Kafka 設計的初衷就是處理日誌的，可以看做是一個日誌（訊息）系統一個重要元件，針對性很強，所以 如果業務方面還是建議選擇 RabbitMq 。 Kafka 的效能（吞吐量、TPS ）比RabbitMq 要高出來很多。