Game server database optimization method and system

Abstract

The invention relates to a game server database optimization method and system. A database agent is additionally arranged between a game server and a database; for data read-write operation initiated by the game server, the database agent allocates the data table name hash to a certain table service for execution according to the data table name hash; organizing all in-transit modification operations of any data table according to a'primary key-> write cache record list 'of the table; the database writing thread receives a batch writing request periodically initiated by the corresponding table service, writes data into the relational database, and notifies the table service thread of a writing result; and the database reading thread group is a common thread group, receives calling of all table services, reads data from the database and returns the data to the table service thread. According to the scheme, the read-write throughput speed of the game database can be greatly improved according to the actual scene requirement of the mobile game, and the concurrent read performance and the batch write performance of the database are fully exerted.

Description

Technical Field

[0001] The present invention relates to the field of network communication technology, and in particular to a game server database optimization method and system. Background Art

[0002] With the rapid popularization of smart phones and the rapid development of the Internet, mobile Internet-related businesses have gradually become the focus of attention of domestic manufacturers. From the perspective of the entire industry, China's mobile game industry is in a period of rapid development. In recent years, with the joint promotion of telecom operators and mobile game developers, China's mobile game industry has achieved rapid development. With the development of interactive entertainment technology, various types of interactive game applications have been greatly developed. There are many types of games and game control methods, and the form of games has also transitioned from computers or game consoles to mobile games.

[0003] As the mobile game market is booming, the industry often uses relational databases to store player data. Game server data has the following characteristics:

[0004] The frequency of changes is high. For example, when a player synthesizes an item, clicks on a development function, or uses a skill, these actions may directly lead to multiple records being modified, deleted, or added.

[0005] High security requirements. No loss or inconsistency is allowed. Data errors can cause huge economic losses.

[0006] High capacity requirements. When the server is launched or an event is launched, a large number of players will log in to the game in a short period of time, causing a lot of read pressure; when an event ends or is settled, there may be a large amount of data updated, causing write pressure.

[0007] The need for multi-table queries is extremely low. Although foreign keys are also used, master and slave data are often loaded together (such as when a player logs in). A small number of multi-table query needs (such as leaderboards) are generally solved using redundant fields to avoid additional loading of data for players who are not online.

[0008] The industry technical solutions in the prior art generally use code generation technology to generate proprietary data structure mappings and use them directly in memory. When a player logs in, a read thread group is used to read the memory mapping structure from the database. When the data changes, the memory data is modified directly. The write thread group periodically writes the modified data back to the database in increments or in full. When the player logs out, it is unloaded from memory and the accumulated write operations are executed.

[0009] This approach has the following drawbacks:

[0010] Data consistency cannot be guaranteed. When a piece of data is unloaded and is immediately requested to be read, if the last write operation has not been completed, old data may be retrieved, and corresponding protection needs to be added in the peripheral logic. If the read and write threads of a table are specified to be the same, data consistency can be guaranteed, but a large number of single record modifications that are not merged will seriously reduce performance; at the same time, single-threaded reading will also cause huge read performance pressure.

[0011] Poor peak capacity. When an activity is settled or many players log out for a short period of time, the accumulated write pressure will be forced to execute together, increasing the instability of the system.

[0012] Low data security. Because the save is triggered periodically, the changes made during the period may be lost due to server downtime, and additional components need to be developed to protect the data.

[0013] Therefore, although the data solutions in the prior art are feasible, they have a low degree of generalization and leave some difficult problems. Summary of the invention

[0014] The present invention provides a game server database optimization method and system, which solves the problems existing in the game server data operation in the prior art, greatly exerts the performance of relational database, exerts the high-throughput batch writing and high-performance concurrent reading characteristics of relational database, and ensures data consistency and data security.

[0015] According to one aspect of the present invention, a game server database optimization method is provided, comprising:

[0016] Add a database proxy between the game server and the database;

[0017] For data read and write operations initiated by the game server, the database agent is assigned to a table service according to the hash of the data table name for execution; the table service includes write caches for several data tables and a database write thread; each table service is driven by a separate thread;

