你是否聽到人們說過，異步Python代碼比普通（或同步）Python代碼更快？果真是那樣嗎？

1、“同步”和“異步”是什么意思？

Web應(yīng)用程序通常要處理許多請求，這些請求在很短的時間段內(nèi)來自不同的客戶端。為避免處理延遲，必須考慮并行處理多個請求，這通常稱為“并發(fā)”。

在本文中，我將繼續(xù)使用Web應(yīng)用程序作為例子，但是要記住還有其它類型的應(yīng)用程序也從并發(fā)完成多個任務(wù)中獲益，因此這個討論并不僅僅是針對Web應(yīng)用程序的。

術(shù)語“同步”和“異步”指的是編寫并發(fā)應(yīng)用程序的兩種方式。所謂的“同步”服務(wù)器使用底層操作系統(tǒng)支持的線程和進程來實現(xiàn)這種并發(fā)性。下面是同步部署的一個示意圖：

在這種情況下，我們有5臺客戶端，都向應(yīng)用程序發(fā)送請求。這個應(yīng)用程序的訪問入口是一個Web服務(wù)器，通過將服務(wù)分配給一個服務(wù)器worker池來充當(dāng)負(fù)載均衡器，這些worker可以實現(xiàn)為進程、線程或者兩者的結(jié)合。這些worker執(zhí)行負(fù)載均衡器分配給他們的請求。你使用Web應(yīng)用程序框架（如Flask或Django）編寫的應(yīng)用程序邏輯運行在這些worker中。

這種類型的方案對于有多個CPU的服務(wù)器比較好，因為你可以將worker的數(shù)量設(shè)置為CPU的數(shù)量，這樣你就能均衡地利用你的處理器核心，而單個Python進程由于全局解釋器鎖（GIL）的限制無法實現(xiàn)這一點。

在缺點方面，上面的示意圖也清楚展示了這種方案的主要局限。我們有5個客戶端，卻只有4個worker。如果這5個客戶端在同一時間都發(fā)送請求，那么負(fù)載均衡器會將某一個客戶端之外的所有請求發(fā)送到worker池，而剩下的請求不得不保留在一個隊列中，等待有worker變得可用。因此，五分之四的請求會立即響應(yīng)，而剩下的五分之一需要等一會兒。服務(wù)器優(yōu)化的一個關(guān)鍵就在于選擇適當(dāng)數(shù)量的worker來防止或最小化給定預(yù)期負(fù)載的請求阻塞。

一個異步服務(wù)器的配置很難畫，但是我會盡力而為：

這種類型的服務(wù)器運行在單個進程中，通過循環(huán)控制。這個循環(huán)是一個非常有效率的任務(wù)管理器和調(diào)度器，創(chuàng)建任務(wù)來執(zhí)行由客戶端發(fā)送的請求。與長期存在的服務(wù)器worker不同，異步任務(wù)是由循環(huán)創(chuàng)建，用來處理某個特定的請求，當(dāng)那個請求完成時，該任務(wù)也會被銷毀。任何時候，一臺異步服務(wù)器都會有上百或上千個活躍的任務(wù)，它們都在循環(huán)的管理下執(zhí)行自己的工作。

你可能想知道異步任務(wù)之間的并行是如何實現(xiàn)的。這就是有趣的部分，因為一個異步應(yīng)用程序通過唯一的協(xié)同多任務(wù)處理來實現(xiàn)這點。這意味著什么？當(dāng)一個任務(wù)需要等待一個外部事件（例如一個數(shù)據(jù)庫服務(wù)器的響應(yīng)）時，不會像一個同步的worker那樣等待，而是會告訴循環(huán)它需要等待什么，然后將控制權(quán)返回給它。循環(huán)就能夠在這個任務(wù)被數(shù)據(jù)庫阻塞的時候發(fā)現(xiàn)另外一個準(zhǔn)備就緒的任務(wù)。最終，數(shù)據(jù)庫將發(fā)送一個響應(yīng)，而那時循環(huán)會認(rèn)為第一個的任務(wù)已經(jīng)準(zhǔn)備好再次運行，并將盡快恢復(fù)它。

異步任務(wù)暫停和恢復(fù)執(zhí)行的這種能力可能在抽象上很難理解。為了幫助你應(yīng)用到你已經(jīng)知道的東西，可以考慮在Python中使用await或yield關(guān)鍵字這一方法來實現(xiàn)，但你之后會發(fā)現(xiàn)這并不是唯一實現(xiàn)異步任務(wù)的方法。

