Reactor模式詳解
前記
第一次聽到Reactor模式是三年前的某個晚上，一個室友突然跑過來問我什麼是Reactor模式？我上網查了一下，很多人都是給出NIO中的 Selector的例子，而且就是NIO裡Selector多路複用模型，只是給它起了一個比較fancy的名字而已，雖然它引入了EventLoop概 念，這對我來說是新的概念，但是程式碼實現卻是一樣的，因而我並沒有很在意這個模式。然而最近開始讀Netty原始碼，而Reactor模式是很多介紹Netty的文章中被大肆宣傳的模式，因而我再次問自己，什麼是Reactor模式？本文就是對這個問題關於我的一些理解和嘗試著來解答。
什麼是Reactor模式
要回答這個問題，首先當然是求助Google或Wikipedia，其中Wikipedia上說：“The reactor design pattern is an event handling pattern for handling service requests delivered concurrently by one or more inputs. The service handler then demultiplexes the incoming requests and dispatches them synchronously to associated request handlers.”。從這個描述中，我們知道Reactor模式首先是事件驅動的，有一個或多個併發輸入源，有一個Service Handler，有多個Request Handlers
從結構上，這有點類似生產者消費者模式，即有一個或多個生產者將事件放入一個Queue中，而一個或多個消費者主動的從這個Queue中Poll事件來處理；而Reactor模式則並沒有Queue來做緩衝，每當一個Event輸入到Service Handler之後，該Service Handler會主動的根據不同的Event型別將其分發給對應的Request Handler來處理。
更學術的，這篇文章（Reactor An Object Behavioral Pattern for Demultiplexing and Dispatching Handles for Synchronous Events
Reactor模式結構
在解決了什麼是Reactor模式後，我們來看看Reactor模式是由什麼模組構成。圖是一種比較簡潔形象的表現方式，因而先上一張圖來表達各個模組的名稱和他們之間的關係：
Handle：即作業系統中的控制代碼，是對資源在作業系統層面上的一種抽象，它可以是開啟的檔案、一個連線(Socket)、Timer等。由於Reactor模式一般使用在網路程式設計中，因而這裡一般指Socket
Handle，即一個網路連線（Connection，在Java NIO中的Channel）。這個Channel註冊到Synchronous
Event
Demultiplexer中，以監聽Handle中發生的事件，對ServerSocketChannnel可以是CONNECT事件，對SocketChannel可以是READ、WRITE、CLOSE事件等。
Synchronous Event Demultiplexer：阻塞等待一系列的Handle中的事件到來，如果阻塞等待返回，即表示在返回的Handle中可以不阻塞的執行返回的事件型別。這個模組一般使用作業系統的select來實現。在Java
NIO中用Selector來封裝，當Selector.select()返回時，可以呼叫Selector的selectedKeys()方法獲取Set<SelectionKey>，一個SelectionKey表達一個有事件發生的Channel以及該Channel上的事件型別。上圖的“Synchronous
Event Demultiplexer ---notifies-->
Handle”的流程如果是對的，那內部實現應該是select()方法在事件到來後會先設定Handle的狀態，然後返回。不瞭解內部實現機制，因而保留原圖。
Initiation Dispatcher：用於管理Event
Handler，即EventHandler的容器，用以註冊、移除EventHandler等；另外，它還作為Reactor模式的入口呼叫Synchronous
Event
Demultiplexer的select方法以阻塞等待事件返回，當阻塞等待返回時，根據事件發生的Handle將其分發給對應的Event
Handler處理，即回撥EventHandler中的handle_event()方法。
Event Handler：定義事件處理方法：handle_event()，以供InitiationDispatcher回撥使用。
Concrete Event Handler：事件EventHandler介面，實現特定事件處理邏輯。
Reactor模式模組之間的互動
簡單描述一下Reactor各個模組之間的互動流程，先從序列圖開始：
1. 初始化InitiationDispatcher，並初始化一個Handle到EventHandler的Map。
2. 註冊EventHandler到InitiationDispatcher中，每個EventHandler包含對相應Handle的引用，從而建立Handle到EventHandler的對映（Map）。
3. 呼叫InitiationDispatcher的handle_events()方法以啟動Event Loop。在Event Loop中，呼叫select()方法（Synchronous Event Demultiplexer）阻塞等待Event發生。
4. 當某個或某些Handle的Event發生後，select()方法返回，InitiationDispatcher根據返回的Handle找到註冊的EventHandler，並回調該EventHandler的handle_events()方法。
5.
在EventHandler的handle_events()方法中還可以向InitiationDispatcher中註冊新的Eventhandler，比如對AcceptorEventHandler來，當有新的client連線時，它會產生新的EventHandler以處理新的連線，並註冊到InitiationDispatcher中。
Reactor模式實現
在Reactor An Object Behavioral Pattern for Demultiplexing and Dispatching Handles for Synchronous Events中，一直以Logging
Server來分析Reactor模式，這個Logging
Server的實現完全遵循這裡對Reactor描述，因而放在這裡以做參考。Logging
Server中的Reactor模式實現分兩個部分：Client連線到Logging Server和Client向Logging
Server寫Log。因而對它的描述分成這兩個步驟。
Client連線到Logging Server
1. Logging Server註冊LoggingAcceptor到InitiationDispatcher。
2. Logging Server呼叫InitiationDispatcher的handle_events()方法啟動。
3. InitiationDispatcher內部呼叫select()方法（Synchronous Event Demultiplexer），阻塞等待Client連線。
4. Client連線到Logging Server。
5. InitiationDisptcher中的select()方法返回，並通知LoggingAcceptor有新的連線到來。
6. LoggingAcceptor呼叫accept方法accept這個新連線。
7. LoggingAcceptor建立新的LoggingHandler。
8. 新的LoggingHandler註冊到InitiationDispatcher中(同時也註冊到Synchonous Event Demultiplexer中)，等待Client發起寫log請求。
Client向Logging Server寫Log
1. Client傳送log到Logging server。
2. InitiationDispatcher監測到相應的Handle中有事件發生，返回阻塞等待，根據返回的Handle找到LoggingHandler，並回調LoggingHandler中的handle_event()方法。
3. LoggingHandler中的handle_event()方法中讀取Handle中的log資訊。
4. 將接收到的log寫入到日誌檔案、資料庫等裝置中。
3.4步驟迴圈直到當前日誌處理完成。
5. 返回到InitiationDispatcher等待下一次日誌寫請求。
在Reactor An Object Behavioral Pattern for Demultiplexing and Dispatching Handles for Synchronous Events有對Reactor模式的C++的實現版本，多年不用C++，因而略過。
Java NIO對Reactor的實現
在Java的NIO中，對Reactor模式有無縫的支援，即使用Selector類封裝了作業系統提供的Synchronous Event Demultiplexer功能。這個Doug Lea已經在Scalable IO In Java中有非常深入的解釋了，因而不再贅述，另外這篇文章對Doug Lea的Scalable IO In Java有一些簡單解釋，至少它的程式碼格式比Doug Lea的PPT要整潔一些。
需要指出的是，不同這裡使用InitiationDispatcher來管理EventHandler，在Doug
Lea的版本中使用SelectionKey中的Attachment來儲存對應的EventHandler，因而不需要註冊EventHandler這個步驟，或者設定Attachment就是這裡的註冊。而且在這篇文章中，Doug
Lea從單執行緒的Reactor、Acceptor、Handler實現這個模式出發；演化為將Handler中的處理邏輯多執行緒化，實現類似Proactor模式，此時所有的IO操作還是單執行緒的，因而再演化出一個Main
Reactor來處理CONNECT事件(Acceptor)，而多個Sub
Reactor來處理READ、WRITE等事件(Handler)，這些Sub
Reactor可以分別再自己的執行緒中執行，從而IO操作也多執行緒化。這個最後一個模型正是Netty中使用的模型。並且在Reactor An Object Behavioral Pattern for Demultiplexing and Dispatching Handles for Synchronous Events的9.5 Determine the Number of Initiation Dispatchers in an Application中也有相應的描述。
EventHandler介面定義
對EventHandler的定義有兩種設計思路：single-method設計和multi-method設計：
A single-method interface：它將Event封裝成一個Event
Object，EventHandler只定義一個handle_event(Event
event)方法。這種設計的好處是有利於擴充套件，可以後來方便的新增新的Event型別，然而在子類的實現中，需要判斷不同的Event型別而再次擴充套件成
不同的處理方法，從這個角度上來說，它又不利於擴充套件。另外在Netty3的使用過程中，由於它不停的建立ChannelEvent類，因而會引起GC的不穩定。
A multi-method interface：這種設計是將不同的Event型別在
EventHandler中定義相應的方法。這種設計就是Netty4中使用的策略，其中一個目的是避免ChannelEvent建立引起的GC不穩定，
另外一個好處是它可以避免在EventHandler實現時判斷不同的Event型別而有不同的實現，然而這種設計會給擴充套件新的Event型別時帶來非常
大的麻煩，因為它需要該介面。
關於Netty4對Netty3的改進可以參考這裡：
為什麼使用Reactor模式
歸功與Netty和Java NIO對Reactor的宣傳，本文慕名而學習的Reactor模式，因而已經預設Reactor具有非常優秀的效能，然而慕名歸慕名，到這裡，我還是要不得不問自己Reactor模式的好處在哪裡？即為什麼要使用這個Reactor模式？在Reactor An Object Behavioral Pattern for Demultiplexing and Dispatching Handles for Synchronous Events中是這麼說的：
這些貌似是很多模式的共性：解耦、提升複用性、模組化、可移植性、事件驅動、細力度的併發控制等，因而並不能很好的說明什麼，特別是它鼓吹的對效能的提升，這裡並沒有體現出來。當然在這篇文章的開頭有描述過另一種直觀的實現：Thread-Per-Connection，即傳統的實現，提到了這個傳統實現的以下問題：
對於效能，它其實就是第一點關於Efficiency的描述，即執行緒的切換、同步、資料的移動會引起效能問題。也就是說從效能的角度上，它最大的提升就是減少了效能的使用，即不需要每個Client對應一個執行緒。我的理解，其他業務邏輯處理很多時候也會用到相同的執行緒，IO讀寫操作相對CPU的操作還是要慢很多，即使Reactor機制中每次讀寫已經能保證非阻塞讀寫，這裡可以減少一些執行緒的使用，但是這減少的執行緒使用對效能有那麼大的影響嗎？答案貌似是肯定的，這篇論文(SEDA: Staged Event-Driven Architecture - An Architecture for Well-Conditioned, Scalable Internet Service)對隨著執行緒的增長帶來效能降低做了一個統計：
在這個統計中，每個執行緒從磁碟中讀8KB資料，每個執行緒讀同一個檔案，因而資料本身是快取在作業系統內部的，即減少IO的影響；所有執行緒是事先分配的，不會有執行緒啟動的影響；所有任務在測試內部產生，因而不會有網路的影響。該統計資料執行環境：Linux
2.2.14，2GB記憶體，4-way 500MHz Pentium
III。從圖中可以看出，隨著執行緒的增長，吞吐量線上程數為8個左右的時候開始線性下降，並且到64個以後而迅速下降，其相應事件也線上程達到256個後指數上升。即1+1<2，因為執行緒切換、同步、資料移動會有效能損失，執行緒數增加到一定數量時，這種效能影響效果會更加明顯。
對於這點，還可以參考C10K Problem，用以描述同時有10K個Client發起連線的問題，到2010年的時候已經出現10M Problem了。
當然也有人說：Threads are expensive are no longer valid.在不久的將來可能又會發生不同的變化，或者這個變化正在、已經發生著？沒有做過比較仔細的測試，因而不敢隨便斷言什麼，然而本人觀點，即使執行緒變的影響並沒有以前那麼大，使用Reactor模式，甚至時SEDA模式來減少執行緒的使用，再加上其他解耦、模組化、提升複用性等優點，還是值得使用的。
Reactor模式的缺點
Reactor模式的缺點貌似也是顯而易見的：
1. 相比傳統的簡單模型，Reactor增加了一定的複雜性，因而有一定的門檻，並且不易於除錯。
2.
Reactor模式需要底層的Synchronous Event
Demultiplexer支援，比如Java中的Selector支援，作業系統的select系統呼叫支援，如果要自己實現Synchronous
Event Demultiplexer可能不會有那麼高效。
3.
Reactor模式在IO讀寫資料時還是在同一個執行緒中實現的，即使使用多個Reactor機制的情況下，那些共享一個Reactor的Channel如果出現一個長時間的資料讀寫，會影響這個Reactor中其他Channel的相應時間，比如在大檔案傳輸時，IO操作就會影響其他Client的相應時間，因而對這種操作，使用傳統的Thread-Per-Connection或許是一個更好的選擇，或則此時使用Proactor模式。
"它其實就是第一點關於Efficiency的描述，即執行緒的切換、同步、資料的移動會引起效能問題", 作者這段話是本篇文章的題眼, 因為Jakob在部落格裡說過"它適用於連線數很多但每個連線的流量很小(處理時間很短)的情況", 兩種表述一個思想.
另外,
reactor pattern和observer pattern兩種模式類似, 區別在於前者與多個事件源關聯, 後者與多個事件源關聯.
這點區別, 又反過來印證了上述思想, reactor pattern和多個事件源關聯, 每個事件的處理時間很短, 所以, 大家複用執行緒,
避免執行緒切換/同步/資料移動帶來的效能問題; observer pattern和單個事件源關聯, 不同事件的處理時間不一致, 各類事件獨享執行緒,
避免處理時間長的影響處理時間短的響應速度
轉載自：http://www.blogjava.net/DLevin/archive/2015/09/02/427045.html