這裡對比下RocketMQ和RabbitMQ，並總結常見問題的解決方式。
1.特性
RocketMQ：
NameServer:整個MQ叢集提供服務協調與治理，具體就是記錄維護Topic、Broker的資訊，及監控Broker的執行狀態，Name Server是一個幾乎無狀態節點，可叢集部署，節點之間無任何資訊同步，相當於註冊中心.
Broker:訊息伺服器，作為server提供訊息核心服務，每個Broker與Name Server叢集中的所有節點建立長連線，定時註冊Topic資訊到所有Name Server；
Producer:訊息生產者，業務的發起方，負責生產訊息傳輸給broker.
Consumer:訊息消費者，業務的處理方，負責從broker獲取訊息並進行業務邏輯處理
RabbitMQ:
Broker:訊息伺服器，作為server提供訊息核心服務
Channel:通道是建立在真實的TCP連線內的虛擬連線.
Routing key:生產者將訊息傳送到交換機時，會在訊息頭上攜帶一個 key，這個 key就是routing key，來指定這個訊息的路由規則。
Binding key:在繫結Exchange與Queue時，一般會指定一個binding key，生產者將訊息傳送給Exchange時，訊息頭上會攜帶一個routing key，當binding key與routing key相匹配時，訊息將會被路由到對應的Queue中。
2.重複消費
正常情況下，消費者在消費訊息的時候，消費完畢後，會發送一個確認訊息給訊息佇列，訊息佇列就知道該訊息被消費了，就會將該訊息從訊息佇列中刪除； 但是因為網路傳輸等等故障，確認資訊沒有傳送到訊息佇列，導致訊息佇列不知道自己已經消費過該訊息了，再次將訊息分發給其他的消費者。
保證訊息的唯一性，就算是多次傳輸，不要讓訊息的多次消費帶來影響；保證訊息等冪性；
3.丟失資料
生產者丟資料：（1）採取send()同步發訊息，傳送結果是同步感知的。傳送失敗後可以重試，設定重試次數。預設3次。（2）傳送失敗的訊息會儲存在Commitlog中。
訊息佇列丟資料：（1）訊息支援持久化到Commitlog裡面，即使宕機後重啟，未消費的訊息也是可以加載出來的；（2）Broker自身支援同步刷盤、非同步刷盤的策略，可以保證接收到的訊息一定儲存在本地的記憶體中；（3）Broker叢集支援 1主N從的策略，支援同步複製和非同步複製的方式，同步複製可以保證即使Master 磁碟崩潰，訊息仍然不會丟失
消費者丟失資料：（1）完全成功後傳送ACK；（2）維護一個持久化的offset
生產者丟資料：RabbitMQ提供transaction（事務，支援回滾）和confirm模式（ACK給生產者）來確保生產者不丟訊息；
訊息佇列丟資料：開啟rabbitmq的持久化，就是訊息寫入之後會持久化到磁碟，持久化可以跟生產者那邊的confirm機制配合起來，只有訊息被持久化到磁碟之後，才會通知生產者ack。
消費者丟失資料：消費者丟資料一般是因為採用了自動確認訊息模式，改為手動確認訊息，處理訊息成功後，手動回覆確認訊息。
4.消費順序
主要思路有兩種：1、單執行緒消費來保證訊息的順序性；2、對訊息進行編號，消費者處理時根據編號判斷順序。
每個queue的資料本身就是有序的，只要消費者這邊有序消費，那麼可以保證資料被順序消費。如果是多執行緒消費，就要consumer內部用記憶體佇列做排隊。
5.高可用
多Master：配置簡單，效能最高，但可能會有少量訊息丟失（配置相關），單臺機器重啟或宕機期間，該機器下未被消費的訊息在機器恢復前不可訂閱，影響訊息實時性
多Master多Slave非同步模式：每個Master配一個Slave，有多對Master-Slave，訊息寫入全部是傳送到Master Broker的，獲取訊息也可以Master獲取，少了Slave Broker，會導致所有讀寫壓力都集中在Master Broker，叢集採用非同步複製方式，主備有短暫訊息延遲，毫秒級；效能同多Master幾乎一樣，實時性高，主備間切換對應用透明，不需人工干預，但Master宕機或磁碟損壞時會有少量訊息丟失；
多Master多Slave同步模式：每個Master配一個Slave，有多對Master-Slave，訊息寫入全部是傳送到Master Broker的，獲取訊息也可以Master獲取，少了Slave Broker，會導致所有讀寫壓力都集中在Master Broker，叢集採用同步雙寫方式，主備都寫成功，嚮應用返回成功；優點是服務可用性與資料可用性非常高；缺點是效能比非同步叢集略低，當前版本主宕備不能自動切換為主。
普通叢集模式：多臺機器上啟動多個rabbitmq例項，每個機器啟動一個。但是你建立的queue，只會放在一個rabbtimq例項上，但是每個例項都同步queue的元資料。完了你消費的時候，實際上如果連線到了另外一個例項，那麼那個例項會從queue所在例項上拉取資料過來。如果那個放queue的例項宕機了，會導致接下來其他例項就無法從那個例項拉取，如果你開啟了訊息持久化，讓rabbitmq落地儲存訊息的話，訊息不一定會丟，得等這個例項恢復了，然後才可以繼續從這個queue拉取資料。
映象叢集模式：建立的queue，無論元資料還是queue裡的訊息都會存在於多個例項上，然後每次寫訊息到queue的時候，都會自動把訊息到多個例項的queue裡進行訊息同步。缺點:（1）效能開銷大，因為需要進行整個叢集內部所有例項的資料同步；（2）無法線性擴容: 因為每一個伺服器中都包含整個叢集服務節點中的所有資料, 這樣如果一旦單個伺服器節點的容量無法容納了。
這裡對比下RocketMQ和RabbitMQ，並總結常見問題的解決方式。
1.特性
RocketMQ：
NameServer:整個MQ叢集提供服務協調與治理，具體就是記錄維護Topic、Broker的資訊，及監控Broker的執行狀態，Name Server是一個幾乎無狀態節點，可叢集部署，節點之間無任何資訊同步，相當於註冊中心.
Broker:訊息伺服器，作為server提供訊息核心服務，每個Broker與Name Server叢集中的所有節點建立長連線，定時註冊Topic資訊到所有Name Server；
Producer:訊息生產者，業務的發起方，負責生產訊息傳輸給broker.
Consumer:訊息消費者，業務的處理方，負責從broker獲取訊息並進行業務邏輯處理
RabbitMQ:
Broker:訊息伺服器，作為server提供訊息核心服務
Channel:通道是建立在真實的TCP連線內的虛擬連線.
Routing key:生產者將訊息傳送到交換機時，會在訊息頭上攜帶一個 key，這個 key就是routing key，來指定這個訊息的路由規則。
Binding key:在繫結Exchange與Queue時，一般會指定一個binding key，生產者將訊息傳送給Exchange時，訊息頭上會攜帶一個routing key，當binding key與routing key相匹配時，訊息將會被路由到對應的Queue中。
2.重複消費
正常情況下，消費者在消費訊息的時候，消費完畢後，會發送一個確認訊息給訊息佇列，訊息佇列就知道該訊息被消費了，就會將該訊息從訊息佇列中刪除； 但是因為網路傳輸等等故障，確認資訊沒有傳送到訊息佇列，導致訊息佇列不知道自己已經消費過該訊息了，再次將訊息分發給其他的消費者。
保證訊息的唯一性，就算是多次傳輸，不要讓訊息的多次消費帶來影響；保證訊息等冪性；
3.丟失資料
RocketMQ：
生產者丟資料：（1）採取send()同步發訊息，傳送結果是同步感知的。傳送失敗後可以重試，設定重試次數。預設3次。（2）傳送失敗的訊息會儲存在Commitlog中。
訊息佇列丟資料：（1）訊息支援持久化到Commitlog裡面，即使宕機後重啟，未消費的訊息也是可以加載出來的；（2）Broker自身支援同步刷盤、非同步刷盤的策略，可以保證接收到的訊息一定儲存在本地的記憶體中；（3）Broker叢集支援 1主N從的策略，支援同步複製和非同步複製的方式，同步複製可以保證即使Master 磁碟崩潰，訊息仍然不會丟失
消費者丟失資料：（1）完全成功後傳送ACK；（2）維護一個持久化的offset
RabbitMQ:
生產者丟資料：RabbitMQ提供transaction（事務，支援回滾）和confirm模式（ACK給生產者）來確保生產者不丟訊息；
訊息佇列丟資料：開啟rabbitmq的持久化，就是訊息寫入之後會持久化到磁碟，持久化可以跟生產者那邊的confirm機制配合起來，只有訊息被持久化到磁碟之後，才會通知生產者ack。
消費者丟失資料：消費者丟資料一般是因為採用了自動確認訊息模式，改為手動確認訊息，處理訊息成功後，手動回覆確認訊息。
4.消費順序
主要思路有兩種：1、單執行緒消費來保證訊息的順序性；2、對訊息進行編號，消費者處理時根據編號判斷順序。
每個queue的資料本身就是有序的，只要消費者這邊有序消費，那麼可以保證資料被順序消費。如果是多執行緒消費，就要consumer內部用記憶體佇列做排隊。
5.高可用
RocketMQ：
多Master：配置簡單，效能最高，但可能會有少量訊息丟失（配置相關），單臺機器重啟或宕機期間，該機器下未被消費的訊息在機器恢復前不可訂閱，影響訊息實時性
多Master多Slave非同步模式：每個Master配一個Slave，有多對Master-Slave，訊息寫入全部是傳送到Master Broker的，獲取訊息也可以Master獲取，少了Slave Broker，會導致所有讀寫壓力都集中在Master Broker，叢集採用非同步複製方式，主備有短暫訊息延遲，毫秒級；效能同多Master幾乎一樣，實時性高，主備間切換對應用透明，不需人工干預，但Master宕機或磁碟損壞時會有少量訊息丟失；
多Master多Slave同步模式：每個Master配一個Slave，有多對Master-Slave，訊息寫入全部是傳送到Master Broker的，獲取訊息也可以Master獲取，少了Slave Broker，會導致所有讀寫壓力都集中在Master Broker，叢集採用同步雙寫方式，主備都寫成功，嚮應用返回成功；優點是服務可用性與資料可用性非常高；缺點是效能比非同步叢集略低，當前版本主宕備不能自動切換為主。
RabbitMQ:
普通叢集模式：多臺機器上啟動多個rabbitmq例項，每個機器啟動一個。但是你建立的queue，只會放在一個rabbtimq例項上，但是每個例項都同步queue的元資料。完了你消費的時候，實際上如果連線到了另外一個例項，那麼那個例項會從queue所在例項上拉取資料過來。如果那個放queue的例項宕機了，會導致接下來其他例項就無法從那個例項拉取，如果你開啟了訊息持久化，讓rabbitmq落地儲存訊息的話，訊息不一定會丟，得等這個例項恢復了，然後才可以繼續從這個queue拉取資料。
映象叢集模式：建立的queue，無論元資料還是queue裡的訊息都會存在於多個例項上，然後每次寫訊息到queue的時候，都會自動把訊息到多個例項的queue裡進行訊息同步。缺點:（1）效能開銷大，因為需要進行整個叢集內部所有例項的資料同步；（2）無法線性擴容: 因為每一個伺服器中都包含整個叢集服務節點中的所有資料, 這樣如果一旦單個伺服器節點的容量無法容納了。