一個異步應(yīng)用程序完全運行在單個進程或線程中，這可以說是令人吃驚的。當(dāng)然，這種類型的并發(fā)需要遵循一些規(guī)則，因此你不能讓一個任務(wù)占用CPU太長時間，否則，剩余的任務(wù)會被阻塞。為了異步執(zhí)行，所有的任務(wù)需要定時主動暫停并將控制權(quán)返還給循環(huán)。為了從異步方式獲益，一個應(yīng)用程序需要有經(jīng)常被I/O阻塞的任務(wù)，并且沒有太多CPU工作。Web應(yīng)用程序通常非常適合，特別是當(dāng)它們需要處理大量客戶端請求時。

在使用一個異步服務(wù)器時，為了最大化多CPU的利用率，通常需要創(chuàng)建一個混合方案，增加一個負(fù)載均衡器并在每個CPU上運行一個異步服務(wù)器，如下圖所示：

2、Python中實現(xiàn)異步的2種方法

我敢肯定，你知道要在Python中寫一個異步應(yīng)用程序，你可以使用asyncio package，這個包是在協(xié)程的基礎(chǔ)上實現(xiàn)了所有異步應(yīng)用程序都需要的暫停和恢復(fù)特性。其中yield關(guān)鍵字，以及更新的async和await都是asyncio構(gòu)建異步能力的基礎(chǔ)。

Python生態(tài)系統(tǒng)中還有其它基于協(xié)程的異步方案，例如Trio和Curio。還有Twisted，它是所有協(xié)程框架中最古老的，甚至出現(xiàn)得比asyncio都要早。如果你對編寫異步Web應(yīng)用程序感興趣，有許多基于協(xié)程的異步框架可以選擇，包括aiohttp、sanic、FastAPI和Tornado。

很多人不知道的是，協(xié)程只是Python中編寫異步代碼的兩種方法之一。第二種方法是基于一個叫做greenlet的庫，你可以用pip安裝它。Greenlets和協(xié)程類似，它們也允許一個Python函數(shù)暫停執(zhí)行并稍后恢復(fù)，但它們實現(xiàn)這點的方式完全不同，這意味著Python中的異步生態(tài)系統(tǒng)分成兩大類。

協(xié)程與greenlets之間針對異步開發(fā)最有意思的區(qū)別是，前者需要Python語言特定的關(guān)鍵字和特性才能工作，而后者并不需要。我的意思是，基于協(xié)程的應(yīng)用程序需要使用一種特定的語法來書寫，而基于greenlet的應(yīng)用程序看起來幾乎和普通Python代碼一樣。這非常酷，因為在某些情況下，這讓同步代碼可以被異步執(zhí)行，這是諸如asyncio之類的基于協(xié)程的方案做不到的。

那么在greenlet方面，跟asyncio對等的庫有哪些？我知道3個基于greenlet的異步包：Gevent、Eventlet和Meinheld，盡管最后一個更像是一個Web服務(wù)器而不是一個通用的異步庫。它們都有自己的異步循環(huán)實現(xiàn)，而且它們都提供了一個有趣的“monkey-patching”功能，取代了Python標(biāo)準(zhǔn)庫中的阻塞函數(shù)，例如那些執(zhí)行網(wǎng)絡(luò)和線程的函數(shù)，并基于greenlets實現(xiàn)了等效的非阻塞版本。如果你有一些同步代碼想要異步運行，這些包會對你有所幫助。

據(jù)我所知，唯一明確支持greenlet的Web框架只有Flask。這個框架會自動監(jiān)測，當(dāng)你想要運行在一個greenlet Web服務(wù)器上時，它會自我進行相應(yīng)調(diào)整，而無需進行任何配置。這么做時，你需要注意不要調(diào)用阻塞函數(shù)，或者，如果你要調(diào)用阻塞函數(shù)，最好用猴子補丁來“修復(fù)”那些阻塞函數(shù)。

但是，F(xiàn)lask并不是唯一受益于greenlets的框架。其它Web框架，例如Django和Bottle，雖然沒有g(shù)reenlets，但也可以通過結(jié)合一個greenlet Web服務(wù)器并使用monkey-patching修復(fù)阻塞函數(shù)的方式來異步運行。

3、異步比同步更快嗎？

