深入理解Python異步編程(上)

前言

很多朋友對異步編程都處于“聽說很強(qiáng)大”的認(rèn)知狀態(tài)蛀蜜。鮮有在生產(chǎn)項(xiàng)目中使用它糠睡。而使用它的同學(xué)扩灯，則大多數(shù)都停留在知道如何使用 Tornado脏毯、Twisted闹究、Gevent 這類異步框架上，出現(xiàn)各種古怪的問題難以解決食店。而且使用了異步框架的部分同學(xué)渣淤，由于用法不對赏寇，感覺它并沒牛逼到哪里去，所以很多同學(xué)做 Web 后端服務(wù)時還是采用 Flask价认、Django等傳統(tǒng)的非異步框架蹋订。

從上兩屆 PyCon 技術(shù)大會看來，異步編程已經(jīng)成了 Python 生態(tài)下一階段的主旋律刻伊。如新興的 Go露戒、Rust、Elixir 等編程語言都將其支持異步和高并發(fā)作為主要“賣點(diǎn)”捶箱，技術(shù)變化趨勢如此智什。Python 生態(tài)為不落人后，從2013年起由 Python 之父 Guido 親自操刀主持了Tulip(asyncio)項(xiàng)目的開發(fā)丁屎。

本系列教程分為上中下篇荠锭，讓讀者深入理解Python異步編程，解決在使用異步編程中的疑惑晨川，深入學(xué)習(xí)Python3中新增的asyncio庫和async/await語法证九，盡情享受 Python 帶來的簡潔優(yōu)雅和高效率。

內(nèi)容安排

上篇

  • 了解 異步編程及其緊密相關(guān)的概念共虑，如阻塞/非阻塞愧怜、同步/異步、并發(fā)/并行等

  • 理解 異步編程是什么妈拌，以及異步編程的困難之處

  • 理解 為什么需要異步編程

  • 熟悉 如何從同步阻塞發(fā)展到異步非阻塞的

  • 掌握epoll + Callback + Event loop是如何工作的

  • 掌握 Python 是如何逐步從回調(diào)到生成器再到原生協(xié)程以支持異步編程的

  • 掌握 asyncio 的工作原理

中篇

  • 掌握 asyncio 標(biāo)準(zhǔn)庫基本使用

  • 掌握 asyncio 的事件循環(huán)

  • 掌握 協(xié)程與任務(wù)如何使用與管理（如調(diào)度與取消調(diào)度）

  • 掌握 同步原語的使用(Lock拥坛、Event、Condition尘分、Queue)

  • 掌握 asyncio 和多進(jìn)程猜惋、多線程結(jié)合使用

下篇

  • 理解 GIL 對異步編程的影響

  • 理解 asyncio 踩坑經(jīng)驗(yàn)

  • 理解 回調(diào)、協(xié)程培愁、綠程(Green-Thread)著摔、線程對比總結(jié)

  • 掌握 多進(jìn)程、多線程定续、協(xié)程各自的適用場景

  • 了解 Gevent/libev谍咆、uvloop/libuv 與asyncio的區(qū)別和聯(lián)系

  • 掌握 Python異步編程的一些指導(dǎo)細(xì)則

1 什么是異步編程

通過學(xué)習(xí)相關(guān)概念，我們逐步解釋異步編程是什么香罐。

1.1 阻塞

  • 程序未得到所需計算資源時被掛起的狀態(tài)卧波。

  • 程序在等待某個操作完成期間时肿，自身無法繼續(xù)干別的事情庇茫，則稱該程序在該操作上是阻塞的。

  • 常見的阻塞形式有：網(wǎng)絡(luò)I/O阻塞螃成、磁盤I/O阻塞旦签、用戶輸入阻塞等查坪。

阻塞是無處不在的，包括CPU切換上下文時宁炫，所有的進(jìn)程都無法真正干事情偿曙，它們也會被阻塞。（如果是多核CPU則正在執(zhí)行上下文切換操作的核不可被利用羔巢。）

1.2 非阻塞

  • 程序在等待某操作過程中望忆，自身不被阻塞，可以繼續(xù)運(yùn)行干別的事情竿秆，則稱該程序在該操作上是非阻塞的启摄。

  • 非阻塞并不是在任何程序級別、任何情況下都可以存在的幽钢。

  • 僅當(dāng)程序封裝的級別可以囊括獨(dú)立的子程序單元時歉备，它才可能存在非阻塞狀態(tài)。

非阻塞的存在是因?yàn)樽枞嬖诜搜啵驗(yàn)槟硞€操作阻塞導(dǎo)致的耗時與效率低下蕾羊，我們才要把它變成非阻塞的。

1.3 同步

  • 不同程序單元為了完成某個任務(wù)帽驯，在執(zhí)行過程中需靠某種通信方式以協(xié)調(diào)一致龟再，稱這些程序單元是同步執(zhí)行的。

  • 例如購物系統(tǒng)中更新商品庫存尼变，需要用“行鎖”作為通信信號吸申，讓不同的更新請求強(qiáng)制排隊(duì)順序執(zhí)行，那更新庫存的操作是同步的享甸。

  • 簡言之截碴，同步意味著有序。

1.4 異步

  • 為完成某個任務(wù)蛉威，不同程序單元之間過程中無需通信協(xié)調(diào)日丹，也能完成任務(wù)的方式。

  • 不相關(guān)的程序單元之間可以是異步的蚯嫌。

  • 例如哲虾，爬蟲下載網(wǎng)頁。調(diào)度程序調(diào)用下載程序后择示，即可調(diào)度其他任務(wù)束凑，而無需與該下載任務(wù)保持通信以協(xié)調(diào)行為。不同網(wǎng)頁的下載栅盲、保存等操作都是無關(guān)的汪诉，也無需相互通知協(xié)調(diào)。這些異步操作的完成時刻并不確定。

  • 簡言之扒寄，異步意味著無序鱼鼓。

上文提到的“通信方式”通常是指異步和并發(fā)編程提供的同步原語，如信號量该编、鎖迄本、同步隊(duì)列等等。我們需知道课竣，雖然這些通信方式是為了讓多個程序在一定條件下同步執(zhí)行嘉赎，但正因?yàn)槭钱惒降拇嬖冢判枰@些通信方式于樟。如果所有程序都是按序執(zhí)行曹阔，其本身就是同步的，又何需這些同步信號呢隔披？

1.5 并發(fā)

  • 并發(fā)描述的是程序的組織結(jié)構(gòu)赃份。指程序要被設(shè)計成多個可獨(dú)立執(zhí)行的子任務(wù)。

  • 以利用有限的計算機(jī)資源使多個任務(wù)可以被實(shí)時或近實(shí)時執(zhí)行為目的奢米。

1.6 并行

  • 并行描述的是程序的執(zhí)行狀態(tài)抓韩。指多個任務(wù)同時被執(zhí)行。

  • 以利用富余計算資源（多核CPU）加速完成多個任務(wù)為目的鬓长。

并發(fā)提供了一種程序組織結(jié)構(gòu)方式谒拴，讓問題的解決方案可以并行執(zhí)行，但并行執(zhí)行不是必須的涉波。

1.7 概念總結(jié)

  • 并行是為了利用多核加速多任務(wù)完成的進(jìn)度

  • 并發(fā)是為了讓獨(dú)立的子任務(wù)都有機(jī)會被盡快執(zhí)行英上，但不一定能加速整體進(jìn)度

  • 非阻塞是為了提高程序整體執(zhí)行效率

  • 異步是高效地組織非阻塞任務(wù)的方式

要支持并發(fā)，必須拆分為多任務(wù)啤覆，不同任務(wù)相對而言才有阻塞/非阻塞苍日、同步/異步。所以窗声，并發(fā)相恃、異步、非阻塞三個詞總是如影隨形笨觅。

1.8 異步編程

  • 以進(jìn)程拦耐、線程、協(xié)程见剩、函數(shù)/方法作為執(zhí)行任務(wù)程序的基本單位杀糯，結(jié)合回調(diào)、事件循環(huán)苍苞、信號量等機(jī)制固翰，以提高程序整體執(zhí)行效率和并發(fā)能力的編程方式。