[0018] All in-progress modification operations of any data table are organized according to the table's "primary key->write cache record list"; the write cache record consists of a unique operation ID, field modification data, and write status; the unique operation ID increases with time; the write status marks whether the record has been stored;

[0019] The database writing thread accepts the batch writing requests periodically initiated by the corresponding table service, writes the data into the relational database, and notifies the table service thread of the writing results;

[0020] The database reading thread group is a public thread group that receives calls from all table services, reads data from the database, and returns it to the table service thread.

[0021] The database agent also includes an LSM disaster recovery database as a disaster recovery component to perform data read and write backup; using a KV database based on log-structured merge-tree technology, it can write data with extremely high performance and prevent the loss of write cache records.

[0022] The database proxy also includes a SQL Parser module, which is responsible for converting external request SQL statements into internal structures; when the database proxy is used as an in-process component, the internal structure is directly used to make requests.

[0023] When performing a data read operation, the process is as follows:

[0024] Assign a unique operation ID to the current operation;

[0025] When it is determined that the current operation is to read data according to the primary key, it is further determined whether there is an INSERT operation record corresponding to the primary key in the current write cache; if so, all write records after the INSERT operation in the write cache are merged and the read result is returned;

[0026] When it is determined that the current operation is to read data according to conditions or there is no INSERT operation record corresponding to the primary key in the current write cache, a query is first executed from the database; after obtaining the result, it is merged with the operation after the current read operation in the write cache according to the unique operation ID, and a second filtering is performed according to the query conditions to obtain the latest result and return it.

[0027] When writing data, the process is as follows:

[0028] Assign a unique operation ID to the current operation;

[0029] Add the write operation to the end of the list corresponding to the primary key, or merge the unwritten operations corresponding to the primary key in the list for writing.

[0030] The write operation is timed trigger; the specific operation process is as follows:

[0031] Traverse the unwritten operations in the write cache and generate batch update data;

[0032] Obtain the write lock of the current data table, and perform batch write operations on the database based on the write lock and batch update data;

[0033] After the write operation is completed, the write lock is released and the completed write operation in the write cache is deleted.

[0034] When the LSM disaster recovery database exists in the database proxy as a disaster recovery component for data read and write backup, after each write operation enters the data table service, a unique operation ID is assigned to the current operation and saved in the LSM disaster recovery database;

[0035] After the write operation is completed, the completed write operation is deleted from the LSM disaster recovery database.

[0036] When performing a multi-table query of data, the process is as follows:

[0037] When a non-primary key condition deletion or cross-table query request is obtained from the server, the write cache of the data table associated with the request is executed; after suspending the table service of the associated data table, the corresponding deletion or query operation is executed on the database;

[0038] After the operation is completed, the table service of the associated data table is replied and the operation result is returned.

[0039] According to another aspect of the present invention, a game server database optimization system is provided, including a database agent arranged between a server and a database, wherein the database agent includes:

[0040] A table service allocation unit is used to initiate data read and write operations on the game server. The database agent is allocated to a table service according to the hash of the data table name for execution; the table service includes a write cache of several data tables and a database write thread; each table service is driven by a separate thread;

[0041] The data table operation unit is used for all in-transit modification operations of any data table, and is organized according to the table's "primary key->write cache record list"; the write cache record consists of a unique operation ID, field modification data, and write status; the unique operation ID increases with time; the write status marks whether the record has been stored;

[0042] The data writing unit is used for the database writing thread to accept the batch writing requests regularly initiated by the corresponding table service, write the data into the relational database, and notify the table service thread of the writing result;

[0043] The data reading unit is used for the database reading thread group as a public thread group, receives calls from all table services, reads data from the database, and returns it to the table service thread.

[0044] The database agent further includes:

[0045] LSM disaster recovery database is used as a disaster recovery component to perform data read and write backup. It uses a KV database based on log-structured merge-tree technology, which can write data with extremely high performance and prevent the loss of write cache records.

