### MQ消息重復消費解決方案 1. 消息中增加版本號標識，消費端只接受比當前消費端版本號高的消息； 示例： |messageId | 業務標識 | 版本號 | |:-|:-|:-| |1xxx | 101 | 1.0 | |2xxx | 101 | 2.0 | |1xxx | 101 | 1.0 | 上面第一條消息被消費端接收處理成功后，消費端更新版本號為1.0，當第二條消息被接收時，因為消息版本號大于消費端當前版本號，處理后更新版本號為2.0，當第三條消息過來時因為當前消費端版本號大于消息本身的版本號，直接丟棄；--該方案能解決重復消費問題； 2. 消息中增加版本號標識，且消費端只接受比當前版本大1的消息； 該方案用于處理對消息順序有要求的場景，示例： 消息1 ==> 1xxx + 101 + 結算消息 + 2.0 消息2 ==> 2xxx + 101 + 扣款消息 + 1.0 如果消息1先到達消費端，消費完成后，消費端版本號變為2.0，那么消息2到達時因為消息版本號比消費端版本號低，直接被丟棄了，那么造成的后果就是，某一筆業務沒有被扣款就把錢結算給供應商了 以上兩種方案都是使用版本號機制來控制消息的重復消費，使用版本號的最大問題是： * 對發送方必須要求消息帶業務版本號。 * 下游必須存儲消息的版本號，對于要嚴格保證順序的。 3. 狀態機 根據業務流程制定業務狀態流轉機制，比如"待支付"狀態的訂單，只能接受"支付成功"或"支付失敗"的消息；實際操作中可以針對不同的業務場景或不同的狀態流轉發送不同topic的消息； 4. 利用日志表記錄消息消費記錄：利用一張日志表來記錄已經處理成功的消息的ID，如果新到的消息ID已經在日志表中，那么就不再處理這條消息(該方案僅能解決重復消費問題)； ### MQ消息不可達 1. 消息生產者在往MQ里面發消息的同時，為保證系統的高可靠，可同步往消息的中間系統寫一條記錄，包括：消息ID|業務ID|TOPIC，那么如果消息沒有及時到達消費端(網絡異常/消息阻塞)，消費端可利用JOB定時查詢自己關心的消息(TOPIC+時間條件)以便及時處理，可作為一種補償機制；中間件可定期刪除過期數據