如果在某程序的運(yùn)行時，能根據(jù)已經(jīng)執(zhí)行的指令準(zhǔn)確判斷它接下來要進(jìn)行哪個具體操作倦挂，那它是同步程序，反之則為異步程序担巩。（無序與有序的區(qū)別）

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

1.9 異步之難(nán)

  • 控制不住“計幾”寫的程序拳话，因?yàn)槠鋱?zhí)行順序不可預(yù)料先匪，當(dāng)下正要發(fā)生什么事件不可預(yù)料。在并行情況下更為復(fù)雜和艱難弃衍。

所以呀非，幾乎所有的異步框架都將異步編程模型簡化：一次只允許處理一個事件。故而有關(guān)異步的討論幾乎都集中在了單線程內(nèi)镜盯。

  • 如果某事件處理程序需要長時間執(zhí)行岸裙，所有其他部分都會被阻塞。

所以速缆，一旦采取異步編程降允，每個異步調(diào)用必須“足夠小”，不能耗時太久艺糜。如何拆分異步任務(wù)成了難題剧董。

  • 程序下一步行為往往依賴上一步執(zhí)行結(jié)果，如何知曉上次異步調(diào)用已完成并獲取結(jié)果破停？

  • 回調(diào)（Callback）成了必然選擇翅楼。那又需要面臨“回調(diào)地獄”的折磨。

  • 同步代碼改為異步代碼真慢，必然破壞代碼結(jié)構(gòu)犁嗅。

  • 解決問題的邏輯也要轉(zhuǎn)變，不再是一條路走到黑晤碘，需要精心安排異步任務(wù)褂微。

2 苦心異步為哪般

如上文所述，異步編程面臨諸多難點(diǎn)园爷，Python 之父親自上陣打磨4年才使 asyncio 模塊在Python 3.6中“轉(zhuǎn)正”宠蚂，如此苦心為什么？答案只有一個：它值得童社！下面我們看看為何而值得签则。

2.1 CPU的時間觀

image

我們將一個 2.6GHz 的 CPU 擬人化氓轰，假設(shè)它執(zhí)行一條命令的時間湃窍，他它感覺上過了一秒鐘奏瞬。CPU是計算機(jī)的處理核心，也是最寶貴的資源圃郊，如果有浪費(fèi)CPU的運(yùn)行時間，導(dǎo)致其利用率不足，那程序效率必然低下（因?yàn)閷?shí)際上有資源可以使效率更高）浦辨。

如上圖所示，在千兆網(wǎng)上傳輸2KB數(shù)據(jù)沼沈，CPU感覺過了14個小時流酬，如果是在10M的公網(wǎng)上呢？那效率會低百倍列另！如果在這么長的一段時間內(nèi)芽腾，CPU只是傻等結(jié)果而不能去干其他事情，是不是在浪費(fèi)CPU的青春页衙？

魯迅說摊滔，浪費(fèi)“CPU”的時間等于謀財害命。而兇手就是程序猿店乐。

2.2 面臨的問題

  • 成本問題

如果一個程序不能有效利用一臺計算機(jī)資源惭载，那必然需要更多的計算機(jī)通過運(yùn)行更多的程序?qū)嵗齺韽浹a(bǔ)需求缺口。例如我前不久主導(dǎo)重寫的項(xiàng)目响巢，使用Python異步編程描滔，改版后由原來的7臺服務(wù)器削減至3臺，成本驟降57%踪古。一臺AWS m4.xlarge 型通用服務(wù)器按需付費(fèi)實(shí)例一年價格約 1.2 萬人民幣含长。

  • 效率問題

如果不在乎錢的消耗，那也會在意效率問題伏穆。當(dāng)服務(wù)器數(shù)量堆疊到一定規(guī)模后拘泞，如果不改進(jìn)軟件架構(gòu)和實(shí)現(xiàn)，加機(jī)器是徒勞枕扫，而且運(yùn)維成本會驟然增加陪腌。比如別人家的電商平臺支持6000單/秒支付，而自家在下單量才支撐2000單/秒烟瞧，在雙十一這種活動的時候诗鸭，錢送上門也賺不到。

  • C10k/C10M挑戰(zhàn)

C10k（concurrently handling 10k connections）是一個在1999年被提出來的技術(shù)挑戰(zhàn)参滴，如何在一顆1GHz CPU强岸，2G內(nèi)存，1gbps網(wǎng)絡(luò)環(huán)境下砾赔，讓單臺服務(wù)器同時為1萬個客戶端提供FTP服務(wù)蝌箍。而到了2010年后青灼，隨著硬件技術(shù)的發(fā)展，這個問題被延伸為C10M妓盲，即如何利用8核心CPU杂拨，64G內(nèi)存，在10gbps的網(wǎng)絡(luò)上保持1000萬并發(fā)連接悯衬，或是每秒鐘處理100萬的連接弹沽。（兩種類型的計算機(jī)資源在各自的時代都約為1200美元）

成本和效率問題是從企業(yè)經(jīng)營角度講，C10k/C10M問題則是從技術(shù)角度出發(fā)挑戰(zhàn)軟硬件極限甚亭。C10k/C10M 問題得解贷币，成本問題和效率問題迎刃而解击胜。

2.3 解決方案

《約束理論與企業(yè)優(yōu)化》中指出：“除了瓶頸之外亏狰，任何改進(jìn)都是幻覺。”

CPU告訴我們偶摔，它自己很快暇唾，而上下文切換慢、內(nèi)存讀數(shù)據(jù)慢辰斋、磁盤尋址與取數(shù)據(jù)慢策州、網(wǎng)絡(luò)傳輸慢……總之，離開CPU 后的一切宫仗，除了一級高速緩存够挂，都很慢。我們觀察計算機(jī)的組成可以知道藕夫，主要由運(yùn)算器孽糖、控制器、存儲器毅贮、輸入設(shè)備办悟、輸出設(shè)備五部分組成。運(yùn)算器和控制器主要集成在CPU中滩褥，除此之外全是I/O病蛉，包括讀寫內(nèi)存、讀寫磁盤瑰煎、讀寫網(wǎng)卡全都是I/O铺然。I/O成了最大的瓶頸。

異步程序可以提高效率酒甸，而最大的瓶頸在I/O探熔，業(yè)界誕生的解決方案沒出意料：異步I/O吧，異步I/O吧烘挫，異步I/O吧吧诀艰！

3 異步I/O進(jìn)化之路

如今柬甥，地球上最發(fā)達(dá)、規(guī)模最龐大的計算機(jī)程序其垄，莫過于因特網(wǎng)苛蒲。而從CPU的時間觀中可知，網(wǎng)絡(luò)I/O是最大的I/O瓶頸绿满，除了宕機(jī)沒有比它更慢的臂外。所以，諸多異步框架都對準(zhǔn)的是網(wǎng)絡(luò)I/O喇颁。

我們從一個爬蟲例子說起漏健，從因特網(wǎng)上下載10篇網(wǎng)頁。

3.1 同步阻塞方式

最容易想到的解決方案就是依次下載橘霎，從建立socket連接到發(fā)送網(wǎng)絡(luò)請求再到讀取響應(yīng)數(shù)據(jù)蔫浆，順序進(jìn)行。

image

注：總體耗時約為4.5秒姐叁。（因網(wǎng)絡(luò)波動每次測試結(jié)果有所變動瓦盛，本文取多次平均值）

如上圖所示，blocking_way() 的作用是建立 socket 連接外潜，發(fā)送HTTP請求原环，然后從 socket 讀取HTTP響應(yīng)并返回數(shù)據(jù)。示例中我們請求了 example.com 的首頁处窥。在sync_way() 執(zhí)行了10次嘱吗，即下載 example.com 首頁10次。

在示例代碼中有兩個關(guān)鍵點(diǎn)滔驾。一是第10行的 sock.connect(('example.com', 80))谒麦，該調(diào)用的作用是向example.com主機(jī)的80端口發(fā)起網(wǎng)絡(luò)連接請求。 二是第14行嵌灰、第18行的sock.recv(4096)弄匕，該調(diào)用的作用是從socket上讀取4K字節(jié)數(shù)據(jù)。

