你知道的越多担扑，你不知道的越多

點贊再看，養(yǎng)成習(xí)慣

GitHub上已經(jīng)開源 https://github.com/JavaFamily 有一線大廠面試點腦圖趣钱、個人聯(lián)系方式和人才交流群涌献，歡迎Star和完善

在項目開發(fā)過程中，企業(yè)會有很多的任務(wù)首有、需求洁奈、缺陷等需要進行管理，CORNERSTONE 提供敏捷绞灼、任務(wù)利术、需求、缺陷低矮、測試管理寒瓦、WIKI、共享文件和日歷等功能模塊惶楼，幫助企業(yè)完成團隊協(xié)作和敏捷開發(fā)中的項目管理需求怎茫；更有甘特圖、看板蝗锥、思維導(dǎo)圖跃洛、燃盡圖等多維度視圖，幫助企業(yè)全面把控項目情況终议。

前言

消息隊列在互聯(lián)網(wǎng)技術(shù)存儲方面使用如此廣泛汇竭，幾乎所有的后端技術(shù)面試官都要在消息隊列的使用和原理方面對小伙伴們進行360°的刁難。

作為一個在互聯(lián)網(wǎng)公司面一次拿一次Offer的面霸穴张，打敗了無數(shù)競爭對手细燎，每次都只能看到無數(shù)落寞的身影失望的離開，略感愧疚（請允許我使用一下夸張的修辭手法）皂甘。

于是在一個寂寞難耐的夜晚玻驻，暖男我痛定思痛，決定開始寫《吊打面試官》系列偿枕，希望能幫助各位讀者以后面試勢如破竹璧瞬，對面試官進行360°的反擊，吊打問你的面試官渐夸，讓一同面試的同僚瞠目結(jié)舌嗤锉，瘋狂收割大廠Offer！

撈一下

上一期捺萌，簡單的介紹了一下消息隊列的基礎(chǔ)知識档冬，里面有消息隊列的應(yīng)用場景膘茎，以及使用之后可能帶來的問題，但是上期沒對怎么解決這些問題做回答酷誓，因為要控制篇幅嘛（明明是自己覺得MQ寫不了多少期披坏，要多懟一期出來！渣男）

咳咳盐数，我們言歸正傳棒拂，沒看的朋友去看一下，有助于這期的閱讀：

《吊打面試官》系列-消息隊列基礎(chǔ)

面試開始

一個風(fēng)度翩翩玫氢，穿著格子襯衣的中年男子帚屉，拿著一個滿是劃痕的mac向你走來，看著錚亮的頭漾峡，心想著肯定是尼瑪頂級架構(gòu)師吧攻旦！但是我們看過暖男敖丙的系列，腹有詩書氣自華生逸，虛都不虛牢屋。

image

沒錯小伙子還是我，上次話說一半你就溜了槽袄，這次我非得好好的問問你烙无。

好的面試官，因為上次著急遍尺，敖丙的系列更新了所以趕回家去看了截酷！

我信你個鬼，我們開始吧乾戏，上次說到了消息隊列的消息重復(fù)消費迂苛，你能跟我介紹這是怎么樣子的場景么？

消息重復(fù)消費是使用消息隊列之后歧蕉，必須考慮的一個問題灾部，也是比較嚴重和常見的問題康铭，帥丙我在開發(fā)過程中惯退，但凡用到了消息隊列，我第一時間考慮的就是重復(fù)消費的問題从藤。

就比如有這樣的一個場景催跪，用戶下單成功后我需要去一個活動頁面給他加GMV（銷售總額），最后根據(jù)他的GMV去給他發(fā)獎勵夷野，這是電商活動很常見的玩法懊蒸。

類似累計下單金額到哪個梯度給你返回什么梯度的獎勵這樣。

image

我只能告訴你這樣的活動頁面10000%是用異步去加的（別問我為什么悯搔，因為這個活動的后端是敖丙我做的??）骑丸，不然你想，你一個用戶下一單就給他加一下，那就意味著對那張表就要操作一下通危，你考慮下雙十一當天多少次對這個表的操作铸豁？這數(shù)據(jù)庫或者緩存都頂不住吧。

