冪等:
- 落表狀態(tài)
- Redis設(shè)置key,setnx也能,但都不能設(shè)置過期時(shí)間或需要設(shè)置較長時(shí)間
======================== 一致性 =============================
一. MQ消息生產(chǎn)端: 本地業(yè)務(wù)與消息生產(chǎn)者
- 本地業(yè)務(wù)與發(fā)送MQ同一個(gè)事務(wù)(生產(chǎn)者發(fā)送重試(rocketMQ默認(rèn)2次),一般處理方式,杜絕不了會(huì)出現(xiàn)不一致的情況)
目前生產(chǎn)環(huán)境處理方式,兼有業(yè)務(wù)重試機(jī)制 - 事務(wù)消息(rocketMQ)
- 獨(dú)立消息服務(wù)
二. MQ消息生產(chǎn)端與消費(fèi)端:
一般依靠MQ重試機(jī)制,從而保證最終一致性
三. 重試:
四. rocketMQ消息丟失:
首先在如下三個(gè)部分都可能會(huì)出現(xiàn)丟失消息的情況：
Producer端
Broker端
Consumer端
- 生產(chǎn)端: 重試(默認(rèn)2次)
producer.setRetryTimesWhenSendFailed(10);//重試10次
- broker: 通過同步刷盤防止
## 默認(rèn)情況為 ASYNC_FLUSH，修改為同步刷盤：SYNC_FLUSH，實(shí)際場景看業(yè)務(wù)，同步刷盤效率肯定不如異步刷盤高。
flushDiskType = SYNC_FLUSH
Consumer端: 完全消費(fèi)正常后在進(jìn)行手動(dòng)ack確認(rèn)
五. rocketMQ的消息堆積如何處理
下游消費(fèi)系統(tǒng)如果宕機(jī)了，導(dǎo)致幾百萬條消息在消息中間件里積壓，此時(shí)怎么處理?
你們線上是否遇到過消息積壓的生產(chǎn)故障?如果沒遇到過，你考慮一下如何應(yīng)對?
首先要找到是什么原因?qū)е碌南⒍逊e，是Producer太多了，Consumer太少了導(dǎo)致的還是說其他情況, 總之先定位問題。然后看下消息消費(fèi)速度是否正常，正常的話，可以通過上線更多consumer臨時(shí)解決消息堆 積問題
追問：如果Consumer和Queue不對等，上線了多臺(tái)也在短時(shí)間內(nèi)無法消費(fèi)完堆積的消息怎么
辦？
1. 準(zhǔn)備一個(gè)臨時(shí)的topic
2. queue的數(shù)量是堆積的幾倍
3. queue分布到多Broker中
4. 上線一臺(tái)Consumer做消息的搬運(yùn)工，把原來Topic中的消息挪到新的Topic里，不做業(yè)務(wù)邏輯處理，只是
挪過去
5. 上線N臺(tái)Consumer同時(shí)消費(fèi)臨時(shí)Topic中的數(shù)據(jù)
6. 修復(fù)原來的Consumer，繼續(xù)消費(fèi)之前的Topic
追問：堆積時(shí)間過長消息超時(shí)了？
RocketMQ中的消息只會(huì)在commitLog被刪除的時(shí)候才會(huì)消失，不會(huì)超時(shí)。也就是說未被消費(fèi)的消息不會(huì)存在
超時(shí)刪除這情況。
追問：堆積的消息會(huì)不會(huì)進(jìn)死信隊(duì)列？
不會(huì)，消息在消費(fèi)失敗后會(huì)進(jìn)入重試隊(duì)列（%RETRY%+ConsumerGroup），16次（默認(rèn)16次，messageDelayLevel 沒有1,2級別直接從第3級別開始重試,延時(shí)消息級別才是18個(gè)）才會(huì)進(jìn)入死信隊(duì)列
（%DLQ%+ConsumerGroup）。
1）死信消息具有以下特性：
- 不會(huì)再被消費(fèi)者正常消費(fèi)。
- 有效期與正常消息相同，均為 3 天，3 天后會(huì)被自動(dòng)刪除。因此，請?jiān)谒佬畔a(chǎn)生后的 3 天內(nèi)及時(shí)處理。
文獻(xiàn):
https://blog.csdn.net/qingwufeiyang_530/article/details/110563298