[0046] The SQL Parser module is responsible for converting external request SQL statements into internal structures. When the database agent is used as an in-process component, the internal structure is directly used for requests.

[0047] The beneficial effects of adopting the above scheme are:

[0048] A database proxy is added between the game server and the database. For data read and write operations initiated by the game server, the database proxy is assigned to a table service according to the hash of the data table name for execution. All in-transit modification operations of any data table are organized according to the table's "primary key -> write cache record list". The database write thread accepts batch write requests regularly initiated by the corresponding table service, writes data to the relational database, and notifies the table service thread of the write result. The database read thread group is a public thread group, which receives calls from all table services, reads data from the database, and returns it to the table service thread.

[0049] In the solution of the present invention, according to the actual scenario requirements of mobile games, the read and write throughput speed of the game database can be greatly improved, and the concurrent read performance of the database and the batch write performance of the database can be fully utilized. For industry scenarios, most write operations can be automatically merged, which greatly reduces the pressure on the database. At the same time, it has extremely strong disaster recovery capabilities, ensures consistency at the single table level, has a high degree of versatility, and can be used as a database proxy process. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] Figure 1 A flowchart of the principles of a game server database optimization method provided by an embodiment of the present invention.

[0051] Figure 2 A schematic diagram of the database proxy location provided in an embodiment of the present invention.

[0052] Figure 3 A schematic diagram of a database proxy structure provided by an embodiment of the present invention.

[0053] Figure 4 A schematic diagram of a database proxy data reading process provided by an embodiment of the present invention.

[0054] Figure 5 A schematic diagram of a database proxy data writing process provided by an embodiment of the present invention.

[0055] Figure 6 A schematic diagram of a multi-table data query process provided by an embodiment of the present invention.

[0056] Figure 7 A schematic diagram of the structure of a game server database optimization system provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0057] The principles and features of the present invention are described below in conjunction with the accompanying drawings. The examples given are only used to explain the present invention and are not used to limit the scope of the present invention. It should be noted that the embodiments of the present application and the features in the embodiments can be combined with each other without conflict.

[0058] Each embodiment of the present invention provides a proxy module for a relational database, which can fully utilize the high-throughput batch writing and high-performance concurrent reading characteristics of the relational database to ensure data consistency and data security.

[0059] The present invention is further described below in conjunction with the accompanying drawings.

[0060] like Figure 1 As shown, it is a principle flow chart of the game server database optimization method provided by Embodiment 1 of the present invention, which is specifically as follows:

[0061] Step 11, add a database proxy between the game server and the database.

[0062] In the embodiment of the present invention, the specific architecture is as follows Figure 2 The specific database proxy structure is as follows Figure 3 As shown. A database proxy is added between the game server and the database to solve the problem of connecting the server and the database in the prior art. The database can be a MySQL database or other types of databases. This embodiment takes the MySQL database as an example to illustrate the implementation principle of this embodiment.

[0063] Step 12: For data read and write operations initiated by the game server, the database agent assigns them to a table service according to the hash of the data table name for execution.

[0064] In this embodiment, the table service contains write caches for several data tables and a database write thread; each table service is driven by a separate thread. For all read and write operations from the game server, the database agent assigns them to a table service according to the table name hash for execution. The table service contains write caches for multiple tables and a database write thread, and each table service is driven by a separate thread.

[0065] Multiple table services run simultaneously in the database agent. Each table service contains write caches for multiple tables and a write thread for write operations.

[0066] Step 13: All in-progress modification operations of any data table are organized according to the table's "primary key->write cache record list".

[0067] In this embodiment, the write cache record consists of a unique operation ID, field modification data and a write status; the unique operation ID increases with time; the write status marks whether the record has been stored.

[0068] In this embodiment, all in-transit modification operations of a table are organized according to the table's "primary key->write cache record list".

