|
在業(yè)務(wù)系統(tǒng)的開發(fā)當(dāng)中，為了保障系統(tǒng)的高性能、高可用，基本都會使用分布式架構(gòu)，采用消息隊列將生產(chǎn)者（響應(yīng)調(diào)用的服務(wù)）與消費者（發(fā)起調(diào)用的服務(wù)）進(jìn)行解耦，讓生產(chǎn)者服務(wù)和消費者服務(wù)可以并行處理更多的程序調(diào)用、用戶請求。當(dāng)消息隊列遇上分布式，就變成了分布式消息隊列，也就是說請求在消費隊列發(fā)給了多個服務(wù)器節(jié)點，所有服務(wù)器節(jié)點的消息隊列之和就是請求數(shù)。在分布式中最高頻的問題便是數(shù)據(jù)一致性問題，多個服務(wù)器節(jié)點因為時間空間的不一致從而接收到的數(shù)據(jù)、傳出去的數(shù)據(jù)都不一樣，在消息隊列中最高頻的問題便是生產(chǎn)消費不一致，從而導(dǎo)致數(shù)據(jù)丟失等。當(dāng)分布式遇上消息隊列，我們一起來看看存在哪些坑，又如何避免這些坑？
一、數(shù)據(jù)重復(fù)消費之坑
在Kafka消息隊列的設(shè)計中，系統(tǒng)通過偏移量offset來標(biāo)記消息的順序。生產(chǎn)者服務(wù)將消息寫進(jìn)隊列，消費者從隊列里拿消息進(jìn)行消費，消費成功后將偏移量提交，下次再消費時就從最新的偏移量開始消費數(shù)據(jù)。在分布式消息隊列中，有可能會出現(xiàn)這樣的情況，生產(chǎn)者往隊列中寫進(jìn)去了2條數(shù)據(jù)，比如數(shù)據(jù)1偏移量為1，數(shù)據(jù)2偏移量為2，消費者從隊列里先消費了偏移量1，偏移量1提交成功，正要去消費數(shù)據(jù)2時，出現(xiàn)了斷電或進(jìn)程中斷等問題導(dǎo)致系統(tǒng)重啟后，再去消費了數(shù)據(jù)2，這樣就導(dǎo)致數(shù)據(jù)被重復(fù)消費了。我們可通過一個簡單的例子來看看：
雙十一大促的時候，iPhone12在淘寶售賣，Alice提交了訂單1進(jìn)行支付購買，Bob也提交了訂單2進(jìn)行支付購買，并且他們都購買成功了，訂單系統(tǒng)會把所有成功的訂單信息都放在消息隊列，用以購買成功后系統(tǒng)會給用戶推送消息，推送消息的服務(wù)從隊列里拿消息進(jìn)行消費，它先拿了消息1，給Alice推送了成功購買的信息，并且標(biāo)記已成功處理消息，正當(dāng)它繼續(xù)去拿消息2推送時，已經(jīng)推送成功了，但是在標(biāo)記推送成功時斷電了，等系統(tǒng)重啟后，消息推送系統(tǒng)又再次從消息2開始處理，重新推送消息。對于Bob來說，他就收到了兩條重復(fù)消息，如果系統(tǒng)程序老出問題，他就會一直收到重復(fù)消息，這樣的用戶體驗非常不好。
避坑指南來了，那就是通過程序算法解決。當(dāng)用戶下訂單支付成功后，訂單的狀態(tài)會由開始變?yōu)橹Ц冻晒虼渌停⑼扑拖到y(tǒng)再進(jìn)行消息推送時從消息隊列和訂單系統(tǒng)中同時獲取信息，double check二者是否一致，再進(jìn)行消息的推送，從而避免了數(shù)據(jù)的重復(fù)消費問題。
二、消息丟失之坑
我們知道完整的消息隊列系統(tǒng)是由三部分組成的，生產(chǎn)者、消息隊列、消費者。在生產(chǎn)者生產(chǎn)消息給到消費隊列、消息隊列存放消息、消費者消費消息這三個過程中，如果哪個過程出了問題，都會導(dǎo)致消息丟失。如果是在購買成功發(fā)送推送消息的場景，那么消息丟失都還好，不會產(chǎn)生什么損失。但如果是在下訂單的場景、減庫存的場景，消息丟失那就嚴(yán)重了。在下訂單場景中，多個用戶在平臺購買商品，創(chuàng)建了訂單，但是因為訂單消息丟失了，支付系統(tǒng)尚未獲取到訂單從而沒有去發(fā)起支付程序，新冠肺炎疫苗也救不了你了。在減庫存場景中，多個用戶參加秒殺活動，成功發(fā)起了創(chuàng)建訂單請求，這時候庫存系統(tǒng)進(jìn)行庫存的減少，然而訂單系統(tǒng)尚未收到，不斷的創(chuàng)建訂單，最后系統(tǒng)庫存都沒有了，前方還在不斷的創(chuàng)建訂單，iPhone12本來只有10個參加秒殺，現(xiàn)在變?yōu)?000個，剩下的990個，都需要商家全額購買給到消費者，不好意思，新冠肺炎疫苗也救不了你。
避坑指南來了，針對生產(chǎn)者存放消息進(jìn)隊列丟失的問題，可以采用確認(rèn)機(jī)制，生產(chǎn)者生產(chǎn)的消息都帶上唯一ID，寫入消息隊列后，消息隊列返回一個ack確認(rèn)消息，標(biāo)明成功接收，如果沒有接收到消息，則在超時時間范圍內(nèi)返回nack消息，標(biāo)明消息未接收成功。針對消息隊列丟消息的問題，可以采用持久化方案，將消息隊列的消息放入在磁盤中，并且將創(chuàng)建的隊列持久化；針對消費者丟消息的問題，可以采用確認(rèn)機(jī)制，消費者處理完消息之后，主動返回ack消息告訴隊列，已處理完畢，超過時間范圍后則重新處理。
三、消息亂序之坑
消息亂序是指生產(chǎn)者生產(chǎn)的消息順序和消費者消費的消息順序不一樣。在雙十一大促時，Alice本來沒有什么要買的，但是看到大家都在買啊，那也就參加隨便買一點，就當(dāng)是過節(jié)了，看到iPhone12價格4999還不錯，就下單買了一個，吃了個飯回來后發(fā)現(xiàn)自己好像沒有什么需求，于是又把訂單取消了。這時候訂單系統(tǒng)有兩條消息，第一條訂單成功創(chuàng)建，第二條訂單取消。當(dāng)消息隊列系統(tǒng)中有多個消費者時，消費者1拿到了第一條消息，去發(fā)貨了，消費者2拿到了第二條消息，取消了訂單。對于Alice來說，他覺得既驚訝又開心，不花一分錢就擁有了iPhone12，但對于商家來說，總收入和總庫存對不上，產(chǎn)生了損失，很難受。
避坑指南來了，那就是通過程序算法解決，第一針對同一個ID發(fā)起的消息，放入同一個隊列，第二創(chuàng)建多個消費者，每個消費者只消費一個隊列。
四、消息積壓之坑
消息積壓是指 消息隊列的數(shù)據(jù)沒有被及時處理，場景1是消費者出現(xiàn)了問題不能來消費，從而導(dǎo)致消息全在隊列里，場景2是消費者消費速度太慢生產(chǎn)者生產(chǎn)太快，從而導(dǎo)致消息全在隊列里。典型的業(yè)務(wù)場景就是，雙十一大促時，用戶發(fā)起了大量的訂單清單，但是庫存系統(tǒng)和支付系統(tǒng)都出現(xiàn)了問題，導(dǎo)致訂單不能被處理，從而損失多筆訂單。
避坑指南是創(chuàng)建更多的隊列、更多的消費者、加快消費者消費速度。
微服務(wù)是好東西，分布式也是好東西，消息隊列也是好東西，三者結(jié)合產(chǎn)生了更大的洪荒之力。但正如一枚硬幣有正也有反，它們帶來了更好的技術(shù)解決方案同時也帶來很多問題，新技術(shù)的問題破解還有待攻克，掃碼下方二維碼，領(lǐng)取免費試聽課，更多新技術(shù)等你探索。
 |
