文章來(lái)源于公眾號(hào)：架構(gòu)頭條 作者：Miguel
你是否有別人說(shuō)過(guò)，異步 Python 代碼比“普通（或同步）Python 代碼更快？那么事實(shí)真的是這樣嗎？
“同步”和“異步”是什么意思？
Web 應(yīng)用程序通常要處理許多請(qǐng)求，這些請(qǐng)求在短時(shí)間內(nèi)來(lái)自不同的客戶端。為避免處理延遲，必須考慮并行處理多個(gè)請(qǐng)求，這通常稱為“并發(fā)”。
在本文中，我將繼續(xù)使用 Web 應(yīng)用程序作為例子，但還有其它類型的應(yīng)用程序也從并發(fā)中獲益。因此，這個(gè)討論并不僅僅是針對(duì) Web 應(yīng)用程序的。
術(shù)語(yǔ)“同步”和“異步”指的是編寫并發(fā)應(yīng)用程序的兩種方式。所謂的“同步”服務(wù)器使用底層操作系統(tǒng)支持的線程和進(jìn)程來(lái)實(shí)現(xiàn)這種并發(fā)性。下面是同步部署的一個(gè)示意圖：
在這種情況下，我們有 5 臺(tái)客戶端，都向應(yīng)用程序發(fā)送請(qǐng)求。這個(gè)應(yīng)用程序的訪問(wèn)入口是一個(gè) Web 服務(wù)器，通過(guò)將服務(wù)分配給一個(gè)服務(wù)器 worker 池來(lái)充當(dāng)負(fù)載均衡器，這些 worker 可以實(shí)現(xiàn)為進(jìn)程、線程或者兩者的結(jié)合。這些 worker 執(zhí)行負(fù)載均衡器分配給他們的請(qǐng)求。你使用 Web 應(yīng)用程序框架（例如 Flask 或 Django）編寫的應(yīng)用程序邏輯運(yùn)行在這些 worker 中。
這種類型的方案對(duì)于有多個(gè) CPU 的服務(wù)器比較好，因?yàn)槟憧梢詫?worker 的數(shù)量設(shè)置為 CPU 的數(shù)量，這樣你就能均衡地利用你的處理器核心，而單個(gè) Python 進(jìn)程由于全局解釋器鎖（GIL）的限制無(wú)法實(shí)現(xiàn)這一點(diǎn)。
在缺點(diǎn)上，上面的示意圖也清楚展示了這種方案的主要局限。我們有 5 個(gè)客戶端，卻只有 4 個(gè) worker。如果這 5 個(gè)客戶端在同一時(shí)間都發(fā)送請(qǐng)求，那么負(fù)載均衡器會(huì)將某一個(gè)客戶端之外的所有請(qǐng)求發(fā)送到 worker 池，而剩下的請(qǐng)求不得不保留在一個(gè)隊(duì)列中，等待有 worker 變得可用。因此，五分之四的請(qǐng)求會(huì)立即響應(yīng)，而剩下的五分之一需要等一會(huì)兒。服務(wù)器優(yōu)化的一個(gè)關(guān)鍵就在于選擇適當(dāng)數(shù)量的 worker 來(lái)防止或最小化給定預(yù)期負(fù)載的請(qǐng)求阻塞。
一個(gè)異步服務(wù)器的配置很難畫，但是我盡力而為：
這種類型的服務(wù)器運(yùn)行在單個(gè)進(jìn)程中，通過(guò)循環(huán)控制。這個(gè)循環(huán)是一個(gè)非常有效率的任務(wù)管理器和調(diào)度器，創(chuàng)建任務(wù)來(lái)執(zhí)行由客戶端發(fā)送的請(qǐng)求。與長(zhǎng)期存在的服務(wù)器 worker 不同，異步任務(wù)是由循環(huán)創(chuàng)建，用來(lái)處理某個(gè)特定的請(qǐng)求，當(dāng)那個(gè)請(qǐng)求完成時(shí)，該任務(wù)也會(huì)被銷毀。任何時(shí)候，一臺(tái)異步服務(wù)器都會(huì)有上百或上千個(gè)活躍的任務(wù)，它們都在循環(huán)的管理下執(zhí)行自己的工作。
你可能想知道異步任務(wù)之間的并行是如何實(shí)現(xiàn)的。這就是有趣的部分，因?yàn)橐粋€(gè)異步應(yīng)用程序通過(guò)唯一的協(xié)同多任務(wù)處理來(lái)實(shí)現(xiàn)這點(diǎn)。這意味著什么？當(dāng)一個(gè)任務(wù)需要等待一個(gè)外部事件（例如，一個(gè)數(shù)據(jù)庫(kù)服務(wù)器的響應(yīng)）時(shí)，不會(huì)像一個(gè)同步的 worker 那樣等待，而是會(huì)告訴循環(huán)，它需要等待什么，然后將控制權(quán)返回給它。循環(huán)就能夠在這個(gè)任務(wù)被數(shù)據(jù)庫(kù)阻塞的時(shí)候發(fā)現(xiàn)另外一個(gè)準(zhǔn)備就緒的任務(wù)。最終，數(shù)據(jù)庫(kù)將發(fā)送一個(gè)響應(yīng)，而那時(shí)循環(huán)會(huì)認(rèn)為第一個(gè)的任務(wù)已經(jīng)準(zhǔn)備好再次運(yùn)行，并將盡快恢復(fù)它。
異步任務(wù)暫停和恢復(fù)執(zhí)行的這種能力可能在抽象上很難理解。為了幫你應(yīng)用到你已經(jīng)知道的東西，可以考慮在 Python 中使用await或yield關(guān)鍵字這一方法來(lái)實(shí)現(xiàn)，但你之后會(huì)發(fā)現(xiàn)，這并不是唯一實(shí)現(xiàn)異步任務(wù)的方法。
一個(gè)異步應(yīng)用程序完全運(yùn)行在單個(gè)進(jìn)程或線程中，這可以說(shuō)是令人吃驚的。當(dāng)然，這種類型的并發(fā)需要遵循一些規(guī)則，因此，你不能讓一個(gè)任務(wù)占用 CPU 太長(zhǎng)時(shí)間，否則，剩余的任務(wù)會(huì)被阻塞。為了異步執(zhí)行，所有的任務(wù)需要定時(shí)主動(dòng)暫停并將控制權(quán)返還給循環(huán)。為了從異步方式獲益，一個(gè)應(yīng)用程序需要有經(jīng)常被 I/O 阻塞的任務(wù)，并且沒(méi)有太多 CPU 工作。Web 應(yīng)用程序通常非常適合，特別是當(dāng)它們需要處理大量客戶端請(qǐng)求時(shí)。
在使用一個(gè)異步服務(wù)器時(shí)，為了最大化多 CPU 的利用率，通常需要?jiǎng)?chuàng)建一個(gè)混合方案，增加一個(gè)負(fù)載均衡器并在每個(gè) CPU 上運(yùn)行一個(gè)異步服務(wù)器，如下圖所示：
Python 中實(shí)現(xiàn)異步的 2 種方法
我敢肯定，你知道要在 Python 中寫一個(gè)異步應(yīng)用程序，你可以使用 asyncio package，這個(gè)包是在協(xié)程的基礎(chǔ)上實(shí)現(xiàn)了所有異步應(yīng)用程序都需要的暫停和恢復(fù)特性。其中yield關(guān)鍵字，以及更新的async和await都是asyncio構(gòu)建異步能力的基礎(chǔ)。
https://docs.python.org/3/library/asyncio.html
Python 生態(tài)系統(tǒng)中還有其它基于協(xié)程的異步方案，例如 Trio 和 Curio。還有 Twisted，它是所有協(xié)程框架中最古老的，甚至出現(xiàn)得比asyncio都要早。
如果你對(duì)編寫異步 Web 應(yīng)用程序感興趣，有許多基于協(xié)程的異步框架可以選擇，包括 aiohttp、sanic、FastAPI 和 Tornado。
很多人不知道的是，協(xié)程只是 Python 中編寫異步代碼的兩種方法之一。第二種方法是基于一個(gè)叫做 greenlet 的庫(kù)，你可以用 pip 安裝它。Greenlets 和協(xié)程類似，它們也允許一個(gè) Python 函數(shù)暫停執(zhí)行并稍后恢復(fù)，但是它們實(shí)現(xiàn)這點(diǎn)的方式完全不同，這意味著 Python 中的異步生態(tài)系統(tǒng)分成兩大類。
協(xié)程與 greenlets 之間針對(duì)異步開發(fā)最有意思的區(qū)別是，前者需要 Python 語(yǔ)言特定的關(guān)鍵字和特性才能工作，而后者并不需要。我的意思是，基于協(xié)程的應(yīng)用程序需要使用一種特定的語(yǔ)法來(lái)書寫，而基于 greenlet 的應(yīng)用程序看起來(lái)幾乎和普通 Python 代碼一樣。這非?？?，因?yàn)樵谀承┣闆r下，這讓同步代碼可以被異步執(zhí)行，這是諸如asyncio之類的基于協(xié)程的方案做不到的。
那么在 greenlet 方面，跟asyncio對(duì)等的庫(kù)有哪些？我知道 3 個(gè)基于 greenlet 的異步包：Gevent、Eventlet 和 Meinheld，盡管最后一個(gè)更像是一個(gè) Web 服務(wù)器而不是一個(gè)通用的異步庫(kù)。它們都有自己的異步循環(huán)實(shí)現(xiàn)，而且它們都提供了一個(gè)有趣的“monkey-patching”功能，取代了 Python 標(biāo)準(zhǔn)庫(kù)中的阻塞函數(shù)，例如那些執(zhí)行網(wǎng)絡(luò)和線程的函數(shù)，并基于 greenlets 實(shí)現(xiàn)了等效的非阻塞版本。如果你有一些同步代碼想要異步運(yùn)行，這些包會(huì)對(duì)你有所幫助。
據(jù)我所知，唯一明確支持 greenlet 的 Web 框架只有 Flask。這個(gè)框架會(huì)自動(dòng)監(jiān)測(cè)，當(dāng)你想要運(yùn)行在一個(gè) greenlet Web 服務(wù)器上時(shí)，它會(huì)自我進(jìn)行相應(yīng)調(diào)整，而無(wú)需進(jìn)行任何配置。這么做時(shí)，你需要注意不要調(diào)用阻塞函數(shù)，或者，如果你要調(diào)用阻塞函數(shù)，最好用猴子補(bǔ)丁來(lái)“修復(fù)”那些阻塞函數(shù)。
但是，F(xiàn)lask 并不是唯一受益于 greenlets 的框架。其它 Web 框架，例如 Django 和 Bottle]，雖然沒(méi)有 greenlets，但也可以通過(guò)結(jié)合一個(gè) greenlet Web 服務(wù)器并使用 monkey-patching 修復(fù)阻塞函數(shù)的方式來(lái)異步運(yùn)行。
異步比同步更快嗎？
對(duì)于同步和異步應(yīng)用程序的性能，存在著一個(gè)廣泛的誤解——異步應(yīng)用程序比同步應(yīng)用程序快得多。
對(duì)此，我需要澄清一下。無(wú)論是用同步方式寫，還是用異步方式寫，Python 代碼運(yùn)行速度是幾乎相同的。除了代碼，有兩個(gè)因素能夠影響一個(gè)并發(fā)應(yīng)用程序的性能：上下文切換和可擴(kuò)展性。
上下文切換
在所有運(yùn)行的任務(wù)間公平地共享 CPU 所需的工作，稱為上下文切換，能夠影響應(yīng)用程序的性能。對(duì)同步應(yīng)用程序來(lái)說(shuō)，這項(xiàng)工作是由操作系統(tǒng)完成的，而且基本上是一個(gè)黑箱，不需要配置或微調(diào)選項(xiàng)。對(duì)異步應(yīng)用程序來(lái)說(shuō)，上下文切換是由循環(huán)完成的。
默認(rèn)的循環(huán)實(shí)現(xiàn)由asyncio提供，是用 Python 編寫的，效率不是很高。而 uvloop 包提供了一個(gè)備選的循環(huán)方案，其中部分代碼是用 C 編寫的來(lái)實(shí)現(xiàn)更好的性能。Gevent 和 Meinheld 所使用的事件循環(huán)也是用 C 編寫的。Eventlet 用的是 Python 編寫的循環(huán)。
高度優(yōu)化的異步循環(huán)比操作系統(tǒng)在進(jìn)行上下文切換方面更有效率，但根據(jù)我的經(jīng)驗(yàn)，要想看到實(shí)際的效率提升，你運(yùn)行的并發(fā)量必須非常大。對(duì)于大部分應(yīng)用程序，我不認(rèn)為同步和異步上下文切換之間的性能差距有多明顯。
擴(kuò)展性
我認(rèn)為異步更快這個(gè)神話的來(lái)源是，異步應(yīng)用程序通常會(huì)更有效地使用 CPU、能更好地進(jìn)行擴(kuò)展并且擴(kuò)展方式比同步更靈活。
如果上面示意圖中的同步服務(wù)器同時(shí)收到 100 個(gè)請(qǐng)求，想一下會(huì)發(fā)生什么。這個(gè)服務(wù)器同時(shí)最多只能處理 4 個(gè)請(qǐng)求，因此大部分請(qǐng)求會(huì)停留在一個(gè)隊(duì)列中等待，直到它們被分配一個(gè) worker。
與之形成對(duì)比的是，異步服務(wù)器會(huì)立即創(chuàng)建 100 個(gè)任務(wù)（或者使用混合模式的話，在 4 個(gè)異步 worker 上每個(gè)創(chuàng)建 25 個(gè)任務(wù)）。使用異步服務(wù)器，所有請(qǐng)求都會(huì)立即開始處理而不用等待（盡管公平地說(shuō)，這種方案也還會(huì)有其它瓶頸會(huì)減慢速度，例如對(duì)活躍的數(shù)據(jù)庫(kù)連接的限制）。
如果這 100 個(gè)任務(wù)主要使用 CPU，那么同步和異步方案會(huì)有相似的性能，因?yàn)槊總€(gè) CPU 運(yùn)行的速度是固定的，Python 執(zhí)行代碼的速度總是相同的，應(yīng)用程序要完成的工作也是相同的。但是，如果這些任務(wù)需要做很多 I/O 操作，那么同步服務(wù)器只能處理 4 個(gè)并發(fā)請(qǐng)求而不能實(shí)現(xiàn) CPU 的高利用率。而另一方面，異步服務(wù)器會(huì)更好地保持 CPU 繁忙，因?yàn)樗遣⑿械剡\(yùn)行所有這 100 個(gè)請(qǐng)求。
你可能會(huì)想，為什么你不能運(yùn)行 100 個(gè)同步 worker，那樣，這兩個(gè)服務(wù)器就會(huì)有相同的并發(fā)能力。要注意，每個(gè) worker 需要自己的 Python 解釋器以及與之相關(guān)聯(lián)的所有資源，再加上一份單獨(dú)的應(yīng)用程序拷貝及其資源。你的服務(wù)器和應(yīng)用程序的大小將決定你可以運(yùn)行多少個(gè) worker 實(shí)例，但通常這個(gè)數(shù)字不會(huì)很大。另一方面，異步任務(wù)非常輕量，都運(yùn)行在單個(gè) worker 進(jìn)程的上下文中，因此具有明顯優(yōu)勢(shì)。
綜上所述，只有如下場(chǎng)景時(shí)，我們可以說(shuō)異步可能比同步快：
- 存在高負(fù)載（沒(méi)有高負(fù)載，訪問(wèn)的高并發(fā)性就沒(méi)有優(yōu)勢(shì)）
- 任務(wù)是 I/O 綁定的（如果任務(wù)是 CPU 綁定的，那么超過(guò) CPU 數(shù)目的并發(fā)并沒(méi)有幫助）
- 你查看單位時(shí)間內(nèi)的平均請(qǐng)求處理數(shù)。如果你查看單個(gè)請(qǐng)求的處理時(shí)間，你不會(huì)看到有很大差別，甚至異步可能更慢，因?yàn)楫惒接懈嗖l(fā)的任務(wù)在爭(zhēng)奪 CPU。
結(jié)論
希望本文能解答異步代碼的一些困惑和誤解。我希望你能記住以下兩個(gè)關(guān)鍵點(diǎn)：
- 異步應(yīng)用程序只有在高負(fù)載下才會(huì)比同步應(yīng)用程序做得更好
- 多虧了 greenlets，即使你用一般方式寫代碼并使用 Flask 或 Django 之類的傳統(tǒng)框架，也能從異步中受益。
以上就是W3Cschool編程獅關(guān)于Python同步與異步有何不同？的相關(guān)介紹了，希望對(duì)大家有所幫助。
