Some thoughts on the development mode of Golang server

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

Multithreading + Synchronous Blocking model

The Golang server development methods used in our game projects are as follows

1. Multithreaded logic

2. Synchronous blocking. That is, everyone a thread (goroutine), io thread = logical thread

Advantages of this approach:

1. Synchronous blocking mode is similar to the way people think

2. Logical processing performance has a certain increase

After large-scale use of this pattern to write logic, we found that this pattern has only 1 drawbacks: The writer needs to deal with multi-threaded relationships

But this itself is indeed directly fatal, recall the C + + ERA, multithreading, debugging the difficulty of reproducing ... The brain-mending scene is too bad to look straight

Single thread + asynchronous multi-process model

In the C + + ERA, I have written a set of ASIO C + + server frameworks. The use of IO Multi-threading, logical single thread, relies on the advantages of C + + performance, making development easy and hassle-free.

In the Golang era, why not try a single-threaded asynchronous multi-process approach to writing logic?

Compared with the multi-threaded synchronous blocking, we find that the pros and cons complement each other. Then it's back to the problem of domain selection. For the game server needs to be easy to use, easy to develop, pressure reduction (non-MMO) These characteristics, single-threaded asynchronous multi-process is suitable

So, what points should we be aware of when writing single-threaded asynchronous multi-process servers with Golang?

1. Socket processing is fully encapsulated, only through channel throw to logical thread queue processing

2. Database, RPC and other IO processing, are changed to asynchronous callback mode, do not use synchronous interface

3. Players to save the submission data can be considered to copy and submit to disk to save threads, improve performance.

4. Multi-process architecture, such as gateway process, to spread the IO pressure into the process

5. In logic authoring, the use of Go threads and channel is not allowed, there is a need to improve the performance of the part needs to be written separately

The pain of the actor model

Cellnet in the development of the use of the Actor model to further simplify the problem of multithreading logic, after a period of time after the prototype development, found some problems, listed as follows:

1. The strong type of Golang is not suitable for the actor model, which often requires dynamic generation of various types of messages, but Skynet (C+lua)/erlang has a natural advantage

2. The actor model itself is not omnipotent and does not solve all the needs, especially the game

3. The actor model has some difficulty in understanding the application. It also needs to build a framework, to get started complex

In short, we have seen some of the use cases of Erlang and Skynet, there is no application of a very pure and mature successful Actor model case, from the traditional socket server framework spanning to the actor model will be ripped to the egg, so later Cellnet will consider the return to the mature socket server framework. The architecture is easy to get started, high expansion.