而且大家應(yīng)該也有這樣的體會菊碟，你下單了馬上去看一些活動頁面节芥，有時候馬上就有了，有時候卻延遲有很久逆害，為啥头镊？這個速度取決于消息隊列的消費速度，消費慢堵塞了就遲點看到唄魄幕。

你下個單支付成功你就發(fā)個消息出去相艇，我們上面那個活動的開發(fā)人員就監(jiān)聽你的支付成功消息，我監(jiān)聽到你這個訂單成功支付的消息纯陨，那我就去我活動GMV表里給你加上去厂捞，聽到這里大家可能覺得順理成章。

image

但是我告訴大家一般消息隊列的使用队丝，我們都是有重試機制的靡馁，就是說我下游的業(yè)務(wù)發(fā)生異常了，我會拋出異常并且要求你重新發(fā)一次机久。

我這個活動這里發(fā)生錯誤臭墨，你要求重發(fā)肯定沒問題。但是大家仔細想一下問題在哪里膘盖？

是的胧弛，不止你一個人監(jiān)聽這個消息啊，還有別的服務(wù)也在監(jiān)聽侠畔，他們也會失敗啊结缚，他一失敗他也要求重發(fā)，但是你這里其實是成功的软棺，重發(fā)了红竭，你的錢不就加了兩次了？

對不對喘落？茵宪？？是不是這個道理瘦棋？稀火？？

還不理解赌朋？看下面 ↓

image

就好比上面的這樣凰狞，我們的積分系統(tǒng)處理失敗了篇裁，他這個系統(tǒng)肯定要求你重新發(fā)送一次這個消息對吧，積分的系統(tǒng)重新接收并且處理成功了赡若，但是別人的活動茴恰，優(yōu)惠券等等服務(wù)也監(jiān)聽了這個消息呀，那不就可能出現(xiàn)活動系統(tǒng)給他加GMV加兩次斩熊，優(yōu)惠券扣兩次這種情況么往枣？

真實的情況其實重試是很正常的，服務(wù)的網(wǎng)絡(luò)抖動粉渠，開發(fā)人員代碼Bug分冈，還有數(shù)據(jù)問題等都可能處理失敗要求重發(fā)的。

嗯小伙子分析得很仔細嘛霸株，那你在開發(fā)過程中是怎么去保證的呀雕沉？

一般我們叫這樣的處理叫接口冪等。

冪等（idempotent去件、idempotence）是一個數(shù)學(xué)與計算機學(xué)概念坡椒，常見于抽象代數(shù)中。

在編程中一個冪等操作的特點是其任意多次執(zhí)行所產(chǎn)生的影響均與一次執(zhí)行的影響相同尤溜。

冪等函數(shù)倔叼，或冪等方法，是指可以使用相同參數(shù)重復(fù)執(zhí)行宫莱，并能獲得相同結(jié)果的函數(shù)丈攒。這些函數(shù)不會影響系統(tǒng)狀態(tài)，也不用擔心重復(fù)執(zhí)行會對系統(tǒng)造成改變授霸。

例如巡验，“setTrue()”函數(shù)就是一個冪等函數(shù),無論多次執(zhí)行，其結(jié)果都是一樣的.更復(fù)雜的操作冪等保證是利用唯一交易號(流水號)實現(xiàn).

通俗了講就是你同樣的參數(shù)調(diào)用我這個接口碘耳，調(diào)用多少次結(jié)果都是一個显设，你加GMV同一個訂單號你加一次是多少錢，你加N次都還是多少錢辛辨。

但是如果不做冪等捕捂，你一個訂單調(diào)用多次錢不就加多次嘛，同理你退款調(diào)用多次錢也就減多次了愉阎。

大致處理流程如下：

image

那怎么保證呢绞蹦？

一般帥丙我是這么回答的：

帥氣面試官您好，一般冪等榜旦，我會分場景去考慮，看是強校驗還是弱校驗景殷，比如跟金錢相關(guān)的場景那就很關(guān)鍵呀溅呢，就做強校驗澡屡，別不是很重要的場景做弱校驗。

強校驗：

比如你監(jiān)聽到用戶支付成功的消息咐旧，你監(jiān)聽到了去加GMV是不是要調(diào)用加錢的接口驶鹉，那加錢接口下面再調(diào)用一個加流水的接口，兩個放在一個事務(wù)铣墨，成功一起成功失敗一起失敗室埋。

