Actor Pattern

不同的 Actors 各自負責不同的工作，彼此之間用共通的介面溝通

此Pattern主要想要解決關於多執行緒一些concurrency的問題。(Shared mutable state => race condition、dead lock)

每個演員彼此之間只透過Message互動，你可以想像每個Actor都跑在不同的Thread上，收到訊息之後各自決定該採取怎麼樣的行動(例如改變自己的State...)，沒有share state

基本上每一個演員 ( Actor ) 會擁有

1. message queue (會從中把訊息處理掉)
2. 每個 Actor 都有自己的 private state，別的 Actor 沒辦法直接更動你的 state，降低了因為 shared state 產生的問題。

處理訊息時他可以做一些事情(FIFO, Actor同時只能處理一個訊息)

1. 做出決策(可能改變Private State, Value)
2. 或是建立更多的其他演員(這些演員他可以管理)
3. 或是傳送更多訊息給其他演員
4. 或是指定某位演員接下來要怎麼處理訊息 (指示該如何處理下一個 Message)

第四個的意思是說，舉例來說，假設有個 Counter Actor A，一直以來都是會把接受到的 Message 數字累加到自己的 counter state 中，但今天可以有另一個 Actor B 傳遞訊息跟 Actor A 說：『hey, 你這次先不用累加數字了，但是下一個傳進來的訊息，你要乘以 2 以後再放到計數器內喔』。 (節錄自 https://blog.techbridge.cc/2019/06/21/actor-model-in-web/)

另外此Pattern很大的好錯就是，容錯系統

Actor對於他創建的Child Actor擁有Supervisor的權限，例如可以跟Child說發生錯誤導致crash前可以傳個訊息給我，好讓我重啟一個同樣的Actor替代你(或是傳restart訊息之類的總之就是想辦法讓它活過來)。這樣的能力造就了一個 Self-healing systems

這個Pattern也非常適用於分散式系統。

優點:

1.容易擴充 2.容錯率高 3.分散式 4.沒有共享Share state

缺點:

1.Actor還是容易受到dead lock的影響 2.Mailbox 有overflowing的問題

Reference

https://blog.techbridge.cc/2019/06/21/actor-model-in-web/