Akka中Actor介紹《seventeen》譯

What is an Actor?

上一節關於Actor Systems的部分解釋了actor如何造成層次結構，而且是構建應用程序時的最小單元。本節將單獨查看一個這樣的actor，解釋在實現它時的概念。有關全部細節的更深刻參考，請參閱Actors。

Actor是State，Behavior，Mailbox，Child Actors和Supervisor Strategy的容器。全部這些都封裝在Actor Reference以後。一個值得注意的方面是演員有一個明確的生命週期，當再也不被引用時它們不會被自動銷燬;在建立一個以後，您有責任確保它最終也會被終止 - 這也能夠控制當Actor終止時如何釋放資源。

Actor Reference

以下所述，須要從外部屏蔽actor對象以便從actor模型中受益。所以，使用actor Reference將actor表示到外部使用，actor Reference是能夠自由且無限制地傳遞的對象。這分爲內部和外部對象，能夠實現全部所需操做的透明性：從新啓動actor而無需在其餘地方更新引用，將實際的actor對象放在遠程主機上，向徹底不一樣的應用程序中的actor發送消息。但最重要的方面是，除非演員自己不明智地發佈這些信息，不然沒法查看演員內部並從外部獲取其狀態。

State

Actor對象一般包含一些反映actor可能處於的狀態的變量。這能夠是顯式狀態機（例如使用FSM模塊），也能夠是計數器，監聽器集，待處理請求等。這些數據是讓演員有價值的東西，必須保護他們免受其餘演員的腐敗。好消息是，Akka Actor在概念上每一個都有本身的輕量級線程，徹底屏蔽了系統的其餘部分。這意味着您沒必要使用鎖來同步訪問，而是能夠編寫您的actor代碼而沒必要擔憂併發性。

在幕後，Akka將在一組真實線程上運行多組actor，一般許多actor共享一個線程，而且一個actor的後續調用最終可能會在不一樣的線程上進行處理。Akka確保此實現細節不會影響處理actor狀態的單線程。

由於內部狀態對於Actor的操做相當重要，因此具備不一致的狀態是致命的。所以，當actor失敗並由其主管從新啓動時，將從頭開始建立狀態，就像首次建立actor同樣。這是爲了實現系統自我修復的能力。

經過持久保存收到的消息並在從新啓動後重放它們，能夠自動將actor的狀態恢復到重啓前的狀態（請參閱「 Persistence」）。

Behavior

每次處理消息時，都會根據actor的當前behavior進行匹配。behavior是指定義在該時間點對消息做出反應的動做的函數，例如，若是客戶端被受權則轉發請求，不然拒絕它。此行爲可能會隨時間而改變，例如由於不一樣的客戶端會隨着時間的推移得到受權，或者由於參與者可能會進入「服務中斷」模式並稍後返回。這些更改是經過在狀態變量中對它們進行編碼來實現的，這些狀態變量是從行爲邏輯中讀取的，或者函數自己能夠在運行時被換出，請參閱變爲和不成熟的操做。可是，在構造actor對象期間定義的初始行爲是特殊的，由於從新啓動actor會將其行爲重置爲此初始行爲。

Mailbox

Actor的目的是處理消息，這些消息從其它Actor（或Actor系統外部）發送。鏈接發送者和接收者的片斷是Actor的郵箱：每一個Actor只有一個郵箱，全部發件人都將其郵件排入隊列。入隊以發送操做的時間順序發生，這意味着因爲跨線程分配actor的明顯隨機性，從不一樣的actor發送的消息可能在運行時沒有定義的順序。另外一方面，從同一個actor向同一目標發送多個消息將以相同的順序排列它們。

有不一樣的郵箱實現可供選擇，默認爲FIFO：由actor處理的消息的順序與它們排隊的順序相匹配。這一般是一個很好的默認設置，但應用程序可能須要優先處理某些消息而不是其餘消息。在這種狀況下，優先級郵箱不會老是排在最後，而是排列在消息優先級給定的位置，甚至可能位於前面。在使用這樣的隊列時，處理的消息的順序天然會由隊列的算法定義，而且一般不是FIFO。

Akka與其餘一些actor模型實現的不一樣之處在於，當前行爲必須始終處理下一個出列的消息，沒有掃描郵箱以查找下一個匹配的消息。沒法處理消息一般會被視爲失敗，除非覆蓋此行爲。

Child Actors

每一個Actor均可能是一個主管：若是它建立子任務來委派子任務，它將自動監督它們。子項列表保存在actor的上下文中，而且actor能夠訪問它。經過建立（context.actorOf（...））或中止（context.stop（child））子項來完成對列表的修改，並當即反映這些操做。實際的建立和終止操做以異步方式在幕後發生，所以它們不會「阻止」他們的主管。

Supervisor Strategy

Actor的最後一部分是處理其子女故障的策略。而後，Akka透明地完成故障處理，對每一個進入的故障應用監督和監控中描述的策略之一。因爲此策略是Actor系統結構的基礎，所以一旦建立了Actor，就沒法更改。

考慮到每一個Actor只有一個這樣的策略，這意味着若是不一樣的策略適用於一個Actor的各個孩子，那麼這些孩子應該被分組在具備匹配策略的中間監督者之下，再次優先考慮Actor系統的結構。將任務拆分爲子任務。

When an Actor Terminates

一旦一個actor終止，自行中止或被其主管中止，它將釋放其資源，將全部剩餘的消息從其郵箱中排放到系統的「死信郵箱」中。將它們做爲DeadLetters轉發到EventStream。而後，使用系統郵箱在actor引用中替換郵箱，將全部新消息重定向到EventStream做爲DeadLetters。儘管如此，這是在盡力而爲的基礎上完成的，所以不要依賴它來構建「保證交付」。

不只僅是默默地轉儲消息的緣由受到了咱們的測試的啓發：咱們在轉發死信的事件總線上註冊了TestEventListener，而且會在收到的每封死信中記錄警告 - 這對解密頗有幫助更快地測試失敗。能夠想到，該特徵也可用於其餘目的。