建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
一、寫(xiě)在前面
之前寫(xiě)過(guò)一篇文章《??RabbitMQ是如何收發(fā)消息的？(通俗易懂)??》，我們用一個(gè)簡(jiǎn)單易懂的電商場(chǎng)景給大家引入說(shuō)明了一個(gè)消息中間件的使用場(chǎng)景。
盈江ssl適用于網(wǎng)站、小程序/APP、API接口等需要進(jìn)行數(shù)據(jù)傳輸應(yīng)用場(chǎng)景，ssl證書(shū)未來(lái)市場(chǎng)廣闊！成為創(chuàng)新互聯(lián)的ssl證書(shū)銷(xiāo)售渠道，可以享受市場(chǎng)價(jià)格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：13518219792（備注：SSL證書(shū)合作）期待與您的合作！
同時(shí)，我們還基于RabbitMQ的HelloWorld級(jí)別的代碼，給出了訂單服務(wù)和倉(cāng)儲(chǔ)服務(wù)如何基于MQ中間件收發(fā)消息的示例。
二、業(yè)務(wù)場(chǎng)景回顧
這篇文章，我們來(lái)稍微深入探討一些MQ中間件使用中的基礎(chǔ)技術(shù)問(wèn)題。
首先回顧一下上篇文章做出來(lái)的一個(gè)架構(gòu)圖，看看訂單服務(wù)和消息服務(wù)是如何基于MQ來(lái)收發(fā)消息的。
我們稍微把這個(gè)圖細(xì)化一點(diǎn)，簡(jiǎn)單來(lái)說(shuō)就是多個(gè)訂單服務(wù)實(shí)例給queue推送消息，多個(gè)倉(cāng)儲(chǔ)服務(wù)每個(gè)消費(fèi)一部分消息。如下圖所示：
三、意外宕機(jī)，問(wèn)題凸現(xiàn)
假如你線上對(duì)MQ技術(shù)的使用就到此為止了，那么基本可以跟offer說(shuō)拜拜了。。。
因?yàn)槿绻俏业脑?，作為一個(gè)面試官就沒(méi)法繼續(xù)往下問(wèn)了。你這個(gè)MQ的使用以及理解的深度僅此而已的話，那基本就是剛剛對(duì)MQ技術(shù)入門(mén)的程度。
如果面試官要繼續(xù)問(wèn)，完全可以問(wèn)下面的問(wèn)題：
那你說(shuō)說(shuō)如果倉(cāng)儲(chǔ)服務(wù)作為消費(fèi)者服務(wù)，剛收到了一個(gè)訂單消息，但是在完成消息的處理之前，也就是還沒(méi)對(duì)訂單完成倉(cāng)儲(chǔ)調(diào)度發(fā)貨，結(jié)果這個(gè)倉(cāng)儲(chǔ)服務(wù)突然就宕機(jī)了，這個(gè)時(shí)候會(huì)發(fā)生什么事情？
所以說(shuō)，大家還是要對(duì)這個(gè)技術(shù)了解得稍微深入一點(diǎn)點(diǎn)，否則隨便被問(wèn)幾個(gè)問(wèn)題就完蛋了。
大伙兒先來(lái)看看下面的圖，感受一下車(chē)禍現(xiàn)場(chǎng)。
RabbitMQ這個(gè)中間件默認(rèn)的一個(gè)行為，就是只要倉(cāng)儲(chǔ)服務(wù)收到一個(gè)訂單消息，RabbitMQ就會(huì)立馬把這條訂單消息給標(biāo)記為刪除，這個(gè)行為叫做自動(dòng)ack，也就是投遞完成一條消息就自動(dòng)確認(rèn)這個(gè)消息處理完畢了。
但是接著如果此時(shí)倉(cāng)儲(chǔ)服務(wù)收到了一個(gè)訂單消息，但是還沒(méi)來(lái)得及對(duì)倉(cāng)庫(kù)系統(tǒng)完成商品的調(diào)度發(fā)貨，結(jié)果直接就宕機(jī)了。
此時(shí)，明顯這個(gè)訂單消息就丟失了啊，因?yàn)镽abbitMQ那里已經(jīng)沒(méi)有了。。。
這會(huì)導(dǎo)致什么樣的尷尬體驗(yàn)?zāi)?？就是一個(gè)用戶(hù)支付了8999元，對(duì)一個(gè)iphone8下了訂單，結(jié)果呢，死等活等了好幾天，就是不見(jiàn)網(wǎng)站上顯示他的iphone8在發(fā)貨。
搞了半天，原因就是他的那個(gè)iphone8的訂單在倉(cāng)儲(chǔ)服務(wù)那里，還沒(méi)來(lái)得及調(diào)度發(fā)貨直接就宕機(jī)了，導(dǎo)致這個(gè)訂單消息就一直丟失了，始終沒(méi)有給這個(gè)用戶(hù)通知倉(cāng)庫(kù)系統(tǒng)進(jìn)行發(fā)貨。
這個(gè)問(wèn)題，是不是很尷尬？所以說(shuō)，技術(shù)問(wèn)題是會(huì)嚴(yán)重影響企業(yè)的核心業(yè)務(wù)流程的！
各位小伙伴，還記得上一講咱們的倉(cāng)儲(chǔ)服務(wù)消費(fèi)消息的代碼中，有一行關(guān)鍵的代碼：
這行代碼對(duì)channel.basicConsume()方法，傳入的第二個(gè)參數(shù)：true，其實(shí)就是一個(gè)關(guān)鍵的參數(shù)。
這個(gè)true就代表了一個(gè)核心的含義，他的意思是，RabbitMQ只要把一個(gè)消息投遞到倉(cāng)儲(chǔ)服務(wù)手上，立馬就標(biāo)記這個(gè)消息刪除了。
但是在這個(gè)默認(rèn)的配置之下，要是倉(cāng)儲(chǔ)服務(wù)收到一個(gè)訂單消息，結(jié)果還沒(méi)來(lái)得及完成耗時(shí)幾十秒的倉(cāng)儲(chǔ)調(diào)度發(fā)貨的業(yè)務(wù)邏輯，結(jié)果突然宕機(jī)了，那么這個(gè)訂單消息就永久性丟失了！
找了半天，原來(lái)問(wèn)題的癥結(jié)在這里啊！大家是不是明白了，上一篇文章最后為什么我會(huì)說(shuō)，這個(gè)代碼目前為止還有很多的問(wèn)題。
所以這個(gè)時(shí)候，我們?nèi)绻Ｍ灰驗(yàn)閭}(cāng)儲(chǔ)服務(wù)的突然宕機(jī)導(dǎo)致一條訂單消息丟失，就需要改造一下倉(cāng)儲(chǔ)服務(wù)消費(fèi)消息的代碼了。
首先，我們需要把那個(gè)參數(shù)從true改為false，如下代碼所示：
只要修改為false之后，RabbitMQ就不會(huì)盲目的投遞消息到倉(cāng)儲(chǔ)服務(wù)，立馬就刪除消息了，說(shuō)白了就是關(guān)閉autoAck的行為，不要自作主張的認(rèn)為消息處理成功了。
接著，我們需要改造一下處理訂單消息的代碼，如下代碼所示。
這段代碼，說(shuō)白了，就是在對(duì)訂單完成了調(diào)度發(fā)貨之后，在finally代碼塊中手動(dòng)執(zhí)行了ack操作，說(shuō)我自己已經(jīng)完成了耗時(shí)幾十秒的業(yè)務(wù)邏輯的處理，現(xiàn)在可以手動(dòng)ack通知RabbitMQ，這個(gè)消息處理完畢了。
此時(shí)整個(gè)架構(gòu)運(yùn)行流程大致看起來(lái)跟下面的圖那樣子。
架構(gòu)流程改成上面那樣后，就意味著只有完成了倉(cāng)儲(chǔ)調(diào)度發(fā)貨的代碼業(yè)務(wù)邏輯，確保倉(cāng)庫(kù)系統(tǒng)收到通知之后，倉(cāng)儲(chǔ)服務(wù)才會(huì)在代碼中手動(dòng)發(fā)送ack消息給RabbitMQ。
此時(shí)，RabbitMQ收到了這個(gè)ack消息，才會(huì)標(biāo)記對(duì)應(yīng)的訂單消息被刪除了。
如果說(shuō)在倉(cāng)儲(chǔ)服務(wù)收到了訂單消息，但是還沒(méi)來(lái)得及完成倉(cāng)儲(chǔ)調(diào)度發(fā)貨的業(yè)務(wù)邏輯，那也就絕對(duì)不會(huì)執(zhí)行這條訂單消息的ack操作，然后RabbitMQ也就不會(huì)收到這條訂單消息的ack通知。
一旦RabbitMQ發(fā)現(xiàn)代表消費(fèi)者的某個(gè)倉(cāng)儲(chǔ)服務(wù)實(shí)例突然宕機(jī)了，而這個(gè)倉(cāng)儲(chǔ)服務(wù)收到的一些訂單消息還沒(méi)來(lái)得及處理，沒(méi)給自己發(fā)送那些消息的ack通知。
此時(shí)，RabbitMQ會(huì)自動(dòng)對(duì)這條訂單消息重發(fā)推送給其他在運(yùn)行中的倉(cāng)儲(chǔ)服務(wù)實(shí)例，讓其他的倉(cāng)儲(chǔ)服務(wù)實(shí)例去處理這條訂單消息。
這樣的話，就可以保證這條訂單消息不會(huì)因?yàn)槟硞€(gè)倉(cāng)儲(chǔ)服務(wù)實(shí)例的宕機(jī)而丟失，他會(huì)確保必須由某個(gè)倉(cāng)儲(chǔ)服務(wù)實(shí)例完成這條訂單消息的調(diào)度發(fā)貨處理，然后才會(huì)刪除那條訂單消息。
四、總結(jié) tips
最后再來(lái)一張圖，大家直觀的感受一下：
好了，各位同學(xué)，這篇文章是不是相對(duì)稍微深入一點(diǎn)點(diǎn)，讓大家了解到了一些使用MQ技術(shù)時(shí)候要考慮的一些問(wèn)題？
實(shí)際上無(wú)論是RocketMQ、Kafka還是RabbitMQ，都有類(lèi)似的autoAck或者是手動(dòng)ack的機(jī)制。
線上生產(chǎn)環(huán)境中運(yùn)行時(shí)，你必須要考慮到消費(fèi)者服務(wù)可能宕機(jī)的問(wèn)題。
如果消費(fèi)者服務(wù)沒(méi)處理完消息就自己宕機(jī)了，那么一定會(huì)導(dǎo)致部分消息的丟失，進(jìn)而影響核心業(yè)務(wù)流程的運(yùn)轉(zhuǎn)。
因此大家在線上使用MQ時(shí)，一定要充分考慮這些潛在問(wèn)題，同時(shí)結(jié)合具體的MQ提供的一些API、參數(shù)來(lái)進(jìn)行合理設(shè)置，確保消息不要隨意丟失。
網(wǎng)站欄目：車(chē)禍現(xiàn)場(chǎng)！線上突然宕機(jī)，一條訂單消息丟失了
當(dāng)前地址：http://www.dlmjj.cn/article/djehjsj.html
