在業(yè)務系統(tǒng)的開發(fā)當中，為了保障系統(tǒng)的高性能、高可用，基本都會使用分布式架構，采用消息隊列將生產者（響應調用的服務）與消費者（發(fā)起調用的服務）進行解耦，讓生產者服務和消費者服務可以并行處理更多的程序調用、用戶請求。當消息隊列遇上分布式，就變成了分布式消息隊列，也就是說請求在消費隊列發(fā)給了多個服務器節(jié)點，所有服務器節(jié)點的消息隊列之和就是請求數。在分布式中最高頻的問題便是數據一致性問題，多個服務器節(jié)點因為時間空間的不一致從而接收到的數據、傳出去的數據都不一樣，在消息隊列中最高頻的問題便是生產消費不一致，從而導致數據丟失等。當分布式遇上消息隊列，我們一起來看看存在哪些坑，又如何避免這些坑？

01數據重復消費之坑

在Kafka消息隊列的設計中，系統(tǒng)通過偏移量offset來標記消息的順序。生產者服務將消息寫進隊列，消費者從隊列里拿消息進行消費，消費成功后將偏移量提交，下次再消費時就從最新的偏移量開始消費數據。在分布式消息隊列中，有可能會出現這樣的情況，生產者往隊列中寫進去了2條數據，比如數據1偏移量為1，數據2偏移量為2，消費者從隊列里先消費了偏移量1，偏移量1提交成功，正要去消費數據2時，出現了斷電或進程中斷等問題導致系統(tǒng)重啟后，再去消費了數據2，這樣就導致數據被重復消費了。我們可通過一個簡單的例子來看看：

雙十一大促的時候，iPhone12在淘寶售賣，Alice提交了訂單1進行支付購買，Bob也提交了訂單2進行支付購買，并且他們都購買成功了，訂單系統(tǒng)會把所有成功的訂單信息都放在消息隊列，用以購買成功后系統(tǒng)會給用戶推送消息，推送消息的服務從隊列里拿消息進行消費，它先拿了消息1，給Alice推送了成功購買的信息，并且標記已成功處理消息，正當它繼續(xù)去拿消息2推送時，已經推送成功了，但是在標記推送成功時斷電了，等系統(tǒng)重啟后，消息推送系統(tǒng)又再次從消息2開始處理，重新推送消息。對于Bob來說，他就收到了兩條重復消息，如果系統(tǒng)程序老出問題，他就會一直收到重復消息，這樣的用戶體驗非常不好。

避坑指南來了，那就是通過程序算法解決。當用戶下訂單支付成功后，訂單的狀態(tài)會由開始變?yōu)橹Ц冻晒虼渌?，消息推送系統(tǒng)再進行消息推送時從消息隊列和訂單系統(tǒng)中同時獲取信息，doublecheck二者是否一致，再進行消息的推送，從而避免了數據的重復消費問題。

02消息丟失之坑

我們知道完整的消息隊列系統(tǒng)是由三部分組成的，生產者、消息隊列、消費者。在生產者生產消息給到消費隊列、消息隊列存放消息、消費者消費消息這三個過程中，如果哪個過程出了問題，都會導致消息丟失。如果是在購買成功發(fā)送推送消息的場景，那么消息丟失都還好，不會產生什么損失。但如果是在下訂單的場景、減庫存的場景，消息丟失那就嚴重了。在下訂單場景中，多個用戶在平臺購買商品，創(chuàng)建了訂單，但是因為訂單消息丟失了，支付系統(tǒng)尚未獲取到訂單從而沒有去發(fā)起支付程序，新冠肺炎疫苗也救不了你了。在減庫存場景中，多個用戶參加秒殺活動，成功發(fā)起了創(chuàng)建訂單請求，這時候庫存系統(tǒng)進行庫存的減少，然而訂單系統(tǒng)尚未收到，不斷的創(chuàng)建訂單，最后系統(tǒng)庫存都沒有了，前方還在不斷的創(chuàng)建訂單，iPhone12本來只有10個參加秒殺，現在變?yōu)?000個，剩下的990個，都需要商家全額購買給到消費者，不好意思，新冠肺炎疫苗也救不了你。

避坑指南來了，針對生產者存放消息進隊列丟失的問題，可以采用確認機制，生產者生產的消息都帶上唯一ID，寫入消息隊列后，消息隊列返回一個ack確認消息，標明成功接收，如果沒有接收到消息，則在超時時間范圍內返回nack消息，標明消息未接收成功。針對消息隊列丟消息的問題，可以采用持久化方案，將消息隊列的消息放入在磁盤中，并且將創(chuàng)建的隊列持久化；針對消費者丟消息的問題，可以采用確認機制，消費者處理完消息之后，主動返回ack消息告訴隊列，已處理完畢，超過時間范圍后則重新處理。

03消息亂序之坑

消息亂序是指生產者生產的消息順序和消費者消費的消息順序不一樣。在雙十一大促時，Alice本來沒有什么要買的，但是看到大家都在買啊，那也就參加隨便買一點，就當是過節(jié)了，看到iPhone12價格4999還不錯，就下單買了一個，吃了個飯回來后發(fā)現自己好像沒有什么需求，于是又把訂單取消了。這時候訂單系統(tǒng)有兩條消息，第一條訂單成功創(chuàng)建，第二條訂單取消。當消息隊列系統(tǒng)中有多個消費者時，消費者1拿到了第一條消息，去發(fā)貨了，消費者2拿到了第二條消息，取消了訂單。對于Alice來說，他覺得既驚訝又開心，不花一分錢就擁有了iPhone12，但對于商家來說，總收入和總庫存對不上，產生了損失，很難受。

避坑指南來了，那就是通過程序算法解決，第一針對同一個ID發(fā)起的消息，放入同一個隊列，第二創(chuàng)建多個消費者，每個消費者只消費一個隊列。

04消息積壓之坑

消息積壓是指消息隊列的數據沒有被及時處理，場景1是消費者出現了問題不能來消費，從而導致消息全在隊列里，場景2是消費者消費速度太慢生產者生產太快，從而導致消息全在隊列里。典型的業(yè)務場景就是，雙十一大促時，用戶發(fā)起了大量的訂單清單，但是庫存系統(tǒng)和支付系統(tǒng)都出現了問題，導致訂單不能被處理，從而損失多筆訂單。

避坑指南是創(chuàng)建更多的隊列、更多的消費者、加快消費者消費速度。

微服務是好東西，分布式也是好東西，消息隊列也是好東西，三者結合產生了更大的洪荒之力。但正如一枚硬幣有正也有反，它們帶來了更好的技術解決方案同時也帶來很多問題，新技術的問題破解還有待攻克