我正在考虑开始在Service Fabric中使用Actors，但我想在开始之前澄清一些事情。
我有一个API接受用户处理某些数据并返回ID的请求。用户的多个请求在处理过程中不会重叠，并且完全孤立，所以我觉得演员的工作效果很好。
然而，我想要理解的是，在我从每个请求创建的每个actor中本地存储状态，然后当api查询该数据时，这是一个好习惯吗？
据我所知，演员在没有被使用时会被停用＆＃34; （https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-reliable-actors-lifecycle）但仍保持其状态，并在对actor进行新调用时重新激活。所以从理论上讲，如果为每个actor分配了相同的ID并将其发送回用户，那么就不会有任何问题，即使演员已被停用，用户也可以回来查询数据。
这是一个好方法还是我应该让演员完成工作并将存储卸载到另一个有状态服务？很高兴得到这个问题的优缺点列表。
答案 0 :(得分：3)
将Actors映射到用户可能是一种很好的方法，只要您的状态被标记为Persistent，即使在Actor激活/停用期间状态可靠地存储（即复制到其他节点）。一个活跃的Actor只是意味着它被加载到ActorService的工作内存中。如果一个Actor被停用并随后被调用，它就会被重新激活。如果将ActorId映射到用户ID，则可以在Actor本身中存储相同的标识，而无需辅助数据存储（例如数据库）。
Actors的特点是它们是单线程的。这意味着对Actor和Actor的状态的访问是以顺序方式完成的。如果对Actor的访问主要是由用户与API的交互驱动的，那么这应该不是问题。另一方面，如果您有多个服务同时访问您的Actor，那么这可能会成为您的瓶颈，在这种情况下，您可能需要考虑使用可靠的有状态服务代替数据/状态。
持久演员
没有状态和独立持久性的演员
有状态服务
无国籍服务