保持服務結構主體的狀態

Question

我正在考慮開始在Service Fabric中使用Actor，但是我想在開始之前先澄清一些事情。

我有一個API，可以接受用戶的請求以處理一些數據並返回ID。 來自用戶的多個請求在處理中不會重疊，並且完全隔離，因此我覺得參與者可以很好地做到這一點。

但是我想了解的是，將狀態本地存儲在我根據每個請求創建的每個參與者中，然后在api查詢該數據時是一種好習慣嗎？

我了解，當不“使用”時，參與者會被停用（ https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-reliable-actors-lifecycle ），但仍保持其狀態和狀態對演員的新呼叫時，將重新激活。 因此，從理論上講，如果為每個參與者分配了與發送回用戶相同的ID，那么即使參與者被停用，用戶也可以返回並查詢數據不會有任何問題。

這是一個好方法嗎？還是我應該讓參與者來做工作並將存儲分擔給另一個有狀態服務？ 很好地獲得此問題的利弊清單。

Answer 1

將Actor映射到用戶可能是一個很好的方法，只要您的狀態被標記為對Actor Persistent ，狀態就可以可靠地存儲（即復制到其他節點），即使在Actor激活/停用之間也是如此。 活動的Actor只是意味着將其加載到ActorService工作內存中。 如果一個Actor被停用並隨后被調用，則只需將其重新激活即可。 如果將ActorId映射到用戶ID，則可以在Actor自身中存儲相同的身份，而無需輔助數據存儲（例如數據庫）。

Actor的特征是它們是單線程的。 這意味着以順序的方式訪問Actor和Actor的狀態。 如果對Actor的訪問主要是由用戶與您的API的交互驅動的，那么這應該不是問題。 另一方面，如果您有多個服務正在同時訪問Actor，則這可能成為您的瓶頸，在這種情況下，您可能要考慮使用可靠的有狀態服務代替數據/狀態。

持久演員

• 單線程訪問
• 包含狀態
• 由ActorId划分

沒有國家和單獨堅持的行為者

• 單線程訪問
• 由ActorId划分
• 狀態/數據訪問受持久性解決方案限制（SQL連接池等）

有狀態的服務

• 多線程訪問
• 由“手動”分配的分區鍵進行分區
• 狀態可靠地包含在分區中

無狀態服務

• 多線程訪問
• 無分區，多個實例
• 狀態/數據訪問受持久性解決方案限制（SQL連接池等）