<史上最強>深刻理解 Python 異步編程(上)

時間 2019-11-12

原文原文鏈接

前言

不少朋友對異步編程都處於「據說很強大」的認知狀態。鮮有在生產項目中使用它。而使用它的同窗，則大多數都停留在知道如何使用 Tornado、Twisted、Gevent 這類異步框架上，出現各類古怪的問題難以解決。並且使用了異步框架的部分同窗，因爲用法不對，感受它並沒牛逼到哪裏去，因此不少同窗作 Web 後端服務時仍是採用 Flask、Django等傳統的非異步框架。git

從上兩屆 PyCon 技術大會看來，異步編程已經成了 Python 生態下一階段的主旋律。如新興的 Go、Rust、Elixir 等編程語言都將其支持異步和高併發做爲主要「賣點」，技術變化趨勢如此。Python 生態爲不落人後，從2013年起由 Python 之父 Guido 親自操刀主持了Tulip(asyncio)項目的開發。程序員

本系列教程分爲上中下篇，讓讀者深刻理解Python異步編程，解決在使用異步編程中的疑惑，深刻學習Python3中新增的asyncio庫和async/await語法，盡情享受 Python 帶來的簡潔優雅和高效率。github

內容安排

上篇

瞭解異步編程及其緊密相關的概念，如阻塞/非阻塞、同步/異步、併發/並行等
理解異步編程是什麼，以及異步編程的困難之處
理解爲何須要異步編程
熟悉如何從同步阻塞發展到異步非阻塞的
掌握epoll + Callback + Event loop是如何工做的
掌握 Python 是如何逐步從回調到生成器再到原生協程以支持異步編程的
掌握 asyncio 的工做原理

中篇

掌握 asyncio 標準庫基本使用
掌握 asyncio 的事件循環
掌握協程與任務如何使用與管理（如調度與取消調度）
掌握同步原語的使用(Lock、Event、Condition、Queue)
掌握 asyncio 和多進程、多線程結合使用

下篇

理解 GIL 對異步編程的影響
理解 asyncio 踩坑經驗
理解回調、協程、綠程(Green-Thread)、線程對比總結
掌握多進程、多線程、協程各自的適用場景
瞭解 Gevent/libev、uvloop/libuv 與asyncio的區別和聯繫
掌握 Python異步編程的一些指導細則

1 什麼是異步編程

經過學習相關概念，咱們逐步解釋異步編程是什麼。算法

1.1 阻塞

程序未獲得所需計算資源時被掛起的狀態。
程序在等待某個操做完成期間，自身沒法繼續幹別的事情，則稱該程序在該操做上是阻塞的。
常見的阻塞形式有：網絡I/O阻塞、磁盤I/O阻塞、用戶輸入阻塞等。

阻塞是無處不在的，包括CPU切換上下文時，全部的進程都沒法真正幹事情，它們也會被阻塞。（若是是多核CPU則正在執行上下文切換操做的核不可被利用。）編程

1.2 非阻塞

程序在等待某操做過程當中，自身不被阻塞，能夠繼續運行幹別的事情，則稱該程序在該操做上是非阻塞的。
非阻塞並不是在任何程序級別、任何狀況下均可以存在的。
僅當程序封裝的級別能夠囊括獨立的子程序單元時，它纔可能存在非阻塞狀態。

非阻塞的存在是由於阻塞存在，正由於某個操做阻塞致使的耗時與效率低下，咱們纔要把它變成非阻塞的。後端

1.3 同步

不一樣程序單元爲了完成某個任務，在執行過程當中需靠某種通訊方式以協調一致，稱這些程序單元是同步執行的。
例如購物系統中更新商品庫存，須要用「行鎖」做爲通訊信號，讓不一樣的更新請求強制排隊順序執行，那更新庫存的操做是同步的。
簡言之，同步意味着有序。

1.4 異步

爲完成某個任務，不一樣程序單元之間過程當中無需通訊協調，也能完成任務的方式。
不相關的程序單元之間能夠是異步的。
例如，爬蟲下載網頁。調度程序調用下載程序後，便可調度其餘任務，而無需與該下載任務保持通訊以協調行爲。不一樣網頁的下載、保存等操做都是無關的，也無需相互通知協調。這些異步操做的完成時刻並不肯定。
簡言之，異步意味着無序。

上文提到的「通訊方式」一般是指異步和併發編程提供的同步原語，如信號量、鎖、同步隊列等等。咱們需知道，雖然這些通訊方式是爲了讓多個程序在必定條件下同步執行，但正由於是異步的存在，才須要這些通訊方式。若是全部程序都是按序執行，其自己就是同步的，又何需這些同步信號呢？緩存

1.5 併發

併發描述的是程序的組織結構。指程序要被設計成多個可獨立執行的子任務。
以利用有限的計算機資源使多個任務能夠被實時或近實時執行爲目的。

1.6 並行

並行描述的是程序的執行狀態。指多個任務同時被執行。
以利用富餘計算資源（多核CPU）加速完成多個任務爲目的。

併發提供了一種程序組織結構方式，讓問題的解決方案能夠並行執行，但並行執行不是必須的。服務器