我們知道沽瞭，創(chuàng)建網(wǎng)絡(luò)連接迁匠，多久能創(chuàng)建完成不是客戶端決定的，而是由網(wǎng)絡(luò)狀況和服務(wù)端處理能力共同決定驹溃。服務(wù)端什么時候返回了響應(yīng)數(shù)據(jù)并被客戶端接收到可供程序讀取城丧，也是不可預(yù)測的。所以sock.connect()和sock.recv()這兩個調(diào)用在默認(rèn)情況下是阻塞的豌鹤。

注：sock.send()函數(shù)并不會阻塞太久亡哄，它只負(fù)責(zé)將請求數(shù)據(jù)拷貝到TCP/IP協(xié)議棧的系統(tǒng)緩沖區(qū)中就返回，并不等待服務(wù)端返回的應(yīng)答確認(rèn)布疙。

假設(shè)網(wǎng)絡(luò)環(huán)境很差蚊惯，創(chuàng)建網(wǎng)絡(luò)連接需要1秒鐘愿卸，那么sock.connect()就得阻塞1秒鐘，等待網(wǎng)絡(luò)連接成功截型。這1秒鐘對一顆2.6GHz的CPU來講趴荸，仿佛過去了83年，然而它不能干任何事情宦焦。sock.recv()也是一樣的必須得等到服務(wù)端的響應(yīng)數(shù)據(jù)已經(jīng)被客戶端接收发钝。我們下載10篇網(wǎng)頁，這個阻塞過程就得重復(fù)10次波闹。如果一個爬蟲系統(tǒng)每天要下載1000萬篇網(wǎng)頁呢酝豪？！

上面說了很多精堕，我們力圖說明一件事：同步阻塞的網(wǎng)絡(luò)交互方式孵淘，效率低十分低下。特別是在網(wǎng)絡(luò)交互頻繁的程序中锄码。這種方式根本不可能挑戰(zhàn)C10K/C10M夺英。

3.2 改進(jìn)方式：多進(jìn)程

在一個程序內(nèi)晌涕，依次執(zhí)行10次太耗時滋捶，那開10個一樣的程序同時執(zhí)行不就行了。于是我們想到了多進(jìn)程編程余黎。為什么會先想到多進(jìn)程呢重窟？發(fā)展脈絡(luò)如此。在更早的操作系統(tǒng)（Linux 2.4）及其以前惧财，進(jìn)程是 OS 調(diào)度任務(wù)的實(shí)體巡扇，是面向進(jìn)程設(shè)計的OS。

image

注：總體耗時約為 0.6 秒垮衷。

改善效果立竿見影厅翔。但仍然有問題〔笸唬總體耗時并沒有縮減到原來的十分之一刀闷，而是九分之一左右，還有一些時間耗到哪里去了仰迁？進(jìn)程切換開銷甸昏。

進(jìn)程切換開銷不止像“CPU的時間觀”所列的“上下文切換”那么低。CPU從一個進(jìn)程切換到另一個進(jìn)程徐许，需要把舊進(jìn)程運(yùn)行時的寄存器狀態(tài)施蜜、內(nèi)存狀態(tài)全部保存好，再將另一個進(jìn)程之前保存的數(shù)據(jù)恢復(fù)雌隅。對CPU來講翻默，幾個小時就干等著缸沃。當(dāng)進(jìn)程數(shù)量大于CPU核心數(shù)量時，進(jìn)程切換是必然需要的修械。

除了切換開銷和泌，多進(jìn)程還有另外的缺點(diǎn)。一般的服務(wù)器在能夠穩(wěn)定運(yùn)行的前提下祠肥，可以同時處理的進(jìn)程數(shù)在數(shù)十個到數(shù)百個規(guī)模武氓。如果進(jìn)程數(shù)量規(guī)模更大，系統(tǒng)運(yùn)行將不穩(wěn)定仇箱，而且可用內(nèi)存資源往往也會不足县恕。

多進(jìn)程解決方案在面臨每天需要成百上千萬次下載任務(wù)的爬蟲系統(tǒng)，或者需要同時搞定數(shù)萬并發(fā)的電商系統(tǒng)來說剂桥，并不適合忠烛。

除了切換開銷大，以及可支持的任務(wù)規(guī)模小之外权逗，多進(jìn)程還有其他缺點(diǎn)美尸，如狀態(tài)共享等問題，后文會有提及斟薇，此處不再細(xì)究师坎。

3.3 繼續(xù)改進(jìn)：多線程

由于線程的數(shù)據(jù)結(jié)構(gòu)比進(jìn)程更輕量級，同一個進(jìn)程可以容納多個線程堪滨，從進(jìn)程到線程的優(yōu)化由此展開胯陋。后來的OS也把調(diào)度單位由進(jìn)程轉(zhuǎn)為線程，進(jìn)程只作為線程的容器袱箱，用于管理進(jìn)程所需的資源遏乔。而且OS級別的線程是可以被分配到不同的CPU核心同時運(yùn)行的。

image

注：總體運(yùn)行時間約0.43秒发笔。

結(jié)果符合預(yù)期盟萨，比多進(jìn)程耗時要少些。從運(yùn)行時間上看了讨，多線程似乎已經(jīng)解決了切換開銷大的問題捻激。而且可支持的任務(wù)數(shù)量規(guī)模，也變成了數(shù)百個到數(shù)千個量蕊。

但是铺罢，多線程仍有問題，特別是Python里的多線程残炮。首先韭赘，Python中的多線程因?yàn)镚IL的存在，它們并不能利用CPU多核優(yōu)勢势就，一個Python進(jìn)程中泉瞻，只允許有一個線程處于運(yùn)行狀態(tài)脉漏。那為什么結(jié)果還是如預(yù)期，耗時縮減到了十分之一袖牙？

因?yàn)樵谧鲎枞南到y(tǒng)調(diào)用時侧巨，例如sock.connect(),sock.recv()時，當(dāng)前線程會釋放GIL鞭达，讓別的線程有執(zhí)行機(jī)會司忱。但是單個線程內(nèi)，在阻塞調(diào)用上還是阻塞的畴蹭。

小提示：Python中 time.sleep 是阻塞的坦仍，都知道使用它要謹(jǐn)慎，但在多線程編程中叨襟，time.sleep 并不會阻塞其他線程繁扎。

除了GIL之外，所有的多線程還有通病糊闽。它們是被OS調(diào)度梳玫，調(diào)度策略是搶占式的，以保證同等優(yōu)先級的線程都有均等的執(zhí)行機(jī)會右犹，那帶來的問題是：并不知道下一時刻是哪個線程被運(yùn)行提澎，也不知道它正要執(zhí)行的代碼是什么。所以就可能存在競態(tài)條件傀履。

例如爬蟲工作線程從任務(wù)隊(duì)列拿待抓取URL的時候虱朵，如果多個爬蟲線程同時來取莉炉，那這個任務(wù)到底該給誰钓账？那就需要用到“鎖”或“同步隊(duì)列”來保證下載任務(wù)不會被重復(fù)執(zhí)行。

而且線程支持的多任務(wù)規(guī)模絮宁，在數(shù)百到數(shù)千的數(shù)量規(guī)模梆暮。在大規(guī)模的高頻網(wǎng)絡(luò)交互系統(tǒng)中，仍然有些吃力绍昂。當(dāng)然啦粹，多線程最主要的問題還是競態(tài)條件。

3.4 非阻塞方式

終于窘游，我們來到了非阻塞解決方案唠椭。先來看看最原始的非阻塞如何工作的。

image

注：總體耗時約4.3秒忍饰。

首先注意到兩點(diǎn)贪嫂，就感覺被騙了。一是耗時與同步阻塞相當(dāng)艾蓝，二是代碼更復(fù)雜力崇。要非阻塞何用斗塘？且慢。

上圖第9行代碼sock.setblocking(False)告訴OS亮靴，讓socket上阻塞調(diào)用都改為非阻塞的方式馍盟。之前我們說到，非阻塞就是在做一件事的時候茧吊，不阻礙調(diào)用它的程序做別的事情贞岭。上述代碼在執(zhí)行完 sock.connect() 和 sock.recv() 后的確不再阻塞，可以繼續(xù)往下執(zhí)行請求準(zhǔn)備的代碼或者是執(zhí)行下一次讀取搓侄。

