一、選擇訊息佇列產品的基本標準
在訊息佇列的技術選型上，並不存在說哪個訊息佇列就是「最好的」。常用的幾個訊息佇列，每個產品都有自己的優勢和劣勢，需要根據現有系統的情況，選擇最適合的那款產品。
技術產品的及格標準：
訊息佇列產品的及格標準：
二、可供選擇的訊息佇列產品
1、rabbitmq
介紹：劣勢：
rabbitmq 官方文件：
2、rocketmq
介紹：劣勢：
rocketmq 官方文件：
rocketmq 中國開發者中心：
3、kafka
介紹：劣勢：
kafka 官方文件：
三、第二梯隊的訊息佇列
這些產品之所有沒那麼流行，或多或少都有著比較明顯的短板，不推薦使用，只是作簡單介紹。
1、activemq
2、zeromq
3、pulsar
四、總結：
選擇的建議：
如果訊息佇列並不是將要構建系統的主角之一，對訊息佇列功能和效能都沒有很高的要求，只需乙個開箱即用易維護的產品，建議使用rabbitmq。(有良好的運維介面，僅僅只是使用訊息佇列功能，用於非同步和業務模組解耦，對效能要求不是很高。rabbitmq能滿足現階段需求)
，比如在交易系統中用訊息佇列傳遞訂單，那rocketmq的低延遲和金融級的穩定性是你需要的。
如果需要處理海量的訊息，想收集日誌、監控資訊或是前端埋點這類資料，或應用場景大量使用了大資料、流計算(做事後的統計分析)相關的開源產品，那kafka是最適合的。
1 選擇訊息佇列MQ
更快的返回結果。減少等待，實現了步驟之間的併發，提公升系統整體效能。使用訊息佇列隔離閘道器和後端服務，以達到流量控制和保護後端服務的目的。秒殺開始後，當短時間內大量的秒殺請求到達閘道器時，不會直接衝擊到後端的秒殺服務，而是先堆積在訊息佇列中，後端服務按照自己的最大處理能力，從訊息佇列中消費請求進行處...
使用訊息佇列場景及訊息佇列的選擇策略
在實際開發中已經接觸過kafka，rabbitmq等訊息佇列了，但對於什麼場景下使用佇列，而現在開源的佇列又那麼多元化，該怎麼去選擇呢，今天我花時間去檢視了很多資料，也受益匪淺，花時間整理下，以供以後使用佇列時參考。a.非同步處理，提高吞吐量，減少開銷 b.應用解耦，防止介面端應用崩潰，資料阻塞丟失...
訊息佇列 訊息佇列
輪詢排程 一次性分發所有訊息，保證訊息平均分配，不管消費者是否能正常消費 訊息應答 保證消費端能確實消費，不丟失 公平 乙個乙個分發所有訊息,在保證分發到的執行緒確認回覆後，才分發下個訊息給下個空閒的消費者，訊息持久化 保證佇列中的訊息不丟失，包括3要素 交換器 訊息佇列 訊息都必須宣告持久化 發布...