Categories
程式開發

同步與異步Python有何不同?


你是否聽到人們說過,異步Python代碼比“普通(或同步)Python代碼更快?果真是那樣嗎?

“同步”和“異步”是什麼意思?

Web應用程序通常要處理許多請求,這些請求在很短的時間段內來自不同的客戶端。 為避免處理延遲,必須考慮並行處理多個請求,這通常稱為“並發”。

在本文中,我將繼續使用Web應用程序作為例子,但是要記住還有其它類型的應用程序也從並發完成多個任務中獲益,因此這個討論並不僅僅是針對Web應用程序的。

術語“同步”和“異步”指的是編寫並發應用程序的兩種方式。 所謂的“同步”服務器使用底層操作系統支持的線程和進程來實現這種並發性。 下面是同步部署的一個示意圖:

同步與異步Python有何不同? 1

在這種情況下,我們有5台客戶端,都向應用程序發送請求。 這個應用程序的訪問入口是一個Web服務器,通過將服務分配給一個服務器worker池來充當負載均衡器,這些worker可以實現為進程、線程或者兩者的結合。 這些worker執行負載均衡器分配給他們的請求。 你使用Web應用程序框架(例如Flask或Django)編寫的應用程序邏輯運行在這些worker中。

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

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

一個異步服務器的配置很難畫,但是我會盡力而為:

同步與異步Python有何不同? 2

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

你可能想知道異步任務之間的並行是如何實現的。 這就是有趣的部分,因為一個異步應用程序通過唯一的協同多任務處理來實現這點。 這意味著什麼? 當一個任務需要等待一個外部事件(例如,一個數據庫服務器的響應)時,不會像一個同步的worker那樣等待,而是會告訴循環它需要等待什麼,然後將控制權返回給它。 循環就能夠在這個任務被數據庫阻塞的時候發現另外一個準備就緒的任務。 最終,數據庫將發送一個響應,而那時循環會認為第一個的任務已經準備好再次運行,並將盡快恢復它。

異步任務暫停和恢復執行的這種能力可能在抽像上很難理解。 為了幫助你應用到你已經知道的東西,可以考慮在Python中使用awaityield關鍵字這一方法來實現,但你之後會發現這並不是唯一實現異步任務的方法。

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

在使用一個異步服務器時,為了最大化多CPU的利用率,通常需要創建一個混合方案,增加一個負載均衡器並在每個CPU上運行一個異步服務器,如下圖所示:

同步與異步Python有何不同? 3

Python中實現異步的2種方法

我敢肯定,你知道要在Python中寫一個異步應用程序,你可以使用異步包,這個包是在協程的基礎上實現了所有異步應用程序都需要的暫停和恢復特性。 其中yield關鍵字,以及更新的asyncawait都是asyncio構建異步能力的基礎。

Python生態系統中還有其它基於協程的異步方案,例如三重奏古玩。 還有扭曲的,它是所有協程框架中最古老的,甚至出現得比asyncio都要早。

如果你對編寫異步Web應用程序感興趣,有許多基於協程的異步框架可以選擇,包括aiohttpSanicFastAPI龍捲風

很多人不知道的是,協程只是Python中編寫異步代碼的兩種方法之一。 第二種方法是基於一個叫做綠葉的庫,你可以用pip安裝它。 Greenlets和協程類似,它們也允許一個Python函數暫停執行並稍後恢復,但是它們實現這點的方式完全不同,這意味著Python中的異步生態系統分成兩大類。

協程與greenlets之間針對異步開發最有意思的區別是,前者需要Python語言特定的關鍵字和特性才能工作,而後者並不需要。 我的意思是,基於協程的應用程序需要使用一種特定的語法來書寫,而基於greenlet的應用程序看起來幾乎和普通Python代碼一樣。 這非常酷,因為在某些情況下,這讓同步代碼可以被異步執行,這是諸如asyncio之類的基於協程的方案做不到的。

那麼在greenlet方面,跟asyncio對等的庫有哪些? 我知道3個基於greenlet的異步包:通風事件我的英雄,儘管最後一個更像是一個Web服務器而不是一個通用的異步庫。 它們都有自己的異步循環實現,而且它們都提供了一個有趣的“monkey-patching”功能,取代了Python標準庫中的阻塞函數,例如那些執行網絡和線程的函數,並基於greenlets實現了等效的非阻塞版本。 如果你有一些同步代碼想要異步運行,這些包會對你有所幫助。

據我所知,唯一明確支持greenlet的Web框架只有燒瓶。 這個框架會自動監測,當你想要運行在一個greenlet Web服務器上時,它會自我進行相應調整,而無需進行任何配置。 這麼做時,你需要注意不要調用阻塞函數,或者,如果你要調用阻塞函數,最好用猴子補丁來“修復”那些阻塞函數。

但是,Flask並不是唯一受益於greenlets的框架。 其它Web框架,例如Django的瓶子,雖然沒有greenlets,但也可以通過結合一個greenlet Web服務器並使用monkey-patching修復阻塞函數的方式來異步運行。

異步比同步更快嗎?

對於同步和異步應用程序的性能,存在著一個廣泛的誤解——異步應用程序比同步應用程序快得多。

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

上下文切換

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

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

高度優化的異步循環比操作系統在進行上下文切換方面更有效率,但根據我的經驗,要想看到實際的效率提升,你運行的並發量必須非常大。 對於大部分應用程序,我不認為同步和異步上下文切換之間的性能差距有多明顯。

擴展性

我認為異步更快這個神話的來源是,異步應用程序通常會更有效地使用CPU、能更好地進行擴展並且擴展方式比同步更靈活。

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

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

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

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

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

  • 存在高負載(沒有高負載,訪問的高並發性就沒有優勢)
  • 任務是I/O綁定的(如果任務是CPU綁定的,那麼超過CPU數目的並發並沒有幫助)
  • 你查看單位時間內的平均請求處理數。 如果你查看單個請求的處理時間,你不會看到有很大差別,甚至異步可能更慢,因為異步有更多並發的任務在爭奪CPU。

結論

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

  • 異步應用程序只有在高負載下才會比同步應用程序做得更好
  • 多虧了greenlets,即使你用一般方式寫代碼並使用Flask或Django之類的傳統框架,也能從異步中受益。

如果你想要了解更多關於異步系統如何工作的細節,可以查看YouTube上我在PyCon的演講入門的異步Python

作者介紹:

Miguel Grinberg是一名軟件工程師、攝影師和電影製作人,住在愛爾蘭的德羅赫拉。 你可以在臉書Google+領英Github推特關注他。

原文鏈接:

https://blog.miguelgrinberg.com/post/sync-vs-async-python-what-is-the-difference