1.7 概念總結

並行是爲了利用多核加速多任務完成的進度
併發是爲了讓獨立的子任務都有機會被儘快執行，但不必定能加速總體進度
非阻塞是爲了提升程序總體執行效率
異步是高效地組織非阻塞任務的方式

要支持併發，必須拆分爲多任務，不一樣任務相對而言纔有阻塞/非阻塞、同步/異步。因此，併發、異步、非阻塞三個詞老是如影隨形。網絡

1.8 異步編程

以進程、線程、協程、函數/方法做爲執行任務程序的基本單位，結合回調、事件循環、信號量等機制，以提升程序總體執行效率和併發能力的編程方式。

若是在某程序的運行時，能根據已經執行的指令準確判斷它接下來要進行哪一個具體操做，那它是同步程序，反之則爲異步程序。（無序與有序的區別）數據結構

同步/異步、阻塞/非阻塞並不是水火不容，要看討論的程序所處的封裝級別。例如購物程序在處理多個用戶的瀏覽請求能夠是異步的，而更新庫存時必須是同步的。

1.9 異步之難(nán)

控制不住「計幾」寫的程序，由於其執行順序不可預料，當下正要發生什麼事件不可預料。在並行狀況下更爲複雜和艱難。

因此，幾乎全部的異步框架都將異步編程模型簡化：一次只容許處理一個事件。故而有關異步的討論幾乎都集中在了單線程內。

若是某事件處理程序須要長時間執行，全部其餘部分都會被阻塞。

因此，一旦採起異步編程，每一個異步調用必須「足夠小」，不能耗時過久。如何拆分異步任務成了難題。

程序下一步行爲每每依賴上一步執行結果，如何知曉上次異步調用已完成並獲取結果？
回調（Callback）成了必然選擇。那又須要面臨「回調地獄」的折磨。
同步代碼改成異步代碼，必然破壞代碼結構。
解決問題的邏輯也要轉變，再也不是一條路走到黑，須要精心安排異步任務。

2 苦心異步爲哪般

如上文所述，異步編程面臨諸多難點，Python 之父親自上陣打磨4年才使 asyncio 模塊在Python 3.6中「轉正」，如此苦心爲何？答案只有一個：它值得！下面咱們看看爲什麼而值得。

2.1 CPU的時間觀

咱們將一個 2.6GHz 的 CPU 擬人化，假設它執行一條命令的時間，他它感受上過了一秒鐘。CPU是計算機的處理核心，也是最寶貴的資源，若是有浪費CPU的運行時間，致使其利用率不足，那程序效率必然低下（由於實際上有資源可使效率更高）。

如上圖所示，在千兆網上傳輸2KB數據，CPU感受過了14個小時，若是是在10M的公網上呢？那效率會低百倍！若是在這麼長的一段時間內，CPU只是傻等結果而不能去幹其餘事情，是否是在浪費CPU的青春？

魯迅說，浪費「CPU」的時間等於謀財害命。而兇手就是程序猿。

2.2 面臨的問題

成本問題

若是一個程序不能有效利用一臺計算機資源，那必然須要更多的計算機經過運行更多的程序實例來彌補需求缺口。例如我前不久主導重寫的項目，使用Python異步編程，改版後由原來的7臺服務器削減至3臺，成本驟降57%。一臺AWS m4.xlarge 型通用服務器按需付費實例一年價格約 1.2 萬人民幣。

效率問題

若是不在意錢的消耗，那也會在乎效率問題。當服務器數量堆疊到必定規模後，若是不改進軟件架構和實現，加機器是徒勞，並且運維成本會驟然增長。好比別人家的電商平臺支持6000單/秒支付，而自家在下單量才支撐2000單/秒，在雙十一這種活動的時候，錢送上門也賺不到。

C10k/C10M挑戰

C10k（concurrently handling 10k connections）是一個在1999年被提出來的技術挑戰，如何在一顆1GHz CPU，2G內存，1gbps網絡環境下，讓單臺服務器同時爲1萬個客戶端提供FTP服務。而到了2010年後，隨着硬件技術的發展，這個問題被延伸爲C10M，即如何利用8核心CPU，64G內存，在10gbps的網絡上保持1000萬併發鏈接，或是每秒鐘處理100萬的鏈接。（兩種類型的計算機資源在各自的時代都約爲1200美圓）

成本和效率問題是從企業經營角度講，C10k/C10M問題則是從技術角度出發挑戰軟硬件極限。C10k/C10M 問題得解，成本問題和效率問題迎刃而解。

2.3 解決方案

《約束理論與企業優化》中指出：「除了瓶頸以外，任何改進都是幻覺。」

CPU告訴咱們，它本身很快，而上下文切換慢、內存讀數據慢、磁盤尋址與取數據慢、網絡傳輸慢……總之，離開CPU 後的一切，除了一級高速緩存，都很慢。咱們觀察計算機的組成能夠知道，主要由運算器、控制器、存儲器、輸入設備、輸出設備五部分組成。運算器和控制器主要集成在CPU中，除此以外全是I/O，包括讀寫內存、讀寫磁盤、讀寫網卡全都是I/O。I/O成了最大的瓶頸。