代碼變得更復(fù)雜也是上述原因所致曹步。第11行要放在try語句內(nèi)，是因?yàn)?code>socket在發(fā)送非阻塞連接請求過程中休讳，系統(tǒng)底層也會拋出異常讲婚。connect()被調(diào)用之后，立即可以往下執(zhí)行第15和16行的代碼俊柔。

需要while循環(huán)不斷嘗試 send()筹麸，是因?yàn)?code>connect()已經(jīng)非阻塞，在send()之時并不知道 socket 的連接是否就緒雏婶，只有不斷嘗試物赶，嘗試成功為止，即發(fā)送數(shù)據(jù)成功了留晚。recv()調(diào)用也是同理酵紫。

雖然 connect() 和 recv() 不再阻塞主程序，空出來的時間段CPU沒有空閑著错维，但并沒有利用好這空閑去做其他有意義的事情奖地，而是在循環(huán)嘗試讀寫 socket （不停判斷非阻塞調(diào)用的狀態(tài)是否就緒）。還得處理來自底層的可忽略的異常赋焕。也不能同時處理多個 socket 参歹。

然后10次下載任務(wù)仍然按序進(jìn)行。所以總體執(zhí)行時間和同步阻塞相當(dāng)隆判。如果非得這樣子犬庇，那還不如同步阻塞算了。

3.5 非阻塞改進(jìn)

3.5.1 epoll

判斷非阻塞調(diào)用是否就緒如果 OS 能做侨嘀，是不是應(yīng)用程序就可以不用自己去等待和判斷了臭挽，就可以利用這個空閑去做其他事情以提高效率。

所以OS將I/O狀態(tài)的變化都封裝成了事件咬腕，如可讀事件欢峰、可寫事件。并且提供了專門的系統(tǒng)模塊讓應(yīng)用程序可以接收事件通知。這個模塊就是select赤赊。讓應(yīng)用程序可以通過select注冊文件描述符和回調(diào)函數(shù)闯狱。當(dāng)文件描述符的狀態(tài)發(fā)生變化時，select 就調(diào)用事先注冊的回調(diào)函數(shù)抛计。

select因其算法效率比較低哄孤，后來改進(jìn)成了poll，再后來又有進(jìn)一步改進(jìn)吹截，BSD內(nèi)核改進(jìn)成了kqueue模塊瘦陈，而Linux內(nèi)核改進(jìn)成了epoll模塊。這四個模塊的作用都相同波俄，暴露給程序員使用的API也幾乎一致晨逝，區(qū)別在于kqueue 和 epoll 在處理大量文件描述符時效率更高。

鑒于 Linux 服務(wù)器的普遍性懦铺，以及為了追求更高效率捉貌，所以我們常常聽聞被探討的模塊都是 epoll 。

3.5.2 回調(diào)(Callback)

把I/O事件的等待和監(jiān)聽任務(wù)交給了 OS冬念，那 OS 在知道I/O狀態(tài)發(fā)生改變后（例如socket連接已建立成功可發(fā)送數(shù)據(jù)）趁窃，它又怎么知道接下來該干嘛呢？只能回調(diào)急前。

需要我們將發(fā)送數(shù)據(jù)與讀取數(shù)據(jù)封裝成獨(dú)立的函數(shù)醒陆，讓epoll代替應(yīng)用程序監(jiān)聽socket狀態(tài)時，得告訴epoll：“如果socket狀態(tài)變?yōu)榭梢酝飳憯?shù)據(jù)（連接建立成功了）裆针，請調(diào)用HTTP請求發(fā)送函數(shù)刨摩。如果socket 變?yōu)榭梢宰x數(shù)據(jù)了（客戶端已收到響應(yīng)），請調(diào)用響應(yīng)處理函數(shù)世吨≡枭玻”

于是我們利用epoll結(jié)合回調(diào)機(jī)制重構(gòu)爬蟲代碼：

image

此處和前面稍有不同的是，我們將下載不同的10個頁面另假，相對URL路徑存放于urls_todo集合中∠裎荩現(xiàn)在看看改進(jìn)在哪。

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

其次奏甫，導(dǎo)入了selectors模塊戈轿，并創(chuàng)建了一個DefaultSelector 實(shí)例。Python標(biāo)準(zhǔn)庫提供的selectors模塊是對底層select/poll/epoll/kqueue的封裝阵子。DefaultSelector類會根據(jù) OS 環(huán)境自動選擇最佳的模塊思杯，那在 Linux 2.5.44 及更新的版本上都是epoll了。

然后，在第25行和第31行分別注冊了socket可寫事件(EVENT_WRITE)和可讀事件(EVENT_READ)發(fā)生后應(yīng)該采取的回調(diào)函數(shù)色乾。

雖然代碼結(jié)構(gòu)清晰了誊册，阻塞操作也交給OS去等待和通知了，但是暖璧，我們要抓取10個不同頁面案怯，就得創(chuàng)建10個Crawler實(shí)例，就有20個事件將要發(fā)生澎办，那如何從selector里獲取當(dāng)前正發(fā)生的事件嘲碱，并且得到對應(yīng)的回調(diào)函數(shù)去執(zhí)行呢？

3.5.3 事件循環(huán)（Event Loop）

為了解決上述問題局蚀，那我們只得采用老辦法麦锯，寫一個循環(huán)，去訪問selector模塊琅绅，等待它告訴我們當(dāng)前是哪個事件發(fā)生了扶欣，應(yīng)該對應(yīng)哪個回調(diào)。這個等待事件通知的循環(huán)千扶，稱之為事件循環(huán)宵蛀。

image

上述代碼中，我們用stopped全局變量控制事件循環(huán)何時停止县貌。當(dāng)urls_todo消耗完畢后术陶，會標(biāo)記stopped為True。

重要的是第49行代碼煤痕，selector.select() 是一個阻塞調(diào)用梧宫，因?yàn)槿绻录话l(fā)生，那應(yīng)用程序就沒事件可處理摆碉，所以就干脆阻塞在這里等待事件發(fā)生塘匣。那可以推斷，如果只下載一篇網(wǎng)頁，一定要connect()之后才能send()繼而recv()净薛，那它的效率和阻塞的方式是一樣的喻括。因?yàn)椴辉?code>connect()/recv()上阻塞，也得在select()上阻塞驰徊。

所以，selector機(jī)制(后文以此稱呼代指epoll/kqueue)是設(shè)計用來解決大量并發(fā)連接的堕阔。當(dāng)系統(tǒng)中有大量非阻塞調(diào)用棍厂，能隨時產(chǎn)生事件的時候，selector機(jī)制才能發(fā)揮最大的威力超陆。

下面是如何啟創(chuàng)建10個下載任務(wù)和啟動事件循環(huán)的：

image

注：總體耗時約0.45秒牺弹。

上述執(zhí)行結(jié)果令人振奮。在單線程內(nèi)用 事件循環(huán)+回調(diào) 搞定了10篇網(wǎng)頁同時下載的問題。這张漂，已經(jīng)是異步編程了晶默。雖然有一個for 循環(huán)順序地創(chuàng)建Crawler 實(shí)例并調(diào)用 fetch 方法，但是fetch 內(nèi)僅有connect()和注冊可寫事件航攒，而且從執(zhí)行時間明顯可以推斷磺陡，多個下載任務(wù)確實(shí)在同時進(jìn)行！

上述代碼異步執(zhí)行的過程：

  1. 創(chuàng)建Crawler 實(shí)例屎债；

  2. 調(diào)用fetch方法仅政，會創(chuàng)建socket連接和在selector上注冊可寫事件；

  3. fetch內(nèi)并無阻塞操作盆驹，該方法立即返回圆丹；

  4. 重復(fù)上述3個步驟，將10個不同的下載任務(wù)都加入事件循環(huán)躯喇；

  5. 啟動事件循環(huán)辫封，進(jìn)入第1輪循環(huán)，阻塞在事件監(jiān)聽上廉丽；

  6. 當(dāng)某個下載任務(wù)EVENT_WRITE被觸發(fā)倦微，回調(diào)其connected方法，第一輪事件循環(huán)結(jié)束正压；

  7. 進(jìn)入第2輪事件循環(huán)欣福，當(dāng)某個下載任務(wù)有事件觸發(fā)，執(zhí)行其回調(diào)函數(shù)焦履；此時已經(jīng)不能推測是哪個事件發(fā)生拓劝，因?yàn)橛锌赡苁巧洗?code>connected里的EVENT_READ先被觸發(fā)，也可能是其他某個任務(wù)的EVENT_WRITE被觸發(fā)嘉裤；（此時郑临，原來在一個下載任務(wù)上會阻塞的那段時間被利用起來執(zhí)行另一個下載任務(wù)了）

  8. 循環(huán)往復(fù)，直至所有下載任務(wù)被處理完成

  9. 退出事件循環(huán)屑宠，結(jié)束整個下載程序

