設計模式 reactor

2021-06-27 16:52:53 字數 1587 閱讀 1958

先看個段子吧,更好理解

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設計模式

reactor設計模式,是一種基於事件驅動的設計模式。pattern oriented software architecture,volume 2 對這個模式做了詳細的講解。這個模式的結構圖如下 圖中的handle對應的是作業系統提供的控制代碼,例如i o控制代碼,event handler類持有...

Reactor設計模式

reactor這個詞譯成漢語還真沒有什麼合適的,很多地方叫反應器模式,但更多好像就直接叫reactor模式了,其實我覺著叫應答者模式更好理解一些。通過了解,這個模式更像乙個侍衛,一直在等待你的召喚,或者叫召喚獸。併發系統常使用reactor模式,代替常用的多執行緒的處理方式,節省系統的資源,提高系統...

Reactor設計模式

nio用到的reactor設計模式,下面的說明比較清楚,留作記錄。reactor設計模式和觀察者模式非常相似,但是它比觀察者模式複雜,reactor設計模式使用乙個selector物件相當於觀察模者式裡面的觀察者,每個 socketserverchannal 例項和socketchannal例項都相...