Actor併發編程模型淺析

一.Actor模型介紹

在單核 CPU 發展已經達到一個瓶頸的今天，要增加硬體的速度更多的是增加 CPU 核的數目。而針對這種情況，要使我們的程式運行效率提高，那麼也應該從併發方面入手。傳統的多線程方法又極其容易出現 Bug 而難以維護，不過別擔心，今天將要介紹另一種併發的模式能一定程度解決這些問題，那就是 Actor 模型。

Actor 模型其實就是定義一組規則，這些規則規定了一組系統中各個模塊如何交互及回應。在一個 Actor 系統中，Actor 是最小的單元模塊，系統由多個 Actor 組成。每個 Actor 有兩個東西，一個是 mailbox，一個是自身狀態。同時 Actor 有接收和發送的功能。下麵代碼給出一個大概的 Actor 樣例：

trait Actor {
  //持有一個表示自身狀態的私有變數
  val state:Integer = 0;
  //持有一個mailbox 的隊列
  val mailBox:mutable.Queue[Message] = scala.collection.mutable.Queue[Message]()
  def send(message : Message): Unit ={
      ...
  }
  def recive(): Unit ={
      ...
  }
}

當一個 Actor 接收到消息後，它會執行下麵三種操作中的一種：

• 創建其他actors。
• 向其他actors發送消息。
• 修改自身狀態。
  需要註意的是，儘管許多actors同時運行，但是一個actor只能順序地處理消息。也就是說其它actors發送了三條消息給一個actor，這個actor只能一次處理一條。所以如果你要並行處理3條消息，你需要把這條消息發給3個actors。

下麵這張圖展示了一個簡單的 Actor 模型系統：

瞭解了 Actor 模型的大概規則後，我們用兩個具體的例子來看看 Actor 模型的妙處以及不足吧。

二. 兩個例子

2.1 素數計算

假設我們現在有一個任務，需要找出100000以內素數個數，並且使用多線程的方式實現。

下圖展示了使用共用記憶體的方式和以Actor模型的方式進行併發執行。

這裡展示了兩種處理併發的不同思路，傳統的方式是通過鎖/同步的方式來實現併發，每次同步獲取當前值，並讓一個線程去判斷值是否為素數，是的話再通過同步的方式對計數器加1（這裡的說明只是作為提供思路用，這種方法自然有很大的優化空間）。

而使用 Actor 模型則不一樣，它將這一過程拆分成幾個模塊，即拆分成幾個 Actor 。每個 Actor 負責不同的部分，通過消息傳遞的方式讓這幾個 Actor 協同工作，並且其中涉及到主要計算的 Actor 可以有多個，通過多個 Actor 協同工作實現併發。

2.2 銀行轉賬

銀行轉賬的任務描述很簡單，假設有兩個用戶，現在用戶A向用戶B轉賬100元，這個 Actor 模型該如何設計呢？

用戶 A 和 用戶 B 明顯是兩個 Actor ，但我們同時還需要一個可以控制用戶A Actor 和用戶B Actor 的 Actor ，我們稱之為 轉賬管家 Actor。那麼流程圖如下。

可以看到，當一個轉賬需求過來的時候，Actor 管家會先向 用戶A Actor 發送扣款 100 元的信息，接受到扣款成功消息後再發送消息給用戶B Actor，發送讓其增加 100 元的消息。

一切看起來都很美好是吧，但這裡面有一個問題，那就是在用戶A Actor 扣款期間，用戶B Actor 是不受限制的，此時對用戶B Actor 進行操作是合法的！針對這種情況單純的Actor模型就顯得比較乏力了，需要加入其他機制以保證一致性。

看到這你就明白了，Actor 模型並非萬能的，它有一定的缺點。那就是針對一致性要求比較強的場景比較乏力。

三. 為什麼會出現 Actor 模型

接下來我們來聊聊為什麼會有 Actor 模型這種併發編程模型出現。

我們需要先說說併發性中的一致性和隔離性。

一致性即讓數據保持一致，比如銀行轉賬例子中，用戶A 轉給　用戶B 100塊錢，沒有其他干擾的情況下，轉賬完成時。用戶A 的賬戶必然減少 100 元，用戶B 的賬戶必然增加100 元，這就滿足了一致性。不能說用戶A 減少50 或用戶B 增加了 200。

隔離性可以理解為犧牲一部分的一致性需求，而獲得性能的提高。打個比方，在完全一致的情況下，任務都是串列的，這時候也就不存在隔離性了。

明白這些之後，你就直到為什麼會有 Actor 模型了。

傳統併發模式，共用記憶體是傾向於強一致性弱隔離性的。比如悲觀鎖/同步的方式，其實就是使用強一致性的方式控制併發。而Actor 模型天然是強隔離性且弱一致性，所以 Actor 模型在併發中有良好的性能，且易於控制和管理。

這樣你就明白 Actor 模型適合於什麼樣的併發場景了，當對一致性需求不是很高的情況下且對性能需求較高時，Actor 模型無疑是一個值得嘗試的方案。