3.5.4 總結(jié)

目前為止厢洞，我們已經(jīng)從同步阻塞學(xué)習(xí)到了異步非阻塞。掌握了在單線程內(nèi)同時并發(fā)執(zhí)行多個網(wǎng)絡(luò)I/O阻塞型任務(wù)的黑魔法典奉。而且與多線程相比躺翻，連線程切換都沒有了，執(zhí)行回調(diào)函數(shù)是函數(shù)調(diào)用開銷秋柄，在線程的棧內(nèi)完成获枝，因此性能也更好，單機(jī)支持的任務(wù)規(guī)模也變成了數(shù)萬到數(shù)十萬個骇笔。（不過我們知道：沒有免費(fèi)午餐，也沒有銀彈。）

部分編程語言中笨触，對異步編程的支持就止步于此（不含語言官方之外的擴(kuò)展）懦傍。需要程序猿直接使用epoll去注冊事件和回調(diào)、維護(hù)一個事件循環(huán)芦劣，然后大多數(shù)時間都花在設(shè)計回調(diào)函數(shù)上粗俱。

通過本節(jié)的學(xué)習(xí)，我們應(yīng)該認(rèn)識到虚吟，不論什么編程語言寸认，但凡要做異步編程，上述的“事件循環(huán)+回調(diào)”這種模式是逃不掉的串慰，盡管它可能用的不是epoll偏塞，也可能不是while循環(huán)。如果你找到了一種不屬于 “等會兒告訴你” 模型的異步方式邦鲫，請立即給我打電話（注意灸叼，打電話是Call）。

為什么我們在某些異步編程中并沒有看到 CallBack 模式呢庆捺？這就是我們接下來要探討的問題古今。本節(jié)是學(xué)習(xí)異步編程的一個終點(diǎn)，也是另一個起點(diǎn)滔以。畢竟咱們講 Python 異步編程捉腥，還沒提到其主角協(xié)程的用武之地。

4 Python 對異步I/O的優(yōu)化之路

我們將在本節(jié)學(xué)習(xí)到 Python 生態(tài)對異步編程的支持是如何繼承前文所述的“事件循環(huán)+回調(diào)”模式演變到asyncio的原生協(xié)程模式你画。

4.1 回調(diào)之痛抵碟，以終為始

在第3節(jié)中，我們已經(jīng)學(xué)會了“事件循環(huán)+回調(diào)”的基本運(yùn)行原理撬即，可以基于這種方式在單線程內(nèi)實(shí)現(xiàn)異步編程立磁。也確實(shí)能夠大大提高程序運(yùn)行效率。但是剥槐，剛才所學(xué)的只是最基本的唱歧，然而在生產(chǎn)項(xiàng)目中，要應(yīng)對的復(fù)雜度會大大增加粒竖÷溃考慮如下問題：

  • 如果回調(diào)函數(shù)執(zhí)行不正常該如何？

  • 如果回調(diào)里面還要嵌套回調(diào)怎么辦蕊苗？要嵌套很多層怎么辦沿后？

  • 如果嵌套了多層，其中某個環(huán)節(jié)出錯了會造成什么后果朽砰？

  • 如果有個數(shù)據(jù)需要被每個回調(diào)都處理怎么辦尖滚？

  • ……

在實(shí)際編程中喉刘，上述系列問題不可避免。在這些問題的背后隱藏著回調(diào)編程模式的一些缺點(diǎn)：

  • 回調(diào)層次過多時代碼可讀性差

    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)

  • 破壞代碼結(jié)構(gòu)
    寫同步代碼時漆弄，關(guān)聯(lián)的操作時自上而下運(yùn)行：

    do_a()
do_b()

    如果 b 處理依賴于 a 處理的結(jié)果睦裳，而 a 過程是異步調(diào)用，就不知 a 何時能返回值撼唾，需要將后續(xù)的處理過程以callback的方式傳遞給 a 廉邑，讓 a 執(zhí)行完以后可以執(zhí)行 b。代碼變化為：

    do_a(do_b())

    如果整個流程中全部改為異步處理倒谷，而流程比較長的話蛛蒙，代碼邏輯就會成為這樣：

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

    上面實(shí)際也是回調(diào)地獄式的風(fēng)格，但這不是主要矛盾渤愁。主要在于牵祟，原本從上而下的代碼結(jié)構(gòu)，要改成從內(nèi)到外的猴伶。先f课舍，再e，再d他挎，…筝尾，直到最外層 a 執(zhí)行完成。在同步版本中办桨，執(zhí)行完a后執(zhí)行b筹淫，這是線程的指令指針控制著的流程，而在回調(diào)版本中呢撞，流程就是程序猿需要注意和安排的损姜。

  • 共享狀態(tài)管理困難
    回顧第3節(jié)爬蟲代碼，同步阻塞版的sock對象從頭使用到尾殊霞，而在回調(diào)的版本中摧阅，我們必須在Crawler實(shí)例化后的對象self里保存它自己的sock對象。如果不是采用OOP的編程風(fēng)格绷蹲，那需要把要共享的狀態(tài)接力似的傳遞給每一個回調(diào)棒卷。多個異步調(diào)用之間，到底要共享哪些狀態(tài)祝钢，事先就得考慮清楚比规，精心設(shè)計。

  • 錯誤處理困難
    一連串的回調(diào)構(gòu)成一個完整的調(diào)用鏈拦英。例如上述的 a 到 f蜒什。假如 d 拋了異常怎么辦？整個調(diào)用鏈斷掉疤估，接力傳遞的狀態(tài)也會丟失灾常，這種現(xiàn)象稱為調(diào)用棧撕裂霎冯。 c 不知道該干嘛，繼續(xù)異常岗憋，然后是 b 異常肃晚，接著 a 異常锚贱。好嘛仔戈，報錯日志就告訴你，a 調(diào)用出錯了拧廊，但實(shí)際是 d 出錯监徘。所以，為了防止棧撕裂吧碾，異常必須以數(shù)據(jù)的形式返回凰盔，而不是直接拋出異常，然后每個回調(diào)中需要檢查上次調(diào)用的返回值倦春，以防錯誤吞沒户敬。

如果說代碼風(fēng)格難看是小事，但棧撕裂和狀態(tài)管理困難這兩個缺點(diǎn)會讓基于回調(diào)的異步編程很艱難睁本。所以不同編程語言的生態(tài)都在致力于解決這個問題尿庐。才誕生了后來的Promise、Co-routine等解決方案呢堰。

Python 生態(tài)也以終為始抄瑟，秉承著“程序猿不必難程序猿”的原則，讓語言和框架開發(fā)者苦逼一點(diǎn)枉疼，也要讓應(yīng)用開發(fā)者舒坦皮假。在事件循環(huán)+回調(diào)的基礎(chǔ)上衍生出了基于協(xié)程的解決方案，代表作有 Tornado骂维、Twisted惹资、asyncio 等。接下來我們隨著 Python 生態(tài)異步編程的發(fā)展過程航闺，深入理解Python異步編程褪测。

4.2 核心問題

通過前面的學(xué)習(xí)，我們清楚地認(rèn)識到異步編程最大的困難：異步任務(wù)何時執(zhí)行完畢来颤？接下來要對異步調(diào)用的返回結(jié)果做什么操作汰扭？

上述問題我們已經(jīng)通過事件循環(huán)和回調(diào)解決了。但是回調(diào)會讓程序變得復(fù)雜福铅。要異步萝毛，必回調(diào)，又是否有辦法規(guī)避其缺點(diǎn)呢滑黔？那需要弄清楚其本質(zhì)笆包，為什么回調(diào)是必須的环揽？還有使用回調(diào)時克服的那些缺點(diǎn)又是為了什么？

