Akka Theory Summary __ Akka

Akkais a concurrent processing framework based on the Actor model implementation. Event-driven concurrency processing model, each actor has its own properties and operations, which avoids the usual situation because multiple threads share attributes (data) instead of locking mechanisms. This mechanism is applied well in the Scala,cloure language, and the operations and attributes are processed in a separate unit to improve the ability of concurrent processing.
Five characteristics of Akka
1 easy to build parallel and distributed applications (simple concurrency & Distribution)
Akka in the design of asynchronous communication and distributed architecture, and the upper level of abstraction, such as actors, Futures, STM and so on.
2) Reliability (resilient by design)
The system has self-healing capabilities and is monitored locally/remotely.
3 High-performance (High performance)
50 million messages can be sent per second in a single machine. Memory footprint is small, 2.5 million actors can be saved in 1GB memory.
4 elasticity, no center (elastic-decentralized)
Self-adaptive responsible for equalization, routing, partitioning, configuration
5) extensible (extensible) can be extended using Akka expansion packs.
Hierarchical Structureand business organization (such as company) type, actors also have a hierarchy, a actor can be responsible for a function of the program, you can need to assign it to the task into smaller manageable small task. So a actor can create multiple child actor to accomplish these small tasks and manage them. Each actor has and only one manager (supervisor).
One of the essence of the Actor system is that it can break down a complex task into small, able-to-handle problems. The advantage of this is that not only does the task itself have a clear structure, but the actor message used to process it is also well analyzed, and if a actor cannot handle certain situations, it can send a failure message to its administrator requesting help. This escalation structure supports handling errors at the appropriate level. When we define a actor, it is best to conform to some of the following rules: 1 actors should be a good colleague, the efficient completion of their own problems without giving other actor cause unnecessary trouble and not excessive resources. In terms of programming terminology, event handling is used to handle events and return results. Actor should not block certain external entities (such as a lock, network port) 2) do not pass data that can be changed between actor, so use state-invariant messages preferentially. 3 actor can save certain States and define some functions, which means that data is not passed and the behavior of the data is processed. The top level of actor should be the core layer of your handling of errors, so don't create too many top-level actor and prioritize pure hierarchies.
carefully manage blocking operationsIf some of the potentially blocking operations are unavoidable, such as the need to wait for some external conditions to cause a thread to sleep (such as a network operation), you may want to use future to encapsulate the blocking operations in these cases, but this approach is simplistic You may soon find bottlenecks or out-of-memory phenomena.
Here is an incomplete list of solutions that can be used to solve this problem: 1 completes this blocking operation in a actor and ensures that the operation is done exclusively with a thread pool. 2 Use a future to complete this blocking operation, giving the upper bound of the number that can handle the operation at the same time. 3 Use a future to complete this blocking operation and use a pool of threads with a defined upper bound. 4) specifically defines a thread to manage a set of potentially blocked resources and then distributes messages to actor when an event occurs.
Actors ModelActor model is nothing new, it was proposed by Carl Hewitt in the early 70 to solve a series of programming problems in distributed programming. Its characteristics are as follows:
All things in the system can play a actor
Actor completely independent of each other
When the message is received, all the actions taken by actor are parallel, and the action in one method has no definite order.
Actor is described by identity and current behavior
Actor may be divided into original (primitive) and non-primitive (non primitive) categories many development languages provide native actor models. such as Erlang,scala, such as Actor, can be regarded as an independent entity, there is no connection between them. However, they can communicate through messages. After a actor receives other actor information, it can make various corresponding according to the need. The type of the message can be arbitrary, and the contents of the message can be arbitrary. This is a bit like webservice. Provide only interface services, you don't have to understand how I do it. A actor how to handle multiple actor requests. It builds a message queue, which is queued every time it receives a message, and it takes out the message body from the queue each time. Usually we all make the process loop. Allow actor to handle the messages sent at all times.
actor Message
actor How to send messages1) Fire and forget way: Tell. 2 Send and Receive mode: Ask. Blocking, it waits for the child actor to return to future.
In Akka, future represents an asynchronous task performed by the Executioncontextexecutor of System.dispatcher (). Scheduler represents a dispatch task.