前言

很多朋友對非同步程式設計都處於“聽說很強大”的認知狀態。鮮有在生產專案中使用它。而使用它的同學，則大多數都停留在知道如何使用 Tornado、Twisted、Gevent 這類非同步框架上，出現各種古怪的問題難以解決。而且使用了非同步框架的部分同學，由於用法不對，感覺它並沒牛逼到哪裡去，所以很多同學做 Web 後端服務時還是採用 Flask、Django等傳統的非非同步框架。

從上兩屆 PyCon 技術大會看來，非同步程式設計已經成了 Python 生態下一階段的主旋律。如新興的 Go、Rust、Elixir 等程式語言都將其支援非同步和高併發作為主要“賣點”，技術變化趨勢如此。Python 生態為不落人後，從2013年起由 Python 之父 Guido 親自操刀主持了Tulip(asyncio)專案的開發。

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

內容安排

上篇

• 瞭解 非同步程式設計及其緊密相關的概念，如阻塞/非阻塞、同步/非同步、併發/並行等
• 理解 非同步程式設計是什麼，以及非同步程式設計的困難之處
• 理解 為什麼需要非同步程式設計
• 熟悉 如何從同步阻塞發展到非同步非阻塞的
• 掌握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()和註冊可寫事件，而且從執行時間明顯可以推斷，多個下載任務確實在同時進行！

上述程式碼非同步執行的過程：

1. 建立Crawler 例項；
2. 呼叫fetch方法，會建立socket連線和在selector上註冊可寫事件；
3. fetch內並無阻塞操作，該方法立即返回；
4. 重複上述3個步驟，將10個不同的下載任務都加入事件迴圈；
5. 啟動事件迴圈，進入第1輪迴圈，阻塞在事件監聽上；
6. 當某個下載任務EVENT_WRITE被觸發，回撥其connected方法，第一輪事件迴圈結束；
7. 進入第2輪事件迴圈，當某個下載任務有事件觸發，執行其回撥函式；此時已經不能推測是哪個事件發生，因為有可能是上次connected裡的EVENT_READ先被觸發，也可能是其他某個任務的EVENT_WRITE被觸發；（此時，原來在一個下載任務上會阻塞的那段時間被利用起來執行另一個下載任務了）
8. 迴圈往復，直至所有下載任務被處理完成
9. 退出事件迴圈，結束整個下載程式

3.5.4 總結

目前為止，我們已經從同步阻塞學習到了非同步非阻塞。掌握了在單執行緒內同時併發執行多個網路I/O阻塞型任務的黑魔法。而且與多執行緒相比，連執行緒切換都沒有了，執行回撥函式是函式呼叫開銷，線上程的棧內完成，因此效能也更好，單機支援的任務規模也變成了數萬到數十萬個。（不過我們知道：沒有免費午餐，也沒有銀彈。）

部分程式語言中，對非同步程式設計的支援就止步於此（不含語言官方之外的擴充套件）。需要程式猿直接使用epoll去註冊事件和回撥、維護一個事件迴圈，然後大多數時間都花在設計回撥函式上。

通過本節的學習，我們應該認識到，不論什麼程式語言，但凡要做非同步程式設計，上述的“事件迴圈+回撥”這種模式是逃不掉的，儘管它可能用的不是epoll，也可能不是while迴圈。如果你找到了一種不屬於 “等會兒告訴你” 模型的非同步方式，請立即給我打電話（注意，打電話是Call）。

為什麼我們在某些非同步程式設計中並沒有看到 CallBack 模式呢？這就是我們接下來要探討的問題。本節是學習非同步程式設計的一個終點，也是另一個起點。畢竟我們們講 Python 非同步程式設計，還沒提到其主角協程的用武之地。

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

我們將在本節學習到 Python 生態對非同步程式設計的支援是如何繼承前文所述的“事件迴圈+回撥”模式演變到asyncio的原生協程模式。

4.1 回撥之痛，以終為始

在第3節中，我們已經學會了“事件迴圈+回撥”的基本執行原理，可以基於這種方式在單執行緒內實現非同步程式設計。也確實能夠大大提高程式執行效率。但是，剛才所學的只是最基本的，然而在生產專案中，要應對的複雜度會大大增加。考慮如下問題：

• 如果回撥函式執行不正常該如何？
• 如果回撥裡面還要巢狀回撥怎麼辦？要巢狀很多層怎麼辦？
• 如果巢狀了多層，其中某個環節出錯了會造成什麼後果？
• 如果有個資料需要被每個回撥都處理怎麼辦？
• ……

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

• 回撥層次過多時程式碼可讀性差

• 破壞程式碼結構

寫同步程式碼時，關聯的操作時自上而下執行：

如果 b 處理依賴於 a 處理的結果，而 a 過程是非同步呼叫，就不知 a 何時能返回值，需要將後續的處理過程以callback的方式傳遞給 a ，讓 a 執行完以後可以執行 b。程式碼變化為：

如果整個流程中全部改為非同步處理，而流程比較長的話，程式碼邏輯就會成為這樣：

上面實際也是回撥地獄式的風格，但這不是主要矛盾。主要在於，原本從上而下的程式碼結構，要改成從內到外的。先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。以下兩種在生成器裡玩子生成器的方式是等價的。

第二個功能就是在子生成器和原生成器的呼叫者之間開啟雙向通道，兩者可以直接通訊。

通過上述程式碼清晰地理解了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庫後變化很大：

• 沒有了yield 或 yield from，而是async/await
• 沒有了自造的loop()，取而代之的是asyncio.get_event_loop()
• 無需自己在socket上做非同步操作，不用顯式地註冊和登出事件，aiohttp庫已經代勞
• 沒有了顯式的 Future 和 Task，asyncio已封裝
• 更少量的程式碼，更優雅的設計

說明：我們這裡傳送和接收HTTP請求不再自己操作socket的原因是，在實際做業務專案的過程中，要處理妥善地HTTP協議會很複雜，我們需要的是功能完善的非同步HTTP客戶端，業界已經有了成熟的解決方案，DRY不是嗎？

和同步阻塞版的程式碼對比：

• 非同步化
• 程式碼量相當（引入aiohttp框架後更少）
• 程式碼邏輯同樣簡單，跟同步程式碼一樣的結構、一樣的邏輯
• 接近10倍的效能提升

結語

到此為止，我們已經深入地學習了非同步程式設計是什麼、為什麼、在Python裡是怎麼樣發展的。我們找到了一種讓程式碼看起來跟同步程式碼一樣簡單，而效率卻提升N倍（具體提升情況取決於專案規模、網路環境、實現細節）的非同步程式設計方法。它也沒有回撥的那些缺點。

本系列教程接下來的一篇將是學習asyncio庫如何的使用，快速掌握它的主要內容。後續我們還會深入探究asyncio的優點與缺點，也會探討Python生態中其他非同步I/O方案和asyncio的區別。

附

參考資料

• 《A Web Crawler With asyncio Coroutines》
• 《讓 CPU 告訴你硬碟和網路到底有多慢》

相關程式碼

• http://github.com/denglj/aiotutorial