Actor model - Bhushan-Jagtap-2013/AzureServiceFabricExamples GitHub Wiki
Threading
- [Traditional] Primary thread and additional threads
Actor
-
Model system as set of actors
-
Actor model contains 1. state 2. code 3. mailbox 4. send messages to other actors.
-
In Service fabric this can be implemented
- Code - reliable services
- State - Reliable state
- Mailboxes - service remoting
-
SF provides support for actor model
-
Mutiple actors can run parallelly, but one actor processes messages sequentially.
-
Actor is created when first time call is made to actor runtime.
-
Actor can be something like user. Each one will have its won state, lifecycle and scale (can be moved around in SF instances).
-
Each actor will have actor id. This will provide context information for tasks such as logging details, communicate with external data providers, any other context.
-
Actor id provides concurrency
-
Need to decide on what should be actor type. For each actor type there will be one actor instance. if there are too many actor instances it will put pressure on system. e.g., one user one actor. If there are two less actors, then it will cause a starvation as one actor can process one request.
-
Actor state management: Only allow single key value store and its already initialized.
-
Actor state management handles automatic transaction management.
-
state reliability and scalability options.
-
What can be stored in actor state?
- Class with public constructor with no parameters
- Array or concrete type in collections
- Use commonly known data types
State storage options
- Persisted - default. replicate to 3 replicas.
- Volatile - replicate but only in memory. Faster.
- No persistent - non replicated and non-reliable.
Performance optimizations:
- Every operation on state will be serialized at class level and replicated over network. So, there is a performance cost. Solution -> break it into small values.
- Use fixed (predictable) number of actors. - Reuse the actors. Delete actor to release stored metadata.