異步程序能夠提升效率，而最大的瓶頸在I/O，業界誕生的解決方案沒出意料：異步I/O吧，異步I/O吧，異步I/O吧吧！

3 異步I/O進化之路

現在，地球上最發達、規模最龐大的計算機程序，莫過於因特網。而從CPU的時間觀中可知，網絡I/O是最大的I/O瓶頸，除了宕機沒有比它更慢的。因此，諸多異步框架都對準的是網絡I/O。

咱們從一個爬蟲例子提及，從因特網上下載10篇網頁。

3.1 同步阻塞方式

最容易想到的解決方案就是依次下載，從創建socket鏈接到發送網絡請求再到讀取響應數據，順序進行。

注：整體耗時約爲4.5秒。（因網絡波動每次測試結果有所變更，本文取屢次平均值）

如上圖所示，blocking_way() 的做用是創建 socket 鏈接，發送HTTP請求，而後從 socket讀取HTTP響應並返回數據。示例中咱們請求了 example.com 的首頁。在sync_way() 執行了10次，即下載 example.com 首頁10次。

在示例代碼中有兩個關鍵點。一是第10行的 sock.connect((‘example.com’, 80))，該調用的做用是向example.com主機的80端口發起網絡鏈接請求。二是第14行、第18行的sock.recv(4096)，該調用的做用是從socket上讀取4K字節數據。

咱們知道，建立網絡鏈接，多久能建立完成不是客戶端決定的，而是由網絡情況和服務端處理能力共同決定。服務端何時返回了響應數據並被客戶端接收到可供程序讀取，也是不可預測的。因此sock.connect()和sock.recv()這兩個調用在默認狀況下是阻塞的。

注：sock.send()函數並不會阻塞過久，它只負責將請求數據拷貝到TCP/IP協議棧的系統緩衝區中就返回，並不等待服務端返回的應答確認。

假設網絡環境不好，建立網絡鏈接須要1秒鐘，那麼sock.connect()就得阻塞1秒鐘，等待網絡鏈接成功。這1秒鐘對一顆2.6GHz的CPU來說，彷彿過去了83年，然而它不能幹任何事情。sock.recv()也是同樣的必須得等到服務端的響應數據已經被客戶端接收。咱們下載10篇網頁，這個阻塞過程就得重複10次。若是一個爬蟲系統天天要下載1000萬篇網頁呢？！

上面說了不少，咱們力圖說明一件事：同步阻塞的網絡交互方式，效率低十分低下。特別是在網絡交互頻繁的程序中。這種方式根本不可能挑戰C10K/C10M。

3.2 改進方式：多進程

在一個程序內，依次執行10次太耗時，那開10個同樣的程序同時執行不就好了。因而咱們想到了多進程編程。爲何會先想到多進程呢？發展脈絡如此。在更早的操做系統（Linux 2.4）及其之前，進程是 OS 調度任務的實體，是面向進程設計的OS。

注：整體耗時約爲 0.6 秒。

改善效果立竿見影。但仍然有問題。整體耗時並無縮減到原來的十分之一，而是九分之一左右，還有一些時間耗到哪裏去了？進程切換開銷。

進程切換開銷不止像「CPU的時間觀」所列的「上下文切換」那麼低。CPU從一個進程切換到另外一個進程，須要把舊進程運行時的寄存器狀態、內存狀態所有保存好，再將另外一個進程以前保存的數據恢復。對CPU來說，幾個小時就乾等着。當進程數量大於CPU核心數量時，進程切換是必然須要的。

除了切換開銷，多進程還有另外的缺點。通常的服務器在可以穩定運行的前提下，能夠同時處理的進程數在數十個到數百個規模。若是進程數量規模更大，系統運行將不穩定，並且可用內存資源每每也會不足。

多進程解決方案在面臨天天須要成百上千萬次下載任務的爬蟲系統，或者須要同時搞定數萬併發的電商系統來講，並不適合。

除了切換開銷大，以及可支持的任務規模小以外，多進程還有其餘缺點，如狀態共享等問題，後文會有說起，此處再也不細究。

3.3 繼續改進：多線程

因爲線程的數據結構比進程更輕量級，同一個進程能夠容納多個線程，從進程到線程的優化由此展開。後來的OS也把調度單位由進程轉爲線程，進程只做爲線程的容器，用於管理進程所需的資源。並且OS級別的線程是能夠被分配到不一樣的CPU核心同時運行的。

注：整體運行時間約0.43秒。

結果符合預期，比多進程耗時要少些。從運行時間上看，多線程彷佛已經解決了切換開銷大的問題。並且可支持的任務數量規模，也變成了數百個到數千個。

可是，多線程仍有問題，特別是Python裏的多線程。首先，Python中的多線程由於GIL的存在，它們並不能利用CPU多核優點，一個Python進程中，只容許有一個線程處於運行狀態。那爲何結果仍是如預期，耗時縮減到了十分之一？

由於在作阻塞的系統調用時，例如sock.connect(),sock.recv()時，當前線程會釋放GIL，讓別的線程有執行機會。可是單個線程內，在阻塞調用上仍是阻塞的。

