訊息佇列的作用：非同步、解耦、削峰填谷。
1、處理失敗訊息重發問題
場景：比如活動系統、積分系統同時監聽使用者下單訊息，但是此時可能由於網路抖動或是**bug導致積分系統處理失敗，所以積分系統就會要求傳送端重發訊息。如何保證訊息重複不會影響業務呢？
思考：這個問題其實就是保證介面的冪等性，那如何保證介面冪等性，根據場景可以分為強校驗和弱校驗。
（1）強校驗：跟錢相關的，比如訂單這種，最好建立記錄表，每次訊息過來都要拿著訂單號+業務場景這樣的唯一標識去流水表查，看看有沒有這條記錄，有就直接return，沒有就執行後面的邏輯。
(2) 弱校驗：
比如發簡訊，把這個id+場景唯一標識作為redis的key，放到快取裡面失效時間看場景，一定時間內的這個訊息就去redis判斷。
rocketmq如何實現訊息重發？？？
2、訊息順序消費問題
場景：主要用在資料庫binlog，同步資料的增刪改操作。
思考：順序傳送：乙個topic對應多個佇列（一般是4個），rocketmq提供了messagequeueselector選擇機制（佇列的路由策略），比如訂單訊息，可以對訂單id進行hash取模，傳送時使用同步傳送，讓同乙個訂單發的操作有序送到相同的佇列中。
順序消費：如果是單執行緒，同乙個訂單的操作在同乙個佇列中，根據fifo就可以保證順序消費，如果是多執行緒，可以在迴圈處理訊息時將同乙個訂單的所有操作封裝在一起在扔到執行緒池處理。
**實現：rocketmq提供了併發和順序的訊息監聽方式，併發監聽messagelistenerconcurrently，也就是基於多個執行緒並行來消費訊息，無法保證訊息消費的順序。順序監聽messagelistenerorderly，如下：
consumer.subscribe("store_topic_test","*");
consumer.registermessagelistener((messagelistenerorderly) (list, consumeorderlycontext) ->
);
順序消費會帶來一些問題：
（1）遇到訊息處理失敗，無法跳過，當前佇列消費暫停
（2）降低訊息處理的效能
3、多環境隔離、可靠性訊息傳送、任意延時訊息實現方案
（1）多環境隔離使用rocketmq自帶的佇列路由策略
（2）可靠性傳送和任意延時訊息使用嵌入式k-v資料庫rocksdb
文章：4、如何保證不丟訊息
分為三個階段：
（1）生產階段：有同步傳送和非同步傳送，判斷broker返回的狀態，建立失敗補償機制
（2）broker儲存階段：訊息先存在記憶體中，然後再刷盤，分為同步刷盤和非同步刷盤，可以使用同步刷盤，但是會影響效能。
（3）消費階段：控制訊息返回狀態。
文章：5、消費訊息的兩種方式 pull 和 push
push方式裡，consumer把輪詢過程封裝了，並註冊messagelistener***，取到訊息後，喚醒messagelistener的consumemessage()來消費，對使用者而言，感覺訊息是被推送過來的。push方式其實也是拉取訊息，不過封裝好了輪詢過程。該方式實時性高，用起來方便。
pull方式裡，取訊息的過程需要使用者自己寫，首先通過打算消費的topic拿到messagequeue的集合，遍歷messagequeue集合，然後針對每個messagequeue批量取訊息，一次取完後，記錄該佇列下一次要取的開始offset，直到取完了，再換另乙個messagequeue。該方式控制權在消費端，好控制，但是拉取的時間間隔不好定義。
通過問題了解rocketmq
rocketmq在面試中那些常見問題及答案 彙總 rocketmq 分布式事務 分布式事務 3 rocketmq實現分布式事務原理 1 說說你們公司線上生產環境用的是什麼訊息中介軟體?rabbitmq erlang語言開發，開發者想看原始碼時成本較高，不過社群活動度高。rabbitmq對訊息堆積不是...
RocketMQ解決冪等性問題
一.造成重複消費的原因 在於回饋機制。正常情況下，消費者在消費訊息時候，消費完畢後，會傳送乙個ack確認資訊給訊息佇列 broker 訊息佇列 broker 就知道該訊息被消費了，就會將該訊息從訊息佇列中刪除。不同的訊息佇列傳送的確認資訊形式不同,例如rabbitmq是傳送乙個ack確認訊息，roc...
RocketMQ訊息順序傳送和消費問題
事故現場分析 由於創新業務產品上線，運營產品想通過一些活動來刺激使用者，採用註冊邀請機制即可獲取積分的相關活動。考慮到後續可能還有其他可能的活動來發放積分，所以設計的時候，採用mq訊息模式發放積分，非同步解耦，並能夠保證資料的最終一致性。考慮到使用者積分計算的時候可能存在併發操作的情況，想到兩種解決...