摘要：如果你對異步的了解比較模糊的話，這次可以帶你一次性深入淺出。同步異步任何事物都是有利有弊的。這也導(dǎo)致了在異步環(huán)境下做事務(wù)的成本更高。但是，異步在跨進(jìn)程通訊中更合適抽象成事件來進(jìn)行協(xié)作。

如果第二次看到我的文章，歡迎「文末」掃碼訂閱我個(gè)人的公眾號（跨界架構(gòu)師）喲~?
每周五早8點(diǎn) 按時(shí)送達(dá)到公眾號。當(dāng)然了，也會(huì)時(shí)不時(shí)加個(gè)餐～

Z哥在前面的三篇文章里和你一起聊了「高性能」主題下與「緩存」相關(guān)的內(nèi)容。這次和你來聊聊提高性能的另一個(gè)大招——「異步」。

如果你已經(jīng)對「異步」有所了解的話，這次可以讓你有更深刻的理解。如果你對「異步」的了解比較模糊的話，這次可以帶你一次性深入淺出。

不管我們的思維模式也好，還是平時(shí)寫的最習(xí)慣的代碼，其實(shí)都是以「同步」的方式在進(jìn)行的。所以，「同步」方式用著也挺好，為啥要「異步」呢？拿你平時(shí)去買奶茶、買咖啡的例子來說說你就明白了。

你應(yīng)該有注意到，一般奶茶店都會(huì)分“點(diǎn)單區(qū)”和“取餐區(qū)”。

然后你去消費(fèi)的時(shí)候都是在“點(diǎn)單區(qū)”選擇飲料然后付錢，在“取餐區(qū)”拿做好的飲料。其實(shí)這個(gè)過程就是「異步」的，因?yàn)楫?dāng)營業(yè)員在做飲料的時(shí)候，你是可以去干其它事的，比如在邊上開一局王者榮耀或者吃雞。而他們也可以繼續(xù)接受后面顧客的點(diǎn)單。

如果是「同步」會(huì)怎樣呢？就是你在點(diǎn)單區(qū)點(diǎn)好飲料之后，繼續(xù)排著隊(duì)干等著營業(yè)員做好，直到營業(yè)員把飲料做好交給你之后，你就可以走人了，他再繼續(xù)服務(wù)后面的顧客。

很明顯，如果一個(gè)店鋪里有2個(gè)或者2個(gè)以上的營業(yè)員，用這種「異步」的方式“吞吐量“更高。

因?yàn)閬碣I飲料的人時(shí)間是不規(guī)律的，可能有時(shí)候一下子來十幾個(gè)，可能有時(shí)候半小時(shí)都不來一個(gè)。那么通過這種「異步」的方式，雖然不能縮短制作飲料的時(shí)間，但是可以縮短人流量大的時(shí)候顧客的等待點(diǎn)單時(shí)間，讓顧客可以去做其它事。

其實(shí)軟件系統(tǒng)也是如此，如今我們程序所在的服務(wù)器幾乎全部是多核多線程的。既然有多個(gè)“營業(yè)員”在，那么通過「異步」的方式盡可能的發(fā)揮多線程的作用，才是物盡其用的辦法，還能提升整體的效率。

不過，這事在軟件系統(tǒng)中要稍微復(fù)雜一些，要多考慮一下。因?yàn)榫€程的創(chuàng)建、銷毀、切換成本在很多時(shí)候甚至比獲得的收益還要高。所以，只有將「異步」運(yùn)用于「等待處理的時(shí)間」>「創(chuàng)建、銷毀、切換線程的時(shí)間」的場景下才有價(jià)值。

要滿足這種場景的話，一般就是涉及到「I/O」處理的地方。比如磁盤I/O、網(wǎng)絡(luò)I/O。

比如，一旦涉及到數(shù)據(jù)庫查詢或者RPC調(diào)用的時(shí)候，如果使用「同步」的方式通信，發(fā)起一個(gè)調(diào)用后，調(diào)用方會(huì)阻塞自己并等待整個(gè)操作的完成（想象一下執(zhí)行一條耗時(shí)10秒鐘的sql）。如果使用「異步」通信的話，調(diào)用方不需要等待操作完成就可以返回，甚至可能不需要關(guān)心整個(gè)操作完成與否。

特別對于如今的移動(dòng)網(wǎng)絡(luò)環(huán)境下，通過異步的方式可以在很大程度上保證當(dāng)網(wǎng)絡(luò)很卡的時(shí)候APP上的操作依然是流暢的，不會(huì)出現(xiàn)卡機(jī)。

任何事物都是有利有弊的?！竿健箍梢粤ⅠR知道到底成功與否（比如做奶茶的時(shí)候營業(yè)員發(fā)現(xiàn)珍珠沒了，馬上就可以告訴你），而「異步」不行（這個(gè)時(shí)候你可能去別的地方溜達(dá)了）。這也導(dǎo)致了在「異步」環(huán)境下做「事務(wù)」的成本更高。

