Akka programming: What is actor?

In the previous article, we briefly introduced the actor system, indicating that there is a hierarchical relationship between actor, which is also the most basic unit for actor applications. This article introduces some basic concepts of actor. An actor contains state, behavior, mailbox, and supervisor strategy (Administrator policy ), all of these are encapsulated in an actor reference ). Actor reference An actor object must be isolated from the outside to form an actor model. Therefore, an actor object is represented by an actor reference (think about the concept of file handle, which is similar here ). An actor object can be transmitted and transmitted, but some structures inside the actor cannot be seen from outside the actor system. Status An actor Object usually contains some variables that can be used to save the current state of the actor. This can be a finite state machine (FSM), a counter, waiting for processing requests, etc. It is precisely because of these states that the actor becomes valuable, and these States need to be protected to avoid being damaged by other actors. The good news is that akka's actor, in terms of concept, contains a lightweight thread of its own, which is completely separated from other parts of the system. This means that you do not need to consider synchronization locks. In the background, akka runs multiple actor objects on a physical thread. Generally, several actors share a physical thread, the subsequent calls of an actor may use different physical threads, but these implementation details do not need to be understood by akka actor users. Because the internal status of the actor is very important to the operations of the actor, it is necessary to maintain a consistent State. Therefore, when an actor error needs to be restarted by its administrator, its status will be re-constructed, just like creating an actor. However, you can also choose a storage point before the actor restarts. Action Every time a message is processed, it matches the current behavior of the actor. An action is a function that defines some actions, that is, what needs to be done when a message is sent. For example, a user rejects a request when the verification fails because the request is forwarded. These actions may change over time. Email An actor object is used to process messages. These messages can be sent by one actor to another actor object (or from an external actor ). The component used to connect the sender and receiver is the mailbox. Each actor has only one mailbox, and all senders send messages to this message queue. Different senders send messages in a random order. For the same sender, the order in which messages are sent is the same as the order in which messages are sent to the mailbox. You can select different mailbox implementations. The default is FIFO (first-in-first-out queue ). this is usually advantageous, but in some cases, for example, it is not appropriate to use FIFO to process messages with a higher priority. The akka system differs from other actor models in that the current actor action must process messages in the next queue and there is no way to scan messages in the queue. By default, if a message is not processed, it will be processed as an error unless you redefine this behavior. Sub-actor Each actor can be a supervisor if it creates a sub-actor object to process sub-tasks. The sub-actor is automatically managed. The actor context stores a group of sub-actor objects it creates and can access them. You can modify the list by creating (context. actorof) and stopping (context. Stop (child. The actual creation and termination occur asynchronously. Therefore, the creation and termination of sub-actor will not block the Administrator actor. Administrator Policy The Administrator policy is used to handle subactor errors. Akka automatically handles these errors according to the defined administrator policy. These policies are the most basic components of an actor system. Therefore, after an actor is created, the Administrator policy cannot be modified. Since an actor can only define one administrator policy, this means that if the sub-objects of an actor need different administrator policies, some middle-layer actors are required to group these sub-actors. Terminate actor When an actor is terminated (for example, if the restart fails, it is terminated by itself, or its administrator terminates its operation), the resources it occupies will be released, add unprocessed messages to the system's "dead-letter mailbox". These dead messages will be forwarded to EventSystem as deadletter. Its mailbox is replaced with a system mailbox, and the new message is forwarded to EventSystem as a deadletter.