小提示：Python中 time.sleep 是阻塞的，都知道使用它要謹慎，但在多線程編程中，time.sleep 並不會阻塞其餘線程。

除了GIL以外，全部的多線程還有通病。它們是被OS調度，調度策略是搶佔式的，以保證同等優先級的線程都有均等的執行機會，那帶來的問題是：並不知道下一時刻是哪一個線程被運行，也不知道它正要執行的代碼是什麼。因此就可能存在競態條件。

例如爬蟲工做線程從任務隊列拿待抓取URL的時候，若是多個爬蟲線程同時來取，那這個任務到底該給誰？那就須要用到「鎖」或「同步隊列」來保證下載任務不會被重複執行。

並且線程支持的多任務規模，在數百到數千的數量規模。在大規模的高頻網絡交互系統中，仍然有些吃力。固然，多線程最主要的問題仍是競態條件。

3.4 非阻塞方式

終於，咱們來到了非阻塞解決方案。先來看看最原始的非阻塞如何工做的。

注：整體耗時約4.3秒。

首先注意到兩點，就感受被騙了。一是耗時與同步阻塞至關，二是代碼更復雜。要非阻塞何用？且慢。

上圖第9行代碼sock.setblocking(False)告訴OS，讓socket上阻塞調用都改成非阻塞的方式。以前咱們說到，非阻塞就是在作一件事的時候，不阻礙調用它的程序作別的事情。上述代碼在執行完 sock.connect() 和 sock.recv() 後的確再也不阻塞，能夠繼續往下執行請求準備的代碼或者是執行下一次讀取。

代碼變得更復雜也是上述緣由所致。第11行要放在try語句內，是由於socket在發送非阻塞鏈接請求過程當中，系統底層也會拋出異常。connect()被調用以後，當即能夠往下執行第15和16行的代碼。

須要while循環不斷嘗試 send()，是由於connect()已經非阻塞，在send()之時並不知道 socket 的鏈接是否就緒，只有不斷嘗試，嘗試成功爲止，即發送數據成功了。recv()調用也是同理。

雖然 connect() 和 recv() 再也不阻塞主程序，空出來的時間段CPU沒有空閒着，但並無利用好這空閒去作其餘有意義的事情，而是在循環嘗試讀寫 socket （不停判斷非阻塞調用的狀態是否就緒）。還得處理來自底層的可忽略的異常。也不能同時處理多個 socket 。

而後10次下載任務仍然按序進行。因此整體執行時間和同步阻塞至關。若是非得這樣子，那還不如同步阻塞算了。

3.5 非阻塞改進

3.5.1 epoll

判斷非阻塞調用是否就緒若是 OS 能作，是否是應用程序就能夠不用本身去等待和判斷了，就能夠利用這個空閒去作其餘事情以提升效率。

因此OS將I/O狀態的變化都封裝成了事件，如可讀事件、可寫事件。而且提供了專門的系統模塊讓應用程序能夠接收事件通知。這個模塊就是select。讓應用程序能夠經過select註冊文件描述符和回調函數。當文件描述符的狀態發生變化時，select 就調用事先註冊的回調函數。

select因其算法效率比較低，後來改進成了poll，再後來又有進一步改進，BSD內核改進成了kqueue模塊，而Linux內核改進成了epoll模塊。這四個模塊的做用都相同，暴露給程序員使用的API也幾乎一致，區別在於kqueue 和 epoll 在處理大量文件描述符時效率更高。

鑑於 Linux 服務器的廣泛性，以及爲了追求更高效率，因此咱們經常聽聞被探討的模塊都是 epoll 。

3.5.2 回調(Callback)

把I/O事件的等待和監放任務交給了 OS，那 OS 在知道I/O狀態發生改變後（例如socket鏈接已創建成功可發送數據），它又怎麼知道接下來該幹嗎呢？只能回調。

須要咱們將發送數據與讀取數據封裝成獨立的函數，讓epoll代替應用程序監聽socket狀態時，得告訴epoll：「若是socket狀態變爲能夠往裏寫數據（鏈接創建成功了），請調用HTTP請求發送函數。若是socket 變爲能夠讀數據了（客戶端已收到響應），請調用響應處理函數。」

因而咱們利用epoll結合回調機制重構爬蟲代碼：

此處和前面稍有不一樣的是，咱們將下載不一樣的10個頁面，相對URL路徑存放於urls_todo集合中。如今看看改進在哪。

首先，不斷嘗試send() 和 recv() 的兩個循環被消滅掉了。

其次，導入了selectors模塊，並建立了一個DefaultSelector 實例。Python標準庫提供的selectors模塊是對底層select/poll/epoll/kqueue的封裝。DefaultSelector類會根據 OS 環境自動選擇最佳的模塊，那在 Linux 2.5.44 及更新的版本上都是epoll了。

而後，在第25行和第31行分別註冊了socket可寫事件(EVENT_WRITE)和可讀事件(EVENT_READ)發生後應該採起的回調函數。