[0069] The write cache record consists of "unique operation ID, field modification data, and write status". The operation ID must increase over time, but it can be discontinuous. The write status marks whether this record has been stored. Write operations are idempotent, and multiple executions will not cause data errors.

[0070] A specific embodiment is as follows:

[0071]

[0072] }

[0073] Figure 3 The write caches of multiple tables and the corresponding operations of multiple primary keys corresponding to each write cache are illustrated in FIG.

[0074] Step 104: The database writing thread accepts the batch writing request periodically initiated by the corresponding table service, writes the data into the relational database, and notifies the table service thread of the writing result.

[0075] The database write thread accepts batch write requests regularly initiated by the corresponding table service, that is, writes the write operations of multiple table services to the database regularly. Before writing to the database, the written data can also be merged.

[0076] Step 105: The database reading thread group is a public thread group, which receives calls from all table services, reads data from the database, and returns it to the table service thread.

[0077] like Figure 3 As shown, in this embodiment, the above database agent also includes two optional components, which are as follows:

[0078] The database agent also includes an LSM disaster recovery database as a disaster recovery component for data read and write backup; using a KV database based on log-structured merge-tree technology, it can write data with extremely high performance and prevent the loss of write cache records.

[0079] KV database (Key-Value database) is a non-relational database that stores data in the form of key-value pairs. It accesses and stores data through simple key-value pairs, and has the advantages of high performance, strong scalability, and high flexibility. High performance is its most significant feature, because KV database can reduce query time and improve response speed through simple key-value pair access. For example, Redis, as a popular KV database, can store data in memory, thereby achieving millisecond response time, which is very suitable for application scenarios that require fast reading and writing.

[0080] The basic principle of KV database is based on the data structure of key-value pairs. Each key is unique, and the corresponding value can be quickly found through the key. This simple data model makes the operation of KV database very efficient. The key-value pair data model is the core of KV database, which realizes fast search and storage through underlying data structures such as hash tables and skip tables. Hash tables can complete insertion, deletion and search operations in constant time, while skip tables provide efficient range query and sorting functions in ordered sets.

[0081] Hash table is a common underlying data structure used in KV databases. It maps keys to specific storage locations through hash functions, thereby achieving fast search. The advantage of hash table is that it has fast query speed, but it also has the problem of hash collision. In order to deal with hash collision, common methods include chain address method and open address method. Chain address method stores conflicting key-value pairs through linked lists, while open address method resolves conflicts by detecting free locations.

[0082] Skiplist is a balanced data structure, commonly used in KV databases that support ordered data. Skiplist uses multi-layer linked lists to achieve fast range query and sorting functions. Each layer of linked lists is a subset of the previous layer of linked lists. When querying, the range can be narrowed down layer by layer, thereby improving efficiency. Skiplist is superior to balanced tree in performance and implementation complexity, and is therefore widely used in KV databases.

[0083] Log-Structured-Merge-Tree (LSM-tree) is a hierarchical, ordered data storage structure designed for the characteristics of block storage devices. Its core theoretical basis is: the sequential write speed of the disk is much faster than the random write speed. Even for SSD, due to the influence of block erasure and garbage collection, the sequential write speed is still much faster than the random write speed. LSM-tree divides data into multiple SSTables (Sort String Tables), which contain several ordered arbitrary byte groups. SSTable can be regarded as a data write / modification record similar to a database log. Once written to the external memory, it cannot be modified.

[0084] The database proxy also includes a SQL Parser module, which is responsible for converting external request SQL statements into internal structures. When the database proxy is an in-process component, it directly uses the internal structure to make requests. When a SQL request reaches the server, it first passes through the Parser module. The main function of the Parser module is to determine whether the format of an SQL statement conforms to the corresponding grammatical structure based on the defined grammatical rules. This grammatical structure is automatically generated using Yacc and Flex tools in both MySQL and OceanBase.

