高併發高性能服務器是如何實現的

當在讀這篇文章的時候，你有沒有想過，服務器是怎麼把這篇文章發送給你的呢？

說簡單也簡單，不就是一個用戶請求嗎？服務器根據請求從數據庫中撈出這篇文章，然後通過網絡發回去。

說複雜也複雜，服務器是如何並行處理成千上萬個用戶請求呢？這裏面涉及到哪些技術呢？

這篇文章就來爲你解答這個問題。

多進程

歷史上最早出現也是最簡單的一種並行處理多個請求的方法就是利用多進程。

比如在 Linux 世界中，我們可以使用 fork、exec 等系統調用創建多個進程，我們可以在父進程中接收用戶的連接請求，然後創建子進程去處理用戶請求，就像這樣：

圖片

這種方法的優點就在於：

  1. 編程簡單，非常容易理解

  2. 由於各個進程的地址空間是相互隔離的，因此一個進程崩潰後並不會影響其它進程

  3. 充分利用多核資源

多進程並行處理的優點很明顯，但是缺點同樣明顯：

  1. 各個進程地址空間相互隔離，這一優點也會變成缺點，那就是進程間要想通信就會變得比較困難，你需要藉助進程間通信 (IPC，interprocess communications) 機制，想一想你現在知道哪些進程間通信機制，然後讓你用代碼實現呢？顯然，進程間通信編程相對複雜，而且性能也是一大問題

  2. 我們知道創建進程開銷是比線程要大的，頻繁的創建銷燬進程無疑會加重系統負擔。

幸好，除了進程，我們還有線程。

多線程

不是創建進程開銷大嗎？不是進程間通信困難嗎？這些對於線程來說統統不是問題。

什麼？你還不瞭解線程，趕緊看看這篇《看完這篇還不懂線程與線程池你來打我》，這裏詳細講解了線程這個概念是怎麼來的。

由於線程共享進程地址空間，因此線程間通信天然不需要藉助任何通信機制，直接讀取內存就好了。

線程創建銷燬的開銷也變小了，要知道線程就像寄居蟹一樣，房子 (地址空間) 都是進程的，自己只是一個租客，因此非常的輕量級，創建銷燬的開銷也非常小。

圖片

我們可以爲每個請求創建一個線程，即使一個線程因執行 I/O 操作——比如讀取數據庫等——被阻塞暫停運行也不會影響到其它線程，就像這樣：

圖片

但線程就是完美的、包治百病的嗎，顯然，計算機世界從來沒有那麼簡單。

由於線程共享進程地址空間，這在爲線程間通信帶來便利的同時也帶來了無盡的麻煩。

正是由於線程間共享地址空間，因此一個線程崩潰會導致整個進程崩潰退出，同時線程間通信簡直太簡單了，簡單到線程間通信只需要直接讀取內存就可以了，也簡單到出現問題也極其容易，死鎖、線程間的同步互斥、等等，這些極容易產生 bug，無數程序員寶貴的時間就有相當一部分用來解決多線程帶來的無盡問題。

雖然線程也有缺點，但是相比多進程來說，線程更有優勢，但想單純的利用多線程就能解決高併發問題也是不切實際的。

因爲雖然線程創建開銷相比進程小，但依然也是有開銷的，對於動輒數萬數十萬的鏈接的高併發服務器來說，創建數萬個線程會有性能問題，這包括內存佔用、線程間切換，也就是調度的開銷。

因此，我們需要進一步思考。

Event Loop：事件驅動

到目前爲止，我們提到 “並行” 二字就會想到進程、線程。但是，並行編程只能依賴這兩項技術嗎，並不是這樣的。

還有另一項並行技術廣泛應用在 GUI 編程以及服務器編程中，這就是近幾年非常流行的事件驅動編程，event-based concurrency。

大家不要覺得這是一項很難懂的技術，實際上事件驅動編程原理上非常簡單。

這一技術需要兩種原料：

  1. event

  2. 處理 event 的函數，這一函數通常被稱爲 event handler

剩下的就簡單了：

