Akka is a toolkit and runtime for building high-concurrency, distributed and fault-tolerant applications on the JAVA virtual machine platform. Akka is written in Scala language, and it also provides development interfaces for Scala and Java. Akka's approach to concurrency is based on the Actor model, and the only mechanism for communication between actors is message passing.
Akka features:
A higher abstraction of the concurrency model
Is an asynchronous, non-blocking, high-performance event-driven programming model
Lightweight event processing (1GB of memory can hold millions of actors)
It provides a concurrency model called Actor, which has a smaller granularity than threads, and you can enable a large number of Actors in the system.
It provides a set of fault-tolerant mechanism, allowing some recovery or reset operations when the Actor is abnormal.
Akka can build highly concurrent programs on a single machine, or build distributed programs on the network, and provide location-transparent Actor location services.
maven dependency:
Actor model
In a concurrent program, a thread is the basic execution unit of a concurrent program, but in Akka, the execution unit is an Actor.
Traditional concurrent programs are based on object-oriented methods. Information is transferred through object method calls. If the object's method modifies the state of the object itself, inconsistent state of the object may occur under multithreading. At this time, method calls must be synchronized. , And synchronous operation will sacrifice performance.
In the Actor model, instead of telling the Actor what to do through a method of the Actor object, it sends a message to the Actor. When an actor receives a message, it may perform certain actions based on the content of the message, such as changing its own state. At this time, the change of this state is made by the actor itself, not by external intervention.
Greeter definition
HelloWorld definition
sample.conf
main method
operation result
The first line prints the path of the HelloWorld Actor, which is the first Actor created in the system. The path is: akka://hello/user/helloworld. The first hello represents the system name of the ActorSystem, which is the first parameter entered during construction. user represents the user Actor, all user Actors will be mounted under the user path. Finally helloworld is the name of this Actor.
The second line prints the path of the Greeter Actor, and the third and fourth lines are the information output in Greeter.
The fifth line indicates that the system encountered a message delivery failure, because HelloWorld stopped itself, causing the message sent by Greeter to fail to be delivered successfully.
When using Actor for concurrent development, the focus is no longer on the thread. Thread scheduling has been encapsulated by the Akka framework, and you only need to focus on the Actor object. Information is passed between Actor objects through displayed message sending.
When there are multiple Actors in the system, Akka will automatically select threads in the thread pool to execute our Actor. Different Actors may be executed by the same thread or an Actor may be executed by different threads.
Note: Do not execute time-consuming code in an Actor, as this may cause scheduling problems for other Actors.
Message delivery
Akka applications are driven by messages, and messages are the most important core component besides Actors. The messages passed between actors should satisfy immutability, that is, invariant mode, and mutable messages cannot be used efficiently in a concurrent environment. It is recommended to use immutable objects in Akka. The final field declaration can be used in the code. After the message is constructed, it cannot be changed.
Message delivery strategy:
At most one delivery: Each message in this strategy will be delivered at most once, and there may be occasional delivery failures, resulting in message loss. This strategy is high-performance.
Delivery at least once: Each message in this strategy will be delivered at least once until it succeeds. In some occasional situations, the receiver may receive duplicate messages, but the messages will not be lost. This strategy needs to save the status of message delivery and keep retrying.
Precise delivery: All messages are guaranteed to be delivered accurately and received once successfully, and will neither be lost nor repeated. This strategy is the most expensive and difficult to implement.
Regarding the reliability of the message: there is no need to guarantee the reliability of the message at the Akka layer, it is too expensive and unnecessary. Message reliability should be guaranteed at the business layer of the application, and sometimes the loss of some messages meets the requirements of the application.
The order of message delivery: Akka can guarantee the order of delivery to a certain extent. If Actor A1 sends three messages M1, M2, and M3 to A2 in sequence, and Actor A3 sends three messages M4, M5, and M6 to A2 in sequence, the system can guarantee:
- If M1 is not lost, it must be received by A2 before M2 and M3.
- If M2 is not lost, it must be received by A2 before M3.
- If M4 is not lost, it must be received by A2 before M5 and M6.
- If M5 is not lost, it must be received by A2 before M6.
For A2, the messages from A1 to A3 are not guaranteed to be sequential.
In addition, this message delivery rule is not transferable, as shown in the figure below:
The order in which C receives M1 and M2 is not guaranteed
--References "Practical Java High Concurrency Programming"
Author: summer breeze and
link: https: //www.jianshu.com/p/7d941a3b0ccb
Source: Jane books
are copyrighted by the author. For commercial reprints, please contact the author for authorization, and for non-commercial reprints, please indicate the source.