每次消息過來都要拿著訂單號+業(yè)務(wù)場景這樣的唯一標識（比如天貓雙十一活動）去流水表查，看看有沒有這條流水伊约，有就直接return不要走下面的流程了姚淆，沒有就執(zhí)行后面的邏輯。

之所以用流水表屡律，是因為涉及到金錢這樣的活動腌逢，有啥問題后面也可以去流水表對賬，還有就是幫助開發(fā)人員定位問題超埋。

有的小伙伴可能還是有點懵搏讶，然后人才交流群的小伙伴也說有些例子可以放一點偽代碼，那這期開始能用代碼將的我也寫點霍殴。

image

Tip：GItHub https://github.com/JavaFamily 上有進群方式和個人聯(lián)系方式媒惕，說實話在這個群，哪怕您不說話来庭，光看聊天記錄吓笙，都能學(xué)到東西（美團王炸，三歪（Java3y）巾腕，并夕夕等的大佬都在）面睛。

弱校驗：

這個簡單，一些不重要的場景尊搬，比如給誰發(fā)短信啥的叁鉴，我就把這個id+場景唯一標識作為Redis的key，放到緩存里面失效時間看你場景佛寿，一定時間內(nèi)的這個消息就去Redis判斷幌墓。

用KV就算消息丟了可能這樣的場景也沒關(guān)系，反正丟條無關(guān)痛癢的通知短信嘛（你敢說你沒驗證碼短信丟失的情況冀泻？）常侣。
<img src="http://n.sinaimg.cn/sinacn11/0/w400h400/20180729/def2-hfxsxzh3601415.jpg" alt="" style="zoom:33%;" />

還有很多公司的弱校驗用token啊什么的，反正花樣很多弹渔，但是重要的場景一定要強校驗胳施，真正查問題的時候沒有在磁盤持久化的數(shù)據(jù)，心里還是空空的肢专，就像你和女朋友分開的時候的心里狀態(tài)一樣舞肆。（我單身的怎么知道這種感覺焦辅？猜的）

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

沒有筷登！over！

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

Tip：但是說實話順序消費這里很難介紹惠险，我上周到這周問了很多身邊的師兄開發(fā)過程中這樣的場景不多，我跟三歪也討論了幾次娱两，網(wǎng)上更多的都是介紹binlog的同步莺匠，好像更多的場景就沒了。

一般都是同個業(yè)務(wù)場景下不同幾個操作的消息同時過去十兢，本身順序是對的趣竣，但是你發(fā)出去的時候同時發(fā)出去了，消費的時候卻亂掉了旱物，這樣就有問題了遥缕。

我之前做電商活動也是有這樣的例子，我們都知道數(shù)據(jù)量大的時候數(shù)據(jù)同步壓力還是很大的宵呛，有時候數(shù)據(jù)量大的表需要同步幾個億的數(shù)據(jù)单匣。（并不是主從同步，主從延遲大的話會有問題宝穗，可能是從數(shù)據(jù)庫或者主數(shù)據(jù)庫同步到備庫）

這種情況我們都是懟到隊列里面去户秤，然后慢慢消費的，那問題就來了呀逮矛，我們在數(shù)據(jù)庫同時對一個Id的數(shù)據(jù)進行了增鸡号、改、刪三個操作须鼎，但是你消息發(fā)過去消費的時候變成了改鲸伴，刪、增晋控，這樣數(shù)據(jù)就不對了汞窗。

本來一條數(shù)據(jù)應(yīng)該刪掉了，結(jié)果在你那卻還在赡译，這不是出大問題仲吏！

image

兩者的結(jié)果是不是完全不一樣了 ↑

那你怎么解決呢？

我簡單的說一下我們使用的RocketMQ里面的一個簡單實現(xiàn)吧。

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

生產(chǎn)者消費者一般需要保證順序消息的話红碑，可能就是一個業(yè)務(wù)場景下的舞吭，比如訂單的創(chuàng)建、支付析珊、發(fā)貨羡鸥、收貨。

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

一個topic下有多個隊列奕剃，為了保證發(fā)送有序衷旅，RocketMQ提供了MessageQueueSelector隊列選擇機制，他有三種實現(xiàn):

image

