原創聲明
做者: 劉丹冰Aceld,微信公衆號同名
本文主要介紹常見的Server的併發模型,這些模型與編程語言自己無關,有的編程語言可能在語法上直接透明瞭模型本質,因此開發者不必必定要基於模型去編寫,只是須要知道和了解併發模型的構成和特色便可。git
那麼在瞭解併發模型以前,咱們須要兩個必備的前置知識:github
① 主線程main thread
執行阻塞Accept,每次客戶端Connect連接過來,main thread
中accept響應並創建鏈接golang
② 建立連接成功,獲得Connfd1
套接字後, 依然在main thread
串行處理套接字讀寫,並處理業務。編程
③ 在②處理業務中,若是有新客戶端Connect
過來,Server
無響應,直到當前套接字所有業務處理完畢。安全
④ 當前客戶端處理完後,完畢連接,處理下一個客戶端請求。服務器
優勢:微信
缺點:網絡
1
。 即併發量爲1
。
① 主線程main thread
執行阻塞Accept,每次客戶端Connect連接過來,main thread
中accept響應並創建鏈接多線程
② 建立連接成功,獲得Connfd1
套接字後,建立一個新線程thread1
用來處理客戶端的讀寫業務。main thead
依然回到Accept
阻塞等待新客戶端。併發
③ thread1
經過套接字Connfd1
與客戶端進行通訊讀寫。
④ server在②處理業務中,若是有新客戶端Connect
過來,main thread
中Accept
依然響應並創建鏈接,重複②過程。
優勢:
模型一:單線程Accept(無IO複用)
支持了併發的特性。server
處理業務內聚程度高,客戶端不管如何寫,服務端均會有一個線程作資源響應。缺點:
1:1
正比關係,一次對於高併發場景,線程數量收到硬件上限瓶頸。僅適合學習基本socket編程,不適合任何服務器Server構建。
① 主線程main thread
建立listenFd
以後,採用多路I/O複用機制(如:select、epoll)進行IO狀態阻塞監控。有Client1
客戶端Connect
請求,I/O複用機制檢測到ListenFd
觸發讀事件,則進行Accept
創建鏈接,並將新生成的connFd1
加入到監聽I/O集合
中。
② Client1
再次進行正常讀寫業務請求,main thread
的多路I/O複用機制
阻塞返回,會觸該套接字的讀/寫事件等。
③ 對於Client1
的讀寫業務,Server依然在main thread
執行流程提繼續執行,此時若是有新的客戶端Connect
連接請求過來,Server將沒有即時響應。
④ 等到Server處理完一個鏈接的Read+Write
操做,繼續回到多路I/O複用機制
阻塞,其餘連接過來重複 ②、③流程。
優勢:
1:1
與客戶端的線程數量關係。缺點:
Client3
佔據main thread
流程時,Client1,Client2
流程卡在IO複用
等待下次監聽觸發事件。
① 主線程main thread
建立listenFd
以後,採用多路I/O複用機制(如:select、epoll)進行IO狀態阻塞監控。有Client1
客戶端Connect
請求,I/O複用機制檢測到ListenFd
觸發讀事件,則進行Accept
創建鏈接,並將新生成的connFd1
加入到監聽I/O集合
中。
② 當connFd1
有可讀消息,觸發讀事件,而且進行讀寫消息
③ main thread
按照固定的協議讀取消息,而且交給worker pool
工做線程池, 工做線程池在server啓動以前就已經開啓固定數量的thread
,裏面的線程只處理消息業務,不進行套接字讀寫操做。
④ 工做池處理完業務,觸發connFd1
寫事件,將回執客戶端的消息經過main thead
寫給對方。
優勢:
模型三
, 將業務處理部分,經過工做池分離出來,減小多客戶端訪問Server,業務爲串行執行,大量請求會有排隊延遲時間。缺點:
main thread
單獨處理,最高讀寫並行通道依然爲1.main thread
的Read + Write
① Server在啓動監聽以前,開闢固定數量(N)的線程,用Thead Pool
線程池管理
② 主線程main thread
建立listenFd
以後,採用多路I/O複用機制(如:select、epoll)進行IO狀態阻塞監控。有Client1
客戶端Connect
請求,I/O複用機制檢測到ListenFd
觸發讀事件,則進行Accept
創建鏈接,並將新生成的connFd1
分發給Thread Pool
中的某個線程進行監聽。
③ Thread Pool
中的每一個thread
都啓動多路I/O複用機制(select、epoll)
,用來監聽main thread
創建成功而且分發下來的socket套接字。
④ 如圖, thread
監聽ConnFd一、ConnFd2
, thread2
監聽ConnFd3
,thread3
監聽ConnFd4
. 當對應的ConnFd
有讀寫事件,對應的線程處理該套接字的讀寫及業務。
優勢:
main thread
的單流程讀寫,分散到多線程完成,這樣增長了同一時刻的讀寫並行通道,並行通道數量N
, N
爲線程池Thread
數量。ConnFd套接字
數量幾乎成倍增大,以前的所有監控數量取決於main thread
的多路I/O複用機制
的最大限制(select 默認爲1024, epoll默認與內存大小相關,約3~6w不等),因此理論單點Server最高響應併發數量爲N*(3~6W)
(N
爲線程池Thread
數量,建議與CPU核心成比例1:1)。Thread
處理合理業務的效率,下降CPU切換成本開銷。缺點:
N
,並且多個身處同一個Thread的客戶端,會出現讀寫延遲現象,實際上每一個Thread
的模型特徵與模型三:單線程多路IO複用
一致。
與5、單線程IO複用+多線程IO複用(連接線程池)
無大差別。
不一樣處
main process
(主進程)再也不進行Accept
操做,而是將Accept
過程分散到各個子進程(process)
中.main process
若是Accept成功的fd,其餘進程沒法共享資源,因此須要各子進程自行Accept建立連接main process
只是監聽ListenFd
狀態,一旦觸發讀事件(有新鏈接請求). 經過一些IPC(進程間通訊:如信號、共享內存、管道)等, 讓各自子進程Process
競爭Accept
完成連接創建,並各自監聽。與5、單線程IO複用+多線程IO複用(連接線程池)
無大差別。
不一樣處:
多進程內存資源空間佔用稍微大一些
多進程模型安全穩定型較強,這也是由於各自進程互不干擾的特色致使。
① Server在啓動監聽以前,開闢固定數量(N)的線程,用Thead Pool
線程池管理
② 主線程main thread
建立listenFd
以後,採用多路I/O複用機制(如:select、epoll)進行IO狀態阻塞監控。有Client1
客戶端Connect
請求,I/O複用機制檢測到ListenFd
觸發讀事件,則進行Accept
創建鏈接,並將新生成的connFd1
分發給Thread Pool
中的某個線程進行監聽。
③ Thread Pool
中的每一個thread
都啓動多路I/O複用機制(select、epoll)
,用來監聽main thread
創建成功而且分發下來的socket套接字。一旦其中某個被監聽的客戶端套接字觸發I/O讀寫事件
,那麼,會馬上開闢一個新線程來處理I/O讀寫
業務。
④ 但某個讀寫線程完成當前讀寫業務,若是當前套接字沒有被關閉,那麼將當前客戶端套接字如:ConnFd3
從新加回線程池的監控線程中,同時自身線程自我銷燬。
優勢:
模型5、單線程IO複用+多線程IO複用(連接線程池)
基礎上,除了可以保證同時響應的最高併發數
,又能解決讀寫並行通道
侷限的問題。最大化極限
,一個客戶端能夠對應一個單獨執行流程處理讀寫業務,讀寫並行通道與客戶端數量1:1
關係。缺點:
1:1
的關係,那麼Server須要開闢的Thread
數量就與客戶端一致,那麼線程池中作多路I/O複用
的監聽線程池綁定CPU數量將變得毫無心義。Thread
都可以綁定一個單獨的CPU,那麼此模型將是最優模型。可是目前CPU的數量沒法與客戶端的數量達到一個量級,目前甚至差的不是幾個量級的事。綜上,咱們整理了7中Server的服務器處理結構模型,每一個模型都有各自的特色和優點,那麼對於多少應付高併發和高CPU利用率的模型,目前多數採用的是模型五(或模型五進程版,如Nginx就是相似模型五進程版的改版)。
至於併發模型並不是設計的約複雜越好,也不是線程開闢的越多越好,咱們要考慮硬件的利用與和切換成本的開銷。模型六設計就極爲複雜,線程較多,但以當今的硬件能力沒法支撐,反倒致使該模型性能極差。因此對於不一樣的業務場景也要選擇適合的模型構建,並非必定固定就要使用某個來應用。
mail: danbing.at@gmail.com
github: https://github.com/aceld
原創書籍gitbook: http://legacy.gitbook.com/@aceld
(原創開源)Zinx-基於Golang輕量級服務器併發框架-完整版(附教程視頻)
(原創開源)Lars-基於C++負載均衡遠程調度系統-完整版