What is the most important part of Dapr?

The editor introduced the relationship between Dapr and API in the last article. This time, let’s talk about an important part of Dapr itself—— Actor model

As an important part of Dapr, the Actor model greatly simplifies the complexity of concurrent programming, but what problems can it solve and what is its working principle?

#ActorModel

The actor model originated from the conceptual model of concurrent computing proposed by Carl Hewitt in 1973. This form of computing will perform multiple calculations at the same time. There were no highly parallel computers at the time, but recent advances in multi-core CPUs and distributed systems made the actor model popular.

In the Actor model, an Actor is a unit that is independent of computation and state. Actors are completely isolated from each other, they never share memory. Actors communicate with each other using messages. When an Actor receives a message, it can change its internal state and send the message to other (possibly new) Actors.

Actor model makes it easier to write concurrent systems

Actor provides a turn-based (or single-threaded) access model. Multiple Actors can run concurrently, but each Actor only processes incoming messages one at a time. This means that at any time, at most one thread is guaranteed to be active in an Actor, which makes it easier to write correct concurrent and parallel systems.

What problems can the #Actor model solve?

Implementations of the Actor model are usually tied to a specific language or platform. Actor models can be used from any language or platform using the Dapr Actor building block. Dapr's implementation is based on the Virtual Actor pattern introduced in the project "Orleans". For the Virtual Actor pattern, there is no need to explicitly create the Actor. The first time a message is sent to an actor, the actor will be implicitly activated and placed on a node in the cluster. Actors are silently unloaded from memory when not performing operations. If a node fails, Dapr will automatically move active actors to healthy nodes. In addition to sending messages between actors, the Dapr Actor model supports scheduling future work using timers and reminders.

While the Actor model offers great advantages, the design of Actors must be carefully considered . For example, if multiple clients invoke the same Actor, it will result in poor performance because Actor operations are performed sequentially. The checklist below are some of the criteria applicable to Dapr Actor:

• The problem space deals with concurrency. Without Actors, explicit locking mechanisms need to be introduced into the code.

• The problem space can be partitioned into small, independent and isolated units of state and logic.

• Low-latency reading of Actor state is not required. Because actor operations are performed sequentially, low-latency reads are not guaranteed.

• There is no need to query state across a set of Actors. Queries across actors are inefficient, as each actor's state needs to be read separately and can cause unpredictable delays.

One design pattern that satisfies these conditions is the business process-based saga or process manager design pattern. Saga manages the sequence of steps that must be performed to achieve certain results. The saga (or process manager) maintains the current state of the sequence and triggers the next step. If a step fails, the saga can perform compensating actions. Actors make it easy to handle concurrency in a saga and keep track of the current state. The EShopOnDapr reference application uses the saga pattern and Dapr Actor to implement the sorting process.

#working principle

Dapr provides an HTTP/gRPC API for calling actors.

 This is the base URL for the HTTP API: http://localhost:daprPort/v1.0/actors/actorType/actorId/

• daprPort: The HTTP port that Dapr listens on

• actorType: actor type

• actorId: the ID of the specific Actor to invoke

Actors manage when and where each actor runs, and how messages are routed between actors. If an Actor has not been used for a while, the runtime will deactivate the Actor and remove it from memory. Any state managed by the actor will be preserved and will be available when the actor is reactivated. Dapr uses an idle timer to determine when an Actor can be deactivated. When an action is invoked on an actor (triggered by a method call or an alert), the idle timer is reset and the actor instance is kept active.

The Actor API is only part of the formula. The service itself also needs to implement the API specification, since the actual code you write for the Actor will run within the service itself. The diagram below shows the service and the various API calls between it:

API call between actor service and Dapr Actor

To provide scalability and reliability, actors will be partitioned across all instances of the actor service. The Dapr placement service is responsible for tracking partition information. Supported Actor types are registered with the placement service when a new instance of the Actor service is started. The placement service computes updated partition information for a given Actor type and broadcasts it to all instances. The following diagram shows what happens when the service is scaled to a second replica:

