1. Introduction

The last article briefly described some of the development problems of OOP in a multi-core environment, and the article ended with the introduction of Actor Models as a solution to these problems. You can view the series of articles at the following links:

1.Elixir Para1: Limitations of OOP

This article focuses on what Actor models are and why they are gaining new prominence in today’s multi-core server environment.

2. What is Actor Model

The wiki definition of the Actor Model looks like this:

The actor model in computer science is a mathematical model of concurrent computation that treats actor as the universal primitive of concurrent computation

An Actor Model is a parallel computing Model in computer science. An Actor represents a unit of computation.

That might be a little hard to understand. But in fact, the Actor Model is much closer to the world we know. Imagine this:

  1. Every individual in the real world is actually independent and self-driven;
  2. Individuals respond to messages from the outside world according to their own situation.
  3. Individuals can create new and different individuals.
  4. Individuals collaborate by sending messages to other individuals;

2.1 Take Example 1

With a few of these rules, we can build an entire business solution. Let’s imagine a requirement: let’s imagine a game scene with 100 monsters that can attack and be attacked on their own.

With an OOP design approach, there may be the following steps:

  1. Design a monster class, define their methods: attack, beAttack, define state, such as: HP;
  2. These methods also have to be thread-safe to allow for simultaneous attacks, so they all have locks;
  3. Instantiate 100 objects;
  4. Heartbeat these objects with a thread pool to make them autonomous;

Such steps are functional, but still awkward and unnatural by comparison. The Actor Model is particularly advantageous in this scenario because the Actor Model itself is self-driven and has its own state that can communicate with the outside world via messages. So we just need to define the state of the Actor and the two behaviors, and leave the rest to the monster to run.

Thread pool driver:

The Actor Model:

2.2 Take Example 2

The above example is a game example that really fits the Actor Model. Now consider a transaction system in which users transfer money to each other.

Using the previous design methods, there are generally the following steps:

  1. Design user account table;
  2. If A transfers money to user B, lock A and B first, judge the amount of A, complete the transfer, and unlock the account.
  3. Considering the large number of users, we may use the function of cluster deployment, so the step 2 locks will apply to distributed locks.

In fact, this is not bad, but we can try to apply the Actor Model to design the transfer system, before designing the system. We need to imagine a “butler” who knows my amount and only handles one transaction at a time.

Applicable to Actor Model, our design is as follows:

  1. Design user account table;
  2. The message notifies the butler A to transfer the money to the butler B. The butler A, at his own discretion, deducts the money, and then sends A message to the butler B to increase the money. The butler B processes the message and completes the transfer. Since the butler only does serial processing, there is no need for locks;
  3. Managers A and B only need to be able to communicate on deployment. Therefore, whether A cluster is needed is not considered.

In this example, it does not mean that the Actor Model is more suitable for the transfer system, but just to guide people to think, we usually design the needs, in fact, it is possible to do another idea, if the idea is more suitable for our real world, we will be very easy to understand. (It took me a while to learn the concept of Lock.)

2.3 summary

Briefly summarize the Actor Model. The Actor Model is a kind of concurrent Model with the idea that everything is an Actor. On the stage, each actor is self-driven, according to the outside news, work together to complete a business performance.

An Actor contains the following elements:

  1. State of the state
  2. Mailbox mail
  3. Address the address
  4. Behaviors behavior

For communication, we apply the message abstraction uniformly.

3. Actor Model

3.1 advantage

  1. Easy extension
  2. Fault tolerance
  3. distributed
  4. Status Not shared

A quick explanation:

  1. When the system needs to add functions, you can add behaviors for the corresponding Actor or directly add new actors. Just like your company needs to add new lines of business, we can directly build a department organizational structure to take care of this work;
  2. To explain fault tolerance, you also need to use the concept of a monitor tree. To put it simply, it is to have multiple actors for different businesses. If one Actor is destroyed, another Actor can be used to replace the work (computer redundancy principle).
  3. When we talk about Actor models, we do not need to define which physical host actors live on. They can communicate only if they are on the same network and know each other’s address.
  4. Since the data is owned by the Actor itself, only message can access the data, so there is no shared state, naturally there is no competition problem;

3.2 disadvantages

  1. A deadlock
  2. Mailbox overflows

Actor models are prone to deadlocks. Suppose A sends A message to B, and B sends A message to A, waiting for A reply. Deadlock will occur.

Mailbox is a necessary concept for communication, and can be a bottleneck when messages are heavy.

I think the lack of shared memory affects performance to some extent. For example, in some services that read too much and write too little, shared memory can improve performance.

3.3 Multi-core age and Actor Model

In recent years, the physical performance limit of single-core CPU has basically been reached. In the future, the computing power of CPU should be further improved, and it can only be developed to the multi-core dimension. Many cloud vendors now offer multi-core, large-memory servers.

As we know, the multi-core CPU in the storage pyramid, there are certain problems. Since cpus have their own L1, L2, and L3 caches, in a shared memory environment, multi-core cpus need to use consistency algorithms to ensure cache visibility, which affects performance to some extent, and this problem will be more serious because of the number of cores.

But the Actor Model is a natural fit for such multicore servers. Erlang’s virtual machine, for example, defines the number of schedulers based on the number of cores on the system, and the scheduler itself can improve performance based on memory locality.

4. Programming language and framework of Actor Model

  1. Erlang/Elixir
  2. Akka

5. References

  1. Elang runtime system # Concurrent, parallel, preemptive multitasking
  2. How the Actor Model Meets the Needs of Modern, Distributed Systems
  3. Youtube Actor Model Explained

6. Notice

Hope you can still have some interest in the Actor Model after reading this article. With that in mind, the next article is ready to attempt a formal introduction to the Elixir language. If you like it, you can give it a thumbs-up. If you have any questions, you can leave a message and discuss it together. If you say something wrong, you are also expected to correct it.