539      小米  小米6

談談Python協程技術的演進

一、引言

1. 存儲器山

存儲器山是 Randal Bryant 在《深入理解計算機係統》一書中提出的概念。

基於成本、效率的考量，計算機存儲器被設計成多級金字塔結構，塔頂是速度最快、成本最高的 CPU 內部的寄存器(一般幾 KB)與高速緩存，塔底是成本最低、速度最慢的廣域網雲存儲(如百度雲免費 2T )

存儲器山的指導意義在於揭示了良好設計程序的必要條件是需要有優秀的局部性：

• 時間局部性：相同時間內，訪問同一地址次數越多，則時間局部性表現越佳;
• 空間局部性：下一次訪問的存儲器地址與上一次的訪問過的存儲器地址位置鄰近;

2. cpu的時間觀

我們將一個普通的 2.6GHz 的 CPU 的延遲時間放大到人能體驗的尺度上(數據來自微信公眾號 駒說碼事)：在存儲器頂層執行單條寄存器指令的時間為1秒鍾;從第五層磁盤讀 1MB 數據卻需要一年半;ping 不同的城域網主機，網絡包需要走 12.5 年。

如果程序發送了一個 HTTP 包後便阻塞在同步等待響應的過程上，計算機不得不傻等 12 年後的那個響應再處理別的事情，低下的硬件利用率必然導致低下的程序效率。

3. 同步編程

從以上數據可以看出，內存數據讀寫、磁盤尋道讀寫、網卡讀寫等操作都是 I/O 操作，同步程序的瓶頸在於漫長的 I/O 等待，想要提高程序效率必須減少 I/O 等待時間，從提高程序的局部性著手。

同步編程的改進方式有多進程、多線程，但對於 c10k 問題都不是良好的解決方案，多進程的方式存在操作係統可調度進程數量上限較低，進程間上下文切換時間過長，進程間通信較為複雜。

而 Python 的多線程方式，由於存在眾所周知的 GIL 鎖，性能提升並不穩定，僅能滿足成百上千規模的 I/O 密集型任務，多線程還有一個缺點是由操作係統進行搶占式調度存在競態條件，可能需要引入了鎖與隊列等保障原子性操作的工具。

4. 異步編程

說到異步非阻塞調用，目前的代名詞都是 epoll 與 kqueue，select/poll 由於效率問題基本已被取代。

epoll 是04年 Linux2.6 引入內核的一種 I/O 事件通知機製，它的作用是將大量的文件描述符托管給內核，內核將最底層的 I/O 狀態變化封裝成讀寫事件，這樣就避免了由程序員去主動輪詢狀態變化的重複工作，程序員將回調函數注冊到 epoll 的狀態上，當檢測到相對應文件描述符產生狀態變化時，就進行函數回調。

事件循環是異步編程的底層基石。

上圖是簡單的EventLoop的實現原理，

• 用戶創建了兩個socket連接，將係統返回的兩個文件描述符fd3、fd4通過係統調用在epoll上注冊讀寫事件;
• 當網卡解析到一個tcp包時，內核根據五元組找到相應到文件描述符，自動觸發其對應的就緒事件狀態，並將該文件描述符添加到就緒鏈表中。
• 程序調用epoll.poll()，返回可讀寫的事件集合。
• 對事件集合進行輪詢，調用回調函數等
• 一輪事件循環結束，循環往複。

epoll 並非銀彈，從圖中可以觀察到，如果用戶關注的層次很低，直接操作epoll去構造維護事件的循環，從底層到高層的業務邏輯需要層層回調，造成callback hell，並且可讀性較差。所以，這個繁瑣的注冊回調與回調的過程得以封裝，並抽象成EventLoop。EventLoop屏蔽了進行epoll係統調用的具體操作。對於用戶來說，將不同的I/O狀態考量為事件的觸發，隻需關注更高層次下不同事件的回調行為。諸如libev, libevent之類的使用C編寫的高性能異步事件庫已經取代這部分瑣碎的工作。

在Python框架裏一般會見到的這幾種事件循環：