雖然代碼結構清晰了，阻塞操做也交給OS去等待和通知了，可是，咱們要抓取10個不一樣頁面，就得建立10個Crawler實例，就有20個事件將要發生，那如何從selector裏獲取當前正發生的事件，而且獲得對應的回調函數去執行呢？

3.5.3 事件循環（Event Loop）

爲了解決上述問題，那咱們只得採用老辦法，寫一個循環，去訪問selector模塊，等待它告訴咱們當前是哪一個事件發生了，應該對應哪一個回調。這個等待事件通知的循環，稱之爲事件循環。

上述代碼中，咱們用stopped全局變量控制事件循環什麼時候中止。當urls_todo消耗完畢後，會標記stopped爲True。

重要的是第49行代碼，selector.select() 是一個阻塞調用，由於若是事件不發生，那應用程序就沒事件可處理，因此就乾脆阻塞在這裏等待事件發生。那能夠推斷，若是隻下載一篇網頁，必定要connect()以後才能send()繼而recv()，那它的效率和阻塞的方式是同樣的。由於不在connect()/recv()上阻塞，也得在select()上阻塞。

因此，selector機制(後文以此稱呼代指epoll/kqueue)是設計用來解決大量併發鏈接的。當系統中有大量非阻塞調用，能隨時產生事件的時候，selector機制才能發揮最大的威力。

下面是如何啓建立10個下載任務和啓動事件循環的：

注：整體耗時約0.45秒。

上述執行結果使人振奮。在單線程內用 事件循環+回調 搞定了10篇網頁同時下載的問題。這，已是異步編程了。雖然有一個for 循環順序地建立Crawler 實例並調用 fetch 方法，可是fetch 內僅有connect()和註冊可寫事件，並且從執行時間明顯能夠推斷，多個下載任務確實在同時進行！

上述代碼異步執行的過程：

建立Crawler 實例；
調用fetch方法，會建立socket鏈接和在selector上註冊可寫事件；
fetch內並沒有阻塞操做，該方法當即返回；
重複上述3個步驟，將10個不一樣的下載任務都加入事件循環；
啓動事件循環，進入第1輪循環，阻塞在事件監聽上；
當某個下載任務EVENT_WRITE被觸發，回調其connected方法，第一輪事件循環結束；
進入第2輪事件循環，當某個下載任務有事件觸發，執行其回調函數；此時已經不能推測是哪一個事件發生，由於有多是上次connected裏的EVENT_READ先被觸發，也多是其餘某個任務的EVENT_WRITE被觸發；（此時，原來在一個下載任務上會阻塞的那段時間被利用起來執行另外一個下載任務了）
循環往復，直至全部下載任務被處理完成
退出事件循環，結束整個下載程序

3.5.4 總結

目前爲止，咱們已經從同步阻塞學習到了異步非阻塞。掌握了在單線程內同時併發執行多個網絡I/O阻塞型任務的黑魔法。並且與多線程相比，連線程切換都沒有了，執行回調函數是函數調用開銷，在線程的棧內完成，所以性能也更好，單機支持的任務規模也變成了數萬到數十萬個。（不過咱們知道：沒有免費午飯，也沒有銀彈。）

部分編程語言中，對異步編程的支持就止步於此（不含語言官方以外的擴展）。須要程序猿直接使用epoll去註冊事件和回調、維護一個事件循環，而後大多數時間都花在設計回調函數上。

經過本節的學習，咱們應該認識到，不論什麼編程語言，但凡要作異步編程，上述的「事件循環+回調」這種模式是逃不掉的，儘管它可能用的不是epoll，也可能不是while循環。若是你找到了一種不屬於「等會兒告訴你」模型的異步方式，請當即給我打電話（注意，打電話是Call）。

爲何咱們在某些異步編程中並無看到 CallBack 模式呢？這就是咱們接下來要探討的問題。本節是學習異步編程的一個終點，也是另外一個起點。畢竟我們講 Python 異步編程，還沒提到其主角協程的用武之地。

4 Python 對異步I/O的優化之路

咱們將在本節學習到 Python 生態對異步編程的支持是如何繼承前文所述的「事件循環+回調」模式演變到asyncio的原生協程模式。

4.1 回調之痛，以終爲始

在第3節中，咱們已經學會了「事件循環+回調」的基本運行原理，能夠基於這種方式在單線程內實現異步編程。也確實可以大大提升程序運行效率。可是，剛纔所學的只是最基本的，然而在生產項目中，要應對的複雜度會大大增長。考慮以下問題：

若是回調函數執行不正常該如何？
若是回調裏面還要嵌套回調怎麼辦？要嵌套不少層怎麼辦？
若是嵌套了多層，其中某個環節出錯了會形成什麼後果？
若是有個數據須要被每一個回調都處理怎麼辦？
……

在實際編程中，上述系列問題不可避免。在這些問題的背後隱藏着回調編程模式的一些缺點：

回調層次過多時代碼可讀性差

def callback_1():

# processing ...

def callback_2():

# processing.....

def callback_3():

# processing ....

def callback_4():

#processing .....

def callback_5():

# processing ......

async_function(callback_5)

async_function(callback_4)