對于同步和異步應(yīng)用程序的性能，存在著一個廣泛的誤解——異步應(yīng)用程序比同步應(yīng)用程序快得多。

對此，我需要澄清一下。無論是用同步方式寫，還是用異步方式寫，Python代碼運行速度是幾乎相同的。除了代碼，有兩個因素能夠影響一個并發(fā)應(yīng)用程序的性能：上下文切換和可擴展性。

（1）上下文切換

在所有運行的任務(wù)間公平地共享CPU所需的工作，稱為上下文切換，能夠影響應(yīng)用程序的性能。對同步應(yīng)用程序來說，這項工作是由操作系統(tǒng)完成的，而且基本上是一個黑箱，不需要配置或微調(diào)選項。對異步應(yīng)用程序來說，上下文切換是由循環(huán)完成的。

默認(rèn)的循環(huán)實現(xiàn)由asyncio提供，是用Python編寫的，效率不是很高。而uvloop包提供了一個備選的循環(huán)方案，其中部分代碼是用C編寫的來實現(xiàn)更好的性能。Gevent和Meinheld所使用的事件循環(huán)也是用C編寫的。Eventlet用的是Python編寫的循環(huán)。

高度優(yōu)化的異步循環(huán)比操作系統(tǒng)在進行上下文切換方面更有效率，但根據(jù)我的經(jīng)驗，要想看到實際的效率提升，你運行的并發(fā)量必須非常大。對于大部分應(yīng)用程序，我不認(rèn)為同步和異步上下文切換之間的性能差距有多明顯。

（2）擴展性

我認(rèn)為異步更快這個神話的來源是，異步應(yīng)用程序通常會更有效地使用CPU、能更好地進行擴展并且擴展方式比同步更靈活。

如果上面示意圖中的同步服務(wù)器同時收到100個請求，想一下會發(fā)生什么。這個服務(wù)器同時最多只能處理4個請求，因此大部分請求會停留在一個隊列中等待，直到它們被分配一個worker。

與之形成對比的是，異步服務(wù)器會立即創(chuàng)建100個任務(wù)（或者使用混合模式的話，在4個異步worker上每個創(chuàng)建25個任務(wù)）。使用異步服務(wù)器，所有請求都會立即開始處理而不用等待（盡管公平地說，這種方案也還會有其它瓶頸會減慢速度，例如對活躍的數(shù)據(jù)庫連接的限制）。

如果這100個任務(wù)主要使用CPU，那么同步和異步方案會有相似的性能，因為每個CPU運行的速度是固定的，Python執(zhí)行代碼的速度總是相同的，應(yīng)用程序要完成的工作也是相同的。但是，如果這些任務(wù)需要做很多I/O操作，那么同步服務(wù)器只能處理4個并發(fā)請求而不能實現(xiàn)CPU的高利用率。而另一方面，異步服務(wù)器會更好地保持CPU繁忙，因為它是并行地運行所有這100個請求。

你可能會想，為什么你不能運行100個同步worker，那樣，這兩個服務(wù)器就會有相同的并發(fā)能力。要注意，每個worker需要自己的Python解釋器以及與之相關(guān)聯(lián)的所有資源，再加上一份單獨的應(yīng)用程序拷貝及其資源。你的服務(wù)器和應(yīng)用程序的大小將決定你可以運行多少個worker實例，但通常這個數(shù)字不會很大。另一方面，異步任務(wù)非常輕量，都運行在單個worker進程的上下文中，因此具有明顯優(yōu)勢。

綜上所述，只有如下場景時，我們可以說異步可能比同步快：

存在高負(fù)載（沒有高負(fù)載，訪問的高并發(fā)性就沒有優(yōu)勢）；

任務(wù)是I/O綁定的（如果任務(wù)是CPU綁定的，那么超過CPU數(shù)目的并發(fā)并沒有幫助）；

你查看單位時間內(nèi)的平均請求處理數(shù)。如果你查看單個請求的處理時間，你不會看到有很大差別，甚至異步可能更慢，因為異步有更多并發(fā)的任務(wù)在爭奪CPU。

4、結(jié)論

希望本文能解答異步代碼的一些困惑和誤解。我希望你能記住以下兩個關(guān)鍵點：

異步應(yīng)用程序只有在高負(fù)載下才會比同步應(yīng)用程序做得更好；

多虧了greenlets，即使你用一般方式寫代碼并使用Flask或Django之類的傳統(tǒng)框架，也能從異步中受益。
編輯：lyn