我應該何時在阿卡使用Actors vs. Remote Actors？何時使用本地或遠程演員？
我明白，兩者都可以縮放機器，但只有遠程演員才能擴展出來，所以有沒有實際的生產使用正常的演員？
如果一個遠程角色只有一個較小的初始設置開銷，並且沒有任何其他主要開銷到一個普通的Actor，那麼我會認爲使用遠程Actor是標準的，因爲它可以擴展和輕鬆一下。即使從來沒有需要擴大生產代碼的範圍，也可以選擇（如果不帶行李的話）。
任何有關何時使用演員與遠程演員的洞察力將不勝感激。
遠程演員不能擴展，他們只是對另一臺機器上的本地演員的遠程引用。
對於Akka 2.0，我們將介紹集羣參與者，這將允許您編寫一個Akka應用程序並僅使用配置將其擴展。
經常演員可用於在本地項目中發送消息。 對於遠程參與者，您可以使用它將消息發送到與發送消息的項目相關的相關項目。
請參考這裏的遠程阿卡演員
問題問「如果一個遠程的演員只有一個微小的初始設置開銷，並且沒有任何其他主要的開銷，那麼我會認爲，使用遠程演員將是標準的「。但Fallacies of distributed computing指出，假定任何技術的遠程處理都沒有開銷，這是一個設計錯誤。您有將消息複製到字節並通過網絡接口傳輸的開銷。您還擁有不同進程的所有複雜性，包括上，下，停止或無法訪問，以及網絡打嗝導致丟失，重複或重新排序的消息。
This great article有真實世界的奇怪的網絡錯誤的例子，使遠程難以做出防彈。 Akka項目負責人Roland Kuln在他的free video course about akka中表示，根據他每發送1T個網絡消息的經驗，他看到了腐敗。 Notes on Distributed Systems for Young Bloods說「分佈式系統往往需要實際的，而不是模擬的分佈來消除它們的錯誤」，所以即使是很好的單元測試也不會構成一個完美的系統。有很多的建議，遠程處理不是「免費」，而是努力完成。
如果您需要使用遠程處理來實現可用性或遷移到巨大規模，請注意akka確實可能會發送at-least-once重複數據。所以你必須確保重複的消息不會產生不好的結果。
當你開始使用遠程處理的時候，你有一個分佈式系統，它產生了在Distributed systems for fun and profit中討論的挑戰。除非你正在做非常簡單的事情，比如無狀態的計算器，它們對於重複消息是冪等的，事情會變得棘手。在上面鏈接中關於akka視頻課程的一項任務是製作一個複製的鍵值存儲，通過自己編寫邏輯來處理丟失的消息。它遠非一項簡單的任務。狀態分佈在不同的進程中變得非常困難，參與者封裝狀態，因此分配參與者可能變得非常困難，這取決於您正在構建的系統的一致性和可用性要求。
這一切都意味着，如果你可以避免遠程處理，並實現你需要達到的目標，那麼你應該明智地避免它。如果你確實需要遠程處理，那麼Akka很容易，因爲它的location transparency。所以儘管它是一個很棒的工具箱，可以在工作中隨身攜帶。你應該仔細檢查一下工作是否需要所有的工具或者只需要最簡單的工具。