Akka (0): Talk about Akka's initial understanding and ideas

A period of time has been immersed in functional programming mode, one of the main purposes is to master a set of safe and reliable concurrent programming method (concurrent programming), finally through the Open source project Funda implementation of the single-machine multi-core CPU program parallel operation. However, although the parallel operation in the terminal can make full use of the computing power of multi-core CPU to distribute data processing operations to the foreground can greatly reduce the pressure of the background server, improve the overall efficiency of the system, the current big data prevalent system computing requirements are far from enough, Only through the parallel expansion of hardware (scale-out) to form a cluster and implement distributed operations on top of the new environment to meet the requirements of the software program. Then, the next phase of the goal should be distributed operations. As we all know, Akka should be the most famous and common distributed software development tool, plus the open source project of Scala language. Because Akka is already a mature software tool which is used extensively in the reality, the reference material on the internet is rich, the feeling should be a more ideal choice.

Took a few days to study the Akka official website of the information, first here to understand the situation below to do a summary:

The Akka program is made up of multiple actors. It works by dividing a large operation into many small tasks and then entrusting the tasks to multiple actors. The actor can run not only in the current JVM, but also across the JVM on any machine, which is basically the key to the Akka program's implementation of distributed computing. Of course, this also depends on the akka provided by the monitoring and monitoring of various actor roles, various operational management strategies and methods including fault tolerance mechanism, built-in thread management, remote operation Management (remoting), and a set of distributed messaging system to coordinate and control the security of the overall operation.

Actor is the smallest operating unit in the Akka system. Each actor allows only a single thread, so that the actor is a thread of a finer unit. Akka's programming model and its built-in threading management capabilities enable users to implement multithreaded concurrent programming in a more natural way. The main function of actor is to maintain its internal state in a single thread, so its internal state is certainly mutable (mutable-states), but since each actor is a single-threaded unit, plus the operation is message-driven (Message-driven), Only linear processes are allowed, the results of the operations between actors do not affect each other, so from the Akka as a whole the actor seems to be pure function immutable (pure immutable). The internal state of the Actor (internal states) is similar to the elements of a functional programming immutable set (Immutable collection), all of which are embedded within a type, i.e. F[a] >>> Actor[a] and are very similar from type to style. , can we do a function combination of actors (functional composition) and then implement AKKA programming of functional programming patterns? It should be impossible because we cannot fix the result of the actor's operation. One is that we cannot prevent the actor's operation from having side effects, and then the actor's result is unpredictable, for example, it may send the result to any other actor so that the same input can produce different results. We can think of actors as impure functions (impure function), which may produce different output results for the same input, so it is not possible to classify the actor programming as functional programming, but actor programming is a different kind of programming pattern than other programming patterns, And Akka also has a domain-specific language DSL, which is an independent programming model, actor programming mode. This is a new programming model that needs to be mastered.

The Akka program has the following advantages:

1, Responsive fast response

Respond to user requests in the quickest time (response)

2. High fault tolerance of resilient

Can be passed to the actor by:

Replication (replication),

Closed (containment),

Separation (isolation),

Managed (delegation) to address any level of errors and anomalies that the actor produces

3, Elastic Scalability

System expansion capabilities by increasing the vertical expansion of Computer Configuration (scale-up), adding horizontal scaling (scale-out) of the number of computers in the network

Enables fast response under any load pressure conditions

4. Message-driven Message-driven

-Asynchronous communication (asynchronous communication)

-Loose coupling (loosely coupled)

-Position transparent actor positioning method

-Load balancer (load management), flow control, Back-pressure

One of the features described above provides a location-transparent actor positioning method in the message-driven mode, which can be used to implement distributed operation of the program simply by setting the message receiver address. This is interesting.

In addition to the normal function actor, Akka also offers several actors with special functions, including: Routing (routingacter), Finite state machine (fsmactor), and persistent (persistenceactor). Where Persistenceactor is attractive, it can help implement the new database operating mode es (event-sourcing) through CQRS mode. The basic principle of the CQRS mode is to detach the read and write of the database in order to improve the response of the large data type network application. Of course, from another aspect, event-sourcing as a new database operation mode, should be able to solve any database application software commonly faced with the lack of data replay, and the use of database pressure and other issues.

The initial intention is to focus on the Persistenceactor-based ES schema database application and the Actor-http-based Microservice tool library. Of course, it is hoped that through all kinds of efforts, we can finally achieve distributed applications that allow friends who are not proficient in Akka to write actor patterns conveniently. This may involve a re-grouping of Akka functions, building a new, higher-level abstraction framework, providing APIs, and so on. Of course, these still need to carry on the detailed research study to Akka to have the conclusion.

Just to find that there are not many examples of Scala-based Akka discussions on the web, we will start learning Akka from the beginning of the discussion in the following period of time.