位元組跳動面試官這樣問訊息佇列：分散式事務、重複消費、順序消費，我整理了一下

弱校驗：

這個簡單，一些不重要的場景，比如給誰發簡訊啥的，我就把這個id+場景唯一標識作為Redis的key，放到快取裡面失效時間看你場景，一定時間內的這個訊息就去Redis判斷。

用KV就算訊息丟了可能這樣的場景也沒關係，反正丟條無關痛癢的通知簡訊嘛（你敢說你沒驗證碼簡訊丟失的情況？）。

還有很多公司的弱校驗用token啊什麼的，反正花樣很多，但是重要的場景一定要強校驗，真正查問題的時候沒有在磁碟持久化的資料，心裡還是空空的，就像你和女朋友分開的時候的心裡狀態一樣。（我單身的怎麼知道這種感覺？猜的）

你們有接觸過訊息順序消費這樣的場景麼？你怎麼保證的？

沒有！over！

乖，你肯定不能說沒有啊，就是算真的沒有，你看過敖帥丙的文章都要說有！

Tip：但是說實話順序消費這裡很難介紹，我上週到這周問了很多身邊的師兄開發過程中這樣的場景不多，我跟三歪也討論了幾次，網上更多的都是介紹binlog的同步，好像更多的場景就沒了。

一般都是同個業務場景下不同幾個操作的訊息同時過去，本身順序是對的，但是你發出去的時候同時發出去了，消費的時候卻亂掉了，這樣就有問題了。

我之前做電商活動也是有這樣的例子，我們都知道資料量大的時候資料同步壓力還是很大的，有時候資料量大的表需要同步幾個億的資料。（並不是主從同步，主從延遲大的話會有問題，可能是從資料庫或者主資料庫同步到備庫）

這種情況我們都是懟到佇列裡面去，然後慢慢消費的，那問題就來了呀，我們在資料庫同時對一個Id的資料進行了增、改、刪三個操作，但是你訊息發過去消費的時候變成了改，刪、增，這樣資料就不對了。

本來一條資料應該刪掉了，結果在你那卻還在，這不是出大問題！

兩者的結果是不是完全不一樣了 ↑

那你怎麼解決呢？

我簡單的說一下我們使用的RocketMQ裡面的一個簡單實現吧。

Tip：為啥用RocketMQ舉例呢，這玩意是阿里開源的，我問了下身邊的朋友很多公司都有使用，所以讀者大概率是這個的話我就用這個舉例吧，具體的細節我後面會在RocketMQ和Kafka各自章節說到。

生產者消費者一般需要保證順序訊息的話，可能就是一個業務場景下的，比如訂單的建立、支付、發貨、收貨。

那這些東西是不是一個訂單號呢？一個訂單的肯定是一個訂單號的說，那簡單了呀。

一個topic下有多個佇列，為了保證傳送有序，RocketMQ提供了MessageQueueSelector佇列選擇機制，他有三種實現:

我們可使用Hash取模法，讓同一個訂單傳送到同一個佇列中，再使用同步傳送，只有同個訂單的建立訊息傳送成功，再傳送支付訊息。這樣，我們保證了傳送有序。

RocketMQ的topic內的佇列機制,可以保證儲存滿足FIFO（First Input First Output 簡單說就是指先進先出）,剩下的只需要消費者順序消費即可。

RocketMQ僅保證順序傳送，順序消費由消費者業務保證!!!

這裡很好理解，一個訂單你傳送的時候放到一個佇列裡面去，你同一個的訂單號Hash一下是不是還是一樣的結果，那肯定是一個消費者消費，那順序是不是就保證了？

真正的順序消費不同的中介軟體都有自己的不同實現我這裡就舉個例子，大家思路理解下。

Tip：我寫到這點的時候人才群裡也有人問我，一個佇列有序出去，一個消費者消費不就好了，我想說的是消費者是多執行緒的，你訊息是有序的給他的，你能保證他是有序的處理的？還是一個消費成功了再發下一個穩妥。

你能跟我聊一下分散式事務麼？

分散式事務在現在遍地都是分散式部署的系統中幾乎是必要的。

我們先聊一下啥是事務？

