#ReactorThe reactor design pattern is an event handling pattern for handling service requests delivered concurrently to a service handler by one or more inputs. The service handler then demultiplexes the incoming requests and dispatches them synchronously to the associated request handlers.
Reactor
種為處理服務請求並發提交到一個或多個服務處理器的事件設計模式。當請求抵達後，透過服務處理器將這些請求採用多路分離的方式分發給相應的請求處理器。 Reactor 模式主要由Reactor 和處理器Handler 這兩個核心部分組成，如下圖所示，它倆負責的事情如下：在絕大多數場景下，處理一個網路請求有下列幾個步驟：⑤ send：傳送回應資料
① read：從socket 讀取資料。
② decode：解碼，網路上的資料都是以 byte 的形式進行傳輸的，要想取得真正的請求，必要解碼
③ compute：計算，也就是業務處理。
④ encode：編碼，網路上的資料都是以 byte 的形式進行傳輸的，也就是 socket 只接收 byte，所以必需編碼。
The Reactor is responsible for monitoring and distributing events, and dispatching them to the corresponding Handlers.。新的事件包含連線建立就緒、讀取就緒、寫入就緒等。 Acceptor：請求連接器，處理客戶端新連線。 Reactor 接收到 client 端的連接事件後，會將其轉送給 Acceptor，由 Acceptor 接收 Client 的連接，建立對應的 Handler，並向 Reactor 註冊此 Handler。 Handler：請求處理器，負責事件的處理，將自身與事件綁定，執行非阻塞讀/寫任務，完成channel 的讀入，完成處理業務邏輯後，負責將結果寫出channel 。可用資源池來管理。模型大致如下圖所示：
① 效能：只在程式碼上進行元件的區分，整體操作還是單線程，無法充分利用CPU 資源，且Handler 業務處理部分沒有非同步，一個Reactor 既要負責處理連接請求，又要負責處理讀寫請求，一般來說處理連線請求是很快的，但處理讀寫請求時涉及到業務邏輯處理，相對慢很多。由於Reactor 處理讀寫請求時，其它請求會處於阻塞狀態，因此很容易導致系統效能出現瓶頸
② 可靠性：一旦Reactor 執行緒意外中斷或進入死循環，會導致整個系統通訊模組不可用，不能接收和處理外部訊息，造成節點故障
所以該單Reactor單進程模型不適用於計算密集的場景，只適用於業務處理非常快速的場景。 Redis的線程模型就是基於單 Reactor 單線程模型實現的，因為 Redis 業務處理主要是在內存中完成，操作的速度是很快的，性能瓶頸不在 CPU 上，所以 Redis 對於命令的處理是單進程的。
為了解決單一Reactor單執行緒模型存在的效能問題，就演進出了單Reactor 多執行緒模型，該模型在事件處理器部分中採用了多執行緒（執行緒池）
（1）Reactor 執行緒透過select 監聽事件，收到事件後透過Dispatch 進行分發
（2）如果是連接建立事件，則將事件分發給Acceptor，Acceptor 會透過accept() 方法取得連接，並建立一個Handler 物件來處理後續的回應事件
# （3）如果是IO讀寫事件，則Reactor 會將該事件交由目前連接對應的Handler 來處理
（4）與單Reactor單線程不同的是，Handler 不再做具體業務處理，只負責接收和回應事件，透過read 接收資料後，將資料傳送給後面的Worker 執行緒池進行業務處理。
（5）Worker 執行緒池再分配執行緒進行業務處理，完成後將回應結果發給 Handler 進行處理。
（6）Handler 收到回應結果後透過 send 將回應結果傳回給 Client。
相對於第一種模型來說，在處理業務邏輯，也就是取得到IO讀寫事件之後，交由線程池來處理，Handler 接收到回應後透過send 將回應結果傳回給客戶端。這樣可以降低 Reactor 的效能開銷，從而更專注的做事件分發工作了，提升整個應用的吞吐，並且 Handler 使用了多執行緒模式，可以充分利用 CPU 的效能。但是這個模型存在的問題：
（1）Handler 使用多執行緒模式，自然帶來了多執行緒競爭資源的開銷，同時涉及共享資料的互斥和保護機制，實作比較複雜
（2）單一Reactor 承擔所有事件的監聽、分發和回應，對於高並發場景，容易造成效能瓶頸。
單Reactor多執行緒模型解決了Handler 單執行緒的效能問題，但是Reactor 還是單執行緒的，對於高並發場景還是會有效能瓶頸，所以需要將Reactor 調整為多執行緒模式，也就是接下來要介紹的主從Reactor 多執行緒模型。在主從Reactor 多執行緒模型中，Reactor 被分割成兩個部分
（1）MainReactor：只負責處理連線建立事件，透過select 監聽server socket，將建立的socketChannel 指定註冊給subReactor，通常一個執行緒就可以了
（2）SubReactor：負責讀寫事件，維護自己的selector，基於MainReactor 註冊的SocketChannel 進行多路分離IO 讀寫事件，讀寫網路數據，並將業務處理交由worker 執行緒池來完成。 SubReactor 的個數一般和CPU 個數相同
（1）主執行緒中的MainReactor 物件透過select 監聽事件，接收到事件後透過Dispatch 進行分發，如果事件類型為連線建立事件則分發給Acceptor 進行連線建立
##連線建立：① 從主線程池中隨機選擇一個Reactor 線程作為Acceptor 線程，用於綁定監聽端口，接收客戶端連接
② Acceptor 線程接收客戶端連接請求之後創建新的SocketChannel，將其註冊到主線程池的其它Reactor 執行緒上，由其負責接入認證、IP黑白名單過濾、握手等操作。
③ 步驟② 完成之後，業務層的連結正式建立，將SocketChannel 從主執行緒池的Reactor 執行緒的多工器上摘除，重新註冊到SubReactor 執行緒池的執行緒上，並建立一個Handler 用於處理各種連接事件
（2）如果接收到的不是連接建立事件，則分發給SubReactor，SubReactor 呼叫目前連接對應的Handler 進行處理
（3）Handler 透過read讀取資料後，將資料分發給Worker 執行緒池進行業務處理，Worker 執行緒池則分配執行緒進行業務處理，完成後將回應結果發給Handler
（4）Handler 收到回應結果後透過send 將回應結果回傳給Client
主從Reactor 多執行緒模型的優點在於主執行緒與子執行緒分工明確，主執行緒只負責接收新連接，子執行緒負責完成後續的業務處理，同時主線程和子線程的交互也很簡單，子線程接收主線程的連接後，只管業務處理即可，無須關注主線程，可以直接在子線程將處理結果發送給客戶端。
此Reactor 模型適用於高並發場景，且Netty 網路通訊架構也是採用此實作
##4、Reactor 優缺點：（1）反應快，不必單一同步時間所阻塞，雖然Reactor 本身依然是同步的；（2）可以最大程度的避免複雜的多執行緒及同步問題，並且避免了多執行緒/進程的切換開銷（3）可擴展性，可以方便地透過增加Reactor 實例個數來充分利用CPU 資源；（4）可復用性，Reactor 模型本身與具體事件處理邏輯無關，具有很高的複用性。
以上是Java IO中Reactor網路模型的概念是什麼的詳細內容。更多資訊請關注PHP中文網其他相關文章！
