轉(zhuǎn)一篇駒神的關(guān)于異步編程和Asyncio的文章菩颖。這是上篇誓琼，共三篇抓韩。
原文地址：http://aju.space/2017/07/31/Drive-into-python-asyncio-programming-part-1.html。
建議和《碉堡的Asyncio·中文版》結(jié)合看羽峰，收獲會更多趟咆！
Python asyncio異步編程中文教程，只此一篇足矣梅屉，一覽眾山兄瞪础！
徹底理解異步編程是什么坯汤、為什么虐唠、怎么樣。深入學(xué)習(xí)asyncio的基本原理和原型惰聂，了解生成器疆偿、協(xié)程在Python異步編程中是如何發(fā)展的。
前言
很多朋友對異步編程都處于“聽說很強大”的認知狀態(tài)搓幌。鮮有在生產(chǎn)項目中使用它杆故。而使用它的同學(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ā)作為主要“賣點”反镇，技術(shù)變化趨勢如此圃泡。Python 生態(tài)為不落人后，從2013年起由 Python 之父 Guido 親自操刀主持了Tulip(asyncio)項目的開發(fā)愿险。
本系列教程分為上中下篇，讓讀者深入理解Python異步編程价说，解決在使用異步編程中的疑惑辆亏，深入學(xué)習(xí)Python3中新增的asyncio庫和async/await語法，盡情享受 Python 帶來的簡潔優(yōu)雅和高效率鳖目。
關(guān)鍵詞：異步扮叨、非阻塞、并發(fā)领迈、asyncio彻磁、協(xié)程、Gevent狸捅、uvloop
1 什么是異步編程
通過學(xué)習(xí)相關(guān)概念衷蜓，我們逐步解釋異步編程是什么。
1.1 阻塞
- 程序未得到所需計算資源時被掛起的狀態(tài)尘喝。
- 程序在等待某個操作完成期間磁浇，自身無法繼續(xù)干別的事情，則稱該程序在該操作上是阻塞的朽褪。
- 常見的阻塞形式有：網(wǎng)絡(luò)I/O阻塞置吓、磁盤I/O阻塞、用戶輸入阻塞等缔赠。
阻塞是無處不在的衍锚，包括CPU切換上下文時，所有的進程都無法真正干事情嗤堰，它們也會被阻塞戴质。（如果是多核CPU則正在執(zhí)行上下文切換操作的核不可被利用。）
1.2 非阻塞
- 程序在等待某操作過程中梁棠，自身不被阻塞置森，可以繼續(xù)運行干別的事情，則稱該程序在該操作上是非阻塞的符糊。
- 非阻塞并不是在任何程序級別凫海、任何情況下都可以存在的。
- 僅當程序封裝的級別可以囊括獨立的子程序單元時男娄，它才可能存在非阻塞狀態(tài)行贪。
非阻塞的存在是因為阻塞存在漾稀，正因為某個操作阻塞導(dǎo)致的耗時與效率低下，我們才要把它變成非阻塞的建瘫。
1.3 同步
- 不同程序單元為了完成某個任務(wù)崭捍，在執(zhí)行過程中需靠某種通信方式以協(xié)調(diào)一致，稱這些程序單元是同步執(zhí)行的啰脚。
- 例如購物系統(tǒng)中更新商品庫存殷蛇，需要用“行鎖”作為通信信號，讓不同的更新請求強制排隊順序執(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ā)編程提供的同步原語沈跨，如信號量、鎖兔综、同步隊列等等饿凛。我們需知道，雖然這些通信方式是為了讓多個程序在一定條件下同步執(zhí)行软驰，但正因為是異步的存在涧窒，才需要這些通信方式。如果所有程序都是按序執(zhí)行锭亏，其本身就是同步的纠吴，又何需這些同步信號呢？
1.5 并發(fā)
- 并發(fā)描述的是程序的組織結(jié)構(gòu)慧瘤。指程序要被設(shè)計成多個可獨立執(zhí)行的子任務(wù)戴已。
- 以利用有限的計算機資源使多個任務(wù)可以被實時或近實時執(zhí)行為目的固该。
1.6 并行
- 并行描述的是程序的執(zhí)行狀態(tài)。指多個任務(wù)同時被執(zhí)行糖儡。
- 以利用富余計算資源（多核CPU）加速完成多個任務(wù)為目的伐坏。
并發(fā)提供了一種程序組織結(jié)構(gòu)方式，讓問題的解決方案可以并行執(zhí)行握联，但并行執(zhí)行不是必須的桦沉。
1.7 概念總結(jié)
- 并行是為了利用多核加速多任務(wù)完成的進度
- 并發(fā)是為了讓獨立的子任務(wù)都有機會被盡快執(zhí)行，但不一定能加速整體進度
- 非阻塞是為了提高程序整體執(zhí)行效率
- 異步是高效地組織非阻塞任務(wù)的方式
要支持并發(fā)金闽，必須拆分為多任務(wù)永部，不同任務(wù)相對而言才有阻塞/非阻塞、同步/異步呐矾。所以，并發(fā)懦砂、異步蜒犯、非阻塞三個詞總是如影隨形。
1.8 異步編程
- 以進程荞膘、線程罚随、協(xié)程、函數(shù)/方法作為執(zhí)行任務(wù)程序的基本單位羽资，結(jié)合回調(diào)淘菩、事件循環(huán)、信號量等機制屠升，以提高程序整體執(zhí)行效率和并發(fā)能力的編程方式潮改。
如果在某程序的運行時，能根據(jù)已經(jīng)執(zhí)行的指令準確判斷它接下來要進行哪個具體操作腹暖，那它是同步程序汇在，反之則為異步程序。（無序與有序的區(qū)別）
同步/異步脏答、阻塞/非阻塞并非水火不容糕殉，要看討論的程序所處的封裝級別。例如購物程序在處理多個用戶的瀏覽請求可以是異步的殖告，而更新庫存時必須是同步的阿蝶。
1.9 異步之難(nán)
- 控制不住“計幾”寫的程序，因為其執(zhí)行順序不可預(yù)料黄绩，當下正要發(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 苦心異步為哪般
如上文所述闪唆，異步編程面臨諸多難點盅粪，Python 之父親自上陣打磨4年才使 asyncio 模塊在Python 3.6中“轉(zhuǎn)正”，如此苦心為什么悄蕾？答案只有一個：它值得票顾！下面我們看看為何而值得。
2.1 CPU的時間觀
我們將一個 2.6GHz 的 CPU 擬人化帆调，假設(shè)它執(zhí)行一條命令的時間奠骄，他它感覺上過了一秒鐘。CPU是計算機的處理核心番刊，也是最寶貴的資源戚揭，如果有浪費CPU的運行時間，導(dǎo)致其利用率不足撵枢，那程序效率必然低下（因為實際上有資源可以使效率更高）民晒。
如上圖所示，在千兆網(wǎng)上傳輸2KB數(shù)據(jù)锄禽，CPU感覺過了14個小時潜必，如果是在10M的公網(wǎng)上呢？那效率會低百倍沃但！如果在這么長的一段時間內(nèi)磁滚，CPU只是傻等結(jié)果而不能去干其他事情，是不是在浪費CPU的青春？
魯迅說垂攘，浪費“CPU”的時間等于謀財害命维雇。而兇手就是程序猿。
2.2 面臨的問題
- 成本問題
如果一個程序不能有效利用一臺計算機資源晒他，那必然需要更多的計算機通過運行更多的程序?qū)嵗齺韽浹a需求缺口吱型。例如爬蟲組數(shù)據(jù)流系統(tǒng)在改版后，由原來的7臺服務(wù)器削減至3臺陨仅，成本驟降57%津滞。一臺AWS m4.xlarge 型通用服務(wù)器按需付費實例一年價格約 1.2 萬人民幣。
- 效率問題
如果不在乎錢的消耗灼伤，那也會在意效率問題触徐。當服務(wù)器數(shù)量堆疊到一定規(guī)模后，如果不改進軟件架構(gòu)和實現(xià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萬的連接隘世。（兩種類型的計算機資源在各自的時代都約為1200美元）
成本和效率問題是從企業(yè)經(jīng)營角度講，C10k/C10M問題則是從技術(shù)角度出發(fā)挑戰(zhàn)軟硬件極限鸠踪。C10k/C10M 問題得解丙者，成本問題和效率問題迎刃而解。
2.3 解決方案
《約束理論與企業(yè)優(yōu)化》中指出：“除了瓶頸之外营密，任何改進都是幻覺械媒。”
CPU告訴我們，它自己很快纷捞，而上下文切換慢痢虹、內(nèi)存讀數(shù)據(jù)慢、磁盤尋址與取數(shù)據(jù)慢主儡、網(wǎng)絡(luò)傳輸慢……總之奖唯，離開CPU 后的一切，除了一級高速緩存缀辩，都很慢臭埋。我們觀察計算機的組成可以知道，主要由運算器臀玄、控制器瓢阴、存儲器、輸入設(shè)備健无、輸出設(shè)備五部分組成荣恐。運算器和控制器主要集成在CPU中，除此之外全是I/O累贤，包括讀寫內(nèi)存叠穆、讀寫磁盤、讀寫網(wǎng)卡全都是I/O臼膏。I/O成了最大的瓶頸硼被。
異步程序可以提高效率，而最大的瓶頸在I/O渗磅，業(yè)界誕生的解決方案沒出意料：異步I/O吧嚷硫，異步I/O吧，異步I/O吧吧始鱼！
3 異步I/O進化之路
如今仔掸，地球上最發(fā)達、規(guī)模最龐大的計算機程序医清，莫過于因特網(wǎng)起暮。而從CPU的時間觀中可知，網(wǎng)絡(luò)I/O是最大的I/O瓶頸会烙，除了宕機沒有比它更慢的负懦。所以，諸多異步框架都對準的是網(wǎng)絡(luò)I/O柏腻。
我們從一個爬蟲例子說起密似，從因特網(wǎng)上下載10篇網(wǎng)頁。
3.1 同步阻塞方式
最容易想到的解決方案就是依次下載葫盼，從建立socket連接到發(fā)送網(wǎng)絡(luò)請求再到讀取響應(yīng)數(shù)據(jù)残腌，順序進行。
注：總體耗時約為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)鍵點。一是第10行的 sock.connect(('example.com', 80))掀亩，該調(diào)用的作用是向example.com主機的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)用在默認情況下是阻塞的。
注：sock.send()函數(shù)并不會阻塞太久按傅，它只負責將請求數(shù)據(jù)拷貝到TCP/IP協(xié)議棧的系統(tǒng)緩沖區(qū)中就返回捉超，并不等待服務(wù)端返回的應(yīng)答確認。
假設(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 改進方式：多進程
在一個程序內(nèi)，依次執(zhí)行10次太耗時扔水，那開10個一樣的程序同時執(zhí)行不就行了痛侍。于是我們想到了多進程編程。為什么我們會先想到多進程呢魔市？發(fā)展脈絡(luò)如此主届。在更早的操作系統(tǒng)（Linux 2.4）及其以前，進程是 OS 調(diào)度任務(wù)的實體待德，是面向進程設(shè)計的OS君丁。
注：總體耗時約為 0.6 秒。
改善效果立竿見影磅网。但仍然有問題谈截。總體耗時并沒有縮減到原來的十分之一涧偷，而是九分之一左右簸喂，還有一些時間耗到哪里去了？進程切換開銷燎潮。
進程切換開銷不止像“CPU的時間觀”所列的“上下文切換”那么低喻鳄。CPU從一個進程切換到另一個進程，需要把舊進程運行時的寄存器狀態(tài)确封、內(nèi)存狀態(tài)全部保存好除呵，再將另一個進程之前保存的數(shù)據(jù)恢復(fù)。對CPU來講爪喘，幾個小時就干等著颜曾。當進程數(shù)量大于CPU核心數(shù)量時，進程切換是必然需要的秉剑。
除了切換開銷泛豪，多進程還有另外的缺點。一般的服務(wù)器在能夠穩(wěn)定運行的前提下侦鹏，可以同時處理的進程數(shù)在數(shù)十個到數(shù)百個規(guī)模诡曙。如果進程數(shù)量規(guī)模更大，系統(tǒng)運行將不穩(wěn)定略水，而且可用內(nèi)存資源往往也會不足价卤。
多進程解決方案在面臨每天需要成百上千萬次下載任務(wù)的爬蟲系統(tǒng)，或者需要同時搞定數(shù)萬并發(fā)的電商系統(tǒng)來說渊涝，并不適合慎璧。
除了切換開銷大床嫌，以及可支持的任務(wù)規(guī)模小之外，多進程還有其他缺點炸卑，如狀態(tài)共享等問題既鞠，后文會有提及，此處不再細究盖文。
3.3 繼續(xù)改進：多線程
由于線程的數(shù)據(jù)結(jié)構(gòu)比進程更輕量級嘱蛋，同一個進程可以容納多個線程，從進程到線程的優(yōu)化由此展開五续。后來的OS也把調(diào)度單位由進程轉(zhuǎn)為線程洒敏，進程只作為線程的容器，用于管理進程所需的資源疙驾。而且OS級別的線程是可以被分配到不同的CPU核心同時運行的凶伙。
注：總體運行時間約0.43秒。
結(jié)果符合我們預(yù)期它碎，比多進程耗時要少些函荣。從運行時間上看，多線程似乎已經(jīng)解決了切換開銷大的問題扳肛。而且可支持的任務(wù)數(shù)量規(guī)模傻挂，也變成了數(shù)百個到數(shù)千個。
但是挖息，多線程仍有問題金拒，特別是Python里的多線程。首先套腹，Python中的多線程因為GIL的存在绪抛，它們并不能利用CPU多核優(yōu)勢，一個Python進程中电禀，只允許有一個線程處于運行狀態(tài)幢码。那為什么結(jié)果還是如預(yù)期，耗時縮減到了十分之一尖飞？
因為在做阻塞的系統(tǒng)調(diào)用時症副，例如sock.connect(),sock.recv()時，當前線程會釋放GIL葫松，讓別的線程有執(zhí)行機會瓦糕。但是單個線程內(nèi)底洗，在阻塞調(diào)用上還是阻塞的腋么。
小提示：Python中 time.sleep 是阻塞的，都知道使用它要謹慎亥揖，但在多線程編程中珊擂，time.sleep 并不會阻塞其他線程圣勒。
除了GIL之外，所有的多線程還有通病摧扇。它們是被OS調(diào)度圣贸，調(diào)度策略是搶占式的，以保證同等優(yōu)先級的線程都有均等的執(zhí)行機會扛稽，那帶來的問題是：并不知道下一時刻是哪個線程被運行吁峻，也不知道它正要執(zhí)行的代碼是什么。所以就可能存在競態(tài)條件在张。
例如爬蟲工作線程從任務(wù)隊列拿待抓取URL的時候用含，如果多個爬蟲線程同時來取，那這個任務(wù)到底該給誰帮匾？那就需要用到“鎖”或“同步隊列”來保證下載任務(wù)不會被重復(fù)執(zhí)行啄骇。
而且線程支持的多任務(wù)規(guī)模，在數(shù)百到數(shù)千的數(shù)量規(guī)模瘟斜。在大規(guī)模的高頻網(wǎng)絡(luò)交互系統(tǒng)中缸夹，仍然有些吃力。當然螺句，多線程最主要的問題還是競態(tài)條件虽惭。
3.4 非阻塞方式
終于，我們來到了非阻塞解決方案壹蔓。先來看看最原始的非阻塞如何工作的趟妥。
注：總體耗時約4.3秒。
首先注意到兩點佣蓉，就感覺被騙了披摄。一是耗時與同步阻塞相當，二是代碼更復(fù)雜勇凭。要非阻塞何用责语？且慢暖释。
上圖第9行代碼sock.setblocking(False)告訴OS，讓socket上阻塞調(diào)用都改為非阻塞的方式。之前我們說到枫吧，非阻塞就是在做一件事的時候，不阻礙調(diào)用它的程序做別的事情泣特。上述代碼在執(zhí)行完 sock.connect() 和 sock.recv() 后的確不再阻塞勋桶，可以繼續(xù)往下執(zhí)行請求準備的代碼或者是執(zhí)行下一次讀取。
代碼變得更復(fù)雜也是上述原因所致蘸吓。第11行要放在try語句內(nèi)善炫，是因為socket在發(fā)送非阻塞連接請求過程中，系統(tǒng)底層也會拋出異常库继。connect()被調(diào)用之后箩艺，立即可以往下執(zhí)行第15和16行的代碼窜醉。
需要while循環(huán)不斷嘗試 send()，是因為connect()已經(jīng)非阻塞艺谆，在send()之時并不知道 socket 的連接是否就緒榨惰，只有不斷嘗試，嘗試成功為止静汤，即發(fā)送數(shù)據(jù)成功了琅催。recv()調(diào)用也是同理。
雖然 connect() 和 recv() 不再阻塞主程序虫给，空出來的時間段CPU沒有空閑著恢暖，但并沒有利用好這空閑去做其他有意義的事情，而是在循環(huán)嘗試讀寫 socket （不停判斷非阻塞調(diào)用的狀態(tài)是否就緒）狰右。還得處理來自底層的可忽略的異常杰捂。也不能同時處理多個 socket 。
然后10次下載任務(wù)仍然按序進行棋蚌。所以總體執(zhí)行時間和同步阻塞相當嫁佳。如果非得這樣子，那還不如同步阻塞算了谷暮。
3.5 非阻塞改進
3.5.1 epoll
判斷非阻塞調(diào)用是否就緒如果 OS 能做蒿往，是不是應(yīng)用程序就可以不用自己去等待和判斷了，就可以利用這個空閑去做其他事情以提高效率湿弦。
所以O(shè)S將I/O狀態(tài)的變化都封裝成了事件瓤漏，如可讀事件、可寫事件颊埃。并且提供了專門的系統(tǒng)模塊讓應(yīng)用程序可以接收事件通知蔬充。這個模塊就是select。讓應(yīng)用程序可以通過select注冊文件描述符和回調(diào)函數(shù)班利。當文件描述符的狀態(tài)發(fā)生變化時饥漫，select 就調(diào)用事先注冊的回調(diào)函數(shù)。
select因其算法效率比較低罗标，后來改進成了poll庸队，再后來又有進一步改進，BSD內(nèi)核改進成了kqueue模塊闯割，而Linux內(nèi)核改進成了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ù)封裝成獨立的函數(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)機制重構(gòu)爬蟲代碼：
此處和前面稍有不同的是者甲，我們將下載不同的10個頁面，相對URL路徑存放于urls_todo集合中∑龃矗現(xiàn)在看看改進在哪虏缸。
首先，不斷嘗試send() 和 recv() 的兩個循環(huán)被消滅掉了嫩实。
其次刽辙，導(dǎo)入了selectors模塊，并創(chuàng)建了一個DefaultSelector 實例甲献。Python標準庫提供的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實例语淘，就有20個事件將要發(fā)生，那如何從selector里獲取當前正發(fā)生的事件际歼，并且得到對應(yīng)的回調(diào)函數(shù)去執(zhí)行呢惶翻？
3.5.3 事件循環(huán)（Event Loop）
為了解決上述問題，那我們只得采用老辦法鹅心，寫一個循環(huán)吕粗，去訪問selector模塊，等待它告訴我們當前是哪個事件發(fā)生了旭愧，應(yīng)該對應(yīng)哪個回調(diào)颅筋。這個等待事件通知的循環(huán)宙暇，稱之為事件循環(huán)。
上述代碼中议泵，我們用stopped全局變量控制事件循環(huán)何時停止占贫。當urls_todo消耗完畢后，會標記stopped為True先口。
重要的是第49行代碼型奥，selector.select() 是一個阻塞調(diào)用，因為如果事件不發(fā)生碉京，那應(yīng)用程序就沒事件可處理厢汹，所以就干脆阻塞在這里等待事件發(fā)生。那可以推斷谐宙，如果只下載一篇網(wǎng)頁烫葬，一定要connect()之后才能send()繼而recv()，那它的效率和阻塞的方式是一樣的凡蜻。因為不在connect()/recv()上阻塞厘灼，也得在select()上阻塞。
所以咽瓷，selector機制(后文以此稱呼代指epoll/kqueue)是設(shè)計用來解決大量并發(fā)連接的设凹。當系統(tǒng)中有大量非阻塞調(diào)用，能隨時產(chǎn)生事件的時候茅姜，selector機制才能發(fā)揮最大的威力闪朱。
下面是如何啟創(chuàng)建10個下載任務(wù)和啟動事件循環(huán)的：
注：總體耗時約0.45秒。
上述執(zhí)行結(jié)果令人振奮钻洒。在單線程內(nèi)用 事件循環(huán)+回調(diào) 搞定了10篇網(wǎng)頁同時下載的問題奋姿。這，已經(jīng)是異步編程了素标。雖然有一個for 循環(huán)順序地創(chuàng)建Crawler 實例并調(diào)用 fetch 方法称诗，但是fetch 內(nèi)僅有connect()和注冊可寫事件，而且從執(zhí)行時間明顯可以推斷头遭，多個下載任務(wù)確實在同時進行寓免！
上述代碼異步執(zhí)行的過程：
- 創(chuàng)建Crawler 實例；
- 調(diào)用fetch方法计维，會創(chuàng)建socket連接和在selector上注冊可寫事件袜香；
- fetch內(nèi)并無阻塞操作，該方法立即返回鲫惶；
- 重復(fù)上述3個步驟蜈首，將10個不同的下載任務(wù)都加入事件循環(huán)；
- 啟動事件循環(huán)，進入第1輪循環(huán)欢策，阻塞在事件監(jiān)聽上吆寨；
- 當某個下載任務(wù)EVENT_WRITE被觸發(fā)，回調(diào)其connected方法踩寇，第一輪事件循環(huán)結(jié)束啄清；
- 進入第2輪事件循環(huán)，當某個下載任務(wù)有事件觸發(fā)姑荷，執(zhí)行其回調(diào)函數(shù)；此時已經(jīng)不能推測是哪個事件發(fā)生缩擂，因為有可能是上次connected里的EVENT_READ先被觸發(fā)鼠冕，也可能是其他某個任務(wù)的EVENT_WRITE被觸發(fā)；（此時胯盯，原來在一個下載任務(wù)上會阻塞的那段時間被利用起來執(zhí)行另一個下載任務(wù)了）
- 循環(huán)往復(fù)懈费，直至所有下載任務(wù)被處理完成
- 退出事件循環(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)完成疗杉，因此性能也更好阵谚，單機支持的任務(wù)規(guī)模也變成了數(shù)萬到數(shù)十萬個。（不過我們知道：沒有免費午餐烟具，也沒有銀彈梢什。）
部分編程語言中，對異步編程的支持就止步于此（不含語言官方之外的擴展）朝聋。需要程序猿直接使用epoll去注冊事件和回調(diào)嗡午、維護一個事件循環(huán)，然后大多數(shù)時間都花在設(shè)計回調(diào)函數(shù)上冀痕。
通過本節(jié)的學(xué)習(xí)荔睹，我們應(yīng)該認識到，不論什么編程語言言蛇，但凡要做異步編程应媚，上述的“事件循環(huán)+回調(diào)”這種模式是逃不掉的，盡管它可能用的不是epoll猜极，也可能不是while循環(huán)中姜。如果你找到了一種不屬于 “等會兒告訴你” 模型的異步方式，請立即給我打電話（注意，打電話是Call）丢胚。
為什么我們在某些異步編程中并沒有看到 CallBack 模式呢翩瓜？這就是我們接下來要探討的問題。本節(jié)是學(xué)習(xí)異步編程的一個終點携龟，也是另一個起點兔跌。畢竟咱們講 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)”的基本運行原理仅乓，可以基于這種方式在單線程內(nèi)實現(xiàn)異步編程。也確實能夠大大提高程序運行效率蓬戚。但是夸楣，剛才所學(xué)的只是最基本的，然而在生產(chǎn)項目中子漩，要應(yīng)對的復(fù)雜度會大大增加豫喧。考慮如下問題：
- 如果回調(diào)函數(shù)執(zhí)行不正常該如何幢泼？
- 如果回調(diào)里面還要嵌套回調(diào)怎么辦紧显？要嵌套很多層怎么辦？
- 如果嵌套了多層缕棵，其中某個環(huán)節(jié)出錯了會造成什么后果鸟妙？
- 如果有個數(shù)據(jù)需要被每個回調(diào)都處理怎么辦？
- ……
在實際編程中挥吵，上述系列問題不可避免重父。在這些問題的背后隱藏著回調(diào)編程模式的一些缺點：
- 回調(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)的操作時自上而下運行：
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(......))))))
上面實際也是回調(diào)地獄式的風(fēng)格折柠，但這不是主要矛盾。主要在于批狐，原本從上而下的代碼結(jié)構(gòu)扇售，要改成從外到內(nèi)的前塔。先a，再b承冰，再c华弓，…，直到最內(nèi)層 f 執(zhí)行完成困乒。在同步版本中寂屏，執(zhí)行完a后執(zhí)行b，這是線程的指令指針控制著的流程娜搂，而在回調(diào)版本中迁霎，流程就是程序猿需要注意和安排的。
共享狀態(tài)管理困難
回顧第3節(jié)爬蟲代碼百宇，同步阻塞版的sock對象從頭使用到尾考廉，而在回調(diào)的版本中，我們必須在Crawler實例化后的對象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)用出錯了，但實際是 d 出錯淆衷。所以缸榄，為了防止棧撕裂，異常必須以數(shù)據(jù)的形式返回祝拯，而不是直接拋出異常甚带，然后每個回調(diào)中需要檢查上次調(diào)用的返回值，以防錯誤吞沒。
如果說代碼風(fēng)格難看是小事欲低，但棧撕裂和狀態(tài)共享困難這兩個缺點會讓基于回調(diào)的異步編程很艱難辕宏。所以不同編程語言的生態(tài)都在致力于解決這個問題。才誕生了后來的Promise砾莱、Co-routine等解決方案瑞筐。
Python 生態(tài)也以終為始，秉承著“程序猿不必難程序猿”的原則腊瑟，讓語言和框架開發(fā)者苦逼一點聚假，也要讓應(yīng)用開發(fā)者舒坦。在事件循環(huán)+回調(diào)的基礎(chǔ)上衍生出了基于協(xié)程的解決方案闰非，代表作有 Tornado膘格、Twisted、asyncio 等财松。接下來我們隨著 Python 生態(tài)異步編程的發(fā)展過程瘪贱，深入理解Python異步編程。
4.2 核心問題
通過前面的學(xué)習(xí)辆毡，我們清楚地認識到異步編程最大的困難：異步任務(wù)何時執(zhí)行完畢菜秦？接下來要對異步調(diào)用的返回結(jié)果做什么操作？
上述問題我們已經(jīng)通過事件循環(huán)和回調(diào)解決了舶掖。但是回調(diào)會讓程序變得復(fù)雜球昨。要異步，必回調(diào)眨攘，又是否有辦法規(guī)避其缺點呢主慰？那需要弄清楚其本質(zhì)，為什么回調(diào)是必須的鲫售？還有使用回調(diào)時克服的那些缺點又是為了什么共螺？
答案是程序為了知道自己已經(jīng)干了什么？正在干什么情竹？將來要干什么藐不？換言之，程序得知道當前所處的狀態(tài)鲤妥，而且要將這個狀態(tài)在不同的回調(diào)之間延續(xù)下去佳吞。
多個回調(diào)之間的狀態(tài)管理困難，那讓每個回調(diào)都能管理自己的狀態(tài)怎么樣棉安？鏈式調(diào)用會有棧撕裂的困難底扳，讓回調(diào)之間不再鏈式調(diào)用怎樣？不鏈式調(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é)程具有自己的棧幀尘颓，當然能知道自己處于什么狀態(tài)，協(xié)程之間可以協(xié)作那自然可以通知別的協(xié)程晦譬。
4.3 協(xié)程
- 協(xié)程(Co-routine)疤苹，即是協(xié)作式的例程。
它是非搶占式的多任務(wù)子例程的概括敛腌，可以允許有多個入口點在例程中確定的位置來控制程序的暫停與恢復(fù)執(zhí)行卧土。
例程是什么？編程語言定義的可被調(diào)用的代碼段像樊，為了完成某個特定功能而封裝在一起的一系列指令尤莺。一般的編程語言都用稱為函數(shù)或方法的代碼結(jié)構(gòu)來體現(xiàn)。
4.4 基于生成器的協(xié)程
早期的 Pythoner 發(fā)現(xiàn) Python 中有種特殊的對象——生成器（Generator）凶硅，它的特點和協(xié)程很像缝裁。每一次迭代之間扫皱，會暫停執(zhí)行足绅，繼續(xù)下一次迭代的時候還不會丟失先前的狀態(tài)。
為了支持用生成器做簡單的協(xié)程韩脑，Python 2.5 對生成器進行了增強(PEP 342)氢妈，該增強提案的標題是 “Coroutines via Enhanced Generators”。有了PEP 342的加持段多，生成器可以通過yield 暫停執(zhí)行和向外返回數(shù)據(jù)首量，也可以通過send()向生成器內(nèi)發(fā)送數(shù)據(jù)，還可以通過throw()向生成器內(nèi)拋出異常以便隨時終止生成器的運行进苍。
接下來加缘，我們用基于生成器的協(xié)程來重構(gòu)先前的爬蟲代碼。
4.4.1 未來對象(Future)
不用回調(diào)的方式了觉啊，怎么知道異步調(diào)用的結(jié)果呢拣宏？先設(shè)計一個對象，異步調(diào)用執(zhí)行完的時候杠人，就把結(jié)果放在它里面勋乾。這種對象稱之為未來對象宋下。
未來對象有一個result屬性，用于存放未來的執(zhí)行結(jié)果辑莫。還有個set_result()方法学歧，是用于設(shè)置result的，并且會在給result綁定值以后運行事先給future添加的回調(diào)各吨≈Ρ浚回調(diào)是通過未來對象的add_done_callback()方法添加的。
不要疑惑此處的callback揭蜒，說好了不回調(diào)的嘛伺帘？難道忘了我們曾經(jīng)說的要異步，必回調(diào)忌锯。不過也別急伪嫁，此處的回調(diào)，和先前學(xué)到的回調(diào)偶垮，還真有點不一樣张咳。
4.4.2 重構(gòu) Crawler
現(xiàn)在不論如何，我們有了未來對象可以代表未來的值似舵。先用Future來重構(gòu)爬蟲代碼脚猾。
和先前的回調(diào)版本對比，已經(jīng)有了較大差異砚哗。fetch 方法內(nèi)有了yield表達式龙助，使它成為了生成器。我們知道生成器需要先調(diào)用next()迭代一次或者是先send(None)啟動蛛芥，遇到yield之后便暫停提鸟。那這fetch生成器如何再次恢復(fù)執(zhí)行呢？至少 Future 和 Crawler都沒看到相關(guān)代碼仅淑。
4.4.3 任務(wù)對象(Task)
為了解決上述問題称勋，我們只需遵循一個編程規(guī)則：單一職責，每種角色各司其職涯竟，如果還有工作沒有角色來做赡鲜，那就創(chuàng)建一個角色去做。沒人來恢復(fù)這個生成器的執(zhí)行么庐船？沒人來管理生成器的狀態(tài)么银酬？創(chuàng)建一個，就叫Task好了筐钟，很合適的名字揩瞪。
上述代碼中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)相當簡單涌萤，就是給對應(yīng)的future對象綁定結(jié)果值淹遵。兩個yield表達式都是返回對應(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é)程運行
該事件循環(huán)上場了。接下來崖堤，只需等待已經(jīng)注冊的EVENT_WRITE事件發(fā)生侍咱。事件循環(huán)就像心臟一般，只要它開始跳動倘感，整個程序就會持續(xù)運行放坏。
注：總體耗時約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)心镜廉，因為協(xié)程能夠保存自己的狀態(tài)，知道自己的future是哪個愚战。也不用關(guān)心到底要設(shè)置什么值娇唯，因為要設(shè)置什么值也是協(xié)程內(nèi)安排的齐遵。
此時的loop()，真的成了一個心臟塔插，它只管往外泵血梗摇，不論這份血液是要輸送給大腦還是要給腳趾，只要它還在跳動想许，生命就能延續(xù)伶授。
4.4.5 生成器協(xié)程風(fēng)格和回調(diào)風(fēng)格對比總結(jié)
在回調(diào)風(fēng)格中：
- 存在鏈式回調(diào)（雖然示例中嵌套回調(diào)只有一層）
- 請求和響應(yīng)也不得不分為兩個回調(diào)以至于破壞了同步代碼那種結(jié)構(gòu)
- 程序員必須在回調(diào)之間維護必須的狀態(tài)。
還有更多示例中沒有展示流纹，但確實存在的問題糜烹，參見4.1節(jié)。
而基于生成器協(xié)程的風(fēng)格：
- 無鏈式調(diào)用
- selector的回調(diào)里只管給future設(shè)置值漱凝，不再關(guān)心業(yè)務(wù)邏輯
- loop 內(nèi)回調(diào)callback()不再關(guān)注是誰觸發(fā)了事件
- 已趨近于同步代碼的結(jié)構(gòu)
- 無需程序員在多個協(xié)程之間維護狀態(tài)疮蹦，例如哪個才是自己的sock
4.4.6 碉堡了，但是代碼很丑茸炒！能不能重構(gòu)挚币？
如果說fetch的容錯能力要更強，業(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é)點的地方都有yield湿硝，抽離出來的代碼也需要是生成器薪前。而且fetch()自己也得是生成器。生成器里玩生成器关斜，代碼好像要寫得更丑才可以……
Python 語言的設(shè)計者們也認識到了這個問題示括，再次秉承著“程序猿不必為難程序猿”的原則，他們搗鼓出了一個yield from來解決生成器里玩生成器的問題痢畜。
4.5 用 yield from 改進生成器協(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 subgen
def 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+1
def 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連接的功能:
抽象單次recv()和讀取完整的response功能:
三個關(guān)鍵點的抽象已經(jīng)完成，現(xiàn)在重構(gòu)Crawler類：
上面代碼整體來講沒什么問題辜腺，可復(fù)用的代碼已經(jīng)抽象出去休建，作為子生成器也可以使用 yield from 語法來獲取值。但另外有個點需要注意：在第24和第35行返回future對象的時候评疗，我們了yield from f 而不是原來的yield f测砂。yield可以直接作用于普通Python對象，而yield from卻不行百匆，所以我們對Future還要進一步改造砌些，把它變成一個iterable對象就可以了。
只是增加了__iter__()方法的實現(xiàn)加匈。如果不把Future改成iterable也是可以的存璃，還是用原來的yield f即可。那為什么需要改進呢雕拼？
首先纵东，我們是在基于生成器做協(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改進協(xié)程總結(jié)
用yield from改進基于生成器的協(xié)程亩进，代碼抽象程度更高。使業(yè)務(wù)邏輯相關(guān)的代碼更精簡缩歪。由于其雙向通道功能可以讓協(xié)程之間隨心所欲傳遞數(shù)據(jù)，使Python異步編程的協(xié)程解決方案大大向前邁進了一步谍憔。
于是Python語言開發(fā)者們充分利用yield from匪蝙，使 Guido 主導(dǎo)的Python異步編程框架Tulip迅速脫胎換骨主籍，并迫不及待得讓它在 Python 3.4 中換了個名字asyncio以“實習(xí)生”角色出現(xiàn)在標準庫中。
4.5.4 asyncio 介紹
asyncio是Python 3.4 試驗性引入的異步I/O框架（PEP 3156）逛球，提供了基于協(xié)程做異步I/O編寫單線程并發(fā)代碼的基礎(chǔ)設(shè)施千元。其核心組件有事件循環(huán)（Event Loop）、協(xié)程(Coroutine）颤绕、任務(wù)(Task)幸海、未來對象(Future)以及其他一些擴充和輔助性質(zhì)的模塊。
在引入asyncio的時候奥务，還提供了一個裝飾器@asyncio.coroutine用于裝飾使用了yield from的函數(shù)物独，以標記其為協(xié)程。但并不強制使用這個裝飾器氯葬。
雖然發(fā)展到 Python 3.4 時有了yield from的加持讓協(xié)程更容易了挡篓，但是由于協(xié)程在Python中發(fā)展的歷史包袱所致，很多人仍然弄不明白生成器和協(xié)程的聯(lián)系與區(qū)別帚称，也弄不明白yield 和 yield from 的區(qū)別官研。這種混亂的狀態(tài)也違背Python之禪的一些準則。
于是Python設(shè)計者們又快馬加鞭地在 3.5 中新增了async/await語法（PEP 492）闯睹，對協(xié)程有了明確而顯式的支持戏羽，稱之為原生協(xié)程。async/await 和 yield from這兩種風(fēng)格的協(xié)程底層復(fù)用共同的實現(xiàn)楼吃，而且相互兼容蛛壳。
在Python 3.6 中asyncio庫“轉(zhuǎn)正”，不再是實驗性質(zhì)的所刀，成為標準庫的正式一員衙荐。
4.6 總結(jié)
行至此處，我們已經(jīng)掌握了asyncio的核心原理浮创，學(xué)習(xí)了它的原型忧吟，也學(xué)習(xí)了異步I/O在 CPython 官方支持的生態(tài)下是如何一步步發(fā)展至今的。
實際上斩披，真正的asyncio比我們前幾節(jié)中學(xué)到的要復(fù)雜得多溜族，它還實現(xiàn)了零拷貝、公平調(diào)度垦沉、異常處理煌抒、任務(wù)狀態(tài)管理等等使 Python 異步編程更完善的內(nèi)容。理解原理和原型對我們后續(xù)學(xué)習(xí)有莫大的幫助厕倍。
5 asyncio和原生協(xié)程初體驗
本節(jié)中寡壮，我們將初步體驗asyncio庫和新增語法async/await給我們帶來的便利。由于Python2-3的過度期間，Python3.0-3.4的使用者并不是太多况既，也為了不讓更多的人困惑这溅，也因為aysncio在3.6才轉(zhuǎn)正，所以更深入學(xué)習(xí)asyncio庫的時候我們將使用async/await定義的原生協(xié)程風(fēng)格棒仍，yield from風(fēng)格的協(xié)程不再闡述（實際上它們可用很小的代價相互代替）悲靴。
對比生成器版的協(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的原因是蛋褥，在實際做業(yè)務(wù)項目的過程中临燃，要處理妥善地HTTP協(xié)議會很復(fù)雜，我們需要的是功能完善的異步HTTP客戶端烙心，業(yè)界已經(jīng)有了成熟的解決方案膜廊，DRY不是嗎？
和同步阻塞版的代碼對比：
- 異步化
- 代碼量相當（引入aiohttp框架后更少）
- 代碼邏輯同樣簡單淫茵，跟同步代碼一樣的結(jié)構(gòu)爪瓜、一樣的邏輯
- 接近10倍的性能提升
結(jié)語
到此為止，我們已經(jīng)深入地學(xué)習(xí)了異步編程是什么匙瘪、為什么铆铆、在Python里是怎么樣發(fā)展的。我們找到了一種讓代碼看起來跟同步代碼一樣簡單丹喻，而效率卻提升N倍（具體提升情況取決于項目規(guī)模薄货、網(wǎng)絡(luò)環(huán)境、實現(xiàn)細節(jié)）的異步編程方法碍论。它也沒有回調(diào)的那些缺點谅猾。
本系列教程接下來的一篇將是學(xué)習(xí)asyncio庫如何的使用，快速掌握它的主要內(nèi)容鳍悠。后續(xù)我們還會深入探究asyncio的優(yōu)點與缺點税娜，也會探討Python生態(tài)中其他異步I/O方案和asyncio的區(qū)別。