我們可使用Hash取模法纵朋，讓同一個訂單發(fā)送到同一個隊列中柿顶，再使用同步發(fā)送，只有同個訂單的創(chuàng)建消息發(fā)送成功操软，再發(fā)送支付消息嘁锯。這樣，我們保證了發(fā)送有序聂薪。

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

RocketMQ僅保證順序發(fā)送，順序消費由消費者業(yè)務(wù)保證!!!

這里很好理解藏澳，一個訂單你發(fā)送的時候放到一個隊列里面去仁锯，你同一個的訂單號Hash一下是不是還是一樣的結(jié)果，那肯定是一個消費者消費笆载，那順序是不是就保證了扑馁？

真正的順序消費不同的中間件都有自己的不同實現(xiàn)我這里就舉個例子，大家思路理解下凉驻。

Tip：我寫到這點的時候人才群里也有人問我腻要，一個隊列有序出去，一個消費者消費不就好了涝登，我想說的是消費者是多線程的雄家，你消息是有序的給他的，你能保證他是有序的處理的胀滚？還是一個消費成功了再發(fā)下一個穩(wěn)妥趟济。

你能跟我聊一下分布式事務(wù)么乱投？

分布式事務(wù)在現(xiàn)在遍地都是分布式部署的系統(tǒng)中幾乎是必要的。

我們先聊一下啥是事務(wù)顷编？

分布式事務(wù)戚炫、事務(wù)隔離級別、ACID我相信大家這些東西都耳熟能詳了媳纬，那什么是事務(wù)呢双肤？

概念：

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

在計算機術(shù)語中是指訪問并可能更新數(shù)據(jù)庫中各種數(shù)據(jù)項的一個程序執(zhí)行單元(unit)钮惠。

事務(wù)通常由高級數(shù)據(jù)庫操縱語言或編程語言（如SQL茅糜，C++或Java）書寫的用戶程序用戶程序的執(zhí)行所引起，并用形如begin transaction和end transaction語句（或函數(shù)調(diào)用）來界定素挽。

事務(wù)由事務(wù)開始(begin transaction)和事務(wù)結(jié)束(end transaction)之間執(zhí)行的全體操作組成蔑赘。

特性：

事務(wù)是恢復(fù)和并發(fā)控制的基本單位。

事務(wù)應(yīng)該具有4個屬性：原子性预明、一致性缩赛、隔離性、持久性贮庞。這四個屬性通常稱為ACID特性峦筒。

原子性（atomicity）：一個事務(wù)是一個不可分割的工作單位，事務(wù)中包括的操作要么都做窗慎，要么都不做物喷。

一致性（consistency）：事務(wù)必須是使數(shù)據(jù)庫從一個一致性狀態(tài)變到另一個一致性狀態(tài)。一致性與原子性是密切相關(guān)的遮斥。

隔離性（isolation）：一個事務(wù)的執(zhí)行不能被其他事務(wù)干擾峦失。即一個事務(wù)內(nèi)部的操作及使用的數(shù)據(jù)對并發(fā)的其他事務(wù)是隔離的，并發(fā)執(zhí)行的各個事務(wù)之間不能互相干擾术吗。

持久性（durability）：持久性也稱永久性（permanence）尉辑，指一個事務(wù)一旦提交，它對數(shù)據(jù)庫中數(shù)據(jù)的改變就應(yīng)該是永久性的较屿。接下來的其他操作或故障不應(yīng)該對其有任何影響隧魄。

那有同學(xué)還是不理解，敖丙我總結(jié)了一下就是：事務(wù)就是一系列操作隘蝎，要么同時成功购啄，要么同時失敗。然后會從事務(wù)的 ACID 特性（原子性嘱么、一致性狮含、隔離性、持久性）展開敘述。

事務(wù)就是為了保證一系列操作可以正常執(zhí)行几迄，它必須同時滿足 ACID 特性蔚龙。

那什么是分布式事務(wù)呢？

大家可以想一下映胁，你下單流程可能涉及到10多個環(huán)節(jié)木羹，你下單付錢都成功了，但是你優(yōu)惠券扣減失敗了屿愚，積分新增失敗了汇跨，前者公司會被薅羊毛务荆，后者用戶會不開心妆距，但是這些都在不同的服務(wù)怎么保證大家都成功呢？

聰明函匕，分布式事務(wù)娱据，你看你都會搶答了！