• libevent/libev: Gevent(greenlet+前期libevent，後期libev)使用的網絡庫，廣泛應用;
• tornado: tornado框架自己實現的IOLOOP;
• picoev: meinheld(greenlet+picoev)使用的網絡庫，小巧輕量，相較於libevent在數據結構和事件檢測模型上做了改進，所以速度更快。但從github看起來已經年久失修，用的人不多。
• uvloop: Python3時代的新起之秀。Guido操刀打造了asyncio庫，asyncio可以配置可插拔的event loop，但需要滿足相關的API要求，uvloop繼承自libuv，將一些低層的結構體和函數用Python對象包裝。目前Sanic框架基於這個庫

5. 協程

EventLoop簡化了不同平台上的事件處理，但是處理事件觸發時的回調依然很麻煩，響應式的異步程序編寫對程序員的心智是一項不小的麻煩。

因此，協程被引入來替代回調以簡化問題。協程模型主要在在以下方麵優於回調模型：

• 以近似同步代碼的編程模式取代異步回調模式，真實的業務邏輯往往是同步線性推演的，因此，這種同步式的代碼寫起來更加容易。底層的回調依然是callback hell，但這部分髒活累活已經轉交給編譯器與解釋器去完成，程序員不易出錯。
• 異常處理更加健全，可以複用語言內的錯誤處理機製，回調方式。而傳統異步回調模式需要自己判定成功失敗，錯誤處理行為複雜化。
• 上下文管理簡單化，回調方式代碼上下文管理嚴重依賴閉包，不同的回調函數之間相互耦合，割裂了相同的上下文處理邏輯。協程直接利用代碼的執行位置來表示狀態，而回調則是維護了一堆數據結構來處理狀態。
• 方便處理並發行為，協程的開銷成本很低，每一個協程僅有一個輕巧的用戶態棧空間。

6. EventLoop與協程的發展史

04年，event-driven 的 nginx 誕生並快速傳播，06年以後從俄語區國家擴散到全球。同時期，EventLoop 變得具象化與多元化，相繼在不同的編程語言實現。

近十年以來，後端領域內古老的子例程與事件循環得到結合，協程(協作式子例程)快速發展，並也革新與誕生了一些語言，比如 golang 的 goroutine，luajit 的 coroutine，Python 的 gevent,erlang 的 process，scala 的 actor 等。

就不同語言中麵向並發設計的協程實現而言，Scala 與 Erlang 的 Actor 模型、Golang 中的 goroutine 都較 Python 更為成熟，不同的協程使用通信來共享內存，優化了競態、衝突、不一致性等問題。然而，根本的理念沒有區別，都是在用戶態通過事件循環驅動實現調度。

由於曆史包袱較少，後端語言上的各種異步技術除 Python Twisted 外基本也沒有 callback hell 的存在。其他的方案都已經將 callback hell 的過程進行封裝，交給庫代碼、編譯器、解釋器去解決。

有了協程，有了事件循環庫，傳統的 C10K 問題已經不是挑戰並已經上升到了 C1M 問題。

二、Gevent

Python2 時代的協程技術主要是 Gevent，另一個 meinheld 比較小眾。Gevent 有褒有貶，負麵觀點認為它的實現不夠 Pythonic，脫離解釋器獨自實現了黑盒的調度器，monkey patch 讓不了解的用戶產生混淆。正麵觀點認為正是這樣才得以屏蔽所有的細節，簡化使用難度。

Gevent 基於 Greenlet 與 Libev，greenlet 是一種微線程或者協程，在調度粒度上比 PY3 的協程更大。greenlet 存在於線程容器中，其行為類似線程，有自己獨立的棧空間，不同的 greenlet 的切換類似操作係統層的線程切換。

greenlet.hub 也是一個繼承於原生 greenlet 的對象，也是其他 greenlet 的父節點，它主要負責任務調度。當一個 greenlet 協程執行完部分例程後到達斷點，通過 greenlet.switch() 向上轉交控製權給 hub 對象，hub 執行上下文切換的操作：從寄存器、高速緩存中備份當前 greenlet 的棧內容到內存中，並將原來備份的另一個 greenlet 棧數據恢複到寄存器中。

hub 對象內封裝了一個 loop 對象，loop 負責封裝 libev 的相關操作並向上提供接口，所有 greenlet 在通過 loop 驅動的 hub 下被調度。

三、從yield到async/await

1. 生成器的進化

在 Python2.2 中，第一次引入了生成器，生成器實現了一種惰性、多次取值的方法，此時還是通過 next 構造生成迭代鏈或 next 進行多次取值。

