|
作為一名java程序員,，面試時(shí)時(shí)常會(huì)遇到類似這樣的問題：
…… 這就可能涉及到消息消費(fèi)問題,，關(guān)于消息消費(fèi)問題,，這個(gè)是消息隊(duì)列的基本問題，面試官之所以問這樣的問題我想本質(zhì)上還是考驗(yàn)求職者對(duì)使用消息隊(duì)列如何保證冪等性,。 關(guān)于重復(fù)消費(fèi)的問題,，首先我們需要知道是有哪些場(chǎng)景會(huì)出現(xiàn)： 類似 RabbitMQ、kafka這樣優(yōu)秀的消息隊(duì)列中間件都有可能會(huì)出現(xiàn)消息重復(fù)消費(fèi)的問題,，這并不是框架的問題,，而是框架本身就沒有考慮限制消息重復(fù)消費(fèi)問題，把這個(gè)操作交給開發(fā)者自己來處理了,。 下面以 kafka為例簡(jiǎn)單闡述下消息重復(fù)消費(fèi)問題,。 我們知道，kafka 有個(gè)offset 的概念,，既每當(dāng)有消息寫進(jìn)去時(shí),，每個(gè)消息都會(huì)有一個(gè)對(duì)應(yīng)的offset，代表消息的序號(hào),，然后 consumer 消費(fèi)了數(shù)據(jù)后,，每隔一段時(shí)間，定期會(huì)把自己消費(fèi)過的消息的 offset 提交,，表示“這些我已經(jīng)消費(fèi)過了,，下次我就從上次消費(fèi)到的 offset 地方開始消費(fèi)”。 聽上去很美好，但現(xiàn)實(shí)很骨感,，實(shí)際場(chǎng)景中往往會(huì)有一些出乎意外的事情出現(xiàn),。 譬如有時(shí)候需要重啟系統(tǒng)，正常重啟還好,，要是直接 kill 掉進(jìn)程重啟,，這就難受了。 因?yàn)檫@會(huì)導(dǎo)致 consumer 有的消息雖然處理了,，但是沒來得及執(zhí)行提交 offset動(dòng)作,，而重啟后少數(shù)消息就會(huì)被再次消費(fèi)。 例如數(shù)據(jù) A/B/C 依次進(jìn)入 kafka,，kafka 會(huì)給這三條數(shù)據(jù)每條分配一個(gè) offset,，代表這條數(shù)據(jù)的序號(hào)，假設(shè)分配到的 offset 依次為 101/102/103,。 消費(fèi)者從 kafka 去消費(fèi)的時(shí)候,，也是按照這個(gè)順序去消費(fèi)。 假如當(dāng)消費(fèi)者消費(fèi)了 offset=102 的這條數(shù)據(jù),，剛準(zhǔn)備要去執(zhí)行提交 offset 到 zookeeper,，此時(shí)消費(fèi)者進(jìn)程被重啟了。 那么此時(shí)消費(fèi)過的數(shù)據(jù) A/B 的 offset 實(shí)際上并沒有提交,，kafka 也就不知道之前已經(jīng)消費(fèi)到了 offset=102 這條數(shù)據(jù),。 重啟后，consumer 會(huì)對(duì) kafka 老哥說,，老哥，你接著把上次消費(fèi)到的那個(gè)地方后面的數(shù)據(jù)繼續(xù)給我,。 那么問題來,，由于之前的 offset 并沒有提交成功，此時(shí)數(shù)據(jù) A/B 會(huì)再次傳過來,，要是消費(fèi)者沒有做去重操作的話,，就會(huì)導(dǎo)致重復(fù)消費(fèi)了。 要是消費(fèi)者是做這樣的操作： 消費(fèi)一條消息就往數(shù)據(jù)庫(kù)里插入一條數(shù)據(jù)的話,，這時(shí)可能就把數(shù)據(jù) A/B 在數(shù)據(jù)庫(kù)里插入了兩次了,，于是就產(chǎn)生了臟數(shù)據(jù)了。 其實(shí)重復(fù)消費(fèi)不可怕,，可怕的是忽略了重復(fù)消費(fèi)后,，該如何保證冪等性？ 譬如有這樣一個(gè)業(yè)務(wù)需求,，需要消費(fèi)一條消息就往數(shù)據(jù)庫(kù)里插入一條記錄,，要是有一條消息被重復(fù)消費(fèi)兩次，那么是不是就插入兩條記錄了？ 我想是不是可以先這樣,，當(dāng)消息消費(fèi)到第二次的時(shí)候,，我們先判斷是否之前是否消費(fèi)過了，要是消費(fèi)過了就直接不要了,，這樣就可以保證只有一條數(shù)據(jù),，從而保證了數(shù)據(jù)的正確性。 一條數(shù)據(jù)重復(fù)消費(fèi)兩次,，而數(shù)據(jù)庫(kù)里就只有一條數(shù)據(jù),，這不就保證了系統(tǒng)的冪等性。 什么叫冪等性,？ 冪等（idempotent）是一個(gè)數(shù)學(xué)與計(jì)算機(jī)學(xué)概念,，常見于抽象代數(shù)中。在編程中,，一個(gè)冪等操作的特點(diǎn)是其任意多次執(zhí)行所產(chǎn)生的影響均與一次執(zhí)行的影響相同,。冪等函數(shù)，或冪等方法,，是指可以使用相同參數(shù)重復(fù)執(zhí)行,，并能獲得相同結(jié)果的函數(shù)。 通俗點(diǎn)說,，就是你已經(jīng)有女朋友了,，最近不知怎么啦，走桃花運(yùn)了,，有很多美女為你投懷送抱,， 這種情況下你都不會(huì)動(dòng)心，而不是來者不拒,，多多益善,。 貌似有點(diǎn)扯遠(yuǎn)了，回歸正題,。 關(guān)于冪等性,，我的理解是，就是有一條數(shù)據(jù)或者一個(gè)請(qǐng)求,，重復(fù)發(fā)起多次請(qǐng)求,，我們要確保對(duì)應(yīng)的數(shù)據(jù)不會(huì)受影響。 那么問題來了,，如何保證美女為你投懷送抱,， 都不會(huì)動(dòng)心呢？這個(gè)問題難不難,，把機(jī)會(huì)留給男同胞們,。 我們還是來探討如何保證消息隊(duì)列消費(fèi)的冪等性,？ 這個(gè)需要結(jié)合具體業(yè)務(wù)來思考： 比如你消費(fèi)后就直接執(zhí)行入庫(kù)操作，那么我們可以先根據(jù)主鍵去查詢,，要是該數(shù)據(jù)已經(jīng)有了就不要執(zhí)行插入動(dòng)作,，轉(zhuǎn)向更新動(dòng)作。 比如用 redis,，那問題不大,，因?yàn)槊看味际?set，屬于天然冪等性,。 或許有的業(yè)務(wù)場(chǎng)景較復(fù)雜些,，上面兩個(gè)場(chǎng)景都不是，可能需要讓生產(chǎn)者發(fā)送每條數(shù)據(jù)的時(shí)候,，里面加一個(gè)全局唯一的 id,，類似訂單 orderId 之類，然后你這里消費(fèi)到了,，下一次再重復(fù)消費(fèi)了,，先根據(jù)這個(gè) orderId 去比如 redis 里查，如果沒有消費(fèi)過,，就處理,，要是處理過了，就不要重復(fù)操作,。 關(guān)于消息消費(fèi),，作為一名開發(fā)者，我們不僅要考慮消費(fèi)完整性,，還需要考慮消息被重復(fù)消費(fèi)問題,。 譬如如何避免重復(fù)消費(fèi)？或者說即使重復(fù)消費(fèi)了也要保障數(shù)據(jù)正確性,？ 上面僅僅是個(gè)人看法,，在項(xiàng)目實(shí)際運(yùn)作過程中，如何保證消息隊(duì)列的消費(fèi)是冪等性的,，還得需要結(jié)合具體的業(yè)務(wù)具體分析。 由于筆者水平有限,，文中紕漏之處在所難免,，權(quán)當(dāng)拋磚引玉，不妥之處,，請(qǐng)大家批評(píng)指正,。 |
|
|
