分布式高并發下Actor模型如此優秀
寫在開始
一般來說有兩種策略用來在并發線程中進行通信：共享數據和消息傳遞。使用共享數據方式的并發編程面臨的最大的一個問題就是數據條件競爭。處理各種鎖的問題是讓人十分頭痛的一件事。
傳統多數流行的語言并發是基于多線程之間的共享內存，使用同步方法防止寫爭奪，Actors使用消息模型，每個Actor在同一時間處理最多一個消息，可以發送消息給其他Actor，保證了單獨寫原則。從而巧妙避免了多線程寫爭奪。和共享數據方式相比，消息傳遞機制最大的優點就是不會產生數據競爭狀態。實現消息傳遞有兩種常見的類型：基于channel（golang為典型代表）的消息傳遞和基于Actor（erlang為代表）的消息傳遞。
Actor簡介
Actor模型=數據+行為+消息。
Actor模型是一個通用的并發編程模型，而非某個語言或框架所有，幾乎可以用在任何一門編程語言中，其中最典型的是erlang，在語言層面就提供了Actor模型的支持，殺手锏應用RabbitMQ 就是基于erlang開發的。
更加面向對象
Actor類似面向對象編程（OO）中的對象，每個Actor實例封裝了自己相關的狀態，并且和其他Actor處于物理隔離狀態。舉個游戲玩家的例子，每個玩家在Actor系統中是Player 這個Actor的一個實例，每個player都有自己的屬性，比如Id，昵稱，攻擊力等，體現到代碼級別其實和我們OO的代碼并無多大區別，在系統內存級別也是出現了多個OO的實例
- class PlayerActor
- { public int Id { get; set; }
- public string Name { get; set; }
- }
無鎖
在使用Java/C# 等語言進行并發編程時需要特別的關注鎖和內存原子性等一系列線程問題，而Actor模型內部的狀態由它自己維護即它內部數據只能由它自己修改(通過消息傳遞來進行狀態修改)，所以使用Actors模型進行并發編程可以很好地避免這些問題。Actor內部是以單線程的模式來執行的，類似于redis，所以Actor完全可以實現分布式鎖類似的應用。
異步
每個Actor都有一個專用的MailBox來接收消息，這也是Actor實現異步的基礎。當一個Actor實例向另外一個Actor發消息的時候，并非直接調用Actor的方法，而是把消息傳遞到對應的MailBox里，就好像郵遞員，并不是把郵件直接送到收信人手里，而是放進每家的郵箱，這樣郵遞員就可以快速的進行下一項工作。所以在Actor系統里，Actor發送一條消息是非?？斓?。
這樣的設計主要優勢就是解耦了Actor，數萬個Actor并發的運行，每個actor都以自己的步調運行，且發送消息，接收消息都不會被阻塞。
隔離
每個Actor的實例都維護這自己的狀態，與其他Actor實例處于物理隔離狀態，并非像 多線程+鎖 模式那樣基于共享數據。Actor通過消息的模式與其他Actor進行通信，與OO式的消息傳遞方式不同，Actor之間消息的傳遞是真正物理上的消息傳遞。
天生分布式
每個Actor實例的位置透明，無論Actor地址是在本地還是在遠程機器上對于代碼來說都是一樣的。每個Actor的實例非常小，最多幾百字節，所以單機幾十萬的Actor的實例很輕松。如果你寫過golang代碼，就會發現其實Actor在重量級上很像Goroutine。由于位置透明性，所以Actor系統可以隨意的橫向擴展來應對并發，對于調用者來說，調用的Actor的位置就在本地，當然這也得益于Actor系統強大的路由系統。
生命周期
每個Actor實例都有自己的生命周期，就像C# java 中的GC機制一樣，對于需要淘汰的Actor，系統會銷毀然后釋放內存等資源來保證系統的持續性。其實在Actor系統中，Actor的銷毀完全可以手動干預，或者做到系統自動化銷毀。
容錯
說到Actor的容錯，不得不說還是挺令人意外的。傳統的編程方式都是在將來可能出現異常的地方去捕獲異常來保證系統的穩定性，這就是所謂的防御式編程。但是防御式編程也有自己的缺點，類似于現實，防御的一方永遠不能100%的防御住所有將來可能出現代碼缺陷的地方。比如在java代碼中很多地方充斥著判斷變量是否為nil，這些就屬于防御式編碼最典型的案例。但是Actor模型的程序并不進行防御式編程，而是遵循“任其崩潰”的哲學，讓Actor的管理者們來處理這些崩潰問題。比如一個Actor崩潰之后，管理者可以選擇創建新的實例或者記錄日志。每個Actor的崩潰或者異常信息都可以反饋到管理者那里，這就保證了Actor系統在管理每個Actor實例的靈活性。
劣勢
天下無完美的語言，框架/模型亦是如此。Actor作為分布式下并發模型的一種，也有其劣勢。
- 由于同一類型的Actor對象是分散在多個宿主之中，所以取多個Actor的集合是個軟肋。比如在電商系統中，商品作為一類Actor，查詢一個商品的列表在多數情況下經過以下過程：首先根據查詢條件篩選出一系列商品id，根據商品id分別取商品Actor列表（很可能會產生一個商品搜索的服務，無論是用es或者其他搜索引擎）。如果量非常大的話，有產生網絡風暴的危險（雖然幾率非常?。Ｔ趯崟r性要求不是太高的情況下，其實也可以獨立出來商品Actor的列表，利用MQ接收商品信息修改的信號來處理數據一致性的問題。
- 在很多情況下基于Actor模型的分布式系統，緩存很有可能是進程內緩存，也就是說每個Actor其實都在進程內保存了自己的狀態信息，業內通常把這種服務成為有狀態服務。但是每個Actor又有自己的生命周期，會產生問題嗎？呵呵，也許吧。想想一下，還是拿商品作為例子， 如果環境是非Actor并發模型，商品的緩存可以利用LRU策略來淘汰非活躍的商品緩存，來保證內存不會使用過量，如果是基于Actor模型的進程內緩存呢，每個actor其實就是緩存本身，就不那么容易利用LRU策略來保證內存使用量了，因為Actor的活躍狀態對于你來說是未知的。
- 分布式事物問題，其實這是所有分布式模型都面臨的問題，非由于Actor而存在。還是以商品Actor為例，添加一個商品的時候，商品Actor和統計商品的Actor（很多情況下確實被設計為兩類Actor服務）需要保證事物的完整性，數據的一致性。在很多的情況下可以犧牲實時一致性用最終一致性來保證。
- 每個Actor的mailBox有可能會出現堆積或者滿的情況，當這種情況發生，新消息的處理方式是被拋棄還是等待呢，所以當設計一個Actor系統的時候mailBox的設計需要注意。
升華一下
- 通過以上介紹，既然Actor對于位置是透明的，任何Actor對于其他Actor就好像在本地一樣。基于這個特性我們可以做很多事情了，以前傳統的分布式系統，A服務器如果想和B服務器通信，要么RPC的調用（http調用不太常用），要么通過MQ系統。但是在Actor系統中，服務器之間的通信都變的很優雅了，雖然本質上也屬于RPC調用，但是對于編碼者來說就好像在調用本地函數一樣。其實現在比較時興的是Streaming方式。
- 由于Actor系統的執行模型是單線程，并且異步，所以凡是有資源競爭的類似功能都非常適合Actor模型，比如秒殺活動。
- 基于以上的介紹，Actor模型在設計層面天生就支持了負載均衡，而且對于水平擴容支持的非常好。當然Actor的分布式系統也是需要服務注冊中心的。
- 雖然Actor是單線程執行模型，并不意味著每個Actor都需要占用一個線程，其實Actor上執行的任務就像Golang的goroutine一樣，完全可以是一個輕量級的東西，而且一個宿主上所有的Actor可以共享一個線程池，這就保證了在使用最少線程資源的情況下，最大量化業務代碼。
