1 什么是異步編程

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

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

常見的阻塞形式有：網(wǎng)絡I/O阻塞、磁盤I/O阻塞、用戶輸入阻塞等。

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

1.2 非阻塞程序在等待某操作過程中，自身不被阻塞，可以繼續(xù)運行干別的事情，則稱該程序在該操作上是非阻塞的。

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

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

非阻塞的存在是因為阻塞存在，正因為某個操作阻塞導致的耗時與效率低下，我們才要把它變成非阻塞的。

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

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

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

1.4 異步為完成某個任務，不同程序單元之間過程中無需通信協(xié)調(diào)，也能完成任務的方式。

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

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

簡言之，異步意味著無序。

上文提到的“通信方式”通常是指異步和并發(fā)編程提供的同步原語，如信號量、鎖、同步隊列等等。我們需知道，雖然這些通信方式是為了讓多個程序在一定條件下同步執(zhí)行，但正因為是異步的存在，才需要這些通信方式。如果所有程序都是按序執(zhí)行，其本身就是同步的，又何需這些同步信號呢？

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

以利用有限的計算機資源使多個任務可以被實時或近實時執(zhí)行為目的。

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

以利用富余計算資源(多核CPU)加速完成多個任務為目的。

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

1.7 概念總結(jié)并行是為了利用多核加速多任務完成的進度

并發(fā)是為了讓獨立的子任務都有機會被盡快執(zhí)行，但不一定能加速整體進度

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

異步是高效地組織非阻塞任務的方式

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

1.8 異步編程以進程、線程、協(xié)程、函數(shù)/方法作為執(zhí)行任務程序的基本單位，結(jié)合回調(diào)、事件循環(huán)、信號量等機制，以提高程序整體執(zhí)行效率和并發(fā)能力的編程方式。

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

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

1.9 異步之難(nán)控制不住“計幾”寫的程序，因為其執(zhí)行順序不可預料，當下正要發(fā)生什么事件不可預料。在并行情況下更為復雜和艱難。

所以，幾乎所有的異步框架都將異步編程模型簡化：一次只允許處理一個事件。故而有關(guān)異步的討論幾乎都集中在了單線程內(nèi)。如果某事件處理程序需要長時間執(zhí)行，所有其他部分都會被阻塞。

所以，一旦采取異步編程，每個異步調(diào)用必須“足夠小”，不能耗時太久。如何拆分異步任務成了難題。程序下一步行為往往依賴上一步執(zhí)行結(jié)果，如何知曉上次異步調(diào)用已完成并獲取結(jié)果？

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

3 異步I/O進化之路

如今，地球上最發(fā)達、規(guī)模最龐大的計算機程序，莫過于因特網(wǎng)。而從CPU的時間觀中可知，網(wǎng)絡I/O是最大的I/O瓶頸，除了宕機沒有比它更慢的。所以，諸多異步框架都對準的是網(wǎng)絡I/O。

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

3.1 同步阻塞方式

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

注：總體耗時約為4.5秒。

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

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

3.2 改進方式：多進程

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

注：總體耗時約為 0.6 秒。

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

當進程數(shù)量大于CPU核心數(shù)量時，進程切換是必然需要的。

除了切換開銷，一般的服務器在能夠穩(wěn)定運行的前提下，可以同時處理的進程數(shù)在數(shù)十個到數(shù)百個規(guī)模。如果進程數(shù)量規(guī)模更大，系統(tǒng)運行將不穩(wěn)定，而且可用內(nèi)存資源往往也會不足。

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

除了切換開銷大，以及可支持的任務規(guī)模小之外，多進程還有其他缺點，如狀態(tài)共享等問題。

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

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

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

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

但是，多線程仍有問題，特別是Python里的多線程。首先，Python中的多線程因為GIL的存在，它們并不能利用CPU多核優(yōu)勢，一個Python進程中，只允許有一個線程處于運行狀態(tài)。那為什么結(jié)果還是如預期，耗時縮減到了十分之一？

因為在做阻塞的系統(tǒng)調(diào)用時，例如sock.connect(),sock.recv()時，當前線程會釋放GIL，讓別的線程有執(zhí)行機會。但是單個線程內(nèi)，在阻塞調(diào)用上還是阻塞的。

