訊息中介軟體對比

為什麼選擇RocketMQ

價效比，社群活躍度
價效比之“性”：
效能：阿里支撐，經受住淘寶，天貓雙11重重考驗；效能高；可靠性好；可用性高；易擴充套件
功能：功能完善，我們需要的功能，基本都夠滿足，如：事務訊息，訊息重試，私信佇列，定時訊息等；
易用，跨平臺：跨語言，多協議接入（支援HTTP, MQTT, TCP協議，支援Restful風格HTTP收發訊息）
價效比之“價”：
錢能解決的問題，一般都不是問題，所以免費服務不能滿足的，適當的花錢購買所需服務是值得的，早期阿里引進的IOE，那我們引進的就是RocketMQ的阿里雲和VIP服務；
當然，錢解決不了的問題，那必然是問題，IOE的高消費，不如去IOE尋找技術方面的突破,
社群活躍度：

RocketMQ佇列消費謹記

一個消費者可以消費多個佇列，但一個佇列只能由一個消費者消費

RocketMQ訊息順序和重複消費問題

RocketMQ特性

順序性
訊息過濾
訊息持久化
訊息回溯
大量訊息堆積
定時訊息
訊息重試

RocketMQ廣播與叢集區別

RocketMQ高可用

RocketMQ分散式事務

RocketMQ有哪些坑

RocketMQ的namesrv全掛掉是否影響通訊

RocketMQ的生產者和傳送者Reblance

RocketMQ佇列中的訊息有序，能否保證消費者消費也有序

必須是順序消費才可以，並行消費無法做到有序。是否受網路影響，順序消費也有可能無序，待測

RocketMQ怎麼設定訊息是從Master消費還是從Slaver消費。Master和Slaver同時線上，訊息是否會從Master消費一遍，然後再從Slaver消費一遍？

RocketMQ預設埠

namesrv預設埠9876，broker預設埠10911，VIP預設埠10909，每個broker啟動後預設佔用兩個埠10911和10913或10912和10914

RocketMQ同一臺機，啟動多個生產者例項或多個消費者例項，需要設定不同的例項名稱

RocketMQ無論何種情況（傳送到單個佇列，順序消費或並行消費；或者傳送到多個佇列，順序消費或者並行消費），延時/定時訊息總是遲於非延時/非定時訊息到達broker，延時/定時訊息是在延時/定時時間過後才被投放到broker，也即延時/定時訊息不會影響非延時/非定時訊息到達broker。如果等待所有訊息全部到達broker之後，才啟動消費者，這個延時/定時是否還有意義？

RocketMQ在不考慮網路影響的情況下，只有將同一ID的訊息傳送到同一佇列上，並且消費端使用順序消費，才能保證訊息被順序消費。即生產者不使用MessageQueueSelector或者消費者不使用MessageListenerOrderly的任何一種情況出現都不能保證訊息被順序消費，考慮網路影響的情況待測。

RocketMQ消費端訊息ack是ack到本地佇列，然後由本地佇列登記後，再5秒鐘間隔上報到broker？

經測試：調大上報時間，本地ack之後（返回CONSUME_SUCCESS，且#Diff > 0），立即停掉消費端，過許久，發現仍#Diff > 0，證明消費端確實還沒有上報ack進度給broker；重啟消費端之後，因#Diff > 0，訊息又被重新消費了一次，證明之前broker確實沒收到ack，也由此可證明消費端ack是先ack到本地佇列，停掉消費端，本地佇列的所有資訊都沒有了，也就因此遲遲不會將#Diff變為0。