《Akka應用模式：分布式應用程式設計實踐指南》讀書筆記1

作者屬于Scala、Akka技術愛好者，但苦于Akka沒有關于設計模式的文章，偶爾搜到《Akka應用模式》一書，如獲至寶。現整理一些讀書筆記和自己的感悟，以供參考。

Actor模型

Actor模型感覺還是很給力的，要是按我以前學習actor模型，絕對會對他嗤之以鼻，這玩兒意能幹啥。哈哈哈，隻能說當時年輕氣盛吧。

現實是最終一緻的。

作者舉了一個例子說明了一下，Actor模型的設計哲學：世界不同資訊的交流是異步的。那為啥不基于現實世界來模組化，嘗試使用異步事件來構造軟體系統呢？相信這對于大部分人來說，提供了另一種解決問題的思路。當然，全部都異步畢竟還是很困難的。

結構Actor模型

Actor模型的概念，很早就有了，各個語言都有各自的實作方式。但Actor模型需要遵循以下幾個基本規則：

• • 所有的計算都是在actor中執行的
  • actor之間隻能通過消息進行通信交流
  • 為了響應消息，actor可以進行下列操作
    • • 更改狀态或行為
      • 發消息給其他actor
      • 建立有限數量的子actor

第一點其實還是很好了解的，畢竟把狀态和行為封裝起來是OOP的設計哲學。但第二點說明了兩者的根本差別。在OOP中一個對象與另一個對象的互動是通過對象公開的函數進行的，例如A調用B對象的某個方法就可以改變B對象的狀态。但在actor世界中，隻能通過消息進行交流。這一點是不是很像現實世界，就好像我跟你說一句話，總不能進入你的腦袋中去告訴聽覺系統一樣。

神奇的是第三點，為啥神奇呢？因為它沒有說明對消息如何響應！如果一個actor隻能更改自己的狀态或行為、發消息給其他actor、建立有限數量的子actor，那要他有何用呢？哈哈哈，這也是我剛學的時候特别不了解的事情。

actor之間隻能通過消息進行通信

這一點在上一節中已經說過了。每個actor都有一個郵箱（類似于消息隊列一樣），消息被投遞到某個actor的郵箱後，actor就可以接收并處理這些消息，但是每次隻能接收處理一條消息。what？！這聽上去是不是很扯，一次隻能處理一個消息，請問如何保持多線程時的效率！這個問題後面再聊，我們先看看他的好處。如果一次隻能處理一個消息，那就意味着actor中單線程可以很完美的工作。actor可以自由、任意的修改自己的内部狀态，完美的規避了并發的問題。看上去是不是也很扯？隻是我剛學的時候也是這樣認為的。

其實很多時候，線程、鎖、并發無形中增加了系統的複雜性。而大部分程式員不一定能完美解決這個問題，要不然就不會有那麼多關于解決死鎖的文章了。actor缺消除了這一問題，當然這需要某種機制來保證。這一點後面再說。

actor可以建立子actor

這一點也跟OOP的對象不同。其實我對這一點的了解是，actor的并發問題垂直向下解決了。并發往往意味着多個線程并行執行，即在水準方向上的并發。然後actor可以建立子actor，那麼意味着actor之間可以有一定的層級關系，有層級關系就意味着可以互相通信、父actor可以管理子actor（畢竟子actor都是它建立的）。而這種層級關系在故障恢複時非常有用。

actor可以改變自己的狀态或行為

這一點跟OOP差不多。actor收到某條消息時可改變自己内部的狀态或行為，但OOP中經常會改變狀态，行為比較少改變。actor的這種特性在構造FSM時非常有用。

一切都是actor

其實這一點剛開始我了解的不是很清楚。怎麼一切都是actor呢？一切都是actor是不是意味着行為也可以是actor呢？Actor基本規則中沒有描述對消息的響應在哪裡處理，隻是說可以發消息給其他actor、建立子actor。這裡又說一切都是actor，難道把行為也看成actor，由子actor去處理？嗯，這往往是一種很好的設計模式：某個子actor隻接受一個或少量類型的消息，然後做應答，應答後立即銷毀自身actor。既然可以建立有限數量的子actor，那就意味着可以并發的處理同類型的很多消息。這是不是把并發的問題垂直化處理了呢。

Actor模型的使用

actor看上去很完美，但也有其使用的場景。使用時需要考慮其使用的基本規範和場景。

定義清晰的邊界。

這跟OOP一樣，都需要定義清晰的邊界。清晰的邊界意味着對象或actor封裝的足夠好，執行個體之間隻能通過接口或者消息進行通信，也就是高内聚低耦合。無論從業務上還是技術上，都會是一件完美的事情。

何時使用Actor模型

• • 對高并發有嚴格要求的同時又需要維護某種狀态。畢竟維持并發狀态是Actor模型裡面最基本的屬性。
  • 建構有限狀态機
  • 需要高并發，同時也需要很小心的管理并發。

上面是書籍作者列舉的三種情況，但并不限于此。其實簡單點來說，需要處理高并發，又需要正确的維護某種狀态時，就可以用actor。當然了對于我來說，那就是用actor解決一切高并發的問題，如果不能解決，那就是我的actor設計的不夠好。哈哈哈，我相信以目前的工作内容來看，并發的問題全都可以用actor解決。