Introduction to the game server architecture (III)

This article introduces the architecture and evolution of the game server of the next application.
The role of the game server is to meet the needs of online players, to verify the account, login, a series of logical operations and verification of players in the game world. On this basis, a good architecture can improve efficiency, and it is not impossible to reach a million-level concurrent online number when achieving logic requirements.
Let's start with the simplest structure.

Client ---------- server --------- dbsystem

It is a very simple C/S system. The same server simultaneously processes login registration and creates roles and game logic operations ,. Directly mount the db operation on the server. The database can be either a specific database or a filesystem
It can be seen that it is too simple to put the irrelevant things of login registration creation and specific logic together, seriously reducing the efficiency of specific logical operations, especially in the new server stage, the logic will crash because of the login verification operation.
Therefore, the upgrade is required to separate all types of operations performed only once in the login phase in a single player game operation process and solve the problem separately ,. Therefore, it can become the following stage

-Loginserver-
--
Client--dbsystem
--
-Gameserver-

There are two servers.ArticleAs mentioned at the beginning.

Let's take a look at the next advantage. In loginserver, you can only perform account verification to query the role list and create a role. Then, the player logs in to gameserver. The specific logical operations are completed in gameserver.

A gamer login operation

Send Account Verification, return to role list, create role
CLIENT---------------LOGINSERVER ----------- DBSYSTEM-----------------------CLIENT ------------------
Select the role and login chain break and game connection to log on
Loginserver ------- dbsystem ---------- client ------------------------------------------------------ gameserver

In this way, the efficiency can be effectively improved, and there is no relationship between the player's verification list read and creation and the game, but his shortcomings still exist. We will continue to look at the available areas.

First, improve efficiency from the database (first, from here on it should be affirmed that the database is used, rather than local file), and separate the account library from the Game Database, separated into two independent databases,
There are two specific reasons:
1: In terms of game operation, it is impossible for you to have only one server? As the number of users increases after being divided into multiple servers, cannot all servers share one database? Then you have a database.
So here we are doing this. It is convenient to manage the account database independently and share the entire game, so as to facilitate the management of the overall information economy of the account, such as the point card or something. Each server has a game database, only the gamer information and world information that operate on your server are recorded.
2: The reason is similar to splitting the server into login and game.

The current structure is like this

-Loginserver-
--Accountdbsystem
Client --
--Gamedbsystem
-Gameserver-

But it is definitely not enough after this,
Let's talk about the basics. on the server, you must remember that database operations, I/O operations, and text operations must be performed independently of the main process, you do not want to perform any queries, or do you want to suspend the main thread? However, imagine if a single process is better than a single process? What else can you do with caching? It does not occupy server resources.
Therefore, it is still troublesome. At least there is still much room for improvement in efficiency. Therefore, we add the dbagent module, separate processes, separate database operations, and add cache for some applications.

Add accountagent to accountdbsystem and gameagent to gamedbsystem.

The structure is as follows:

-Loginserver-
--Accountagent-accountdbsystem
Client-
--Gameagent-gamedbsystem
-Gameserver-

Loginserver connects gameserver to both accountagent and gameagent at the same time and uses the two connection servers to operate on the corresponding database. Because accountdbsystem may be shared across the entire server, therefore, accountagent can also be a common server connection to all servers. The loginserver uses the accountagent to verify that the gameserver created a role in the list is queried by the gameagent. Then, the loginserver logs in to the game by querying the complete role information and notifies the accountagent that the account has entered the game to avoid repeated logins. And save it regularly. You can place information such as the ranking of your game and the auction house in the cache of your self-designed gameagent to avoid repeated queries.

Each player's database operation server only needs to send a message to the agent for specific operations, and then return to the server and then to the client. The efficiency of fully asynchronous data operations is greatly improved. Security is also guaranteed.

I am not talking nonsense or looking down on it. More than half of domestic Games use the above structure ..................... This can be regarded as a relatively complete product architecture.

Speaking of this, have you found a commonality. Using this architecture, the game will inevitably select a server first and then verify that the account is logged into the game. This is because the server uses one-on-one processing of login and game, that is, the server you log on to must be the login of the server for verification, therefore, when the client is enabled, he needs to know which login account to connect to and which game to connect after successful verification.
In fact, this is a good solution. You can do some processing on the client to achieve first login verification on the selected server. Therefore, in the configuration, login is no longer one-to-one (multiple logins will be optimized later), and one login will be shared globally. Players enable the client and connect to login. Send account verification. Because accountdbsystem is already made global, you don't have to worry about which server it belongs to and then return success, the player client displays the server list (This list also has the connection information configuration before the client can be selected). After selecting a server, it sends a request to query the role list of a server to login, then you can log on to the game again. After small adjustments and changes, you can first verify and then select the server.

So, in this step, the server architecture is like this.

-Loginserver-
--Accountagent-accountdbsystem
Client-| --------
-| -----------
-
-Gameserver-gameagent-gamedbsystem
-|
-Gameserver-gameagent-gamedbsystem

One login and one accountagent and one accountdbsystem are shared globally.
Each independent server has its own gameagent and gamesdbystem
But the bottleneck of login emerged immediately. At the beginning, a single server was an independent loginserver, and now there is only one server. I can't help it without thinking about it.

In fact, the above architecture does not have to exist. It just needs to be written to make it clearer.

Therefore, loginserver must be configured with multiple loginservers. In this case, you can choose to be as flexible as possible. You can configure multiple loginservers in the entire server unit or multiple loginservers in each server. In this way, when starting the server, this large-area blowout gamer can effectively solve the load. Which login will the client connect to after it is enabled?
Two methods are provided here. One is the configuration, and the other isProgramOn
1:
In the program, you can configure all the loginserver connection information to the client, so that the client can select a random connection after it is enabled. If all of his players are randomly assigned a loginserver after you start the server, it's really worth your attention. Back home
2: Configuration:
In a DNS-Based Server Load balancer system, multiple IP addresses are configured for one domain name. Let the system select the corresponding IP address through Load

That's why
-Loginserver-|

-Loginserver-|

-Loginserver-|
--Accountagent-accountdbsystem
Client-| --------
-| -----------
-
-Gameserver-gameagent-gamedbsystem
-|
-Gameserver-gameagent-gamedbsystem

Or:

-Loginserver-
-Loginserver-
-Loginserver-
....................................... N numbers can be listed above.
--Gameagent-gamedbsystem
-Gameserver-

Client
-Loginserver-
-Loginserver-
-Loginserver-
....................................... N numbers can be listed above.
-Gameagent-gamedbsystem
-Gameserver-

Accountagent -- --- accountdbsystem is global

One server corresponds to multiple loginservers

Because of the dynamic configuration used by loginserver, several loginservers can be switched off without much pressure on the loginserver to save O & M Resources.

I don't want to write it anymore. I 've spent three days on New Year's day. Let's continue tomorrow. Expand the previous one tomorrow, and let's talk about the offline and distributed ones. I won't talk about it anymore.