而且，在分布式系統(tǒng)中遍布著RPC調(diào)用，如果是「同步」調(diào)用的話，還可以配合「短鏈接」做到對連接資源的用完即放。而「異步」的話連接保持的時(shí)間要更長一些，至少要等到回調(diào)觸發(fā)完成后才能釋放。

而且Z哥還要提醒你，在使用「異步」的時(shí)候，有兩點(diǎn)特別容易被忽略。

發(fā)起請求的線程往往和接收響應(yīng)的線程不是同一個(gè)，所以「線程上下文」是不連續(xù)的。（當(dāng)然可以通過做一些額外的編碼工作達(dá)到類似的效果）

雖然請求的順序是由客戶端控制的，但是回調(diào)的時(shí)候可能就不一定是按照請求時(shí)的順序進(jìn)行的，像下圖這樣。

這么看來，「同步」和「異步」都可以通過「請求/響應(yīng)」模型來完成。但是，「異步」在跨進(jìn)程通訊中更合適抽象成「事件」來進(jìn)行協(xié)作。

通過「事件」進(jìn)行「異步」協(xié)作的話，客戶端不是發(fā)起請求，而是發(fā)布一個(gè)「事件」，然后期待其他的協(xié)作者接收到該消息，并且知道該怎么處理它，客戶端不用關(guān)心其他協(xié)作者做了什么，甚至也無需知道有哪些協(xié)作者存在。

基于「事件」的協(xié)作方式耦合度很低。客戶端發(fā)布一個(gè)「事件」，但并不需要知道誰或者什么會(huì)對此作出響應(yīng)，這也意味著，你可以在不影響客戶端的情況下對該「事件」添加新的訂閱者。

總的來說，異步雖然能提升效率，但是還是無法在所有場景使用它。在實(shí)際工作中，往往我們會(huì)同時(shí)運(yùn)用「同步」和「異步」，所以了解清楚它們之間的區(qū)別和優(yōu)缺點(diǎn)是很有必要。

我們以一個(gè)電商APP中的“下單”場景來舉個(gè)例子。

在電商的業(yè)務(wù)場景中，下單最常見的就是以下幾個(gè)操作（順序隨便排的）。

扣減庫存

核銷優(yōu)惠券

生成訂單

生成電子發(fā)票

這些操作都是由用戶在APP中點(diǎn)擊“提交訂單”按鈕之后觸發(fā)的。

那么首先來看APP這邊。一般我們的APP僅僅負(fù)責(zé)UI層面的展示控制，業(yè)務(wù)邏輯部分都是下沉到后端的API去做的。而APP和API之間大多都是以Http或者Tcp協(xié)議的形式進(jìn)行通信的，那么在APP層面，我們只要借助一些異步編程的類庫即可（這方面不是特別專業(yè)，就不多BB了）。

然后到API層面，先給所有接收請求的Action加上異步支持，java的話可以在注解處增加asyncSupported = true，.net的話增加aysnc關(guān)鍵字。如此一來，就是告訴程序所在的宿主（web server或者service）“我這個(gè)方法是支持異步的，你接收到請求之后就不要阻塞了，去忙別的吧”。

接下來就輪到處理上面提到的電商下單場景中的4個(gè)操作了。理論上，這4個(gè)操作可以全部按「請求+回調(diào)」的異步模式進(jìn)行，完全可行。這個(gè)過程其實(shí)有點(diǎn)像「并行」的意思，最終的處理完成時(shí)間是由最晚完成回調(diào)的那個(gè)操作決定的。

但是，為了避免個(gè)別程序的意外情況導(dǎo)致最晚回調(diào)的時(shí)間被拉的很長，我們就需要來考慮一下，那些無需即時(shí)知道甚至無需關(guān)心返回結(jié)果的操作可以通過「事件」的形式進(jìn)行「異步」。

比如，像“生成電子發(fā)票”這種操作，對當(dāng)前這個(gè)業(yè)務(wù)場景來說并不需要實(shí)時(shí)知道它的返回結(jié)果。

雖然我們知道它的業(yè)務(wù)邏輯相比生成訂單這些更簡單，處理起來很快，但是一旦服務(wù)出現(xiàn)問題，那就不好說了。

題外話：網(wǎng)絡(luò)是不可信的，因?yàn)樗菀资艿焦?、不穩(wěn)定，所以在分布式系統(tǒng)中這些“意外情況”格外常見。多一個(gè)硬性的依賴，就多一份出錯(cuò)的可能性。