直到在 Python2.5 中，yield 關鍵字被加入到語法中，這時，生成器有了記憶功能，下一次從生成器中取值可以恢複到生成器上次 yield 執行的位置。

之前的生成器都是關於如何構造迭代器，在 Python2.5 中生成器還加入了 send 方法，與 yield 搭配使用。

我們發現，此時，生成器不僅僅可以 yield 暫停到一個狀態，還可以往它停止的位置通過 send 方法傳入一個值改變其狀態。

舉一個簡單的示例，主要熟悉 yield 與 send 與外界的交互流程：

1. def jump_range(up_to): 
2.     step = 0 
3.     while step < up_to: 
4.       jump = yield step 
5.       print("jump", jump) 
6.       if jump is None: 
7.           jump = 1 
8.           step += jump 
9.       print("step", step) 
10.  
11. if __name__ == '__main__': 
12.     iterator = jump_range(10) 
13.     print(next(iterator))  # 0 
14.     print(iterator.send(4))  # jump4; step4; 4 
15.     print(next(iterator))  # jump None; step5; 5 
16.     print(iterator.send(-1)) # jump -1; step4; 4 

在 Python3.3 中，生成器又引入了 yield from 關鍵字，yield from 實現了在生成器內調用另外生成器的功能，可以輕易的重構生成器，比如將多個生成器連接在一起執行。

1. def gen_3(): 
2.     yield 3 
3.  
4. def gen_234(): 
5.     yield 2 
6.     yield from gen_3() 
7.     yield 4 
8.  
9. def main(): 
10.     yield 1 
11.     yield from gen_234() 
12.     yield 5 
13.  
14. for element in main(): 
15.     print(element)  # 1,2,3,4,5 

從圖中可以看出 yield from 的特點。使用 itertools.chain 可以以生成器為最小組合子進行鏈式組合，使用 itertools.cycle 可以對單獨一個生成器首尾相接，構造一個循環鏈。

使用 yield from 時可以在生成器中從其他生成器 yield 一個值，這樣不同的生成器之間可以互相通信，這樣構造出的生成鏈更加複雜，但生成鏈最小組合子的粒度卻精細至單個 yield 對象。

2. 短暫的asynico.coroutine 與yield from

有了Python3.3中引入的yield from 這項工具，Python3.4 中新加入了asyncio庫，並提供了一個默認的event loop。Python3.4有了足夠的基礎工具進行異步並發編程。

並發編程同時執行多條獨立的邏輯流，每個協程都有獨立的棧空間，即使它們是都工作在同個線程中的。以下是一個示例代碼：

1. import asyncio 
2. import aiohttp 
3.  
4. @asyncio.coroutine 
5. def fetch_page(session, url): 
6.     response = yield from session.get(url) 
7.     if response.status == 200: 
8.         text = yield from response.text() 
9.         print(text) 
10. loop = asyncio.get_event_loop() 
11.  
12. session = aiohttp.ClientSession(looploop=loop) 
13.  
14. tasks = [ 
15.     asyncio.ensure_future( 
16.        fetch_page(session, "https://bigsec.com/products/redq/")), 
17.     asyncio.ensure_future( 
18.        fetch_page(session, "https://bigsec.com/products/warden/")) 
19. ] 
20.  
21. loop.run_until_complete(asyncio.wait(tasks)) 
22. session.close() 
23. loop.close() 

在 Python3.4 中，asyncio.coroutine 裝飾器是用來將函數轉換為協程的語法，這也是 Python 第一次提供的生成器協程 。隻有通過該裝飾器，生成器才能實現協程接口。使用協程時，你需要使用 yield from 關鍵字將一個 asyncio.Future 對象向下傳遞給事件循環，當這個 Future 對象還未就緒時，該協程就暫時掛起以處理其他任務。一旦 Future 對象完成，事件循環將會偵測到狀態變化，會將 Future 對象的結果通過 send 方法方法返回給生成器協程，然後生成器恢複工作。

在以上的示例代碼中，首先實例化一個 eventloop，並將其傳遞給 aiohttp.ClientSession 使用，這樣 session 就不用創建自己的事件循環。

此處顯式的創建了兩個任務，隻有當 fetch_page 取得 api.bigsec.com 兩個 url 的數據並打印完成後，所有任務才能結束，然後關閉 session 與 loop，釋放連接資源。

當代碼運行到 response = yield from session.get(url)處，fetch_page 協程被掛起，隱式的將一個 Future 對象傳遞給事件循環，隻有當 session.get() 完成後，該任務才算完成。