Actor processing unit arrangement service placement service

• On startup, the actor calls the actor service to obtain the registered actor types and the actor's configuration settings.

• Send a list of registered Actor types to the placement service.

• The placement service will broadcast the updated partition information to all Actor service instances. Each instance will keep a cached copy of the partition information and use it to call the Actor.

Because actors are distributed randomly across service instances, actors always need to call other nodes in the network.

The figure below shows the instance of the ordering service running in Pod 1 calling method 3 of the instance with the ship OrderActor ID. Since actor 3 with ID is placed in a different instance, this will result in calls to different nodes in the cluster:

Call the Executor method

• Services call Actor APIs on Actors. The JSON payload in the request body contains the data to be sent to the Actor.

• Use the locally cached partition information in the placement service to determine which actor service instance (partition) is responsible for hosting the Actor with ID . In this example, it's the service instance in pod 2. The call will be forwarded to the corresponding instance 3.

• Instances in Pod 2 invoke the service instance to invoke the Actor. If the Actor has not yet executed an Actor method, the service instance will activate the actor.

Timers and remindersTimers and reminders

Actors can use timers and reminders to schedule their own calls. Both concepts support configuring deadlines. The difference is the lifetime of the callback registration:

• The timer will remain active as long as the Actor is active. Timers do not reset idle timers, so they cannot keep Actors alive

• Reminders take longer than Actor activations. If an Actor is deactivated, the Actor will be reactivated. Reminder will reset idle timer

Timers are registered by calling the Actor API. In the example below, a timer is registered with a time of 0 and a time of 10 seconds.

curl -X POST http://localhost:3500/v1.0/actors/<actorType>/<actorId>/timers/<name> \  -H "Content-Type: application/json" \  -d '{
   
           "dueTime": "0h0m0s0ms",        "period": "0h0m10s0ms"      }'

This reminder will fire in 5 minutes. Since the given time period is empty, this will be a one-time reminder. Both timers and reminders follow a turn-based access model. When a timer or reminder fires, the callback will not be executed until any other method calls or timer/reminder callbacks have completed.

State persistence

Actor state is saved using Dapr state management building blocks. Since the execution component can perform multiple state operations in one round, the state storage component must support multiple transactions. As of this writing, the following state stores support multiple transactions:

• Azure Cosmos DB

• MongoDB

• MySQL

• PostgreSQL

• Redis

• RethinkDB

• SQL Server

To configure a state store component to be used with Actors, the following metadata needs to be attached to the state store configuration:

- name: actorStateStore  value: "true"

Here is a complete YAML example for the Redis state store:

apiVersion: dapr.io/v1alpha1kind: Componentmetadata:  name: statestorespec:  type: state.redis  version: v1  metadata:  - name: redisHost    value: localhost:6379  - name: redisPassword    value: ""  - name: actorStateStore    value: "true"

#Summarize

Dapr actors building blocks make it easier to write correct concurrent systems. Actors are small units of state and logic. They use a round-based access model, eliminating the need to write thread-safe code with locking mechanisms. Actors are created implicitly and silently unloaded from memory when no operations are performed. Automatically persists and loads any state stored in actors when they are reactivated. Actor model implementations are usually created for a specific language or platform. However, with the help of Dapr actor component building blocks, it is possible to leverage the actor actors model from any language or platform.

Actors support timers and reminders to schedule future work. The timer does not reset the idle timer, and allows the Actor to be deactivated if no other operations are being performed. Reminders reset the idle timer and are also automatically kept. Both timers and reminders obey a round-based access model, ensuring that no other operations can be performed while the timer/reminder event is being processed.

Persist actor state using Dapr state management building blocks. Any state store that supports multiple transactions can be used to store actor state.

References:
https://www.cnblogs.com/shanyou/
https://docs.dapr.io/developing-applications/building-blocks/actors/
https://docs.dapr.io/reference/components-reference /supported-state-stores/

Add staros-Nina WeChat, you can invite you to join the group exchange experience~