reactor這個詞譯成漢語還真沒有什麼合適的，很多地方叫反應器模式，但更多好像就直接叫reactor模式了，其實我覺著叫應答者模式更好理解一些。通過了解，這個模式更像乙個侍衛，一直在等待你的召喚，或者叫召喚獸。
併發系統常使用reactor模式，代替常用的多執行緒的處理方式，節省系統的資源，提高系統的吞吐量。
先用比較直觀的方式來介紹一下這種方式的優點，通過和常用的多執行緒方式比較一下，可能更好理解。
以乙個餐飲為例，每乙個人來就餐就是乙個事件，他會先看一下選單，然後點餐。就像乙個**會有很多的請求，要求伺服器做一些事情。處理這些就餐事件的就需要我們的服務人員了。
在多執行緒處理的方式會是這樣的：
乙個人來就餐，乙個服務員去服務，然後客人會看選單，點菜。 服務員將選單給後廚。
二個人來就餐，二個服務員去服務……
五個人來就餐，五個服務員去服務……
這個就是多執行緒的處理方式，乙個事件到來，就會有乙個執行緒服務。很顯然這種方式在人少的情況下會有很好的使用者體驗，每個客人都感覺自己是vip，專人服務的。如果餐廳一直這樣同一時間最多來5個客人，這家餐廳是可以很好的服務下去的。
來了乙個好訊息，因為這家店的服務好，吃飯的人多了起來。同一時間會來10個客人，老闆很開心，但是只有5個服務員，這樣就不能一對一服務了，有些客人就要沒有人管了。老闆就又請了5個服務員，現在好了，又能每個人都受vip待遇了。
越來越多的人對這家餐廳滿意，客源又多了，同時來吃飯的人到了20人，老闆高興不起來了，再請服務員吧，佔地方不說，還要開工錢，再請人就攢不到錢了。怎麼辦呢？老闆想了想，10個服務員對付20個客人也是能對付過來的，服務員勤快點就好了，伺候完乙個客人馬上伺候另外乙個，還是來得及的。綜合考慮了一下，老闆決定就使用10個服務人員的執行緒池啦~~~
但是這樣有乙個比較嚴重的缺點就是，如果正在接受服務員服務的客人點菜很慢，其他的客人可能就要等好長時間了。有些火爆脾氣的客人可能就等不了走人了。
reactor如何處理這個問題呢：
老闆後來發現，客人點菜比較慢，大部服務員都在等著客人點菜，其實幹的活不是太多。老闆能當老闆當然有點不一樣的地方，終於發現了乙個新的方法，那就是：當客人點菜的時候，服務員就可以去招呼其他客人了，等客人點好了菜，直接招呼一聲「服務員」，馬上就有個服務員過去服務。嘿嘿，然後在老闆有了這個新的方法之後，就進行了一次裁員，只留了乙個服務員！這就是用單個執行緒來做多執行緒的事。
實際的餐館都是用的reactor模式在服務。一些設計的模型其實都是從生活中來的。
reactor模式主要是提高系統的吞吐量，在有限的資源下處理更多的事情。
在單核的機上，多執行緒並不能提高系統的效能，除非在有一些阻塞的情況發生。否則執行緒切換的開銷會使處理的速度變慢。就像你乙個人做兩件事情，1、削乙個蘋果。2、切乙個西瓜。那你可以一件一件的做，我想你也會一件一件的做。如果這個時候你使用多執行緒，一會兒削蘋果，一會切西瓜，可以相像究竟是哪個速度快。這也就是說為什麼在單核機上多執行緒來處理可能會更慢。
但當有阻礙操作發生時，多執行緒的優勢才會顯示出來，現在你有另外兩件事情去做，1、削乙個蘋果。2、燒一壺開水。我想沒有人會去做完一件再做另一件，你肯定會一邊燒水，一邊就把蘋果削了。
理論的東西就不多講了，請大家參考一下附件《reactor-siemens.pdf》。圖比較多，e文不好也可以看懂的。
reactor設計模式，是一種基於事件驅動的設計模式。
《pattern-oriented software architecture, volume 2》
對這個模式做了詳細的講解。
這個模式的結構圖如下：
圖中的handle對應的是作業系統提供的控制代碼，例如i/o控制代碼，event_handler類持有這些控制代碼，
reactor類內部提供乙個事件迴圈：handle_events()，事件迴圈的**實現利用了作業系統提供的多路分離函式，
waitformultipleobjects或者select等，這些多路分離的函式的特點是，可以同時等待多個控制代碼，在等待過程中所在
執行緒屬於掛起狀態，不消耗cpu時間，一旦某個控制代碼被觸發，則執行緒被喚醒，函式將返回，執行緒可以執行後面的**，
利用多路分離函式的這一特點，根據被啟用的控制代碼對應的特定事件，呼叫相關的事件處理函式。可以實現事件迴圈。
register_handler()函式用於將event_handler物件註冊到事件驅動列表
中，保證對於某一型別的事件，會呼叫event_handler類的響應函式handle_event()。
reactor類在做多路分離時需要操縱event_handler類的handle，因此event_handler類需要提供get_handle()函式。
另外，當程式不需要再對特定事件響應時，需要把event_handler物件從事件驅動列表中刪除，因此reactor類還實現了
remove_handler函式。
因為reactor相對穩定，一旦實現，不需要再定製，所以沒有提供乙個抽象介面類，但event_handler是經常需要根據不同
的需求定製的，因此需要提供乙個抽象介面類，然後根據實際需求編寫派生類，提供具體控制代碼，並實現相關虛函式。
這個模式的優點是本身不涉及多執行緒，從而避免了執行緒的上下文切換。
對於響應事件處理時間較短的情況下，可以考慮使用這個模式。
如果處理乙個事件需要花費大量時間，就不能使用這個模式，那樣會導致其他事件處理被阻塞。
ace_reactor框架是這一模式的半成品，使用者只要做三件事情就可以實現並使用這一模式：
1.從ace_event_handler派生乙個或多個類
2.向ace_reactor類登記應用的事件處理物件
3.執行ace_reactor事件迴圈。
《pattern-oriented software architecture, volume 2》
《ace程式設計師指南》
reactor設計模式
reactor設計模式，是一種基於事件驅動的設計模式。pattern oriented software architecture,volume 2 對這個模式做了詳細的講解。這個模式的結構圖如下 圖中的handle對應的是作業系統提供的控制代碼，例如i o控制代碼，event handler類持有...
設計模式 reactor
先看個段子吧，更好理解 reactor這個詞譯成漢語還真沒有什麼合適的，很多地方叫反應器模式，但更多好像就直接叫reactor模式了，其實我覺著叫應答者模式更好理解一些。通過了解，這個模式更像乙個侍衛，一直在等待你的召喚，或者叫召喚獸。併發系統常使用reactor模式，代替常用的多執行緒的處理方式，...
Reactor設計模式
nio用到的reactor設計模式，下面的說明比較清楚，留作記錄。reactor設計模式和觀察者模式非常相似，但是它比觀察者模式複雜，reactor設計模式使用乙個selector物件相當於觀察模者式裡面的觀察者，每個 socketserverchannal 例項和socketchannal例項都相...