Tip：真實的應(yīng)用場景可能比我介紹的場景復(fù)雜數(shù)倍盅惜，我只是為了舉例方便一下大家理解所以用了很簡單的例子中剩。

我接觸和了解到的分布式事務(wù)大概分為：

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

這里我就介紹下最簡單的2pc（兩段式）结啼，以及大家以后可能比較常用的半消息事務(wù)也就是最終一致性，目的是讓大家理解下分布式事務(wù)里面消息中間件的作用屈芜，別的事務(wù)都大同小異郊愧，都有很多優(yōu)點。

當然也都有種種弊端：

例如長時間鎖定數(shù)據(jù)庫資源井佑，導(dǎo)致系統(tǒng)的響應(yīng)不快属铁，并發(fā)上不去。

網(wǎng)絡(luò)抖動出現(xiàn)腦裂情況躬翁，導(dǎo)致事物參與者焦蘑，不能很好地執(zhí)行協(xié)調(diào)者的指令，導(dǎo)致數(shù)據(jù)不一致盒发。

單點故障：例如事物協(xié)調(diào)者例嘱，在某一時刻宕機，雖然可以通過選舉機制產(chǎn)生新的Leader宁舰，但是這過程中拼卵，必然出現(xiàn)問題，而TCC明吩，只有強悍的技術(shù)團隊间学，才能支持開發(fā)，成本太高。

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

2pc（兩段式提交） :

image

2pc（兩段式提交）可以說是分布式事務(wù)的最開始的樣子了，像極了媒婆嘿悬，就是通過消息中間件協(xié)調(diào)多個系統(tǒng)实柠，在兩個系統(tǒng)操作事務(wù)的時候都鎖定資源但是不提交事務(wù)，等兩者都準備好了善涨，告訴消息中間件蒂萎，然后再分別提交事務(wù)。

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

是的你可能已經(jīng)發(fā)現(xiàn)了最蕾，如果A系統(tǒng)事務(wù)提交成功了，但是B系統(tǒng)在提交的時候網(wǎng)絡(luò)波動或者各種原因提交失敗了源内，其實還是會失敗的葡粒。

最終一致性：

image

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

• 業(yè)務(wù)主動方本地事務(wù)提交失敗膜钓，業(yè)務(wù)被動方不會收到消息的投遞嗽交。

• 只要業(yè)務(wù)主動方本地事務(wù)執(zhí)行成功，那么消息服務(wù)一定會投遞消息給下游的業(yè)務(wù)被動方颂斜，并最終保證業(yè)務(wù)被動方一定能成功消費該消息（消費成功或失敗夫壁，即最終一定會有一個最終態(tài)）。

不過呢技術(shù)就是這樣沃疮，各種極端的情況我們都需要考慮盒让，也很難有完美的方案，所以才會有這么多的方案三段式忿磅、TCC糯彬、最大努力通知等等分布式事務(wù)方案，大家只需要知道為啥要做葱她，做了有啥好處撩扒，有啥壞處，在實際開發(fā)的時候都注意下就好好了吨些，系統(tǒng)都是根據(jù)業(yè)務(wù)場景設(shè)計出來的搓谆，離開業(yè)務(wù)的技術(shù)沒有意義，離開技術(shù)的業(yè)務(wù)沒有底氣豪墅。

還是那句話：沒有最完美的系統(tǒng)泉手，只有最適合的系統(tǒng)。

面試結(jié)束

小伙子看不出來啊偶器，還是有點東西的嘛斩萌，這幾個點都回答的不錯缝裤，明天你能跟我聊一下RocketMQ么？

敖丙這章花了這么多時間颊郎，不確定他寫不寫的完憋飞，心疼他。好想給他點贊啊姆吭，消息回溯也在單獨介紹消息中間件的時候介紹吧榛做，這章篇幅有點長了。

總結(jié)

這章其實我寫的時間比之前的秒殺還要久内狸，因為順序消息這個場景我不知道怎么講出來大家容易懂一點检眯，最后就參考了網(wǎng)上的，順序消息的實際應(yīng)用場景沒別的那么廣泛昆淡，跟3y也聊了好幾次锰瘸，最后定了這個binlog的場景。

