在沒有IO多路復用的模型的情況下，為了支持高并發采取以下網絡模型

一：阻塞IO+多線程

client連接服務器，服務器有一個線程阻塞的調用accept,accept接收到連接后，創建一個線程來讀寫讀寫，并且處理業務邏輯

阻塞IO不能充分利用CPU，后面就出現了reactor模型

二：reactor模型

特點：

1：非阻塞IO+IO多路復用(此處的IO多路復用采用的是epoll模型，關于為何選用epoll，可以看下以前的一篇文章

IO多路復用之select,poll,epoll分析

)

2：事件循環+以事件驅動或者事件回調的方式處理業務邏輯

?

典型的模型應用代表:redis

可以發現服務器只有一個線程，一個epoll，epoll接收到連接事件后就調用accept,接收到客戶端的fd后，將fd加入到epoll，監聽客戶端的讀寫以及斷開連接事件，讀取到客戶端的消息后，對消息進行解碼，然后業務邏輯處理，處理完后編碼需要回復的數據包，然后發送消息，交互完成后客戶端斷開連接，監聽到斷開連接的消息后調用close.

由上面可以看出來所有的事情都是在一個線程上跑，一個線程的處理能力也是有上限的，要是IO密集型或者是業務處理比較復雜的模型，在該網絡模型上跑就會暴露其確定，為了邏輯處理的密集型問題引出下面的 單reacotor +消息隊列+多線程模型

三：單reactor+消息隊列+多線程

?

可以看到該模型跟reactor的區別就是在業務邏輯處理的地方加了消息隊列，接收到的消息放入接收消息隊列，然后業務線程從該隊列取消息進行業務處理(業務線程數量最好是跟cpu核心數，業務線程中基本沒有了IO操作)，業務線程處理完后，將需要回復的消息放入發送隊列中，當有可發送事件觸發時，epoll從發送隊列取消息發送。該模型很典型的應用到游戲里面，代表框架skynet,游戲中的業務是比較多的。該場景可以解決業務邏輯重的問題，但是IO密集問題沒有得到解決，后面一種場景就是為解決IO秘密而生的模型，多reactor模型

四：多reactor模型 也叫one eventloop per net thread

?

多reactor指的是有多個epoll，具體多少個可以根據cpu的核心數決定，一個reactor專門負責接收連接，接收到的連接添加到sub reactor進行讀寫以及邏輯處理

典型的應用代表為memcached

使用多線程模型就會帶來一個線程crash就會導致整個進程crash，同時數據的讀取需要加鎖，此時就會產生一個多reactor多進程模型

五：多進程reactor

?

一個main進程 fork出多個reactor進程，每個reactor都是跟上面第一種的reactor一樣，這樣每個reactor可以利用一個核心，充分利用多核技術，但是此處有一個問題就是當有事件接入的時候只能一個進程accept，這個時候需要引入一個accept鎖，保證同一時刻只用一個進程調用accept就可以解決該問題，main process可以管理所有的reactor進程，當reactor進程crash時拉起與做一些公共的管理事件

典型的應用就是nginx

六：多reactor+消息隊列+多線程

?

這種網絡模型在實際開發中用的會比較多，在我看來主要是為了達到一個解構的目的，網絡庫跟邏輯處理分離

總結

以上是生活随笔為你收集整理的reactor多线程模型_网络编程模型的演进之路的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。