為什麼說rocketmq更適用於業務型的訊息中介軟體，因為它能夠保證訊息不丟失且帶有事務訊息。先來看一張rocketmq集群部署結構
其中name server主要是提供路由資訊，這裡暫時忽略，大致流程為：
producer(生產者生產訊息) --> broker(儲存訊息) --> consumer(消費訊息)
接下來我們通過這分析者三個節點來具體說明：
預設情況下可以通過同步的方式傳送訊息，然後檢查傳送狀態，如果是ok，就一定傳送到了broker，否則會觸發預設的2次重試，這裡可能成功也可能沒成功，可以**處理
採用事務訊息transactionmqproducer方式傳送訊息，不能保證一定傳送到broker（事務回滾）；但如果傳送consumer時返回ack失敗的話，會儲存在commitlog中，不能算完全丟失
rocketmq支援日誌的索引，如果一條訊息傳送之後超時，可以通過查詢日誌的api來檢查是否在broker儲存成功
訊息支援持久化到commitlog中，即使宕機重啟，也可以保證訊息不會丟失
broker支援同步或非同步刷盤策略，可以保證接收到的訊息一定儲存在本地檔案中
broker集群中支援1主n從策略，支援同步雙寫、非同步複製，其中同步雙寫可以保證即使master磁碟崩潰，訊息不會丟失（在從節點有相同的備份）
consumer自身維護乙個持久化的offset（對應messagequeue裡面的min offset），標記已成功消費或發回broker訊息的下標
如果consumer訊息消費失敗，會將訊息發回到broker，然後更新自己的offset
如果在訊息發回到broker過程中broker掛了，consumer會定時重試這個操作
如果broker和consumer同時掛了，訊息也不會丟失（commitlog和持久化offset），在重啟恢復後繼續從offset繼續消費訊息
總結來說就是：多次重試+持久化+offset+主從備份來保證訊息不丟失
rocketmq如何保證訊息不丟失
一 大體可以從三方面來說 分別從producer傳送機制 broker的持久化機制，以及消費者的offset機制來最大程度保證訊息不易丟失 從producer的視角來看 如果訊息未能正確的儲存在mq中，或者消費者未能正確的消費到這條訊息，都是訊息丟失。從broker的視角來看 如果訊息已經存在bro...
RocketMQ保證訊息不丟失
分別從producer傳送機制 broker的持久化機制，以及消費者的offset機制來最大程度保證訊息不易丟失 從producer的視角來看 如果訊息未能正確的儲存在mq中，或者消費者未能正確的消費到這條訊息，都是訊息丟失。從broker的視角來看 如果訊息已經存在broker裡面了，如何保證不會...
RocketMQ 如何保證訊息順序消費
rocketmq支援區域性順序消費，但不支援全域性，換句話說針對topic中的每個queue是可以按照fifo進行消費。要保證乙個訂單有關的訊息順序消費，有兩點需要注意，一是將訂單有關的訊息傳送到相關topic中同乙個queue裡，二是消費者按照先進先出的原則進行消費。在訊息傳送時，需指定對應的me...