actor模型的本質已經被強調了無數遍：萬物皆actor。actor之間只有傳送訊息這一種通訊方式，例如，無論是管理員讓工作者幹活，還是工作者把成果交還給管理員，它們之間也要通過傳送訊息的方式來傳遞資訊。這麼做看似不如直接方法呼叫來的直接，但是由於大量的訊息可以同時執行。同樣，訊息讓actor之間解耦，訊息發出之後執行成功還是失敗，需要耗費多少時間，只要沒有訊息傳遞回來，這一切都和傳送方無關。actor模型的訊息傳遞形式簡化了並行程式的開發，使開發人員無需在共享記憶體（確切地說，其實是共享「寫」）環境中與「鎖」、「互斥體」等常用基礎元素打交道。不過，使用actor模型編寫應用程式，需要開發人員使用一種與以往不同的設計思路，這樣的思路說難倒不難，說簡單也不簡單。等我們有了成熟、穩固的actor模型之後（例如高效的排程，合適的容錯機制，老趙正在為此努力），再回頭來**這種特殊的架構方式。
由於actor執行的唯一「事件」便是接受到了乙個訊息，而乙個actor很可能會做多件事情，因此我們一定需要一種機制，可以把訊息「分派」到不同的「邏輯段」中去，並為不同的邏輯指定各自所需要的引數。例如，person是乙個actor型別，它有三種任務，不同的任務會帶有不同引數：
◆聊天（chat）：指定另乙個person物件（聊天的另一方），以及乙個topic物件（聊天的話題）。
◆吃飯（eat）：指定乙個restaurant物件（餐館）。
◆幹活（work）：指定乙個person物件（工作完成後的匯報人），以及乙個job物件（任務）。
當person物件獲得一條訊息時，它需要將其識別為聊天、吃飯或幹活中的一種，再從中獲取到這個行動所需要的資料。如果用一幅示意圖來表示，它可能是這樣的：
如何在c#中把一條訊息轉化為一段邏輯的執行，並且盡可能確保一些優勢（如易於編寫，靜態檢查，**提示，重構，單元測試……），這便是這系列文章唯一的目的。正如文章的標題，我們關注的是「訊息執行方式」，而不是：
◆「訊息傳遞」與「共享記憶體」兩種並行方式的比較
◆講述actor模型的應用程式設計方式。
◆提出訊息傳遞時的解耦方式。
……文章使用actor模型作為示例，是因為我編寫的actorlite元件易於說明問題，並且是典型的「訊息傳遞」場景。事實上，文章所表達的內容，適合任何基於訊息傳遞的c#場景，例如記憶體中的訊息佇列、生產者/消費者模式、訊息匯流排……它並沒有限制actor模型這一種架構方式。
Actor模型原理
scala actor執行緒模型可以這樣理解 所有actor共享乙個執行緒池，總的執行緒個數可以配置，也可以根據cpu個數決定 當乙個actor啟動之後，scala分配乙個執行緒給它使用，如果使用receive模型，這個執行緒就一直為該actor所有，如果使用react模型，scala執行完reac...
Actor併發模型入門
使用scala，基於akka的actor併發模型。importakka.actor.actor importakka.actor.props importakka.actor.actorsystem importakka.routing.roundrobinpool 定義乙個封閉的特質 sealed...
Actor模型和CSP模型的區別
引用至 akka erlang的actor模型與go語言的協程goroutine與通道channel代表的csp communicating sequential processes 模型有什麼區別呢？首先這兩者都是併發模型的解決方案，我們看看actor和channel這兩個方案的不同 actor模...