保持服务结构主体的状态

Question

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.

Answer 1

Mapping Actors to users could be a good approach, as long as your state is marked Persistent for the Actor the state is stored reliably (ie replicated to other nodes) even across Actor activations/deactivations. An active Actor simply means that it is loaded into working memory of the ActorService . If an Actor is deactivated and is subsequently called it simply gets reactivated. If you map ActorId to user id then the same identity could be stored within the Actor itself without a need for a secondary data storage (eg database).

What is characteristic for Actors is that they are single-threaded. This means that access to the Actor and the Actor's state is done in a sequential manner. If access to the Actor is primarily driven by the user's interactions with your API then that shouldn't be a problem. If you on the other hand have multiple service that are accessing your Actor concurrently then this might become a bottleneck for you, in which case you may want to consider using a Reliable Stateful Service instead for the data/state.

Persistent Actors

• Single-threaded access
• Contained state
• Partitioned by ActorId

Actors without state and separate persistance

• Single-threaded access
• Partitioned by ActorId
• State/data access limited by persistance solution (SQL connection pool etc.)

Stateful service

• Multi-threaded access
• Partitioned by 'manually' assigned partition key
• State reliably contained within partition

Stateless service

• Multi-threaded access
• No partitioning, multiple instances
• State/data access limited by persistence solution (SQL connection pool etc.)