2016-03-15 101 views
4

當我應該使用持久性Actor時,我陷入了對Akka持久性和持續演員的適用性的混淆?阿卡執行者有什麼用途?

例如從一個給定的購物應用程序的購物車模塊,將每個用戶的購物車會話持續演員與各自唯一的persistenceId?

實際應用中的可用性是什麼?查詢方如何處理持久性actor的狀態?當執行者在實際應用中沒有用處時?

存儲狀態或存儲消息都是一樣的東西?是不是?有什麼區別,我應該使用每一個?

有人能給我一些例子嗎?

+0

我相信持久行爲者是CQRS中的寫入方,並且您仍然需要在某種可查詢存儲中處理讀取方。Akka中的參與者根據定義是事件源,所以我沒有發現任何處理查詢的事件源系統(當然,我意識到其餘的差異)沒有根本的區別。 –

回答

4

這將是高度置評的問題,並且高度評價答案。

想象你有一個任務管理系統,例如吉拉或類似。比方說,你有演員的以下佈局:

  • 項目1
    • 票1
    • 門票2
  • 項目3
    • 票3

如果項目和門票實際上是持久的演員,那麼你必須,相對於標準方法(查詢等),具有以下優點:

  • 把演員上下恢復其狀態 - 所以沒有更復雜查詢並映射到參與者代碼。此外,如果您的應用程序關閉,重新啓動它基本上會加載具有所有歷史記錄的數據(如下)
  • 演員模型/ Akka監督爲您提供了額外的獎勵 - 如果您的演員已經死亡(即任務在嘗試從外部獲取數據時死亡集成),重新啓動它將帶回所有歷史記錄。
  • 追蹤記錄已經存在(您可以對數據進行建模,以便事件日記實際包含所有更改數據,如用戶和時間戳以及舊值/新值)。這實際上適用於多個業務領域 - 例如貿易處理,每筆交易都必須存儲自己的歷史。
  • 另一部分是查詢 - 如果您的系統允許最終一致的設計,您可以將數據分散到項目中的所有工單中,然後使用複雜的查詢並等待響應。

有用性來自您的應用程序的設計 - 有些非常適合(即多個單獨或鬆散耦合的實體),有些不太好(即您只想存儲單個最後一組數據並生成它的預定義報告)

+0

關於Ticket概念和Actor之間的關係。通過這個例子,我們將有一個演員「ticket1」,另一個演員「ticket2」等? –

+0

正確 - 國際海事組織,成爲持久行動者的最佳人選是域中的有形實體 - 門票/項目/交易/無論你喜歡 – abatyuk

+0

現在我開始明白這一點,所以基於演員的應用程序,如阿卡,可以由數百萬演員?謝謝你的答案! –