天天看點

IO設計模式:Actor、Reactor、Proactor

先看看io模型

  先介紹兩種高性能伺服器模型Reactor、Proactor

Reactor模型: 

1 向事件分發器注冊事件回調 

2 事件發生 

4 事件分發器調用之前注冊的函數 

4 在回調函數中讀取資料,對資料進行後續處理 

Reactor模型執行個體:libevent,Redis、ACE

Proactor模型: 

1 向事件分發器注冊事件回調 

2 事件發生 

3 作業系統讀取資料,并放入應用緩沖區,然後通知事件分發器 

4 事件分發器調用之前注冊的函數 

5 在回調函數中對資料進行後續處理 

Preactor模型執行個體:ASIO

reactor和proactor的主要差別:

主動和被動

以主動寫為例: 

Reactor将handle放到select(),等待可寫就緒,然後調用write()寫入資料;寫完處理後續邏輯; 

Proactor調用aoi_write後立刻傳回,由核心負責寫操作,寫完後調用相應的回調函數處理後續邏輯;

可以看出,Reactor被動的等待訓示事件的到來并做出反應;它有一個等待的過程,做什麼都要先放入到監聽事件集合中等待handler可用時再進行操作; 

Proactor直接調用異步讀寫操作,調用完後立刻傳回;

實作

Reactor實作了一個被動的事件分離和分發模型,服務等待請求事件的到來,再通過不受間斷的同步處理事件,進而做出反應;

Proactor實作了一個主動的事件分離和分發模型;這種設計允許多個任務并發的執行,進而提高吞吐量;并可執行耗時長的任務(各個任務間互不影響)

優點

Reactor實作相對簡單,對于耗時短的處理場景處理高效; 

作業系統可以在多個事件源上等待,并且避免了多線程程式設計相關的性能開銷和程式設計複雜性; 

事件的串行化對應用是透明的,可以順序的同步執行而不需要加鎖; 

事務分離:将與應用無關的多路分解和配置設定機制和與應用相關的回調函數分離開來,

Proactor性能更高,能夠處理耗時長的并發場景;

缺點

Reactor處理耗時長的操作會造成事件分發的阻塞,影響到後續事件的處理;

Proactor實作邏輯複雜;依賴作業系統對異步的支援,目前實作了純異步操作的作業系統少,實作優秀的如windows IOCP,但由于其windows系統用于伺服器的局限性,目前應用範圍較小;而Unix/Linux系統對純異步的支援有限,應用事件驅動的主流還是通過select/epoll來實作;

适用場景

Reactor:同時接收多個服務請求,并且依次同步的處理它們的事件驅動程式; 

Proactor:異步接收和同時處理多個服務請求的事件驅動程式;

再說Actor模型: 

Actor模型被稱為高并發事務的終極解決方案,

實體之通過消息通訊,各自處理自己的資料,能夠實作這并行。 

actor模型執行個體:skynet,Erlang 

Actor模型是一個概念模型,用于處理并發計算。它定義了一系列系統元件應該如何動作和互動的通用規則,最著名的使用這套規則的程式設計語言是Erlang。

一個Actor指的是一個最基本的計算單元。它能接收一個消息并且基于其執行計算。

這個理念很像面向對象語言,一個對象接收一條消息(方法調用),然後根據接收的消息做事(調用了哪個方法)。

Actors一大重要特征在于actors之間互相隔離,它們并不互相共享記憶體。這點差別于上述的對象。也就是說,一個actor能維持一個私有的狀态,并且這個狀态不可能被另一個actor所改變。

思路方向:

其實無論是使用資料庫鎖 還是多線程,這裡有一個共同思路,就是将資料喂給線程,就如同計算機是一套加工流水線,資料作為原材料投入這個流水線的開始,流水線出來後就是成品,這套模式的前提是資料是被動的,自身不複雜,沒有自身業務邏輯要求。适合大資料處理或網際網路網站應用等等。

但是如果資料自身要求有嚴格的一緻性,也就是事務機制,資料就不能被動被加工,要讓資料自己有行為能力保護實作自己的一緻性,就像孩子小的時候可以任由爸媽怎麼照顧關心都可以,但是如果孩子長大有自己的思想和要求,他就可能不喜歡被爸媽照顧,他要求自己通過行動實作自己的要求。

資料也是如此。

隻有我們改變思路,讓資料自己有行為維護自己的一緻性,才能真正安全實作真正的事務。

我們可以看到

Actor模型=資料+行為+消息。

Actor模型内部的狀态由自己的行為維護,外部線程不能直接調用對象的行為,必須通過消息才能激發行為,這樣就保證Actor内部資料隻有被自己修改。

參考:

reactor和proactor模式(epoll和iocp)

為什麼Actor模型是高并發事務的終極解決方案?

轉載于:https://www.cnblogs.com/losophy/p/9202815.html

繼續閱讀