另外，線程是被OS調(diào)度，調(diào)度策略是搶占式的，以保證同等優(yōu)先級的線程都有均等的執(zhí)行機會，那帶來的問題是：并不知道下一時刻是哪個線程被運行，也不知道它正要執(zhí)行的代碼是什么。所以就可能存在競態(tài)條件。

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

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

3.4 非阻塞方式

先來看看最原始的非阻塞如何工作的。

總體耗時約4.3秒。

第9行代碼sock.setblocking(False)告訴OS，讓socket上阻塞調(diào)用都改為非阻塞的方式。上述代碼在執(zhí)行完 sock.connect() 和 sock.recv() 后的確不再阻塞，可以繼續(xù)往下執(zhí)行請求準備的代碼或者是執(zhí)行下一次讀取。

代碼變得更復雜也是上述原因所致。第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次下載任務仍然按序進行。所以總體執(zhí)行時間和同步阻塞相當。

3.5 非阻塞改進

3.5.1 epoll

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

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

select因其算法效率比較低，后來改進成了poll，再后來又有進一步改進，Linux內(nèi)核改進成了epoll模塊。

3.5.2 回調(diào)(Callback)

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

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

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

來看看改進在哪。

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

其次，導入了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ā)生后應該采取的回調(diào)函數(shù)。

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

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

為了解決上述問題，我們寫一個循環(huán)，去訪問selector模塊，等待它告訴我們當前是哪個事件發(fā)生了，應該對應哪個回調(diào)。這個等待事件通知的循環(huán)，稱之為事件循環(huán)。

selector.select()是一個阻塞調(diào)用，因為如果事件不發(fā)生，那應用程序就沒事件可處理，所以就干脆阻塞在這里等待事件發(fā)生。所以，selector機制(后文以此稱呼代指epoll/kqueue)是設計用來解決大量并發(fā)連接的。當系統(tǒng)中有大量非阻塞調(diào)用，能隨時產(chǎn)生事件的時候，selector機制才能發(fā)揮最大的威力。

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

總體耗時約0.45秒。

上述代碼異步執(zhí)行的過程：創(chuàng)建Crawler 實例；

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

fetch內(nèi)并無阻塞操作，該方法立即返回；

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

啟動事件循環(huán)，進入第1輪循環(huán)，阻塞在事件監(jiān)聽上；

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

進入第2輪事件循環(huán)，當某個下載任務有事件觸發(fā)，執(zhí)行其回調(diào)函數(shù)；此時已經(jīng)不能推測是哪個事件發(fā)生，因為有可能是上次connected里的EVENT_READ先被觸發(fā)，也可能是其他某個任務的EVENT_WRITE被觸發(fā)；(此時，原來在一個下載任務上會阻塞的那段時間被利用起來執(zhí)行另一個下載任務了)

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

3.5.4 總結(jié)

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

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

通過本節(jié)的學習，我們應該認識到，不論什么編程語言，但凡要做異步編程，上述的“事件循環(huán)+回調(diào)”這種模式是逃不掉的，盡管它可能用的不是epoll，也可能不是while循環(huán)。

為什么我們在某些異步編程中并沒有看到 CallBack 模式呢？這就是我們接下來要探討的問題。

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

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

考慮如下問題：如果回調(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())

Jesse comment：應該是do_b(do_a())吧？？額。。。。

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

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

上面實際也是回調(diào)地獄式的風格，但這不是主要矛盾。主要在于，原本從上而下的代碼結(jié)構(gòu)，要改成從內(nèi)到外的。先f，再e，再d，…，直到最外層 a 執(zhí)行完成。在同步版本中，執(zhí)行完a后執(zhí)行b，這是線程的指令指針控制著的流程，而在回調(diào)版本中，流程就是程序猿需要注意和安排的。共享狀態(tài)管理困難

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

錯誤處理困難

一連串的回調(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)用的返回值，以防錯誤吞沒。

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

to be continued...

總結(jié)

以上是生活随笔為你收集整理的深入理解python异步编程_深入理解Python异步编程的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。