async_function(callback_3)

async_function(callback_2)

async_function(callback_1)

破壞代碼結構

寫同步代碼時，關聯的操做時自上而下運行：

1 2	do_a() do_b()

若是 b 處理依賴於 a 處理的結果，而 a 過程是異步調用，就不知 a 什麼時候能返回值，須要將後續的處理過程以callback的方式傳遞給 a ，讓 a 執行完之後能夠執行 b。代碼變化爲：

1	do_a(do_b())

若是整個流程中所有改成異步處理，而流程比較長的話，代碼邏輯就會成爲這樣：

1	do_a(do_b(do_c(do_d(do_e(do_f(......))))))

上面實際也是回調地獄式的風格，但這不是主要矛盾。主要在於，本來從上而下的代碼結構，要改爲從內到外的。先f，再e，再d，…，直到最外層 a 執行完成。在同步版本中，執行完a後執行b，這是線程的指令指針控制着的流程，而在回調版本中，流程就是程序猿須要注意和安排的。

共享狀態管理困難
回顧第3節爬蟲代碼，同步阻塞版的sock對象從頭使用到尾，而在回調的版本中，咱們必須在Crawler實例化後的對象self裏保存它本身的sock對象。若是不是採用OOP的編程風格，那須要把要共享的狀態接力似的傳遞給每個回調。多個異步調用之間，到底要共享哪些狀態，事先就得考慮清楚，精心設計。
錯誤處理困難
一連串的回調構成一個完整的調用鏈。例如上述的 a 到 f。假如 d 拋了異常怎麼辦？整個調用鏈斷掉，接力傳遞的狀態也會丟失，這種現象稱爲調用棧撕裂。 c 不知道該幹嗎，繼續異常，而後是 b 異常，接着 a 異常。好嘛，報錯日誌就告訴你，a 調用出錯了，但實際是 d 出錯。因此，爲了防止棧撕裂，異常必須以數據的形式返回，而不是直接拋出異常，而後每一個回調中須要檢查上次調用的返回值，以防錯誤吞沒。

若是說代碼風格難看是小事，但棧撕裂和狀態管理困難這兩個缺點會讓基於回調的異步編程很艱難。因此不一樣編程語言的生態都在致力於解決這個問題。才誕生了後來的Promise、Co-routine等解決方案。

Python 生態也以終爲始，秉承着「程序猿沒必要難程序猿」的原則，讓語言和框架開發者苦逼一點，也要讓應用開發者舒坦。在事件循環+回調的基礎上衍生出了基於協程的解決方案，表明做有 Tornado、Twisted、asyncio 等。接下來咱們隨着 Python 生態異步編程的發展過程，深刻理解Python異步編程。

4.2 核心問題

經過前面的學習，咱們清楚地認識到異步編程最大的困難：異步任務什麼時候執行完畢？接下來要對異步調用的返回結果作什麼操做？

上述問題咱們已經經過事件循環和回調解決了。可是回調會讓程序變得複雜。要異步，必回調，又是否有辦法規避其缺點呢？那須要弄清楚其本質，爲何回調是必須的？還有使用回調時克服的那些缺點又是爲了什麼？

答案是程序爲了知道本身已經幹了什麼？正在幹什麼？未來要幹什麼？換言之，程序得知道當前所處的狀態，並且要將這個狀態在不一樣的回調之間延續下去。

多個回調之間的狀態管理困難，那讓每一個回調都能管理本身的狀態怎麼樣？鏈式調用會有棧撕裂的困難，讓回調之間再也不鏈式調用怎樣？不鏈式調用的話，那又如何讓被調用者知道已經完成了？那就讓這個回調通知那個回調如何？並且一個回調，不就是一個待處理任務嗎？

任務之間得相互通知，每一個任務得有本身的狀態。那不就是很古老的編程技法：協做式多任務？然而要在單線程內作調度，啊哈，協程！每一個協程具備本身的棧幀，固然能知道本身處於什麼狀態，協程之間能夠協做那天然能夠通知別的協程。

4.3 協程

協程(Co-routine)，便是協做式的例程。

它是非搶佔式的多任務子例程的歸納，能夠容許有多個入口點在例程中肯定的位置來控制程序的暫停與恢復執行。

例程是什麼？編程語言定義的可被調用的代碼段，爲了完成某個特定功能而封裝在一塊兒的一系列指令。通常的編程語言都用稱爲函數或方法的代碼結構來體現。

4.4 基於生成器的協程

早期的 Pythoner 發現 Python 中有種特殊的對象——生成器（Generator），它的特色和協程很像。每一次迭代之間，會暫停執行，繼續下一次迭代的時候還不會丟失先前的狀態。

爲了支持用生成器作簡單的協程，Python 2.5 對生成器進行了加強(PEP 342)，該加強提案的標題是「Coroutines via Enhanced Generators」。有了PEP 342的加持，生成器能夠經過yield 暫停執行和向外返回數據，也能夠經過send()向生成器內發送數據，還能夠經過throw()向生成器內拋出異常以便隨時終止生成器的運行。

接下來，咱們用基於生成器的協程來重構先前的爬蟲代碼。