[0085] In an embodiment of the present invention, a database agent is added between a game server and a database; for data read and write operations initiated by the game server, the database agent is assigned to a certain table service for execution according to the hash of the data table name; all in-transit modification operations of any data table are organized according to the "primary key->write cache record list" of the table; the database write thread accepts batch write requests regularly initiated by the corresponding table service, writes data to the relational database, and notifies the table service thread of the write result; the database read thread group is a public thread group, which receives calls from all table services, reads data from the database, and returns it to the table service thread.

[0086] In the solution of the present invention, according to the actual scenario requirements of mobile games, the read and write throughput speed of the game database can be greatly improved, and the concurrent read performance of the database and the batch write performance of the database can be fully utilized. For industry scenarios, most write operations can be automatically merged, which greatly reduces the pressure on the database. At the same time, it has extremely strong disaster recovery capabilities, ensures consistency at the single table level, has a high degree of versatility, and can be used as a database proxy process.

[0087] like Figure 4 As shown, a schematic diagram of a database proxy data reading process provided by an embodiment of the present invention includes the following steps:

[0088] Assign a unique operation ID to the current operation;

[0089] When it is determined that the current operation is to read data according to the primary key, it is further determined whether there is an INSERT operation record corresponding to the primary key in the current write cache; if so, all write records after the INSERT operation in the write cache are merged and the read result is returned;

[0090] When it is determined that the current operation is to read data according to conditions or there is no INSERT operation record corresponding to the primary key in the current write cache, a query is first executed from the database; after obtaining the result, it is merged with the operation after the current read operation in the write cache according to the unique operation ID, and a second filtering is performed according to the query conditions to obtain the latest result and return it.

[0091] Specifically, the following points are included:

[0092] Consistency guarantee. When reading data by primary key, if there is an INSERT operation record for this record in the write cache, it will be used directly. By merging all write records after the INSERT record, the latest data can be generated without going through the database and returned directly to the requesting end.

[0093] When reading data by condition, first execute the query from the database, obtain the result, merge it with the operation after the current read operation in the write cache, and then filter it again according to the query condition to obtain the latest result.

[0094] High performance. The read operation is fully concurrent, which can effectively exert the concurrent read performance of the database. Testing on an ordinary machine shows that more than 10,000 queries can be completed per second, which is an order of magnitude higher than non-concurrency.

[0095] like Figure 5 As shown, a schematic diagram of a database proxy data writing process provided by an embodiment of the present invention includes the following steps:

[0096] Assign a unique operation ID to the current operation;

[0097] Add the write operation to the end of the list corresponding to the primary key, or merge the unwritten operations corresponding to the primary key in the list for writing.

[0098] The write operation is timed trigger; the specific operation process is as follows:

[0099] Traverse the unwritten operations in the write cache and generate batch update data;

[0100] Obtain the write lock of the current data table, and perform batch write operations on the database based on the write lock and batch update data;

[0101] After the write operation is completed, the write lock is released and the completed write operation in the write cache is deleted.

[0102] When the LSM disaster recovery database exists in the database proxy as a disaster recovery component for data read and write backup, after each write operation enters the data table service, a unique operation ID is assigned to the current operation and saved in the LSM disaster recovery database;

[0103] After the write operation is completed, the completed write operation is deleted from the LSM disaster recovery database.

[0104] The above data writing operation includes the following points:

[0105] Security. After all write operations enter the table service, a unique operation ID will be assigned and immediately saved to the local LSM disaster recovery database.

[0106] After the operation is successfully written to the database, it is removed from the LSM database.

[0107] When the server restarts, the write cache is restored from the local LSM database.

[0108] High performance. All write operations are executed in batches, which effectively utilizes the characteristics of relational databases and can control the amount of writes to avoid sudden peaks that overwhelm the database.

[0109] The write operation is triggered at a fixed time (for example, ten seconds). When executed, a write lock is acquired to prevent the table service from performing other read and write operations during database writing.

[0110] During the idle periods between write operations, read operations can be fully concurrent.

[0111] For data that is commonly created and then destroyed immediately in games, write operation merging can allow the request to be completed normally without going through the database at all, that is, "insert and then delete, merge into no operation".

