1

I'm looking at starting to use Actors within Service Fabric but I wanted to just clarify a few things before getting started.

I have a API that accepts a request from the user to process some data and returns an ID. Multiple requests from the users don't overlap in processing and are completely isolated so I feel that actors works well for this.

However what I want to understand is that would it be good practice to store the state locally within each actor that I create from each request and then when the api queries that data?

I understand that the actors get deactivated when not "being used" (https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-reliable-actors-lifecycle) but still keep their state and are reactivated when a new call is made to the actor. So in theory there wouldn't be any problem if each actor gets assigned the same ID that gets sent back to the user, then the user can come back and query the data even if the actor has been deactivated.

Is this a good approach or should I just get the actors to do the work and offload the storage to another stateful service? Be good to get a list of pros/cons to this problem.

4

1 回答 1

4

将 Actor 映射到用户可能是一个好方法，只要您的状态被标记Persistent为 Actor，即使在 Actor 激活/停用之间，状态也会可靠地存储（即复制到其他节点）。一个活跃的 Actor 仅仅意味着它被加载到ActorService. 如果一个 Actor 被停用并随后被调用，它只会被重新激活。如果您映射ActorId到用户 ID，那么相同的身份可以存储在 Actor 本身内，而无需辅助数据存储（例如数据库）。

Actor 的特点是它们是单线程的。这意味着对 Actor 和 Actor 状态的访问是按顺序进行的。如果对 Actor 的访问主要是由用户与您的 API 的交互驱动的，那么这应该不是问题。另一方面，如果您有多个服务同时访问您的 Actor，那么这可能会成为您的瓶颈，在这种情况下，您可能需要考虑使用可靠的有状态服务来代替数据/状态。

持久演员

  • 单线程访问
  • 包含状态
  • 按 ActorId 分区

没有状态和单独持久性的参与者

  • 单线程访问
  • 按 ActorId 分区
  • 受持久性解决方案（SQL 连接池等）限制的状态/数据访问

有状态服务

  • 多线程访问
  • 由“手动”分配的分区键分区
  • 状态可靠地包含在分区中

无状态服务

  • 多线程访问
  • 无分区，多实例
  • 受持久性解决方案（SQL 连接池等）限制的状态/数据访问
于 2017-02-15T14:08:02.963 回答