[譯] 異步編程：阻塞與非阻塞

異步編程：阻塞與非阻塞

原文：Asynchronous programming. Blocking I/O and non-blocking I/O

做者：luminousmen

這是關於異步編程系列的第一篇文章。整個系列試着回答一個簡單的問題，「什麼是異步？」

我在一開始深刻研究這個問題的時候，我覺得本身瞭解「異步」。但事實是關於「什麼是異步」我並無什麼頭緒，因此咱們來尋找答案吧！

整個系列：

• 異步編程：阻塞式IO與非阻塞式IO
• 異步編程：協做式多任務
• 異步編程：Await the Future
• 異步編程：Python3.5+

這篇文章中，咱們以網絡編程來討論，不過你能夠輕鬆的用其餘的IO操做來類比，好比文件操做。雖然文中的例子採用Python，但這些觀點並非僅僅針對某種特定的編程語言（我只想說—Python真香）。

---

在通常C/S架構的應用中，客戶端建立請求發送給服務端時，服務端會處理請求並響應，這個過程當中客戶端與服務端首先都須要創建與對方通訊的鏈接，這也就是sockets的做用啦。兩端爲socket綁定端口後服務端就會在本身的socket中監聽來自客戶端的請求。

若是你看過處理器的處理速度與網絡鏈接的比率，你就知道二者的差別是幾個數量級。事實上若是咱們的應用在進行I/O操做，那麼CPU絕大多數的時間什麼都不作，這種應用被稱爲「I/O-bound」。對於構建高效應用而言這是個大🤔麻煩，由於其餘的動做和I/O操做會一直等待着—事實上這些系統都很懶。

有三種方式操做I/O:阻塞式，非阻塞式，異步。最後一種不適用於網絡編程，因此對咱們而言只有前兩種選擇。

阻塞式I/O

這是在UNIX(POSIX)BSD sockets(Windows中相似，稱呼可能不一樣但邏輯是同樣的)中應用阻塞式I/O的例子。

在阻塞式I/O中，客戶端建立請求發送至服務端時，該連接的socket會被一直阻塞到數據讀取或寫入完畢。在這些操做完成以前服務端除了等待什麼也作不了。由此可知在單個線程中咱們沒法同時爲更多的鏈接提供服務。默認狀況下，TCP sockets 處於阻塞模式。

客戶端：

import socket

sock = socket.socket()

host = socket.gethostname()
sock.connect((host, 12345))

data = b"Foo Bar" *10*1024 	# Send a lot of data to be sent
assert sock.send(data) 		# Send data till true
print("Data sent")
複製代碼

服務端：

import socket

s = socket.socket()

host = socket.gethostname()
port = 12345

s.bind((host, port))
s.listen(5)

while True:
	conn, addr = s.accept()
	data = conn.recv(1024)	
	while data:
		print(data)
		data = conn.recv(1024)
	print("Data Received")
	conn.close()
	break
複製代碼

你會注意到服務端一直在打印消息，而且持續到全部數據發送完畢。在服務端的代碼中，「Data Received」不會被打印，這是由於客戶端了發送大量的數據，這將一直耗時到socket被阻塞（這一句有點懵逼，原文：which will take time, and until then the socket will get blocked）。

發生了什麼？send()方法會從客戶端的寫緩存持續獲取數據並嘗試將全部數據發送給服務端。當緩存空了內核纔會再次喚醒進程以獲取下一個被傳輸數據塊。也就是說你的代碼將被阻塞也沒法進行其餘的操做。

如今要實現併發請求咱們須要多線程，即咱們爲每個客戶端鏈接分配一個新的線程。咱們稍後討論這個。

非阻塞式I/O

顯而易見，從字面意思來看這種方式與上面介紹的差別就是「非阻塞」，對客戶端而言任何操做都是當即完成的。非阻塞式I/O就是把請求放入隊列後函數當即返回，以後在某個時刻才進行真實的I/O操做。

咱們回到剛剛客戶端的例子中作些修改：