4.4.1 將來對象(Future)

不用回調的方式了，怎麼知道異步調用的結果呢？先設計一個對象，異步調用執行完的時候，就把結果放在它裏面。這種對象稱之爲將來對象。

將來對象有一個result屬性，用於存放將來的執行結果。還有個set_result()方法，是用於設置result的，而且會在給result綁定值之後運行事先給future添加的回調。回調是經過將來對象的add_done_callback()方法添加的。

不要疑惑此處的callback，說好了不回調的嘛？難道忘了咱們曾經說的要異步，必回調。不過也別急，此處的回調，和先前學到的回調，還真有點不同。

4.4.2 重構 Crawler

如今不論如何，咱們有了將來對象能夠表明將來的值。先用Future來重構爬蟲代碼。

和先前的回調版本對比，已經有了較大差別。fetch 方法內有了yield表達式，使它成爲了生成器。咱們知道生成器須要先調用next()迭代一次或者是先send(None)啓動，遇到yield以後便暫停。那這fetch生成器如何再次恢復執行呢？至少 Future 和 Crawler都沒看到相關代碼。

4.4.3 任務對象(Task)

爲了解決上述問題，咱們只需遵循一個編程規則：單一職責，每種角色各司其職，若是還有工做沒有角色來作，那就建立一個角色去作。沒人來恢復這個生成器的執行麼？沒人來管理生成器的狀態麼？建立一個，就叫Task好了，很合適的名字。

上述代碼中Task封裝了coro對象，即初始化時傳遞給他的對象，被管理的任務是待執行的協程，故而這裏的coro就是fetch()生成器。它還有個step()方法，在初始化的時候就會執行一遍。step()內會調用生成器的send()方法，初始化第一次發送的是None就驅動了coro即fetch()的第一次執行。

send()完成以後，獲得下一次的future，而後給下一次的future添加step()回調。原來add_done_callback()不是給寫爬蟲業務邏輯用的。此前的callback可就乾的是業務邏輯呀。

再看fetch()生成器，其內部寫完了全部的業務邏輯，包括如何發送請求，如何讀取響應。並且註冊給selector的回調至關簡單，就是給對應的future對象綁定結果值。兩個yield表達式都是返回對應的future對象，而後返回Task.step()以內，這樣Task, Future, Coroutine三者精妙地串聯在了一塊兒。

初始化Task對象之後，把fetch()給驅動到了第44行yied f就完事了，接下來怎麼繼續？

4.4.4 事件循環(Event Loop)驅動協程運行

該事件循環上場了。接下來，只需等待已經註冊的EVENT_WRITE事件發生。事件循環就像心臟通常，只要它開始跳動，整個程序就會持續運行。

注：整體耗時約0.43秒。

如今loop有了些許變化，callback()再也不傳遞event_key和event_mask參數。也就是說，這裏的回調根本不關心是誰觸發了這個事件，結合fetch()能夠知道，它只需完成對future設置結果值便可f.set_result()。並且future是誰它也不關心，由於協程可以保存本身的狀態，知道本身的future是哪一個。也不用關心到底要設置什麼值，由於要設置什麼值也是協程內安排的。

此時的loop()，真的成了一個心臟，它只管往外泵血，不論這份血液是要輸送給大腦仍是要給腳趾，只要它還在跳動，生命就能延續。

4.4.5 生成器協程風格和回調風格對比總結

在回調風格中：

存在鏈式回調（雖然示例中嵌套回調只有一層）
請求和響應也不得不分爲兩個回調以致於破壞了同步代碼那種結構
程序員必須在回調之間維護必須的狀態。

還有更多示例中沒有展現，但確實存在的問題，參見4.1節。

而基於生成器協程的風格：

無鏈式調用
selector的回調裏只管給future設置值，再也不關心業務邏輯
loop 內回調callback()再也不關注是誰觸發了事件
已趨近於同步代碼的結構
無需程序員在多個協程之間維護狀態，例如哪一個纔是本身的sock

4.4.6 碉堡了，可是代碼很醜！能不能重構？

若是說fetch的容錯能力要更強，業務功能也須要更完善，怎麼辦？並且技術處理的部分（socket相關的）和業務處理的部分（請求與返回數據的處理）混在一塊兒。

建立socket鏈接能夠抽象複用吧？
循環讀取整個response能夠抽象複用吧？
循環內處理socket.recv()的能夠抽象複用吧？

可是這些關鍵節點的地方都有yield，抽離出來的代碼也須要是生成器。並且fetch()本身也得是生成器。生成器裏玩生成器，代碼好像要寫得更醜才能夠……

Python 語言的設計者們也認識到了這個問題，再次秉承着「程序猿沒必要爲難程序猿」的原則，他們搗鼓出了一個yield from來解決生成器裏玩生成器的問題。

4.5 用 yield from 改進生成器協程

4.5.1 yield from語法介紹

yield from 是Python 3.3 新引入的語法（PEP 380）。它主要解決的就是在生成器裏玩生成器不方便的問題。它有兩大主要功能。

