Game server architecture for large MMO-SNS

SNS games and RPG online games have some different characteristics, which may lead to some differences between the background architecture of such games and the background architecture of RPG online games.

SNS games generally have the following features:

(1) interaction between all player roles

In an SNS game, a player role will look for his friends or any other unrelated player role for some logical interaction.

(2) This type of gamer role is generally invisible

(3) The online or offline status of the player role is vague.

Online gamer roles can actively interact with non-online gamers. If you steal food from a friend garden that is not online, you can attack the city pool of offline gamers.

(4) low interaction frequency and small data volume.

 

According to the above main features, this type of game backend should be designed to be the only big world, and there is no need to see each other between roles. There is a possibility to implement this big world backend. The following architecture can be used in actual commercial projects.

Generally, the previous node is actively connected later.

Connsvr may be webserver or tcpsvr of the custom protocol. It uses a hash ing methodProgram) The request message packet is forwarded to any schedulesvr.

Schedulesvr receives a message request and distributes the request to one or more logicsvr based on the service characteristics of the request. It also provides a transaction mechanism to ensure the integrity of the request processing.

Logicsvr is deployed in a distributed manner in accordance with the hash ing mechanism described above.

Dbproxy is the proxy for accessing DBMS.

In addition, TCP communication is recommended between servers, so that traffic control at the application layer can be implemented through the TCP congestion control mechanism.

 

A simple example is to illustrate the logic of a game. To steal food, Player A on Client 1 wants to steal food from friend B.

(1) A sends a request packet to a connsvr based on a server Load balancer mechanism (DNS round-robin is acceptable). connsvr forwards the request packet to a schedulesvr to the logicsvr where A is located.

(2) schedulesvr sends a request to the logicsvr in which a is located. This logicsvr performs some basic verification, such as whether B is a friend of A. If B is also on this logicsvr, then, the stolen logic of B is processed directly, and the result is returned to schedulesvr.

(3) schedulesvr finds that A & B is not on a logicsvr. If (2) the logic is processed successfully, the message is transferred to the logicsvr of B. logicsvr reduces the number of dishes of B.

(4) schedulesvr finally receives B's processing result and returns the response to the client.

 

The above is a simple SNS application that only involves both parties. The simplest application only involves itself. In addition, some SNS may be related to three parties or more Parties. This can be considered to use servers similar to schedulesvr to process such businesses. For most SNS games, there will be a lot of games attached, and they will be handled in a similar way. For games like inviting friends to make some games, you can consider using independent processes.

Logicsvr is essentially different from logicsvr. The former requires only local gamer role data, while the latter requires global data.

The final results of games often need to be reflected in the primary game in a timely manner, such as getting certain items and changing the experience level. The general process is as follows:

(1) When multiple roles enter a game, pull the latest data from their primary logicsvr.

(2) After the game is completed, save the game results (generally incremental) to the primary logicsvr, exit, and return to the primary logicsvr.