The following intends to provide a brief introduction to Akka which is framework based on the actor model and designed to increase the abstraction, scalability and fault-tolerance of systems. It provides a platform enabling developers to easily create concurrent and loosely coupled applications with the ability of self-healing in the face of failures.
Typical Problems of Complex Systems
Below is mentioned a few of the more important problems and issues that need to be addressed when dealing with more complex systems:
- Threads tend to need a lot of coordination logic, locks and synchronizations.
- The amount of threads to be used within an application is limited.
- It is usually hard to scale up, scale out, deploy and run the complex applications.
- Creating fault tolerant applications that can recover form errors is tedious.
- It is cumbersome to modify applications and systems with load balancing.
How Akka Addresses the Issues?
Alright, now that we know some of the top issues, let’s also mention a few key notes about what Akka has to offer in general and what it brings to the table to address them.
- Akka pushes the burden of low-level thread management and thread-safe code to the actor model.
- The use of actor model also makes Akka to be aligned with reactive manifesto which improves applications in the following terms:
- Message-Driven:
Asynchronous message passing decreases coupling and provides location transparency for system components. - Resilience:
Akka enforces single responsibility through component isolation (actors). - Elasticity:
As systems scale, they will still be able to handle various workloads. In addition, actors can be increased in amount where they are exactly needed and they also can divide the workload among themselves. - Responsiveness:
Loose coupling, Resilience and Elasticity will make the system responsive.
- Message-Driven:
- The increases in abstraction and loose coupling will also result into:
- Reduction in use of shared states among components.
- Increase in CPU utilization.
- Increase in capability to scale up and out.
- Increasing system fault-tolerance.
So, What is an Actor?
Definition: an actor is a fundamental primitive unit of computation or work which basically means that they are designed to perform small, simple and well-defined tasks.
In order to better imagine and understand what an actor is, let’s start getting to know about their behavior and attributes.
- Each actor has a unique address and hence location transparent.
- Each actor has a mailbox (queue of messages), state and behavior.
- Actors are very lightweight (2.7 Million per 1GB of RAM).
- They are formed in hierarchies/trees (parent child relationship).
- They can live and communicate on different machines.
- They can create child actors.
- They can heal their children.
- They can supervise their children.
- They can change their behavior.
- They only communicate with one or more actors via message passing.
- They can only handle one message at a time.
- They can decide what to do with the message.
- Their states are only known by querying them (sending messages).
Note: The fact that actors come in hierarchies and that they can heal their children can really help developers push the risky and error-prone logic to child actors (or leaves); Therefore, as soon as a child dies, its parent is notified and supervises it accordingly.
What is an Actor-System (node)?
A node or an actor-system groups several actors and thus, an instance of it can contain one or more actors. According to this definition, we can now have local or remote actors.
Let’s say actor “a” lives on actor-system “X”; in this case:
Local Actor: An actor “b” is local to actor “a”, if “b” lives on the same actor-system as “a” (meaning actor-system “X”).
Remote Actor: An actor “b” is remote to actor “a”, if “b” lives on a different actor-system (let’s say actor-system “Y”). Also note that actor-system “Y” might be located on the same or a separate machine.
Using addresses, an actor in one actor-system can send messages to local actor or remote actors.
The address of an actor follows the format below and consists of these parts.
|
|
Details of Actors Actions
- Creating Actor:
- With a name and certain properties (called props), actors can create other child actors.
- Sending Messages:
- An actor can send message to a local or remote actor.
- Passing messages among actors are async and non-blocking (Fire & Forget).
- Actors are totally inactive/passive until they receive a message.
- Actors can handle throughput of 50 million messages per second per machine.
- The order of messages are maintained the same for sender and receiver.
- Changing Behavior:
- An actor can change its behavior at runtime.
- This change in behavior is triggered after receiving a message.
- Supervising Children:
- Actors can supervise their child actors.
- Child actors send failure signal and the parent instruct them what to do.
- The child does not need to know how to handle the error.
- Actors can supervise their children even over separate physical nodes.
- There are several error supervising strategies they can pick from.
- these strategies basically indicate what to do if a child fails in general or of a certain event.
- The strategy options are: resume / restart / escalate
Note: In Akka, the message transport and the message delivery are completely separated processes. Akka uses concurrent-linked-queue as the mailbox, however one can define what message queue to use either per actor or per actor-system (node). Its also possible to use broker and let broker handle messaging.
Properties of an Akka Message
An Akka message is a simple immutable data container defined by user and is created and passed asynchronously among actors. Akka messages also aligned with the definition of a message in reactive manifesto.
A message is an item of data that is sent to a specific destination. In a message driven system, addressable recipients await the arrival of messages and react to them, otherwise lying dormant (Reactive Manifesto).