zeromq：c語言實現，不能資料持久化。
activemq：容易丟訊息，最大併發4000。
redis：可以用，但是非主流，案例很少，不方便擴充套件。
rocketmq：阿里巴巴的中介軟體，資料很少。
****
在實際應用中，可能會發生消費者收到queue中的訊息，但沒有處理完成就宕機（或出現其他意外）的情況，這種情況下就可能會導致訊息丟失。為了避免這種情況發生，我們可以要求消費者在消費完訊息後傳送乙個回執給rabbitmq，rabbitmq收到訊息回執（message acknowledgment）後才將該訊息從queue中移除；如果rabbitmq沒有收到回執並檢測到消費者的rabbitmq連線斷開，則rabbitmq會將該訊息傳送給其他消費者（如果存在多個消費者）進行處理。
這裡不存在timeout概念，乙個消費者處理訊息時間再長也不會導致該訊息被傳送給其他消費者，除非它的rabbitmq連線斷開。
這裡會產生另外乙個問題，如果我們的開發人員在處理完業務邏輯後，忘記傳送回執給rabbitmq，這將會導致嚴重的bug——queue中堆積的訊息會越來越多；消費者重啟後會重複消費這些訊息並重複執行業務邏輯…所以，業務處理實現介面冪等很重要。。。
另外pub message是沒有ack的。
如果我們希望即使在rabbitmq服務重啟的情況下，也不會丟失訊息，我們可以將queue與message都設定為可持久化的（durable），這樣可以保證絕大部分情況下我們的rabbitmq訊息不會丟失。但依然解決不了小概率丟失事件的發生（比如rabbitmq伺服器已經接收到生產者的訊息，但還沒來得及持久化該訊息時rabbitmq伺服器就斷電了），如果我們需要對這種小概率事件也要管理起來，那麼我們要用到事務。
kafka：
kafka 的定位主要在日誌等方面， 因為kafka 設計的初衷就是處理日誌的，可以看做是乙個日誌（訊息）系統乙個重要元件，針對性很強，所以 如果業務方面還是建議選擇 rabbitmq 。
kafka 的效能（吞吐量、tps ）比rabbitmq 要高出來很多。
訊息中介軟體的定位分析
訊息中介軟體的定位分析 在以下的分析中，把產生訊息的應用統一定義為訊息的生產者，接收訊息的應用統一定義為訊息的消費者，儘管在mq中不使用這樣的定義，而是稱之為訊息的傳送 者和接收者。從不同的訊息中介軟體對訊息的產生者和使用者的名稱定義來看，實際上已經反映出各訊息中介軟體之間定位的差異，通過下面的分析...
訊息中介軟體
1.訊息的優先順序 2.訊息排序 3.訊息過濾 4.訊息持久化 5.訊息重試 6.事務的支援 7.broker滿 生產者，佇列，消費者 訊息佇列的優點 1 解耦2 非同步訊息，系統響應 在jms中，有兩種訊息模型 點對點模式和發布訂閱模式。1.在點對點模式中 有三種角色 1 訊息佇列，傳送者，接受者...
訊息中介軟體
如何理解訊息中介軟體？訊息中介軟體是儲存訊息的乙個容器，與資料庫不同的是資料庫儲存的資料是可以被修改的，而訊息中介軟體一般不會被修改 訊息中介軟體在消費的生產者與消費者產生，相當於乙個中間人的角色，提供了路由保證訊息的傳遞，如果消費者不能及時接收，訊息會保留下來，知道消費者上線 保證在存活期內 訊息...