session.get() 內部也是協程，其數據傳輸位於在存儲器山最慢的網絡層。當 session.get 完成時，取得了一個 response 對象，再傳遞給原來的 fetch_page 生成器協程，恢複其工作狀態。

為了提高速度，此處 get 方法將取得 http header 與 body 分解成兩次任務，減少一次性傳輸的數據量。response.text() 即是異步請求 http body。

使用 dis 庫查看 fetch_page 協程的字節碼，GET_YIELD_FROM_ITER 是 yield from 的操作碼:

1. In [4]: import dis 
2.  
3. In [5]: dis.dis(fetch_page) 
4.   0 LOAD_FAST 0 (session) 
5.   2 LOAD_ATTR 0 (get) 
6.   4 LOAD_FAST 1 (url) 
7.   6 CALL_FUNCTION 1 
8.   8 GET_YIELD_FROM_ITER 
9.   10 LOAD_CONST 0 (None) 
10.   12 YIELD_FROM 
11.   14 STORE_FAST 2 (response) 
12.  
13.   16 LOAD_FAST 2 (response) 
14.   18 LOAD_ATTR 1 (status) 
15.   20 LOAD_CONST 1 (200) 
16.   22 COMPARE_OP 2 (==) 
17.   24 POP_JUMP_IF_FALSE 48 
18.  
19.   26 LOAD_FAST 2 (response) 
20.   28 LOAD_ATTR 2 (text) 
21.   30 CALL_FUNCTION 0 
22.   32 GET_YIELD_FROM_ITER 
23.   34 LOAD_CONST 0 (None) 
24.   36 YIELD_FROM 
25.   38 STORE_FAST 3 (text) 
26.  
27.   40 LOAD_GLOBAL 3 (print) 
28.   42 LOAD_FAST 3 (text) 
29.   44 CALL_FUNCTION 1 
30.   46 POP_TOP 
31.   >> 48 LOAD_CONST 0 (None) 
32.   50 RETURN_VALUE 

3. async與 await關鍵字

Python3.5 中引入了這兩個關鍵字用以取代 asyncio.coroutine 與 yield from，從語義上定義了原生協程關鍵字，避免了使用者對生成器協程與生成器的混淆。這個階段(3.0-3.4)使用 Python 的人不多，因此曆史包袱不重，可以進行一些較大的革新。

await 的行為類似 yield from，但是它們異步等待的對象並不一致，yield from 等待的是一個生成器對象，而await接收的是定義了__await__方法的 awaitable 對象。

在 Python 中，協程也是 awaitable 對象，collections.abc.Coroutine 對象繼承自 collections.abc.Awaitable。

因此，將上一小節的示例代碼改寫成：

1. import asyncio 
2. import aiohttp 
3.  
4. async def fetch_page(session, url): 
5.     response = await session.get(url) 
6.     if response.status == 200: 
7.         text = await response.text() 
8.         print(text) 
9.  
10. loop = asyncio.get_event_loop() 
11. session = aiohttp.ClientSession(looploop=loop) 
12.  
13. tasks = [ 
14.     asyncio.ensure_future( 
15.         fetch_page(session, "https://bigsec.com/products/redq/")), 
16.     asyncio.ensure_future( 
17.         fetch_page(session, "https://bigsec.com/products/warden/")) 
18. ] 
19. loop.run_until_complete(asyncio.wait(tasks)) 
20. session.close() 
21. loop.close() 

從 Python 語言發展的角度來說，async/await 並非是多麼偉大的改進，隻是引進了其他語言中成熟的語義，協程的基石還是在於 eventloop 庫的發展，以及生成器的完善。從結構原理而言，asyncio 實質擔當的角色是一個異步框架，async/await 是為異步框架提供的 API，因為使用者目前並不能脫離 asyncio 或其他異步庫使用 async/await 編寫協程代碼。即使用戶可以避免顯式地實例化事件循環，比如支持 asyncio/await 語法的協程網絡庫 curio，但是脫離了 eventloop 如心髒般的驅動作用，async/await 關鍵字本身也毫無作用。

四、async/await的使用

1. Future