分散式事務、事務隔離級別、ACID我相信大家這些東西都耳熟能詳了，那什麼是事務呢？

概念：

一般是指要做的或所做的事情。

在計算機術語中是指訪問並可能更新資料庫中各種資料項的一個程式執行單元(unit)。

事務通常由高階資料庫操縱語言或程式語言（如SQL，C++或Java）書寫的使用者程式使用者程式的執行所引起，並用形如begin transaction和end transaction語句（或函式呼叫）來界定。

事務由事務開始(begin transaction)和事務結束(end transaction)之間執行的全體操作組成。

特性：

事務是恢復和併發控制的基本單位。

事務應該具有4個屬性：原子性、一致性、隔離性、永續性。這四個屬性通常稱為ACID特性。

原子性（atomicity）：一個事務是一個不可分割的工作單位，事務中包括的操作要麼都做，要麼都不做。

一致性（consistency）：事務必須是使資料庫從一個一致性狀態變到另一個一致性狀態。一致性與原子性是密切相關的。

隔離性（isolation）：一個事務的執行不能被其他事務干擾。即一個事務內部的操作及使用的資料對併發的其他事務是隔離的，併發執行的各個事務之間不能互相干擾。

永續性（durability）：永續性也稱永久性（permanence），指一個事務一旦提交，它對資料庫中資料的改變就應該是永久性的。接下來的其他操作或故障不應該對其有任何影響。

那有同學還是不理解，敖丙我總結了一下就是：事務就是一系列操作，要麼同時成功，要麼同時失敗。然後會從事務的 ACID 特性（原子性、一致性、隔離性、永續性）展開敘述。

事務就是為了保證一系列操作可以正常執行，它必須同時滿足 ACID 特性。

那什麼是分散式事務呢？

大家可以想一下，你下單流程可能涉及到10多個環節，你下單付錢都成功了，但是你優惠券扣減失敗了，積分新增失敗了，前者公司會被薅羊毛，後者使用者會不開心，但是這些都在不同的服務怎麼保證大家都成功呢？

聰明，分散式事務，你看你都會搶答了！

Tip：真實的應用場景可能比我介紹的場景複雜數倍，我只是為了舉例方便一下大家理解所以用了很簡單的例子。

我接觸和了解到的分散式事務大概分為：

• 2pc（兩段式提交）
• 3pc（三段式提交）
• TCC（Try、Confirm、Cancel）
• 最大努力通知
• XA
• 本地訊息表（ebay研發出的）
• 半訊息/最終一致性（RocketMQ）

這裡我就介紹下最簡單的2pc（兩段式），以及大家以後可能比較常用的半訊息事務也就是最終一致性，目的是讓大家理解下分散式事務裡面訊息中介軟體的作用，別的事務都大同小異，都有很多優點。

當然也都有種種弊端：

例如長時間鎖定資料庫資源，導致系統的響應不快，併發上不去。

網路抖動出現腦裂情況，導致事物參與者，不能很好地執行協調者的指令，導致資料不一致。

單點故障：例如事物協調者，在某一時刻當機，雖然可以通過選舉機制產生新的Leader，但是這過程中，必然出現問題，而TCC，只有強悍的技術團隊，才能支援開發，成本太高。

不多BB了，我們開始介紹這個兩個事物吧。

2pc（兩段式提交） :

2pc（兩段式提交）可以說是分散式事務的最開始的樣子了，像極了媒婆，就是通過訊息中介軟體協調多個系統，在兩個系統操作事務的時候都鎖定資源但是不提交事務，等兩者都準備好了，告訴訊息中介軟體，然後再分別提交事務。

但是我不知道大家看到問題所在沒有？

是的你可能已經發現了，如果A系統事務提交成功了，但是B系統在提交的時候網路波動或者各種原因提交失敗了，其實還是會失敗的。

最終一致性：

整個流程中，我們能保證是：

• 業務主動方本地事務提交失敗，業務被動方不會收到訊息的投遞。

• 只要業務主動方本地事務執行成功，那麼訊息服務一定會投遞訊息給下游的業務被動方，並最終保證業務被動方一定能成功消費該訊息（消費成功或失敗，即最終一定會有一個最終態）。

