Cellnet Development Diary of Game server framework based on Golang (II.)

This is a creation in Article, where the information may have evolved or changed.

Most of the crossing are certainly not very familiar with the actor model.  I am here based on Erlang, Skynet and other languages and framework libraries to explain the Actor model in combat mode. actor Concept

The actor model is similar to OO and is coded according to the human thinking pattern. OO is all about classes, using classes to simulate objects and solve all the problems. Actor similar to using actor to simulate processing objects and cells

The actor calls the process (non-operating system process) in Erlang and calls the SVC (service) mailbox Message Queue in Skynet

Each actor contains a mailbox, which is the mailbox. The actor can only communicate with the outside world by sending and receiving mailbox, that is to say, actors can only communicate with each other through messages, and cannot use other forms.

Mailbox itself is a sequential queue, FIFO. And mailbox theoretically has no upper limit, in fact, mailbox may cause memory to rise due to constant message accumulation. It's all normal.

Since mailbox is a queue, it represents the logical processing of an actor in sequential, single-threaded. However, each actor in the actor group can handle the transaction independently.  So the CPU can be divided into each actor to deal with, the cause of the concurrency also laid the foundation. identity of actor: ID

So, the message between the actors to distribute, how to locate the actor? Use a pointer? handle? Are not.

The actor locator is used with ID. Each actor has a globally unique ID, which does not use a GUID, because it is too difficult to locate, and Erlang chooses an elegant way to implement the ID. Eat a chestnut first:

0.11 1.2 3.5

This is the PID (process ID) of Erlang. The previous part of the point represents a separate domain in which the ID of each process is marked by ordinal, and the ordinal is the part after the decimal point

Then, with the ID, the distribution of the message is very simple, look at the chestnut

Send (source ID, destination ID, send content)

There is the presence of the source ID for the postback, or the virtual source. freedom of communication and deployment independence

With the presence of the actor model, the logic is distributed, meaning that it is written on each actor. Because there is only message communication between the actor model, there is no local content such as a function call or pointer. So the deployment of the actor becomes very free. That is, the actor's logic does not have to be concerned about whether it is deployed in 1 processes or several machines. But for internal performance and transmission efficiency considerations. Can not dismantle the process, as far as possible in the same process, can not be removed to more than one machine, to minimize the dismantling of multiple machines.

But when you do need concurrency, you only need to easily modify the settings or a small amount of code, the entire logic can be run in a distributed cluster

Synchronous and asynchronous

According to Erlang processing, the default process (Actor) uses Send to send messages, the process is asynchronous non-blocking; When synchronous processing is required, RPC is used, that is, the call is used to synchronize the wait, and when the other party process (Actor) receives and processes the message, it returns the result, and then calls ends.

If the other actor sends you a message in call processing, the message is kept in the mailbox of your actor, which is considered mailbox infinite