第一個功能是：讓嵌套生成器沒必要經過循環迭代yield，而是直接yield from。如下兩種在生成器裏玩子生成器的方式是等價的。

def gen_one():

subgen = range(10) yield from subgendef gen_two():

subgen = range(10) for item in subgen: yield item

第二個功能就是在子生成器和原生成器的調用者之間打開雙向通道，二者能夠直接通訊。

def gen():

yield from subgen()def subgen():

while True:

x = yield

yield x+1def main():

g = gen()

next(g) # 驅動生成器g開始執行到第一個 yield

retval = g.send(1) # 看似向生成器 gen() 發送數據

print(retval) # 返回2

g.throw(StopIteration) # 看似向gen()拋入異常

經過上述代碼清晰地理解了yield from的雙向通道功能。關鍵字yield from在gen()內部爲subgen()和main()開闢了通訊通道。main()裏能夠直接將數據1發送給subgen(),subgen()也能夠將計算後的數據2返回到main()裏，main()裏也能夠直接向subgen()拋入異常以終止subgen()。

順帶一提，yield from 除了能夠 yield from 還能夠 yield from 。

4.5.2 重構代碼

抽象socket鏈接的功能:

抽象單次recv()和讀取完整的response功能:

三個關鍵點的抽象已經完成，如今重構Crawler類：

上面代碼總體來說沒什麼問題，可複用的代碼已經抽象出去，做爲子生成器也可使用 yield from 語法來獲取值。但另外有個點須要注意：在第24和第35行返回future對象的時候，咱們了yield from f 而不是原來的yield f。yield能夠直接做用於普通Python對象，而yield from卻不行，因此咱們對Future還要進一步改造，把它變成一個iterable對象就能夠了。

只是增長了__iter__()方法的實現。若是不把Future改爲iterable也是能夠的，仍是用原來的yield f便可。那爲何須要改進呢？

首先，咱們是在基於生成器作協程，而生成器還得是生成器，若是繼續混用yield和yield from 作協程，代碼可讀性和可理解性都很差。其次，若是不改，協程內還得關心它等待的對象是否可被yield，若是協程裏還想繼續返回協程怎麼辦？若是想調用普通函數動態生成一個Future對象再返回怎麼辦？

因此，在Python 3.3 引入yield from新語法以後，就再也不推薦用yield去作協程。全都使用yield from因爲其雙向通道的功能，可讓咱們在協程間爲所欲爲地傳遞數據。

4.5.3 yield from改進協程總結

用yield from改進基於生成器的協程，代碼抽象程度更高。使業務邏輯相關的代碼更精簡。因爲其雙向通道功能可讓協程之間爲所欲爲傳遞數據，使Python異步編程的協程解決方案大大向前邁進了一步。

因而Python語言開發者們充分利用yield from，使 Guido 主導的Python異步編程框架Tulip迅速脫胎換骨，併火燒眉毛得讓它在 Python 3.4 中換了個名字asyncio以「實習生」角色出如今標準庫中。

4.5.4 asyncio 介紹

asyncio是Python 3.4 試驗性引入的異步I/O框架（PEP 3156），提供了基於協程作異步I/O編寫單線程併發代碼的基礎設施。其核心組件有事件循環（Event Loop）、協程(Coroutine）、任務(Task)、將來對象(Future)以及其餘一些擴充和輔助性質的模塊。

在引入asyncio的時候，還提供了一個裝飾器@asyncio.coroutine用於裝飾使用了yield from的函數，以標記其爲協程。但並不強制使用這個裝飾器。

雖然發展到 Python 3.4 時有了yield from的加持讓協程更容易了，可是因爲協程在Python中發展的歷史包袱所致，不少人仍然弄不明白生成器和協程的聯繫與區別，也弄不明白yield和 yield from 的區別。這種混亂的狀態也違背Python之禪的一些準則。

因而Python設計者們又馬不停蹄地在 3.5 中新增了async/await語法（PEP 492），對協程有了明確而顯式的支持，稱之爲原生協程。async/await 和 yield from這兩種風格的協程底層複用共同的實現，並且相互兼容。

在Python 3.6 中asyncio庫「轉正」，再也不是實驗性質的，成爲標準庫的正式一員。

4.6 總結

行至此處，咱們已經掌握了asyncio的核心原理，學習了它的原型，也學習了異步I/O在 CPython 官方支持的生態下是如何一步步發展至今的。

實際上，真正的asyncio比咱們前幾節中學到的要複雜得多，它還實現了零拷貝、公平調度、異常處理、任務狀態管理等等使 Python 異步編程更完善的內容。理解原理和原型對咱們後續學習有莫大的幫助。

5 asyncio和原生協程初體驗

本節中，咱們將初步體驗asyncio庫和新增語法async/await給咱們帶來的便利。因爲Python2-3的過分期間，Python3.0-3.4的使用者並非太多，也爲了避免讓更多的人困惑，也由於aysncio在3.6才轉正，因此更深刻學習asyncio庫的時候咱們將使用async/await定義的原生協程風格，yield from風格的協程再也不闡述（實際上它們可用很小的代價相互代替）。

對比生成器版的協程，使用asyncio庫後變化很大：