[0112] For high-frequency updates in the game, such as experience fields, which may be updated dozens of times within a few seconds, write operation merging can directly merge multiple requests, that is, "update operations can be merged with update operations."

[0113] like Figure 6 As shown, it is a schematic diagram of a multi-table data query process provided by an embodiment of the present invention, wherein:

[0114] When a non-primary key condition deletion or cross-table query request is obtained from the server, the write cache of the data table associated with the request is executed; after suspending the table service of the associated data table, the corresponding deletion or query operation is executed on the database;

[0115] After the operation is completed, the table service of the associated data table is replied and the operation result is returned.

[0116] The solution of this embodiment is specially designed for industry scenarios, including operations such as multi-table query and deletion and modification of non-primary key conditions. Therefore, this embodiment can also support various operations in specific scenarios.

[0117] like Figure 7 FIG. 1 is a schematic diagram of the structure of a game server database optimization system provided by an embodiment of the present invention, including a database agent disposed between the server and the database, wherein the database agent includes:

[0118] Table service allocation unit 21, used for data read and write operations initiated by the game server, the database agent is allocated to a table service for execution according to the hash of the data table name; the table service includes write caches of several data tables and a database write thread; each table service is driven by a separate thread;

[0119] The data table operation unit 22 is used for all in-transit modification operations of any data table, and is organized according to the table's "primary key->write cache record list"; the write cache record consists of a unique operation ID, field modification data, and write status; the unique operation ID increases with time; the write status marks whether the record has been stored;

[0120] The data writing unit 23 is used for the database writing thread to accept the batch writing request regularly initiated by the corresponding table service, write the data into the relational database, and notify the table service thread of the writing result;

[0121] The data reading unit 24 is used for a database reading thread group which is a common thread group, receives calls from all table services, reads data from the database, and returns the data to the table service thread.

[0122] LSM disaster recovery database 25 is used as a disaster recovery component to perform data read and write backup. It uses a KV database based on log-structured merge-tree technology, which can write data with extremely high performance and prevent the loss of write cache records.

[0123] The SQL Parser module 26 is responsible for converting the external request SQL statement into the internal structure; when the database agent is used as an in-process component, the internal structure is directly used to make the request.

[0124] In an embodiment of the present invention, a database agent is added between a game server and a database; for data read and write operations initiated by the game server, the database agent is assigned to a certain table service for execution according to the hash of the data table name; all in-transit modification operations of any data table are organized according to the "primary key->write cache record list" of the table; the database write thread accepts batch write requests regularly initiated by the corresponding table service, writes data to the relational database, and notifies the table service thread of the write result; the database read thread group is a public thread group, which receives calls from all table services, reads data from the database, and returns it to the table service thread.

[0125] In the solution of the present invention, according to the actual scenario requirements of mobile games, the read and write throughput speed of the game database can be greatly improved, and the concurrent read performance of the database and the batch write performance of the database can be fully utilized. For industry scenarios, most write operations can be automatically merged, which greatly reduces the pressure on the database. At the same time, it has extremely strong disaster recovery capabilities, ensures consistency at the single table level, has a high degree of versatility, and can be used as a database proxy process.

[0126] Although the present invention has been described in detail based on specific embodiments, the above-mentioned embodiments are merely examples, and the present invention is not limited to the above-mentioned embodiments.

[0127] Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods, systems, or computer program products. Therefore, the present invention may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage and optical storage, etc.) containing computer-usable program code.

[0128] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0129] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0130] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0131] Obviously, those skilled in the art can make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if these modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention is also intended to include these modifications and variations.

Claims

1. A game server database optimization method, characterized in that: The method comprises: Add a database proxy between the game server and the database; For data read and write operations initiated by the game server, the database agent is assigned to a table service according to the hash of the data table name for execution; the table service includes write caches for several data tables and a database write thread; each table service is driven by a separate thread; All in-progress modification operations of any data table are organized according to the table's "primary key->write cache record list"; the write cache record consists of a unique operation ID, field modification data, and write status; the unique operation ID increases with time; the write status marks whether the record has been stored; The database writing thread accepts the batch writing requests periodically initiated by the corresponding table service, writes the data into the relational database, and notifies the table service thread of the writing results; The database reading thread group is a public thread group that receives calls from all table services, reads data from the database, and returns it to the table service thread.

