引言

我在《項(xiàng)目中為什么要使用消息隊(duì)列》中列舉了兩個使用消息隊(duì)列的例子。

（1）收銀系統(tǒng)，確認(rèn)收款成功，通過MQ通知給物流系統(tǒng)發(fā)貨。

（2）消費(fèi)積分，用戶每消費(fèi)一筆給用戶增加一定積分，京東豆，信用卡積分，2020年如果還沒倒閉的電商平臺中，可以100%的確定訂單系統(tǒng)和積分/獎勵系統(tǒng)不是耦合在一起的。

這些都是很典型的使用消息隊(duì)列的場景。

那么問題來了，想象一下，積分系統(tǒng)收到同一個用戶同一個訂單兩條相同的消息會怎樣？積分會被加兩遍嗎？針對這個問題，面試官又開始一輪三連問，你還能扛得過去嗎？

這不是“面試造火箭，工作擰螺絲”，消息重復(fù)，消息積壓這類問題是你入職后工作中真真切切會遇到的，不是面試官故意刁難你。

1、面試官：

那你有考慮過消息重復(fù)問題怎么解決嗎？

問題分析：還是拿上面的例子分析，積分系統(tǒng)收到同一個用戶同一個訂單兩條相同的消息會怎樣，先不管因?yàn)槭裁丛蛳l(fā)了兩次，積分會被加兩遍嗎？

產(chǎn)品經(jīng)理說： 那肯定不行呀，花100塊給100個積分，積分沒有買一送一服務(wù)。

訂單系統(tǒng)RD說： 我這邊沒辦法100%保證積分廣播只發(fā)一次，萬一出個bug同一筆消費(fèi)積分，消息可能發(fā)了幾百次也不好說。

答：產(chǎn)品說不行，訂單RD說他不保證消息不重復(fù)，Kafka架構(gòu)RD也說無法保證消息不重復(fù)，那怎么辦？我是負(fù)責(zé)積分系統(tǒng)的，針對消息重復(fù)問題，我會針對積分累計接口做**“冪等”**設(shè)計，這個問題，首先我們應(yīng)該從上游就做消息去重處理，但是我們不能100%相信上游系統(tǒng)一定可靠，我是消息消費(fèi)端，只有我這邊做了冪等設(shè)計才能完全避免這種和錢相關(guān)的bug，畢竟如果依賴上游，真的出了用戶消費(fèi)100元最后加了100w積分，這鍋重要還是我們背。

我可以根據(jù)用戶訂單號或者流水號做強(qiáng)冪等，每成功操作一次加積分就記錄下來，即使消息重負(fù)了，我只要判斷同一個訂單號已經(jīng)操作加分了，后續(xù)我們就不會再做任何操作了。

隨手寫了一段偽代碼給面試官：

//沒收到給用戶消費(fèi)通知,先判斷這個orderId時候已經(jīng)有加過積分的歷史記錄，如果沒有操作過，則增加。如果已經(jīng)操作過，直接返回不做任何處理。
List<UserPointHistory> lists = userPointDao.queryHistory(orderId);
if(CollectionUtils.isNotEmpty(lists)){
    //1.加100分。
    userPoint.add(pointCount,orderId);
    //2.保存增加記錄
      userPoint.addHistory(orderId);
}else{
    log.info("該訂單已經(jīng)操作過積分操作")
    return null;
}

Tip：如果冪等還不明白可以看我寫的《談?wù)勗趺蠢斫饨涌趦绲仍O(shè)計，項(xiàng)目中如何保證接口冪等》，上面的代碼加積分和保存增加記錄要保證事務(wù)性，如果你不知道ACID千萬別給自己挖坑，被面試官逮住ACID一頓問。

面試官：這個問題相對不難，有解決思路問題就不大了。

2、面試官：

在多集群消息架構(gòu)中，如果消費(fèi)端要求接收到的消息是有序的，怎么解決消息順序消費(fèi)問題？

問題分析：這個問題什么意思呢，比如一個消息Producer發(fā)送順序是1 2 3，那Consumer接收到的消息也是 1 2 3 ，這就比較為難工程師了，但是還是有辦法的，想要實(shí)現(xiàn)消息有序就要犧牲點(diǎn)什么東西 ---- 性能/可靠性。

答：這個問題從三個角度考慮：

Producer：讓生產(chǎn)端同步發(fā)送消息，消息1確定發(fā)送成功后再發(fā)送消息2，不能異步，保證消息順序入隊(duì)。

服務(wù)端：Producer -> MQ Server -> Consumer 一對一關(guān)系，一對一服務(wù)，這肯定能保證消息是按照順序消費(fèi)的，那么問題來了：

• Producer -> MQ Server -> Consumer任意一個環(huán)節(jié)出現(xiàn)問題，那肯定整個鏈路都阻塞了。
• 單通道模型性能成為瓶頸。

topic不分區(qū)：意思就是讓同一個topic主題都入一個隊(duì)列，在分布式環(huán)境下如果同一個topic進(jìn)入多個分區(qū)，那多個分區(qū)之間肯定無法保證消息順序了。

Consumer：保證消費(fèi)端是串行消費(fèi)，禁止使用多線程。

但是這些方法都會犧牲掉系統(tǒng)的性能和穩(wěn)定性，順序性問題非要使用MQ來做，那也沒有太好的辦法了。

3、面試官：

那如何做到topic不分區(qū)，能舉例說明一下嗎？

問題分析：說真的，工作中要求消息順序消費(fèi)的業(yè)務(wù)場景真的挺少見的，用到的時候少，你可以不用深入研究這一塊，知道方法就行，到時候真的遇到了知道從哪個方向下手。

答：用當(dāng)前比較流行的RocketMQ和Kafka舉例。

RocketMQ：RocketMQ提供了MessageQueueSelector隊(duì)列選擇機(jī)制，我們可以把 Topic 用Hash取模法，相同Topic的Hash值肯定是一樣的，讓同一個 Topic 同一個隊(duì)列中，再使用同步發(fā)送，這樣就能保證消息在一個分區(qū)有序了。

Kafka： Kafka可以把 max.in.flight.requests.per.connection 參數(shù)設(shè)置成1，這樣就可以保證同一個topic在同一個分區(qū)內(nèi)了。

Tip：Topic就是一個字符串，給同一類消息取個名字加以區(qū)分，如：topic.com.xxx.order.orderId，大多數(shù)用戶都可以通過message key來定義，因?yàn)橥粋€key的message可以保證只發(fā)送到同一個partition，比如說key是user id，table row id等等。

總結(jié)

關(guān)于消息重復(fù)和消息順序消費(fèi)問題解決思路比較簡單，都是一些小技巧，雖然內(nèi)容比較枯燥，但是我已經(jīng)盡力說得通俗易懂。

如果用兩句話概括這一接的內(nèi)容：

如何保證消息重復(fù)問題：消費(fèi)端接口冪等。如何保證消息順序消費(fèi)問題：讓同一個消息不分區(qū)，且單線程。

當(dāng)然面試的時候你可別這么干巴巴兩句話，那顯得你太沒水平了，面試最理想的效果就是無論多簡單的問題你都能滔滔不絕，讓面試官無話可說。

以上就是分布式面試消息隊(duì)列解決消息重復(fù)保證消息順序的詳細(xì)內(nèi)容，更多關(guān)于消息隊(duì)列解決消息重復(fù)保證消息順序的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論