你只需要安靜的等待 event 到來就好，當 event 到來之後，檢查一下 event 的類型，並根據該類型找到對應的 event 處理函數，也就是 event handler，然後直接調用該 event handler 就好了。

圖片

That's it !

以上就是事件驅動編程的全部內容，是不是很簡單！

從上面的討論可以看到，我們需要不斷的接收 event 然後處理 event，因此我們需要一個循環 (用 while 或者 for 循環都可以)，這個循環被稱爲 Event loop。

使用僞代碼表示就是這樣：

while(true) {
    event = getEvent();
    handler(event);
}

Event loop 中要做的事情其實是非常簡單的，只需要等待 event 的帶來，然後調用相應的 event 處理函數即可。

注意，這段代碼只需要運行在一個線程或者進程中，只需要這一個 event loop 就可以同時處理多個用戶請求。

有的同學可以依然不明白爲什麼這樣一個 event loop 可以同時處理多個請求呢？

原因很簡單，對於 web 服務器來說，處理一個用戶請求時大部分時間其實都用在了 I/O 操作上，像數據庫讀寫、文件讀寫、網絡讀寫等。當一個請求到來，簡單處理之後可能就需要查詢數據庫等 I/O 操作，我們知道 I/O 是非常慢的，當發起 I/O 後我們大可以不用等待該 I/O 操作完成就可以繼續處理接下來的用戶請求。

圖片

現在你應該明白了吧，雖然上一個用戶請求還沒有處理完我們其實就可以處理下一個用戶請求了，這也是並行，這種並行就可以用事件驅動編程來處理。

這就好比餐廳服務員一樣，一個服務員不可能一直等上一個顧客下單、上菜、喫飯、買單之後才接待下一個顧客，服務員是怎麼做的呢？當一個顧客下完單後直接處理下一個顧客，當顧客喫完飯後會自己回來買單結賬的。

看到了吧，同樣是一個服務員也可以同時處理多個顧客，這個服務員就相當於這裏的 Event loop，即使這個 event loop 只運行在一個線程 (進程) 中也可以同時處理多個用戶請求。

相信你已經對事件驅動編程有一個清晰的認知了，那麼接下來的問題就是事件驅動、事件驅動，那麼這個事件也就是 event 該怎麼獲取呢？

事件來源：IO 多路複用

在《終於明白了，一文徹底理解 I/O 多路複用》這篇文章中我們知道，在 Linux/Unix 世界中一切皆文件，而我們的程序都是通過文件描述符來進行 I/O 操作的，當然對於 socket 也不例外，那我們該如何同時處理多個文件描述符呢？

IO 多路複用技術正是用來解決這一問題的，通過 IO 多路複用技術，我們一次可以監控多個文件描述，當某個文件 (socket) 可讀或者可寫的時候我們就能得到通知啦。

這樣 IO 多路複用技術就成了 event loop 的原材料供應商，源源不斷的給我們提供各種 event，這樣關於 event 來源的問題就解決了。

圖片

當然關於 IO 多路複用技術的詳細講解請參見《終於明白了，一文徹底理解 I/O 多路複用》。

至此，關於利用事件驅動來實現併發編程的所有問題都解決了嗎？event 的來源問題解決了，當得到 event 後調用相應的 handler，看上去大功告成了。

想一想還有沒有其它問題？

問題：阻塞式 IO

現在，我們可以使用一個線程 (進程) 就能基於事件驅動進行並行編程，再也沒有了多線程中讓人惱火的各種鎖、同步互斥、死鎖等問題了。

但是，計算機科學中從來沒有出現過一種能解決所有問題的技術，現在沒有，在可預期的將來也不會有。

那上述方法有什麼問題嗎？

不要忘了，我們 event loop 是運行在一個線程 (進程)，這雖然解決了多線程問題，但是如果在處理某個 event 時需要進行 IO 操作會怎麼樣呢？

