Design Concept of 100,000 online webgame in a single world (IV)-Database Design of player data

 

Database Division

In the game, the most frequent data interaction is the player data. The access volume cannot be solved by a server. Therefore, we consider sharing this data among multiple servers. The sharing method is still horizontal cutting, but instead of using the database's own cutting function, the database is cut at the application logic layer. Write the modulo based on the user ID to the corresponding server.

 

 

Server 1 User ID % number of servers = 0

 

 

Server 2 User ID % number of servers = 1

 

......

Each server is expected to provide 6 K ~ 8 K online user access is expected to require a total of 16 servers. Considering the further expansion of servers, it is recommended that 32 databases be planned during initial planning. Each server can be placed 3 ~ Five databases. After the number of server users reaches, the database will be split into different servers.

 

Design of various modules of the user database

The buildings, resources, items, heroes, and other related tables in the player base are basically owned by players independently, and there is no interaction with other players, therefore, the design of these tables can continue with the previous design.

 

Military Module

The military module is divided into the army table, the army creation event table and the combat event table. Both the force table and the Force creation event are internal tasks of players. You just need to put the relevant data and other player data in a database, however, the combat event table is designed to be two or more players, which is more complex.

The combat event table usually records the attacks that players a (city) attack B (city), including the attacking troops and arrival time. This record is put together with A. B needs to access 32 databases when querying the records attacked by B. If B is put together, when querying the attack situation of your troops, a needs to traverse 32 databases. If the table is taken out separately like a user table and processed on a single server, the table is too large, the query slows down, and the combat server is under too much pressure.

In the previous project, the combat server processes every battle for about 100 ms, that is, 10 battles per second. Of course, you may say that you can use multiple threads, but after using multiple threads, the order of combat events may be reached, affecting users' tactical arrangements.

Here, I plan to change a table to two tables: attack event table and attacked event table. The two tables have the same structure. Join Player A to initiate an attack on Player B. Then add the attack event to the attack event table on the server where Player A is located, and insert the data into the attacked event table on the server where Player B is located. Then each database corresponds to a combat ServerProgramThis program performs attack Computing Based on the attacked event table. After the calculation is complete, the data in the two tables is deleted at the same time.

 

Friend Module

The friend table itself can be divided into two tables, with a player ID serving as the primary key and corresponding players placed in the same database. However, you need to consider your friend application. If the applicant does not see his or her own application, you only need to put the application record and the gamer to be applied in the same data. However, if you need to be visible, it will be a bit difficult. One method is to refer to the design concept of the combat table, which can be divided into the application form and the application form. Another way is to separate the application form and put all user applications in this form. As a person, I prefer a method later.

 

User email Table Design

User mail is an interactive data between two users, but from the perspective of the entire system, it is easier to put a single table on a separate server. Because the content in the mail table is basically read-only, there is only the insert and read functions, and the frequency of user access is not very high, it can be easily cached at the logic layer and web layer.