面試官問：消息被重復(fù)消費(fèi)，怎么避免？有什么好的解決方案？

# 簡單的消息去重解決方案

insert into t_order values .....update t_inv set count = count-1 where good_id = 'good123';

select * from t_order where order_no = 'order123'if(order != null) {    return ;//消息重復(fù)，直接返回}

# 并發(fā)重復(fù)消息

select * from t_order where order_no = 'order123'

if(order != null) {    return ;//消息重復(fù)，直接返回}

select * from t_order where order_no = 'THIS_ORDER_NO' for update //開啟事務(wù)if(order.status != null) {    return ;//消息重復(fù)，直接返回}

# Exactly Once

Exactly-Once 是指發(fā)送到消息系統(tǒng)的消息只能被消費(fèi)端處理且僅處理一次，即使生產(chǎn)端重試消息發(fā)送導(dǎo)致某消息重復(fù)投遞，該消息在消費(fèi)端也只被消費(fèi)一次。

# 基于關(guān)系數(shù)據(jù)庫事務(wù)插入消息表

update t_order set status = 'SUCCESS' where order_no= 'order123';

1.開啟事務(wù)
2.插入消息表（處理好主鍵沖突的問題）
3.更新訂單表（原消費(fèi)邏輯）
4.提交事務(wù)

https://help.aliyun.com/document_detail/102777.html

# 更復(fù)雜的業(yè)務(wù)場景

• 檢查庫存（RPC）
• 鎖庫存（RPC）
• 開啟事務(wù)，插入訂單表（MySQL）
• 調(diào)用某些其他下游服務(wù)（RPC）
• 更新訂單狀態(tài)
• commit 事務(wù)（MySQL）

• 庫存系統(tǒng)消費(fèi)A：檢查庫存并做鎖庫存，發(fā)送消息B給訂單服務(wù)
• 訂單系統(tǒng)消費(fèi)消息B：插入訂單表（MySQL），發(fā)送消息C給自己（下游系統(tǒng)）消費(fèi)
• 下游系統(tǒng)消費(fèi)消息C：處理部分邏輯，發(fā)送消息D給訂單系統(tǒng)
• 訂單系統(tǒng)消費(fèi)消息D：更新訂單狀態(tài)

# 更通用的解決方案

• 問題一：消息已經(jīng)消費(fèi)成功了，第二條消息將被直接冪等處理掉（消費(fèi)成功）。
• 問題二：并發(fā)場景下的消息，依舊能滿足不會出現(xiàn)消息重復(fù)，即穿透冪等擋板的問題。
• 問題三：支持上游業(yè)務(wù)生產(chǎn)者重發(fā)的業(yè)務(wù)重復(fù)的消息冪等問題。

在并發(fā)場景下我們依賴于消息狀態(tài)是做并發(fā)控制使得第 2 條消息重復(fù)的消息會不斷延遲消費(fèi)，即重試。

• 1.性能上損耗更低
• 2.上面我們講到的超時時間可以直接利用Redis本身的ttl實(shí)現(xiàn)

# show me code

https://github.com/Jaskey/RocketMQDedupListener ，

//利用Redis做冪等表DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("TEST-APP1");consumer.subscribe("TEST-TOPIC", "*");
String appName = consumer.getConsumerGroup();// 大部分情況下可直接使用consumer group名StringRedisTemplate stringRedisTemplate = null;// 這里省略獲取StringRedisTemplate的過程DedupConfig dedupConfig = DedupConfig.enableDedupConsumeConfig(appName, stringRedisTemplate);DedupConcurrentListener messageListener = new SampleListener(dedupConfig);
consumer.registerMessageListener(messageListener);consumer.start();

# 這種實(shí)現(xiàn)是否一勞永逸？

• 步驟1：檢查庫存（RPC）
• 步驟2：鎖庫存（RPC）
• 步驟3：開啟事務(wù)，插入訂單表（MySQL）
• 步驟4：調(diào)用某些其他下游服務(wù)（RPC）
• 步驟5：更新訂單狀態(tài)
• 步驟6：commit 事務(wù)（MySQL）

# 本實(shí)現(xiàn)方式的價值？

• 1.各種由于Broker、負(fù)載均衡等原因?qū)е碌南⒅赝哆f的重復(fù)問題
• 2.各種上游生產(chǎn)者導(dǎo)致的業(yè)務(wù)級別消息重復(fù)問題
• 3.重復(fù)消息并發(fā)消費(fèi)的控制窗口問題，就算重復(fù)，重復(fù)也不可能同一時間進(jìn)入消費(fèi)邏輯
  
  

# 一些其他的消息去重的建議

• #1.消息消費(fèi)失敗做好回滾處理。如果消息消費(fèi)失敗本身是帶回滾機(jī)制的，那么消息重試自然就沒有副作用了。
• #2.消費(fèi)者做好優(yōu)雅退出處理。這是為了盡可能避免消息消費(fèi)到一半程序退出導(dǎo)致的消息重試。
• #3.一些無法做到冪等的操作，至少要做到終止消費(fèi)并告警。例如鎖庫存的操作，如果統(tǒng)一的業(yè)務(wù)流水鎖成功了一次庫存，再觸發(fā)鎖庫存，如果做不到冪等的處理，至少要做到消息消費(fèi)觸發(fā)異常（例如主鍵沖突導(dǎo)致消費(fèi)異常等）