總之就是這期創(chuàng)作源泉有點枯竭瘪撇，這章是真的難寫获茬，包括分布式事務(wù)在實際開發(fā)過程中也是很復(fù)雜的環(huán)節(jié)，需要用的時候光是做設(shè)計都要很久倔既，反正我的流程圖長得一匹。

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

絮叨

敖丙我呀，這周有牌面喲吊履，上了CSDN的原力計劃榜單安皱，而且獎金高達50塊！Ｍа住酌伊！

image

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

DISS

image

這是博客園的一個網(wǎng)友在我文章下面的評論咒彤，說實話不知道大家怎么看的，我只想說：呵呵咒精！傻*

我不知道這個多年的經(jīng)驗到底是怎么樣子的多年的經(jīng)驗蔼紧，我本來其實不準備說出來的，因為我發(fā)現(xiàn)我群里很多都是還沒畢業(yè)的大學(xué)生或者應(yīng)屆生狠轻，那就假設(shè)我讀者還有很多這樣的學(xué)生奸例，他們都沒社會經(jīng)驗我怕他們被這樣的人給誤導(dǎo)了。

我記得我在群里說過：

image

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

但是面試裝傻這個觀點湖蜕？還有什么不會要比你強的人這個觀點逻卖？技術(shù)人我相信也有面試官也在看我的文章，你們在面試的時候昭抒，我想遇到厲害的人巴不得招入麾下评也，為自己沖鋒陷陣吧。

而且正常面試的時候你是1-3年的經(jīng)驗灭返，面試你的基本上都是3年以上的盗迟，然后依次順推，當然也有很多很厲害的Leader（我前東家Leader95年的熙含，字節(jié)跳動某產(chǎn)品線很強的Leader96的等等）等大家工作了你就會發(fā)現(xiàn)有些東西沒有時間積累是學(xué)不到的罚缕，你要做的只是一步一個腳印踏實走好就好了。

那些人不管年輕與否能坐在那面試你肯定有他的原因怎静，那你有什么才華邮弹，你盡情施展，他沒那個度量包容你的優(yōu)秀蚓聘，這樣的公司不去也罷腌乡，但是技術(shù)人這樣的真的很少，程序員是一群很崇拜能力的人夜牡。

所以面試你有啥都秀出來与纽，把你的才華盡情的展示出來，風(fēng)就在那氯材，你只管飛翔渣锦。

鳴謝

涉及到分布式事務(wù)的環(huán)節(jié)我參考了前大神同事：魯班（花名）的技術(shù)分享，很感謝他的文章給的思路氢哮，還有問題的解析袋毙！

image

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

image

看到?jīng)]胀溺，就很民主。（敖丙你個渣男皆看，呸仓坞，自己不會就不寫！）

Tip： GItHub https://github.com/JavaFamily 上有進群方式和個人聯(lián)系方式腰吟，說實話在這個群无埃，哪怕您不說話，光看聊天記錄毛雇，都能學(xué)到東西（美團王炸嫉称，三歪（Java3y），并夕夕等的大佬都在）灵疮。

日常求贊

好了各位织阅，以上就是這篇文章的全部內(nèi)容了，能看到這里的人呀震捣，都是人才荔棉。

我每周都會更新幾篇《吊打面試官》系列和互聯(lián)網(wǎng)常用技術(shù)棧相關(guān)的文章，非常感謝人才們能看到這里蒿赢，如果這個文章寫得還不錯润樱，覺得「敖丙」我有點東西的話 求點贊?? 求關(guān)注?? 求分享?? 對暖男我來說真的 非常有用！Ｋ咧病祥国！

創(chuàng)作不易，各位的支持和認可晾腔，就是我創(chuàng)作的最大動力，我們下篇文章見啊犬！

敖丙 | 文 【原創(chuàng)】【轉(zhuǎn)載請聯(lián)系本人】 如果本篇博客有任何錯誤灼擂，請批評指教，不勝感激 觉至！

《吊打面試官》系列每周持續(xù)更新剔应，可以關(guān)注我的公眾號「 三太子敖丙 」第一時間閱讀和催更（公眾號比博客早一到兩篇喲），本文GitHub上已經(jīng)收錄https://github.com/JavaFamily语御，有一線大廠面試點思維導(dǎo)圖峻贮，歡迎Star和完善，里面也有我個人聯(lián)系方式有什么問題也可以直接找我应闯，也有人才交流群纤控，我們一起有點東西。