在《讀取文件時，程序經歷了什麼》一文中，我們講解了最常用的文件讀取在底層是如何實現的，程序員最常用的這種 IO 方式被稱爲阻塞式 IO，也就是說，當我們進行 IO 操作，比如讀取文件時，如果文件沒有讀取完成，那麼我們的程序 (線程) 會被阻塞而暫停執行，這在多線程中不是問題，因爲操作系統還可以調度其它線程。

但是在單線程的 event loop 中是有問題的，原因就在於當我們在 event loop 中執行阻塞式 IO 操作時整個線程 (event loop) 會被暫停運行，這時操作系統將沒有其它線程可以調度，因爲系統中只有一個 event loop 在處理用戶請求，這樣當 event loop 線程被阻塞暫停運行時所有用戶請求都沒有辦法被處理，你能想象當服務器在處理其它用戶請求讀取數據庫導致你的請求被暫停嗎？

圖片

因此，在基於事件驅動編程時有一條注意事項，那就是不允許發起阻塞式 IO。

有的同學可能會問，如果不能發起阻塞式 IO 的話，那麼該怎樣進行 IO 操作呢？

有阻塞式 IO，就有非阻塞式 IO。

非阻塞 IO

爲克服阻塞式 IO 所帶來的問題，現代操作系統開始提供一種新的發起 IO 請求的方法，這種方法就是異步 IO，對應的，阻塞式 IO 就是同步 IO，關於同步和異步這兩個概念可以參考《從小白到高手，你需要理解同步與異步》。

異步 IO 時，假設調用 aio_read 函數 (具體的異步 IO API 請參考具體的操作系統平臺)，也就是異步讀取，當我們調用該函數後可以立即返回，並繼續其它事情，雖然此時該文件可能還沒有被讀取，這樣就不會阻塞調用線程了。此外，操作系統還會提供其它方法供調用線程來檢測 IO 操作是否完成。

就這樣，在操作系統的幫助下 IO 的阻塞調用問題也解決了。

基於事件編程的難點

雖然有異步 IO 來解決 event loop 可能被阻塞的問題，但是基於事件編程依然是困難的。

首先，我們提到，event loop 是運行在一個線程中的，顯然一個線程是沒有辦法充分利用多核資源的，有的同學可能會說那就創建多個 event loop 實例不就可以了，這樣就有多個 event loop 線程了，但是這樣一來多線程問題又會出現。

另一點在於編程方面，在《從小白到高手，你需要理解同步與異步》這篇文章中我們講到過，異步編程需要結合回調函數 (關於回調函數請才參考《程序員應如何徹底理解回調函數》)，這種編程方式需要把處理邏輯分爲兩部分，一部分調用方自己處理，另一部分在回調函數中處理，這一編程方式的改變加重了程序員在理解上的負擔，基於事件編程的項目後期會很難擴展以及維護。

那麼有沒有更好的方法呢？

要找到更好的方法，我們需要解決問題的本質，那麼這個本質問題是什麼呢？

更好的方法

爲什麼我們要使用異步這種難以理解的方式編程呢？

是因爲阻塞式編程雖然容易理解但會導致線程被阻塞而暫停運行。

那麼聰明的你一定會問了，有沒有一種方法既能結合同步 IO 的簡單理解又不會因同步調用導致線程被阻塞呢？

答案是肯定的，這就是用戶態線程，user level thread，也就是大名鼎鼎的協程，關於協程值得單獨拿出一篇文章來講解，就在下一篇。

雖然基於事件編程有這樣那樣的缺點，但是在當今的高性能高併發服務器上基於事件編程方式依然非常流行，但已經不是純粹的基於單一線程的事件驅動了，而是 event loop + multi thread + user level thread。

關於這一組合，同樣值得拿出一篇文章來講解，我們將在後續文章中詳細討論。

總結

高併發技術從最開始的多進程一路演進到當前的事件驅動，計算機技術就像生物一樣也在不斷演變進化，但不管怎樣，瞭解歷史才能更深刻的理解當下。希望這篇文章能對大家理解高併發服務器有所幫助。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/X1IMhT4hSqJJh9AYD0te3Q

猜你喜歡