無論是C++還是Java編寫的網路框架，大多數都是基於Reactor模式進行設計和開發，Reactor模式基於事件驅動，特別適合處理海量的I/O事件。

1.2.1. 單執行緒模型

Reactor單執行緒模型，指的是所有的IO操作都在同一個NIO執行緒上面完成，NIO執行緒的職責如下：

1）作為NIO服務端，接收客戶端的TCP連線；

2）作為NIO客戶端，向服務端發起TCP連線；

3）讀取通訊對端的請求或者應答訊息；

4）向通訊對端傳送訊息請求或者應答訊息。

Reactor單執行緒模型示意圖如下所示：

圖1-1 Reactor單執行緒模型

由於Reactor模式使用的是非同步非阻塞IO，所有的IO操作都不會導致阻塞，理論上一個執行緒可以獨立處理所有IO相關的操作。從架構層面看，一個NIO執行緒確實可以完成其承擔的職責。例如，通過Acceptor類接收客戶端的TCP連線請求訊息，鏈路建立成功之後，通過Dispatch將對應的ByteBuffer派發到指定的Handler上進行訊息解碼。使用者執行緒可以通過訊息編碼通過NIO執行緒將訊息傳送給客戶端。

對於一些小容量應用場景，可以使用單執行緒模型。但是對於高負載、大併發的應用場景卻不合適，主要原因如下：

1）一個NIO執行緒同時處理成百上千的鏈路，效能上無法支撐，即便NIO執行緒的CPU負荷達到100%，也無法滿足海量訊息的編碼、解碼、讀取和傳送；

2）當NIO執行緒負載過重之後，處理速度將變慢，這會導致大量客戶端連線超時，超時之後往往會進行重發，這更加重了NIO執行緒的負載，最終會導致大量訊息積壓和處理超時，成為系統的效能瓶頸；

3）可靠性問題：一旦NIO執行緒意外跑飛，或者進入死迴圈，會導致整個系統通訊模組不可用，不能接收和處理外部訊息，造成節點故障。

為了解決這些問題，演進出了Reactor多執行緒模型，下面我們一起學習下Reactor多執行緒模型。

1.2.2. 多執行緒模型

Rector多執行緒模型與單執行緒模型最大的區別就是有一組NIO執行緒處理IO操作，它的原理圖如下：

圖1-2 Reactor多執行緒模型

Reactor多執行緒模型的特點：

1）有專門一個NIO執行緒-Acceptor執行緒用於監聽服務端，接收客戶端的TCP連線請求；

2）網路IO操作-讀、寫等由一個NIO執行緒池負責，執行緒池可以採用標準的JDK執行緒池實現，它包含一個任務佇列和N個可用的執行緒，由這些NIO執行緒負責訊息的讀取、解碼、編碼和傳送；

3）1個NIO執行緒可以同時處理N條鏈路，但是1個鏈路只對應1個NIO執行緒，防止發生併發操作問題。

在絕大多數場景下，Reactor多執行緒模型都可以滿足效能需求；但是，在極個別特殊場景中，一個NIO執行緒負責監聽和處理所有的客戶端連線可能會存在效能問題。例如併發百萬客戶端連線，或者服務端需要對客戶端握手進行安全認證，但是認證本身非常損耗效能。在這類場景下，單獨一個Acceptor執行緒可能會存在效能不足問題，為了解決效能問題，產生了第三種Reactor執行緒模型-主從Reactor多執行緒模型。

1.2.3. 主從多執行緒模型

主從Reactor執行緒模型的特點是：服務端用於接收客戶端連線的不再是個1個單獨的NIO執行緒，而是一個獨立的NIO執行緒池。Acceptor接收到客戶端TCP連線請求處理完成後（可能包含接入認證等），將新建立的SocketChannel註冊到IO執行緒池（sub reactor執行緒池）的某個IO執行緒上，由它負責SocketChannel的讀寫和編解碼工作。Acceptor執行緒池僅僅只用於客戶端的登陸、握手和安全認證，一旦鏈路建立成功，就將鏈路註冊到後端subReactor執行緒池的IO執行緒上，由IO執行緒負責後續的IO操作。

它的執行緒模型如下圖所示：

圖1-3 主從Reactor多執行緒模型

利用主從NIO執行緒模型，可以解決1個服務端監聽執行緒無法有效處理所有客戶端連線的效能不足問題。

它的工作流程總結如下：

1. 從主執行緒池中隨機選擇一個Reactor執行緒作為Acceptor執行緒，用於繫結監聽埠，接收客戶端連線；
2. Acceptor執行緒接收客戶端連線請求之後建立新的SocketChannel，將其註冊到主執行緒池的其它Reactor執行緒上，由其負責接入認證、IP黑白名單過濾、握手等操作；
3. 步驟2完成之後，業務層的鏈路正式建立，將SocketChannel從主執行緒池的Reactor執行緒的多路複用器上摘除，重新註冊到Sub執行緒池的執行緒上，用於處理I/O的讀寫操作