答案是程序?yàn)榱酥雷约阂呀?jīng)干了什么庵佣？正在干什么歉胶？將來要干什么？換言之巴粪，程序得知道當(dāng)前所處的狀態(tài)通今，而且要將這個狀態(tài)在不同的回調(diào)之間延續(xù)下去。

多個回調(diào)之間的狀態(tài)管理困難肛根，那讓每個回調(diào)都能管理自己的狀態(tài)怎么樣辫塌？鏈?zhǔn)秸{(diào)用會有棧撕裂的困難，讓回調(diào)之間不再鏈?zhǔn)秸{(diào)用怎樣派哲？不鏈?zhǔn)秸{(diào)用的話臼氨，那又如何讓被調(diào)用者知道已經(jīng)完成了？那就讓這個回調(diào)通知那個回調(diào)如何芭届？而且一個回調(diào)储矩，不就是一個待處理任務(wù)嗎？

任務(wù)之間得相互通知褂乍，每個任務(wù)得有自己的狀態(tài)持隧。那不就是很古老的編程技法：協(xié)作式多任務(wù)？然而要在單線程內(nèi)做調(diào)度树叽，啊哈舆蝴，協(xié)程！每個協(xié)程具有自己的棧幀题诵，當(dāng)然能知道自己處于什么狀態(tài)洁仗，協(xié)程之間可以協(xié)作那自然可以通知別的協(xié)程。

4.3 協(xié)程

  • 協(xié)程(Co-routine)性锭，即是協(xié)作式的例程赠潦。

它是非搶占式的多任務(wù)子例程的概括，可以允許有多個入口點(diǎn)在例程中確定的位置來控制程序的暫停與恢復(fù)執(zhí)行草冈。

例程是什么她奥？編程語言定義的可被調(diào)用的代碼段，為了完成某個特定功能而封裝在一起的一系列指令怎棱。一般的編程語言都用稱為函數(shù)或方法的代碼結(jié)構(gòu)來體現(xiàn)哩俭。

4.4 基于生成器的協(xié)程

早期的 Pythoner 發(fā)現(xiàn) Python 中有種特殊的對象——生成器（Generator），它的特點(diǎn)和協(xié)程很像拳恋。每一次迭代之間凡资，會暫停執(zhí)行，繼續(xù)下一次迭代的時候還不會丟失先前的狀態(tài)谬运。

為了支持用生成器做簡單的協(xié)程隙赁，Python 2.5 對生成器進(jìn)行了增強(qiáng)(PEP 342)垦藏，該增強(qiáng)提案的標(biāo)題是 “Coroutines via Enhanced Generators”。有了PEP 342的加持伞访，生成器可以通過yield 暫停執(zhí)行和向外返回數(shù)據(jù)掂骏，也可以通過send()向生成器內(nèi)發(fā)送數(shù)據(jù)，還可以通過throw()向生成器內(nèi)拋出異常以便隨時終止生成器的運(yùn)行厚掷。

接下來弟灼，我們用基于生成器的協(xié)程來重構(gòu)先前的爬蟲代碼。

4.4.1 未來對象(Future)

不用回調(diào)的方式了蝗肪，怎么知道異步調(diào)用的結(jié)果呢袜爪？先設(shè)計一個對象，異步調(diào)用執(zhí)行完的時候薛闪，就把結(jié)果放在它里面。這種對象稱之為未來對象俺陋。

image

未來對象有一個result屬性豁延，用于存放未來的執(zhí)行結(jié)果。還有個set_result()方法腊状，是用于設(shè)置result的诱咏，并且會在給result綁定值以后運(yùn)行事先給future添加的回調(diào)〗赏冢回調(diào)是通過未來對象的add_done_callback()方法添加的袋狞。

不要疑惑此處的callback，說好了不回調(diào)的嘛映屋？難道忘了我們曾經(jīng)說的要異步苟鸯，必回調(diào)。不過也別急棚点，此處的回調(diào)早处，和先前學(xué)到的回調(diào)，還真有點(diǎn)不一樣瘫析。

4.4.2 重構(gòu) Crawler

現(xiàn)在不論如何砌梆，我們有了未來對象可以代表未來的值。先用Future來重構(gòu)爬蟲代碼贬循。

image

和先前的回調(diào)版本對比咸包，已經(jīng)有了較大差異。fetch 方法內(nèi)有了yield表達(dá)式杖虾，使它成為了生成器烂瘫。我們知道生成器需要先調(diào)用next()迭代一次或者是先send(None)啟動，遇到yield之后便暫停亏掀。那這fetch生成器如何再次恢復(fù)執(zhí)行呢忱反？至少 Future 和 Crawler都沒看到相關(guān)代碼泛释。

4.4.3 任務(wù)對象(Task)

為了解決上述問題，我們只需遵循一個編程規(guī)則：單一職責(zé)温算，每種角色各司其職怜校，如果還有工作沒有角色來做，那就創(chuàng)建一個角色去做注竿。沒人來恢復(fù)這個生成器的執(zhí)行么茄茁？沒人來管理生成器的狀態(tài)么？創(chuàng)建一個巩割，就叫Task好了裙顽，很合適的名字。

image

上述代碼中Task封裝了coro對象宣谈，即初始化時傳遞給他的對象愈犹，被管理的任務(wù)是待執(zhí)行的協(xié)程，故而這里的coro就是fetch()生成器闻丑。它還有個step()方法漩怎，在初始化的時候就會執(zhí)行一遍。step()內(nèi)會調(diào)用生成器的send()方法嗦嗡，初始化第一次發(fā)送的是None就驅(qū)動了coro即fetch()的第一次執(zhí)行勋锤。

send()完成之后，得到下一次的future侥祭，然后給下一次的future添加step()回調(diào)叁执。原來add_done_callback()不是給寫爬蟲業(yè)務(wù)邏輯用的。此前的callback可就干的是業(yè)務(wù)邏輯呀矮冬。

再看fetch()生成器谈宛，其內(nèi)部寫完了所有的業(yè)務(wù)邏輯，包括如何發(fā)送請求欢伏，如何讀取響應(yīng)入挣。而且注冊給selector的回調(diào)相當(dāng)簡單，就是給對應(yīng)的future對象綁定結(jié)果值硝拧。兩個yield表達(dá)式都是返回對應(yīng)的future對象径筏，然后返回Task.step()之內(nèi)，這樣Task, Future, Coroutine三者精妙地串聯(lián)在了一起障陶。

初始化Task對象以后滋恬，把fetch()給驅(qū)動到了第44行yied f就完事了，接下來怎么繼續(xù)抱究？

4.4.4 事件循環(huán)(Event Loop)驅(qū)動協(xié)程運(yùn)行

該事件循環(huán)上場了恢氯。接下來，只需等待已經(jīng)注冊的EVENT_WRITE事件發(fā)生。事件循環(huán)就像心臟一般勋拟，只要它開始跳動勋磕，整個程序就會持續(xù)運(yùn)行。

image

注：總體耗時約0.43秒敢靡。

現(xiàn)在loop有了些許變化挂滓，callback()不再傳遞event_key和event_mask參數(shù)。也就是說啸胧，這里的回調(diào)根本不關(guān)心是誰觸發(fā)了這個事件赶站，結(jié)合fetch()可以知道，它只需完成對future設(shè)置結(jié)果值即可f.set_result()纺念。而且future是誰它也不關(guān)心贝椿，因?yàn)?strong>協(xié)程能夠保存自己的狀態(tài)，知道自己的future是哪個陷谱。也不用關(guān)心到底要設(shè)置什么值烙博，因?yàn)橐O(shè)置什么值也是協(xié)程內(nèi)安排的。

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

4.4.5 生成器協(xié)程風(fēng)格和回調(diào)風(fēng)格對比總結(jié)