如果沒有做好前面一些文章中提到的「高可用」保障（文末放傳送門，感興趣的可以看完這篇再去看）的話，一旦所依賴的服務(wù)出現(xiàn)問題就會(huì)被拖累，導(dǎo)致接收到最晚回調(diào)的時(shí)間拉長，甚至由于未能及時(shí)回調(diào)回來導(dǎo)致當(dāng)前的處理無法繼續(xù)下去。

那像這樣的業(yè)務(wù)點(diǎn)，我們就可以通過「事件」的形式進(jìn)行「異步」處理，比如在生成完訂單之后發(fā)出一個(gè)“訂單被創(chuàng)建”的「事件」，然后由訂閱該「事件」的“生成電子發(fā)票服務(wù)“接收該「事件」并進(jìn)行處理。如此一來，即提高了“提交訂單”時(shí)的處理效率，還使得“電子發(fā)票服務(wù)“的任何波動(dòng)都不會(huì)影響到“提交訂單”操作的正常進(jìn)行。

對這個(gè)「事件」的處理，你可以在程序中建立一個(gè)多帶帶的方法進(jìn)行，它的入?yún)⑹且粋€(gè)「事件」基類，返回值是void。具體的「事件」數(shù)據(jù)你可以選擇持久化到DB，也可以選擇投遞到MQ中。大致是下面這樣的代碼

void SendEvent(BaseEvent event){
//投送到DB或者M(jìn)Q；
}
?
?
class BaseEvent{
DateTime OccurredTime;
}
?
class OrderCreated extend BaseEvent{
Order order;
Invoice invoice;
...
}

可能你會(huì)問事件處理失敗了怎么辦？甚至做持久化和投遞到MQ的s以后就異常了咋辦？可以轉(zhuǎn)去看之前的文章《分布式系統(tǒng)關(guān)注點(diǎn)——「共識」的兄弟「事務(wù)」》，以及文末的高可用系列文章。

最后，當(dāng)你在使用異步的時(shí)候，還有一項(xiàng)工作要做，雖然是輔助性的，但是很重要。

就是需要引入一個(gè)全局唯一標(biāo)識將整個(gè)異步的請求鏈路“串“起來，否則排查問題的時(shí)候夠你頭疼的，完全分不清楚哪是哪。如果條件允許，可以再引入一個(gè)日志聚合系統(tǒng)。比如ELK全家桶，讓你可以更高效的篩選日志信息。

好了，我們一起總結(jié)一下。

這次呢，Z哥先和你聊了下「異步」的意義，以及它是如何來提升性能的。

然后和你聊了一下「異步」的一些弊端和常見的運(yùn)用方式。

最后以一個(gè)電商下單的例子梳理了一下做「異步」的思路。

希望對你有所啟發(fā)。

相關(guān)文章：

分布式系統(tǒng)關(guān)注點(diǎn)——360°全方位解讀「緩存」

分布式系統(tǒng)關(guān)注點(diǎn)——先寫DB還是「緩存」？

分布式系統(tǒng)關(guān)注點(diǎn)——緩存背后的“毀滅種子”

分布式系統(tǒng)關(guān)注點(diǎn)——「共識」的兄弟「事務(wù)」

如何在到處是“雷”的系統(tǒng)中「明哲保身」？這是第一招

想通關(guān)「限流」？只要這一篇

讓你的系統(tǒng)“堅(jiān)挺不倒”的最后一個(gè)大招——「降級」

分布式系統(tǒng)關(guān)注點(diǎn)——99%的人都能看懂的「補(bǔ)償」以及最佳實(shí)踐

作者：Zachary

出處：https://www.cnblogs.com/Zacha...

如果你喜歡這篇文章，可以點(diǎn)一下文末的「贊」。

這樣可以給我一點(diǎn)反饋。: )

謝謝你的舉手之勞。

?關(guān)于作者：張帆（Zachary，個(gè)人微信號：Zachary-ZF）。堅(jiān)持用心打磨每一篇高質(zhì)量原創(chuàng)。歡迎掃描下方的二維碼~。
定期發(fā)表原創(chuàng)內(nèi)容：架構(gòu)設(shè)計(jì)丨分布式系統(tǒng)丨產(chǎn)品丨運(yùn)營丨一些思考。
如果你是初級程序員，想提升但不知道如何下手。又或者做程序員多年，陷入了一些瓶頸想拓寬一下視野。歡迎關(guān)注我的公眾號「跨界架構(gòu)師」，回復(fù)「技術(shù)」，送你一份我長期收集和整理的思維導(dǎo)圖。
如果你是運(yùn)營，面對不斷變化的市場束手無策。又或者想了解主流的運(yùn)營策略，以豐富自己的“倉庫”。歡迎關(guān)注我的公眾號「跨界架構(gòu)師」，回復(fù)「運(yùn)營」，送你一份我長期收集和整理的思維導(dǎo)圖。