Process-based game Server Architecture Design

The original name of the blog from Yunfeng: multi-process game server design

Address: http://blog.codingnow.com/2006/10/multi_process_design.html#comments

 

Currently, our game server group is designed in a multi-process manner. To emphasize multi-process, we want to add another point. Each process is single-threaded. Therefore, in our design, the complexity of the system lies in how data is exchanged between processes, without the need to consider data locks between threads.

If the number of processes increases, the system will become chaotic and uncontrollable. After analysis, I decided to make the following restrictions:

1. If a process requires two-way communication with multiple servers, the process cannot process complicated logic, but only filters and forwards data. That is, such a process s will only forward the data sent by process a to process B, or forward the data sent by process B to process. Or data sent from one end can be distributed to different places after simple protocol analysis. For example, separate the chat information in the packet sent from the client and submit it to the chat process.

2. The Data Flow in a process with logical processing must be one-way. It can read data from multiple data sources, but it must be reported to another place after processing, instead of interacting with the data source logically.

3. Each process tries its best to maintain a single input point or a single output point.

4. All time-consuming operations are sent to independent processes and processed in queues.

5. Process is divided by function and scenario. Multiple processes are no longer separated from each other in a single service and scenario for load balancing.

In terms of performance, I consider the following:

We should make full use of the advantages of multi-core, which will be the future development direction. Let each process either process large-volume and small-volume computing, or process small-volume computing. In this way, multiple processes can be put on a physical machine to make full use of machine resources.

The single-threaded Multi-process design gives full play to the advantages of multiple cores. This is because no lock is available, and each thread can work with the maximum throughput. The increased burden is only data replication between processes. In a complex logic system such as online games, it is generally not a bottleneck earlier than logical computing. If you are worried that a single thread does not take advantage of multi-core computing, consider the following example:

Calculate a/B + C/D + E/F. If we use three cores in a process to calculate a/B C/D E/F simultaneously, but it addsProgramDesign complexity. Another way of thinking is to create three processes. The first one is only a/B and the result is handed over to the second process to calculate the sum of C/D, submit a third process to calculate E/F. For a single operation, the cost is increased. It requires additional inter-process communication to replicate intermediate results. However, if we have a large number of consecutive such computing tasks, the overall throughput will increase. Because when calculating a/B, the previous C/D may be computed in parallel in another core.

In the specific design, we only need to fine-cut the task for processing data packets and appropriately increase the length of the processing pipeline to improve the throughput of the entire system. Because logical operations are single-threaded, it is worth noting that all time-consuming operations should be forwarded to independent processes for asynchronous completion. For example, the Data Access Service mentioned below.

The specific scenario management is as follows:

After a player connects, all data packets pass through a process called location service. This process can differentiate the locations of players and then distribute player data to the corresponding scenario service process. This location service also manages the broadcast of messages between players. That is, a single scenario (logic) service does not care about the players who see each data packet, But it replicates and distributes it.

When a gamer switches to a scenario, the scenario server sends gamer data to the data service. The data service process caches gamer data and writes the data to the database. Then, the gamer's new scene number is sent back to the location service process, so that the location server can correctly forward subsequent gamer data packets to the new scenario service process.

The production of dropped items and resources can also be managed in a unified manner. Therefore, the scenario (logic) process sends the request to produce new items to the item allocation service, after the item distribution service generates a new item, it notifies the location server to generate a new item.

Such a series of practices ultimately ensure that each scenario server has a unique data source-the location service process. It has nothing to do with the persistent data in the database, and has nothing to do with the clock. The debugging convenience is significant.

Recently, when many processes are being designed, one of the first challenges is the startup phase. Obviously, it is not a good idea to point out the addresses of other processes with a set of configuration files for each process. However, it is not appropriate to assign a subdomain name to each service during the development period. As a result, we developed a name server. Its function is similar to DNS, but it allows each process to freely register its own location and periodically report its current status. In this way, we can easily use the program to query the required services. The name server protocol uses a POP3-like text protocol, which allows us to manually Telnet for reference. I believe our maintenance personnel will like this design in the future. : D

Above, work since the end of the National Day holiday. Thanks to the hard work of other colleagues in the project team.