在回調(diào)風(fēng)格中：

  • 存在鏈?zhǔn)交卣{(diào)（雖然示例中嵌套回調(diào)只有一層）

  • 請求和響應(yīng)也不得不分為兩個回調(diào)以至于破壞了同步代碼那種結(jié)構(gòu)

  • 程序員必須在回調(diào)之間維護(hù)必須的狀態(tài)眷唉。

還有更多示例中沒有展示，但確實(shí)存在的問題囤官，參見4.1節(jié)冬阳。

而基于生成器協(xié)程的風(fēng)格：

  • 無鏈?zhǔn)秸{(diào)用

  • selector的回調(diào)里只管給future設(shè)置值，不再關(guān)心業(yè)務(wù)邏輯

  • loop 內(nèi)回調(diào)callback()不再關(guān)注是誰觸發(fā)了事件

  • 已趨近于同步代碼的結(jié)構(gòu)

  • 無需程序員在多個協(xié)程之間維護(hù)狀態(tài)党饮，例如哪個才是自己的sock

4.4.6 碉堡了肝陪，但是代碼很丑！能不能重構(gòu)刑顺？

如果說fetch的容錯能力要更強(qiáng)氯窍，業(yè)務(wù)功能也需要更完善，怎么辦蹲堂？而且技術(shù)處理的部分（socket相關(guān)的）和業(yè)務(wù)處理的部分（請求與返回數(shù)據(jù)的處理）混在一起狼讨。

  • 創(chuàng)建socket連接可以抽象復(fù)用吧？

  • 循環(huán)讀取整個response可以抽象復(fù)用吧柒竞？

  • 循環(huán)內(nèi)處理socket.recv()的可以抽象復(fù)用吧政供？

但是這些關(guān)鍵節(jié)點(diǎn)的地方都有yield，抽離出來的代碼也需要是生成器。而且fetch()自己也得是生成器布隔。生成器里玩生成器离陶，代碼好像要寫得更丑才可以……

Python 語言的設(shè)計者們也認(rèn)識到了這個問題，再次秉承著“程序猿不必為難程序猿”的原則衅檀，他們搗鼓出了一個yield from來解決生成器里玩生成器的問題招刨。

4.5 用 yield from 改進(jìn)生成器協(xié)程

4.5.1 yield from語法介紹

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

第一個功能是：讓嵌套生成器不必通過循環(huán)迭代yield，而是直接yield from排苍。以下兩種在生成器里玩子生成器的方式是等價的沦寂。

def gen_one():
    subgen = range(10)    yield from subgendef gen_two():
    subgen = range(10)    for item in subgen:        yield item

第二個功能就是在子生成器和原生成器的調(diào)用者之間打開雙向通道，兩者可以直接通信淘衙。

def gen():
    yield from subgen()def subgen():
    while True:
        x = yield
        yield x+1def main():
    g = gen()
    next(g)                # 驅(qū)動生成器g開始執(zhí)行到第一個 yield
    retval = g.send(1)     # 看似向生成器 gen() 發(fā)送數(shù)據(jù)
    print(retval)          # 返回2
    g.throw(StopIteration) # 看似向gen()拋入異常

通過上述代碼清晰地理解了yield from的雙向通道功能传藏。關(guān)鍵字yield from在gen()內(nèi)部為subgen()和main()開辟了通信通道。main()里可以直接將數(shù)據(jù)1發(fā)送給subgen(),subgen()也可以將計算后的數(shù)據(jù)2返回到main()里彤守，main()里也可以直接向subgen()拋入異常以終止subgen()毯侦。

順帶一提，yield from 除了可以 yield from <generator> 還可以 yield from <iterable>具垫。

4.5.2 重構(gòu)代碼

抽象socket連接的功能:

image

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

image

三個關(guān)鍵點(diǎn)的抽象已經(jīng)完成侈离，現(xiàn)在重構(gòu)Crawler類：

image

上面代碼整體來講沒什么問題，可復(fù)用的代碼已經(jīng)抽象出去筝蚕，作為子生成器也可以使用 yield from 語法來獲取值卦碾。但另外有個點(diǎn)需要注意：在第24和第35行返回future對象的時候，我們了yield from f 而不是原來的yield f起宽。yield可以直接作用于普通Python對象洲胖，而yield from卻不行，所以我們對Future還要進(jìn)一步改造坯沪，把它變成一個iterable對象就可以了绿映。

image

只是增加了__iter__()方法的實(shí)現(xiàn)。如果不把Future改成iterable也是可以的腐晾，還是用原來的yield f即可叉弦。那為什么需要改進(jìn)呢？

首先赴魁，我們是在基于生成器做協(xié)程卸奉，而生成器還得是生成器，如果繼續(xù)混用yield和yield from 做協(xié)程颖御，代碼可讀性和可理解性都不好榄棵。其次凝颇，如果不改，協(xié)程內(nèi)還得關(guān)心它等待的對象是否可被yield疹鳄，如果協(xié)程里還想繼續(xù)返回協(xié)程怎么辦拧略？如果想調(diào)用普通函數(shù)動態(tài)生成一個Future對象再返回怎么辦？

所以瘪弓，在Python 3.3 引入yield from新語法之后垫蛆，就不再推薦用yield去做協(xié)程。全都使用yield from由于其雙向通道的功能腺怯，可以讓我們在協(xié)程間隨心所欲地傳遞數(shù)據(jù)袱饭。

4.5.3 yield from改進(jìn)協(xié)程總結(jié)

用yield from改進(jìn)基于生成器的協(xié)程，代碼抽象程度更高呛占。使業(yè)務(wù)邏輯相關(guān)的代碼更精簡虑乖。由于其雙向通道功能可以讓協(xié)程之間隨心所欲傳遞數(shù)據(jù)，使Python異步編程的協(xié)程解決方案大大向前邁進(jìn)了一步晾虑。

于是Python語言開發(fā)者們充分利用yield from疹味，使 Guido 主導(dǎo)的Python異步編程框架Tulip迅速脫胎換骨，并迫不及待得讓它在 Python 3.4 中換了個名字asyncio以“實(shí)習(xí)生”角色出現(xiàn)在標(biāo)準(zhǔn)庫中帜篇。

4.5.4 asyncio 介紹

asyncio是Python 3.4 試驗(yàn)性引入的異步I/O框架（PEP 3156）糙捺，提供了基于協(xié)程做異步I/O編寫單線程并發(fā)代碼的基礎(chǔ)設(shè)施。其核心組件有事件循環(huán)（Event Loop）笙隙、協(xié)程(Coroutine）洪灯、任務(wù)(Task)、未來對象(Future)以及其他一些擴(kuò)充和輔助性質(zhì)的模塊竟痰。

在引入asyncio的時候婴渡，還提供了一個裝飾器@asyncio.coroutine用于裝飾使用了yield from的函數(shù)，以標(biāo)記其為協(xié)程凯亮。但并不強(qiáng)制使用這個裝飾器。

雖然發(fā)展到 Python 3.4 時有了yield from的加持讓協(xié)程更容易了哄尔，但是由于協(xié)程在Python中發(fā)展的歷史包袱所致，很多人仍然弄不明白生成器和協(xié)程的聯(lián)系與區(qū)別，也弄不明白yield 和 yield from 的區(qū)別澜公。這種混亂的狀態(tài)也違背Python之禪的一些準(zhǔn)則楔脯。

于是Python設(shè)計者們又快馬加鞭地在 3.5 中新增了async/await語法（PEP 492），對協(xié)程有了明確而顯式的支持鸣戴，稱之為原生協(xié)程啃沪。async/await 和 yield from這兩種風(fēng)格的協(xié)程底層復(fù)用共同的實(shí)現(xiàn)，而且相互兼容窄锅。

在Python 3.6 中asyncio庫“轉(zhuǎn)正”创千，不再是實(shí)驗(yàn)性質(zhì)的，成為標(biāo)準(zhǔn)庫的正式一員。

4.6 總結(jié)

行至此處追驴，我們已經(jīng)掌握了asyncio的核心原理械哟，學(xué)習(xí)了它的原型，也學(xué)習(xí)了異步I/O在 CPython 官方支持的生態(tài)下是如何一步步發(fā)展至今的殿雪。

實(shí)際上暇咆，真正的asyncio比我們前幾節(jié)中學(xué)到的要復(fù)雜得多，它還實(shí)現(xiàn)了零拷貝丙曙、公平調(diào)度爸业、異常處理、任務(wù)狀態(tài)管理等等使 Python 異步編程更完善的內(nèi)容亏镰。理解原理和原型對我們后續(xù)學(xué)習(xí)有莫大的幫助扯旷。

5 asyncio和原生協(xié)程初體驗(yàn)

本節(jié)中，我們將初步體驗(yàn)asyncio庫和新增語法async/await給我們帶來的便利拆挥。由于Python2-3的過度期間薄霜，Python3.0-3.4的使用者并不是太多，也為了不讓更多的人困惑纸兔，也因?yàn)?code>aysncio在3.6才轉(zhuǎn)正惰瓜，所以更深入學(xué)習(xí)asyncio庫的時候我們將使用async/await定義的原生協(xié)程風(fēng)格，yield from風(fēng)格的協(xié)程不再闡述（實(shí)際上它們可用很小的代價相互代替）汉矿。

image

對比生成器版的協(xié)程崎坊，使用asyncio庫后變化很大：

  • 沒有了yield 或 yield from，而是async/await

  • 沒有了自造的loop()洲拇，取而代之的是asyncio.get_event_loop()

  • 無需自己在socket上做異步操作奈揍，不用顯式地注冊和注銷事件，aiohttp庫已經(jīng)代勞

  • 沒有了顯式的 Future 和 Task赋续，asyncio已封裝

  • 更少量的代碼男翰，更優(yōu)雅的設(shè)計

說明：我們這里發(fā)送和接收HTTP請求不再自己操作socket的原因是，在實(shí)際做業(yè)務(wù)項(xiàng)目的過程中纽乱，要處理妥善地HTTP協(xié)議會很復(fù)雜蛾绎，我們需要的是功能完善的異步HTTP客戶端，業(yè)界已經(jīng)有了成熟的解決方案鸦列，DRY不是嗎租冠？

和同步阻塞版的代碼對比：

  • 異步化

  • 代碼量相當(dāng)（引入aiohttp框架后更少）

  • 代碼邏輯同樣簡單，跟同步代碼一樣的結(jié)構(gòu)薯嗤、一樣的邏輯

  • 接近10倍的性能提升

結(jié)語

到此為止顽爹，我們已經(jīng)深入地學(xué)習(xí)了異步編程是什么、為什么骆姐、在Python里是怎么樣發(fā)展的镜粤。我們找到了一種讓代碼看起來跟同步代碼一樣簡單捏题，而效率卻提升N倍（具體提升情況取決于項(xiàng)目規(guī)模、網(wǎng)絡(luò)環(huán)境繁仁、實(shí)現(xiàn)細(xì)節(jié)）的異步編程方法涉馅。它也沒有回調(diào)的那些缺點(diǎn)。

本系列教程接下來的一篇將是學(xué)習(xí)asyncio庫如何的使用黄虱，快速掌握它的主要內(nèi)容稚矿。后續(xù)我們還會深入探究asyncio的優(yōu)點(diǎn)與缺點(diǎn)，也會探討Python生態(tài)中其他異步I/O方案和asyncio的區(qū)別捻浦。

附

參考資料

  • 《A Web Crawler With asyncio Coroutines》

  • 《讓 CPU 告訴你硬盤和網(wǎng)絡(luò)到底有多慢》

相關(guān)代碼

已經(jīng)轉(zhuǎn)戰(zhàn)頭條了晤揣，不在這個平臺寫了，TT號：Python集結(jié)號

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 人面猴
    序言：七十年代末朱灿，一起剝皮案震驚了整個濱河市昧识，隨后出現(xiàn)的幾起案子，更是在濱河造成了極大的恐慌盗扒，老刑警劉巖跪楞，帶你破解...
    沈念sama閱讀 218,755評論 6贊 507
  • 死咒
    序言：濱河連續(xù)發(fā)生了三起死亡事件，死亡現(xiàn)場離奇詭異侣灶，居然都是意外死亡甸祭，警方通過查閱死者的電腦和手機(jī)，發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 93,305評論 3贊 395
  • 救了他兩次的神仙讓他今天三更去死
    文/潘曉璐 我一進(jìn)店門褥影，熙熙樓的掌柜王于貴愁眉苦臉地迎上來池户，“玉大人，你說我怎么就攤上這事凡怎⌒＝梗” “怎么了？”我有些...
    開封第一講書人閱讀 165,138評論 0贊 355
  • 道士緝兇錄：失蹤的賣姜人
    文/不壞的土叔 我叫張陵统倒，是天一觀的道長寨典。 經(jīng)常有香客問我，道長房匆，這世上最難降的妖魔是什么凝赛？ 我笑而不...
    開封第一講書人閱讀 58,791評論 1贊 295
  • ?港島之戀（遺憾婚禮）
    正文 為了忘掉前任，我火速辦了婚禮坛缕，結(jié)果婚禮上，老公的妹妹穿的比我還像新娘捆昏。我一直安慰自己赚楚，他們只是感情好，可當(dāng)我...
    茶點(diǎn)故事閱讀 67,794評論 6贊 392
  • 惡毒庶女頂嫁案：這布局不是一般人想出來的
    文/花漫 我一把揭開白布骗卜。 她就那樣靜靜地躺著宠页，像睡著了一般左胞。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上举户，一...
    開封第一講書人閱讀 51,631評論 1贊 305
  • 城市分裂傳說
    那天烤宙，我揣著相機(jī)與錄音，去河邊找鬼俭嘁。 笑死躺枕，一個胖子當(dāng)著我的面吹牛，可吹牛的內(nèi)容都是我干的供填。 我是一名探鬼主播拐云，決...
    沈念sama閱讀 40,362評論 3贊 418
  • 雙鴛鴦連環(huán)套：你想象不到人心有多黑
    文/蒼蘭香墨 我猛地睜開眼，長吁一口氣：“原來是場噩夢啊……” “哼近她！你這毒婦竟也來了叉瘩？” 一聲冷哼從身側(cè)響起，我...
    開封第一講書人閱讀 39,264評論 0贊 276
  • 萬榮殺人案實(shí)錄
    序言：老撾萬榮一對情侶失蹤粘捎，失蹤者是張志新（化名）和其女友劉穎薇缅，沒想到半個月后，有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體攒磨，經(jīng)...
    沈念sama閱讀 45,724評論 1贊 315
  • ?護(hù)林員之死
    正文 獨(dú)居荒郊野嶺守林人離奇死亡泳桦，尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 37,900評論 3贊 336
  • ?白月光啟示錄
    正文 我和宋清朗相戀三年，在試婚紗的時候發(fā)現(xiàn)自己被綠了咧纠。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片蓬痒。...
    茶點(diǎn)故事閱讀 40,040評論 1贊 350
  • 活死人
    序言：一個原本活蹦亂跳的男人離奇死亡，死狀恐怖漆羔，靈堂內(nèi)的尸體忽然破棺而出梧奢，到底是詐尸還是另有隱情，我是刑警寧澤演痒，帶...
    沈念sama閱讀 35,742評論 5贊 346
  • ?日本核電站爆炸內(nèi)幕
    正文 年R本政府宣布亲轨，位于F島的核電站，受9級特大地震影響鸟顺，放射性物質(zhì)發(fā)生泄漏惦蚊。R本人自食惡果不足惜，卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 41,364評論 3贊 330
  • 男人毒藥：我在死后第九天來索命
    文/蒙蒙 一讯嫂、第九天 我趴在偏房一處隱蔽的房頂上張望蹦锋。 院中可真熱鬧，春花似錦欧芽、人聲如沸莉掂。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,944評論 0贊 22
  • 一樁弒父案千扔，背后竟有這般陰謀
    文/蒼蘭香墨 我抬頭看了看天上的太陽憎妙。三九已至库正，卻和暖如春，著一層夾襖步出監(jiān)牢的瞬間厘唾，已是汗流浹背褥符。 一陣腳步聲響...
    開封第一講書人閱讀 33,060評論 1贊 270
  • 情欲美人皮
    我被黑心中介騙來泰國打工， 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留抚垃，地道東北人喷楣。 一個月前我還...
    沈念sama閱讀 48,247評論 3贊 371
  • 代替公主和親
    正文 我出身青樓，卻偏偏與公主長得像讯柔，于是被迫代替她去往敵國和親抡蛙。 傳聞我的和親對象是個殘疾皇子，可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 44,979評論 2贊 355

推薦閱讀更多精彩內(nèi)容