不過呢技術就是這樣，各種極端的情況我們都需要考慮，也很難有完美的方案，所以才會有這麼多的方案三段式、TCC、最大努力通知等等分散式事務方案，大家只需要知道為啥要做，做了有啥好處，有啥壞處，在實際開發的時候都注意下就好好了，系統都是根據業務場景設計出來的，離開業務的技術沒有意義，離開技術的業務沒有底氣。

還是那句話：沒有最完美的系統，只有最適合的系統。

面試結束

小夥子看不出來啊，還是有點東西的嘛，這幾個點都回答的不錯，明天你能跟我聊一下RocketMQ麼？

敖丙這章花了這麼多時間，不確定他寫不寫的完，心疼他。好想給他點贊啊，訊息回溯也在單獨介紹訊息中介軟體的時候介紹吧，這章篇幅有點長了。

總結

這章其實我寫的時間比之前的秒殺還要久，因為順序訊息這個場景我不知道怎麼講出來大家容易懂一點，最後就參考了網上的，順序訊息的實際應用場景沒別的那麼廣泛，跟3y也聊了好幾次，最後定了這個binlog的場景。

總之就是這期創作源泉有點枯竭，這章是真的難寫，包括分散式事務在實際開發過程中也是很複雜的環節，需要用的時候光是做設計都要很久，反正我的流程圖長得一匹。

我每次都想著寫得通俗易懂一點，這篇即使是這樣我覺得還是不夠通俗易懂，但是訊息的場景就是這樣，還有大家加我也不要一上來就問我很多扣細節的點，自己多點思考我覺得可能幫助比我告訴你答案好很多吧？

絮叨

敖丙我呀，這周有牌面喲，上了CSDN的原力計劃榜單，而且獎金高達50塊！！！

錢不多但是很開心，跟老媽聊到她也覺得我出息了，剛好她生日，以前我們這一家人就是那種不過生日的，不過呀今年我工作了，而且有牌面的我拿了的獎金就很關鍵，偷偷叫表弟悄悄去給她買了蛋糕和禮物?，嘻嘻，開心。?

DISS

這是部落格園的一個網友在我文章下面的評論，說實話不知道大家怎麼看的，我只想說：呵呵！傻*

我不知道這個多年的經驗到底是怎麼樣子的多年的經驗，我本來其實不準備說出來的，因為我發現我群裡很多都是還沒畢業的大學生或者應屆生，那就假設我讀者還有很多這樣的學生，他們都沒社會經驗我怕他們被這樣的人給誤導了。

我記得我在群裡說過：

我可以80%肯定的告訴大家他這個觀點就是扯淡，還有那20%我是認同他的謙虛那個觀點，但是謙虛難道不應該是我們對待事物最基本的態度嘛？

但是面試裝傻這個觀點？還有什麼不會要比你強的人這個觀點？技術人我相信也有面試官也在看我的文章，你們在面試的時候，我想遇到厲害的人巴不得招入麾下，為自己衝鋒陷陣吧。

而且正常面試的時候你是1-3年的經驗，面試你的基本上都是3年以上的，然後依次順推，當然也有很多很厲害的Leader（我前東家Leader95年的，位元組跳動某產品線很強的Leader96的等等）等大家工作了你就會發現有些東西沒有時間積累是學不到的，你要做的只是一步一個腳印踏實走好就好了。

那些人不管年輕與否能坐在那面試你肯定有他的原因，那你有什麼才華，你盡情施展，他沒那個度量包容你的優秀，這樣的公司不去也罷，但是技術人這樣的真的很少，程式設計師是一群很崇拜能力的人。

所以面試你有啥都秀出來，把你的才華盡情的展示出來，風就在那，你只管飛翔。

鳴謝

涉及到分散式事務的環節我參考了前大神同事：魯班（花名）的技術分享，很感謝他的文章給的思路，還有問題的解析！

每次寫我都會在群裡問大家，下次大家都在我的交流群裡面也可以多給我點意見，謝謝了。

看到沒，就很民主。（敖丙你個渣男，呸，自己不會就不寫！）