不用回調方法編寫異步代碼後，為了獲取異步調用的結果，引入一個 Future 未來對象。Future 封裝了與 loop 的交互行為，add_done_callback 方法向 epoll 注冊回調函數，當 result 屬性得到返回值後，會運行之前注冊的回調函數，向上傳遞給 coroutine。但是，每一個角色各有自己的職責，用 Future 向生成器 send result 以恢複工作狀態並不合適，Future 對象本身的生存周期比較短，每一次注冊回調、產生事件、觸發回調過程後工作已經完成。所以這裏又需要在生成器協程與 Future 對象中引入一個新的對象 Task，對生成器協程進行狀態管理。

2. Task

Task，顧名思義，是維護生成器協程狀態處理執行邏輯的的任務，Task 內的_step 方法負責生成器協程與 EventLoop 交互過程的狀態遷移:向協程 send 一個值，恢複其工作狀態，協程運行到斷點後，得到新的未來對象，再處理 future 與 loop 的回調注冊過程。

3. Loop

事件循環的工作方式與用戶設想存在一些偏差，理所當然的認知應是每個線程都可以有一個獨立的 loop。但是在運行中，在主線程中才能通過 asyncio.get_event_loop() 創建一個新的 loop，而在其他線程時，使用 get_event_loop() 卻會拋錯，正確的做法應該是 asyncio.set_event_loop() 進行當前線程與 loop 的顯式綁定。由於 loop 的運作行為並不受 Python 代碼的控製，所以無法穩定的將協程拓展到多線程中運行。

協程在工作時，並不了解是哪個 loop 在對其調度，即使調用 asyncio.get_event_loop() 也不一定能獲取到真正運行的那個 loop。因此在各種庫代碼中，實例化對象時都必須顯式的傳遞當前的 loop 以進行綁定。

4. 另一個Future

Python 裏另一個 Future 對象是 concurrent.futures.Future，與 asyncio.Future 互不兼容，但容易產生混淆。concurrent.futures 是線程級的 Future 對象，當使用 concurrent.futures.Executor 進行多線程編程時用於在不同的 thread 之間傳遞結果。

5. 現階段asyncio生態發展的困難

• 由於這兩個關鍵字在2014年發布的Python3.5中才被引入，發展曆史較短，在Python2與Python3割裂的大環境下，生態環境的建立並不完善;
• 對於使用者來說，希望的邏輯是引入一個庫然後調用並獲取結果，並不關心第三方庫的內部邏輯。然而使用協程編寫異步代碼時需要處理與事件循環的交互。對於異步庫來說，其對外封裝性並不能達到同步庫那麼高。異步編程時，用戶通常隻會選擇一個第三方庫來處理所有HTTP邏輯。但是不同的異步實現方法不一致，互不兼容，分歧阻礙了社區壯大;
• 異步代碼雖然快，但不能阻塞，一旦阻塞整個程序失效。使用多線程或多進程的方式將調度權交給操作係統，未免不是一種自我保護;

6. 一些個人看法

其實說了這麼多，個人覺得 asyncio 雖然更加優雅，卻實際使用上並不是像表麵看起來的那麼美好。首先，它不是特別的快(據說比 gevent 快一倍)，卻引入了更多的複雜性，而且從錯誤信息 debug 更加困難。其次，這套解決方案並不成熟，最近 3.4、3.5、3.6 的三個版本，協程也有各種的細節變化，也變得越來越複雜，程序員必須隨時關注語言的變化才能同步。令人疑惑的是為什麼 Python 一定要堅持用生成器來實現協程，最後又將生成器與協程進行新老劃斷，細節卻未得到屏蔽?以目前的成熟度來看，當你寫協程代碼時，必須先去理解協程、生成器的區別，future 對象與 task 對象的職能，loop 的作用。總之，目前在生產環境中使用 asyncio 技術棧來解決問題並不穩定，這個生態還需要持久的發展才能成熟。

作為程序員，在一門語言上深入同樣可以帶來知識的廣度。不同語言有不同的性格，合適的工具解決合適的問題，而以一名 Python 程序員的視角來看，大可不必堅持寄希望於 asyncio 解決 Python 的性能問題，把在縱向上搞懂 asyncio 和這一套協程細節所需的時間拿來橫向學習 Golang，尋求更合適更簡單的解決方案，代碼也可以上線了。

本文作者：Coding Crush

來源：51CTO

最後更新：2017-11-02 11:03:49

  上一篇：  日常開發常用js日期方法

  下一篇：  大數據相關總結（待續）