import socket

sock = socket.socket()

host = socket.gethostname()
sock.connect((host, 12345))
sock.setblocking(0) 		# Now setting to non-blocking mode

data = b"Foo Bar" *10*1024
assert sock.send(data)
print("Data sent")
複製代碼

如今咱們運行這段代碼，你會發現程序在很短的時間裏打印了「Data sent」後就終止了。

爲何會這樣？由於客戶端並無發送全部數據，當咱們經過setblocking(0)把socket設置爲非阻塞式時，它就不會等待操做完成了。因此當咱們以後再調用send()方法時，它會盡量多的寫入數據到緩存中而後當即返回。

使用非阻塞式I/O，咱們就能夠在同一個線程中同時執行不一樣socket中的I/O操做。可是I/O操做是否準備就緒咱們不得而知，因此咱們可能不得不遍歷每一個socket去確認，一般就是採用無限循環。

爲了擺脫這種低效的循環咱們就須要一套輪詢機制，咱們能夠輪詢出全部準備就緒的sockets，還能夠知道它們之中哪些能夠進行新的I/O操做。當有任意sockets準備就緒後咱們將執行入隊操做()，以後咱們即可以等待爲下次I/O操做準備好了的sockets。

有幾種不一樣的輪詢機制，它們在性能與細節上有所不一樣，但一般細節隱藏在「引擎蓋下」，對咱們來講是不可見的。

相關的關鍵字

Notifications:

• Level Triggering (state)
• Edge Triggering (state changed)

Mechanics:

• select(), poll()
• epoll(), kqueue()
• EAGAIN, EWOULDBLOCK

多任務

咱們的目標是同時管理多個客戶端。那麼如何確保同時處理多個請求呢？

這有些選擇：

獨立進程

最簡單,也是最先的一種方式就是在將每一個請求放在一個獨立的進程中處理。咱們可使用以前的阻塞式I/O，若是這個獨立進程忽然崩了也不會對其餘進程形成影響，這很棒對不對？

在形式上這些進程之間幾乎沒有任何通用的地方，因此咱們須要爲每次普通的進程間通訊作額外的事情。此外在任意時刻都有多個進程在等待客戶端請求也是一種資源浪費。

咱們看一看在實踐中這是如何工做的，一般主進程啓動後會進行一些操做，例如，監聽，而後設置一些進程做爲workers,每一個worker能夠在同一個socket上等待接受傳入的鏈接。一旦鏈接創建，這個worker會與該鏈接綁定，它負責處理該鏈接從開始到結束的整個過程，關閉與客戶端通訊的socket後就會從新準備好處理下一次請求。進程能夠在創建鏈接時建立或者提早建立。不一樣的方式可能會對性能形成影響，不過如今這個問題對咱們不重要。

相似的系統有：

• Apache mod_prefork;
• FastCGI (PHP);
• Phusion Passenger (Ruby on Rails);
• PostgreSQL.

線程（OS）

還有一種就是利用操做系統線程的方式啦。在一個進程中咱們能夠建立多個線程。

依然可使用阻塞式I/O，由於只有一個線程會被阻塞。OS已經管理好了這些分在各個進程中的線程。線程比進程更輕量。這表明咱們能夠建立更多的線程。建立1萬個進程很困難，而建立1萬個進程則很輕鬆，並非說線程相比進程更高效而是更輕量。

另外一方面，線程間沒有隔離，也就是若是線程崩了其作在的進程也會崩潰。最麻煩的是進程中的內存在工做中的線程間是共享的，這表明咱們須要考慮線程安全問題。好比：數據庫鏈接或者鏈接池。

結論

阻塞方法會同步執行—運行程序時阻塞方法的操做會在調用後當即直接執行。

非阻塞方法會異步執行—運行程序時非阻塞方法會在調用後立刻返回，真正的操做會在以後執行。

咱們能夠經過多線程與多進程實現多任務處理。

下一篇文章咱們將討論協做式多任務處理已經實現。