2. The method according to claim 1, characterized in that The method further comprises: The database agent also includes an LSM disaster recovery database as a disaster recovery component to perform data read and write backup; using a KV database based on log-structured merge-tree technology, it can write data with extremely high performance and prevent the loss of write cache records.

3. The method according to claim 1, characterized in that The method further comprises: The database proxy also includes a SQL Parser module, which is responsible for converting external request SQL statements into internal structures; when the database proxy is used as an in-process component, the internal structure is directly used to make requests.

4. The method according to claim 1, characterized in that When performing a data read operation, the process is as follows: Assign a unique operation ID to the current operation; When it is determined that the current operation is to read data according to the primary key, it is further determined whether there is an INSERT operation record corresponding to the primary key in the current write cache; if so, all write records after the INSERT operation in the write cache are merged and the read result is returned; When it is determined that the current operation is to read data according to conditions or there is no INSERT operation record corresponding to the primary key in the current write cache, a query is first executed from the database; after obtaining the result, it is merged with the operation after the current read operation in the write cache according to the unique operation ID, and a second filtering is performed according to the query conditions to obtain the latest result and return it.

5. The method according to claim 1, characterized in that When writing data, the process is as follows: Assign a unique operation ID to the current operation; Add the write operation to the end of the list corresponding to the primary key, or merge the unwritten operations corresponding to the primary key in the list for writing.

6. The method according to claim 5, characterized in that The write operation is timed trigger; the specific operation process is as follows: Traverse the unwritten operations in the write cache and generate batch update data; Obtain the write lock of the current data table, and perform batch write operations on the database based on the write lock and batch update data; After the write operation is completed, the write lock is released and the completed write operation in the write cache is deleted.

7. The method according to claim 5, characterized in that The method further comprises: When the LSM disaster recovery database exists in the database proxy as a disaster recovery component for data read and write backup, after each write operation enters the data table service, a unique operation ID is assigned to the current operation and saved in the LSM disaster recovery database; After the write operation is completed, the completed write operation is deleted from the LSM disaster recovery database.

8. The method according to claim 1, characterized in that When performing a multi-table query of data, the process is as follows: When a non-primary key condition deletion or cross-table query request is obtained from the server, the write cache of the data table associated with the request is executed; after suspending the table service of the associated data table, the corresponding deletion or query operation is executed on the database; After the operation is completed, the table service of the associated data table is replied and the operation result is returned.

9. A game server database optimization system, characterized in that: The database agent is provided between the server and the database, and the database agent includes: A table service allocation unit is used to initiate data read and write operations on the game server. The database agent is allocated to a table service according to the hash of the data table name for execution; the table service includes a write cache of several data tables and a database write thread; each table service is driven by a separate thread; The data table operation unit is used for all in-transit modification operations of any data table, and is organized according to the table's "primary key->write cache record list"; the write cache record consists of a unique operation ID, field modification data, and write status; the unique operation ID increases with time; the write status marks whether the record has been stored; The data writing unit is used for the database writing thread to accept the batch writing requests regularly initiated by the corresponding table service, write the data into the relational database, and notify the table service thread of the writing result; The data reading unit is used for the database reading thread group as a public thread group, receives calls from all table services, reads data from the database, and returns it to the table service thread.

10. The system according to claim 9, characterized in that The database agent further includes: LSM disaster recovery database is used as a disaster recovery component to perform data read and write backup. It uses a KV database based on log-structured merge-tree technology, which can write data with extremely high performance and prevent the loss of write cache records. The SQL Parser module is responsible for converting external request SQL statements into internal structures. When the database agent is used as an in-process component, the internal structure is directly used for requests.

Images