Cross-server online game auction bank of multi-server architecture

Abstract

The invention provides a cross-server online game auction bank of a multi-server architecture, and an implementation method is as follows: a public server is erected in a cross-server range to serve as auction clothes, an auction bank independent of database transaction operation is constructed on the auction clothes, and the auction bank uses system resources of the auction clothes to improve bearing capacity and supports cross-server sharing; and the auction clothes and all the game clothes in the cross-clothes area group support cross-clothes communication and remote calling mutually. According to the method, more concurrent operation amount can be supported, and servers in a relatively large cross-server range are supported to share one auction bank. By combining the arrangement of the cross-server transaction operation consistency module and the isolation module, the consistency of the operations related to writing data and the isolation of the operations of different players on the same competitive product are ensured, the delay is greatly reduced, and the game experience is improved.

Description

Technical Field

[0001] The present invention relates to a cross-server online game auction house with a multi-server architecture. Background Art

[0002] Economic system games play a vital role in the field of video games. Such games usually include various transaction-related systems, such as shops, trading houses, auction houses, etc. The design of these systems is crucial to improving the gaming experience. In massively multiplayer online games (MMORPGs), a significant difference compared to stand-alone games is that players can interact with other players in the game, including trading. Systems that support transactions between players can not only improve the playability of the game, but also have a positive impact on the payment design of the game. In multiplayer online games, auction houses, which are trading systems involving multiple people, are particularly common.

[0003] Multiplayer online games usually use a server-based architecture, which means that the entire game's player base is divided into different regions, each with its own independent server. Therefore, the game is composed of multiple servers, and the player data and system data between different servers are usually isolated and independent from each other. Although this architecture helps manage a large number of players, it also brings challenges to cross-server interaction.

[0004] For the auction system in the game, supporting cross-server transactions will usually significantly improve key indicators such as listing volume, bidding volume, and participation rate compared to supporting only single-server transactions. This usually has a positive meaning for the auction system. However, in a cross-server ecosystem, due to the lack of data sharing between multiple servers and the large number of active players, the auction system that supports cross-servers will face more challenges. First, the participation of more players may lead to a significant increase in the number of concurrent operations; second, the auction operations and data consistency issues between cross-servers will also become more complicated.

[0005] The existing cross-server technology has the following significant shortcomings, which may have a negative impact on user experience in practical applications: First, existing technologies are deficient in handling high concurrency. Since these systems usually rely on common databases, these databases are not always deployed on the same physical machine as the game server. Therefore, in order to perform database operations, the system must communicate over the network. This network communication not only increases the latency of database operations, but also increases network latency, thereby reducing execution efficiency overall. In addition, when there are a large number of players, resulting in an increase in the number of concurrent operations, the performance bottleneck of database operations becomes very obvious, especially when compared to pure memory operations.

[0006] Secondly, the latency problem can easily become too high, thus affecting the player's gaming experience. A notable feature of gaming software is that it usually has high requirements for real-time performance. In order to ensure the smooth operation of all functions, high latency must be avoided, otherwise the player's gaming experience will be seriously affected. Especially in systems such as auction houses, due to the involvement of bidding time limits and rush bidding, the implementation of database transaction operations in high concurrency situations will usually be significantly perceived by players, resulting in a poor gaming experience. If the latency exceeds a certain threshold, the system will become almost unusable for players.

[0007] Finally, existing technologies cannot support sharing an auction house in a large cross-server environment. As mentioned above, the larger the cross-server range, the more players there are, and the higher the corresponding concurrency. In this case, the bottleneck of existing technologies will become very obvious, making it impossible to support sharing an auction house in a large cross-server environment.

[0008] In view of the above-mentioned shortcomings, the present invention proposes a solution based on a public server, which does not rely on database transaction functions to develop the functions of the auction system. In this way, the multi-core system resources of the server can be fully utilized, thereby improving the concurrent processing capability to support sharing an auction house in a larger cross-server environment. This method can not only solve the concurrency and delay problems in the prior art, but also provide a better user experience and ensure the real-time and smoothness of the game. Summary of the invention

[0009] The technical problem to be solved by the present invention is to provide a cross-server online game auction house with a multi-server architecture, which does not rely on database transaction functions to develop the functions of the auction system, but makes full use of the multi-core system resources of the server to improve the concurrent processing capability, so as to support sharing of an auction house in a larger cross-server environment, ensure the real-time and smoothness of the game, and improve the user experience.

[0010] The present invention provides a cross-server online game auction house with a multi-server architecture, and the implementation method is as follows: A public server is set up as an auction server within the cross-server range, and an auction house that does not rely on database transaction operations is built on the auction server. The auction house uses the system resources of the auction server to improve the carrying capacity and supports cross-server sharing; and the auction server and all game servers in the cross-server area group support cross-server communication and remote calls with each other.

[0011] Furthermore, the cross-server online game auction house of the multi-server architecture of the present invention includes a cross-server transaction operation consistency module, which is used to ensure the consistency of data writing related operations in the auction house during cross-server transaction operations, and specifically performs the following process: The auction server and the game server are regarded as nodes in the topological structure. Logically, a coordination node is abstracted from all the nodes, and the rest of the nodes are coordinated nodes. After a transaction operation is initiated, the coordinating node first makes all nodes try to enter the ready state; the ready state means that the necessary resources are obtained or occupied and the conditions for executing the transaction are met; If the readiness is successful, all nodes are notified to execute cross-server transactions; If readiness fails, all nodes are notified to roll back cross-server transactions.

[0012] Furthermore, the coordination node is undertaken by the game server.

[0013] Furthermore, the cross-server online game auction house with a multi-server architecture of the present invention includes an isolation module, which is used to ensure the isolation of operations on the same competing product among different players, and specifically performs the following process: a corresponding operation certificate is assigned to each competing product. Only when the player obtains the operation certificate of the corresponding competing product can he perform the corresponding operation on this competing product, otherwise he can only wait or directly regard the operation as failed.

[0014] One or more technical solutions provided by the present invention have at least the following technical effects or advantages: a public server is set up as an auction service within a cross-server range, and an auction system that does not rely on database transaction operations is constructed on the auction service, making full use of the system resources of the auction service to improve the carrying capacity of the auction system, so as to support more concurrent operations, so that it can support a larger cross-server range server to share an auction house as much as possible under relatively low latency. Then, after all coordinated nodes are synchronized to enter the ready state through the coordination node, the execution transaction is executed, so that all nodes in the auction house have the conditions for executing transactions before the transaction submission of all nodes is performed, thereby ensuring the consistency of operations related to writing data. In addition, by giving the competing product corresponding operation credentials to ensure the isolation of operations on the same competing product among different players, compared with the prior art in which all players' operations are first placed in a first-in-first-out operation queue, and the operation serial processing method is taken out one by one in order, the delay is greatly reduced, the situation of waiting for accumulation is avoided, and the game experience is improved.

[0015] The above description is only an overview of the technical solution of the present invention. In order to more clearly understand the technical means of the present invention, it can be implemented according to the contents of the specification. In order to make the above and other purposes, features and advantages of the present invention more obvious and easy to understand, the specific implementation methods of the present invention are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The present invention will be further described below in conjunction with embodiments with reference to the accompanying drawings.

[0017] Figure 1It is a schematic diagram of the framework of the system of the present invention; Figure 2 is a flow chart of the method in Embodiment 1 of the present invention; Figure 3 It is a schematic diagram of the structure of the device in the second embodiment of the present invention. DETAILED DESCRIPTION

[0018] The embodiment of the present application provides a cross-server online game auction house with a multi-server architecture. It does not rely on database transaction functions to develop the functions of the auction system, but instead makes full use of the multi-core system resources of the server to improve the concurrent processing capability, so as to support sharing of an auction house in a larger cross-server environment, ensure the real-time and smoothness of the game, and improve the user experience.

[0019] The technical solution in the embodiment of the present application has the following general idea: a public server is set up as an auction service within the cross-server range, and an auction system that does not rely on database transaction operations is built on the auction service, making full use of the system resources of the auction service to improve the carrying capacity of the auction system, so as to support more concurrent operations, so that it can support a larger cross-server range server to share an auction house as much as possible under relatively low latency. Then, the coordinating node coordinates and synchronizes all coordinated nodes to enter the ready state before executing the execution transaction, so that all nodes in the auction house have the conditions for executing transactions before submitting transactions of all nodes, thereby ensuring the consistency of operations related to writing data. In addition, by giving the competing product corresponding operation credentials to ensure the isolation of operations on the same competing product among different players, compared with the prior art method of putting all players' operations into a first-in-first-out operation queue first, and taking out the operations one by one in order for serial processing, the delay is greatly reduced, the situation of waiting for accumulation is avoided, and the game experience is improved.

[0020] Before introducing the specific embodiments, the system framework corresponding to the method of the embodiment of the present application is first introduced. Figure 1 As shown, the system is roughly divided into three parts: Game server refers to a dedicated server that runs games and processes game data. It provides services to multiple clients (i.e. game players), including processing game logic, managing game status, synchronizing game data, and other functions.

[0021] Client refers to the game client as opposed to the game server. It is a program that provides local services to customers. It is usually installed on ordinary user computers and needs to work with the server. The main function of the game client is to receive and process data from the game server and display the processing results to the user. At the same time, it receives the user's operation instructions and sends them to the server for processing.

[0022] The auction server is a public server specially set up across servers in the present invention. An auction system that does not rely on database transaction operations, namely, an auction house, is constructed on the auction server. The system resources of the auction server are fully utilized to improve the carrying capacity of the auction system, so that it can support a larger cross-server range of servers to share an auction house as much as possible with relatively low latency.

[0023] Embodiment 1 like Figure 2 As shown, this embodiment provides a cross-server online game auction house with a multi-server architecture, and the implementation method is as follows: a public server is set up as an auction server within the cross-server range, and an auction house that does not rely on database transaction operations is built on the auction server. The auction house uses the system resources of the auction server to improve the carrying capacity and supports cross-server sharing; and the auction server and all game servers in the cross-server area group support cross-server communication and remote calls with each other.

[0024] The cross-server online game auction house of the multi-server architecture of the present invention further includes a cross-server transaction operation consistency module, which is used to ensure the consistency of data writing related operations in the auction house during cross-server transaction operations, and specifically performs the following process: The auction server and the game server are regarded as nodes in the topological structure. Logically, a coordination node is abstracted from all the nodes, and the rest of the nodes are coordinated nodes. After a transaction operation is initiated, the coordinating node first makes all nodes try to enter the ready state; the ready state means that the necessary resources are obtained or occupied and the conditions for executing the transaction are met; If the readiness is successful, all nodes are notified to execute cross-server transactions; If readiness fails, all nodes are notified to roll back cross-server transactions.

[0025] Among them, the coordination node is undertaken by the game server.

[0026] Furthermore, the cross-server online game auction house with a multi-server architecture of the present invention includes an isolation module, which is used to ensure the isolation of operations on the same competing product among different players, and specifically performs the following process: a corresponding operation certificate is assigned to each competing product. Only when the player obtains the operation certificate of the corresponding competing product can he perform the corresponding operation on this competing product, otherwise he can only wait or directly regard the operation as failed.

[0027] like Figure 3 As shown, the following takes the bidding operation in the auction house as an example (other operations such as fixed price, listing, delisting, etc. can be generalized in the same way) to explain how to ensure consistency of operations related to writing data in the auction house. From a logical perspective, a bidding operation can be divided into the following steps: (1) The player places a bid and issues an auction request; (2) The auction house confirms that the current bid is valid; (3) Temporarily deduct the transaction currency from the player’s backpack.

[0028] (4) The auction system processes the bid successfully (recording this bid for settlement, updating bids, etc.).

[0029] 1. Regarding cross-server transaction operations: First of all, the entire bidding operation and its sub-operations should be transaction operations. In simple terms, a transaction operation means that all operations that make up a transaction must succeed or fail. A situation where half succeeds and half fails is not allowed. For example, the above step (3) successfully deducts the transaction currency from the player, but step (4) fails to update the price of the competing product. In this case, the player will have the money deducted, but will not actually win the bid. The entire bidding operation must be implemented as a transaction operation. Compared with a single sub-operation to implement a transaction, there will be additional problems with cross-server state coordination. For example, a bidding operation will involve two or more network requests and responses between the game server and the auction server. For a network request, if it times out, the initiator cannot know the status of the target server or whether it has received and responded to the request. This is also the focus of the solution of the present invention, which will be elaborated in detail below: like Figure 2 As shown in the figure, first, all servers are regarded as nodes in the topology structure, and a coordinating node is logically abstracted to coordinate and synchronize the status of all coordinated nodes. After an operation is initiated, the coordinator will work in two steps: A. Try to put all nodes into the ready state. When all nodes are in the ready state, at this step, all nodes should obtain / occupy the necessary resources to ensure that transactions can be executed smoothly on this node.

[0030] B. After all nodes enter the ready state, that is, after all nodes have the conditions to execute transactions, all nodes' transactions are committed.

[0031] In the auction system, the coordination node is the game server. Taking the auction operation as an example, when a player makes an auction request, the game server will enter the ready state for the player and the auction server to request the operation. If all goes well, all server nodes will submit the transaction execution instructions. The specific auction operation process is as follows: S1. The player initiates a bidding request to the coordination node; S2. The coordination node will try to notify the game server to conduct a series of checks on the player to see if the player is eligible to bid. After the check, the player's deposit will be temporarily withheld, which is equivalent to temporarily occupying a part of the transaction currency in the player's backpack. At this time, the game server player is ready.

[0032] S3. The coordination node then tries to notify the auction server to check whether the item being auctioned meets a series of auction condition checks, such as price check and listing status check. If the conditions for being auctioned are met, the item will be locked and put in a temporary occupied state. At this time, the auction server's item is ready.

[0033] If everything is ready, there will be no rollback. Otherwise, the coordination node will notify all ready nodes to roll back. Specifically, for the game server, it will return the transaction currency to release the occupation, and for the auction server, it will release the occupation status of the competing product. If everything is ready, all coordinated nodes will be notified to execute the transaction. The game server will actually deduct the player's transaction currency, and the auction server will implement the auction operation. The corresponding player will be the latest bidder, and the bid will also be updated. After the end, the competing product will be unbanned so that it can continue to be auctioned by other players.

[0034] The above-mentioned ready operation can prevent the sub-transactions of each server from being executed in advance. It first occupies a part of resources to enter the ready state to provide conditions for the smooth execution of the next transaction. When all nodes are ready, it means that the cross-server transaction operations involving the game server and the auction server are all ready for execution. The next step is execution, otherwise it is rolled back. With such a mechanism, if some nodes cannot communicate during the actual auction process and the transactions involved in the nodes do not meet the execution conditions, unnecessary dirty writes will not be performed on the system data itself, and the fault tolerance rate is relatively high.

[0035] 2. Regarding the isolation guarantee between different operations: In addition, in order to ensure the consistency of the above operations and the final data, and to meet the isolation requirements, different bidding operations are mutually exclusive for the same competitive product. For the same competitive product, whether it is operations from different players or the same operation from the same player for a short period of time, they need to be isolated from each other and cannot be operated at the same time. The isolation between these operations is explained as follows: If all the player's operations are pre-stored in a first-in-first-out operation queue, and then the auction system is allowed to take out the operations one by one in order for serial processing, then different operations will be executed in chronological order, thereby achieving mutual isolation. However, the present invention does not recommend this approach, because in the case of high concurrency, the system's processing speed may not keep up with the speed of operations being put into the queue, resulting in operation accumulation, which in turn significantly increases latency. This waiting strategy may make players mistakenly believe that the system is unresponsive, thereby greatly reducing the player's gaming experience.

[0036] In fact, different operations do not necessarily affect each other. We can reduce the granularity of the operation to a single competitive product and set a lock for each competitive product, that is, to grant the corresponding operation certificate. Only when the player obtains the operation certificate of the corresponding competitive product can the player perform the bidding operation; if the certificate cannot be obtained, a waiting strategy can be adopted or the operation can be directly regarded as a failure. However, as mentioned earlier, game systems usually pursue low latency, so in most cases, we can directly regard the operation as a failure and promptly inform the player to refresh and try again. This can improve the response rate while avoiding the situation of waiting accumulation, thereby ensuring that the player's gaming experience will not be affected.

[0037] In order to further optimize the performance and user experience of the auction system, a distributed processing strategy based on a lock mechanism can be adopted. In this strategy, the system will distribute the lock of each competing product to different server nodes to achieve load balancing and high availability. When a player initiates an auction operation, the system will route the request to the corresponding node according to the identifier of the competing product. Only after obtaining the lock on the node can the player's operation be executed.

[0038] In order to reduce the performance loss caused by lock contention, the system can adopt an optimistic lock mechanism. At the beginning of the auction, the system will generate a version number for each competing product. When the player initiates the auction operation, the system will check whether the version number has changed. If the version number has not changed, it means that the status of the competing product has not been modified by other operations, the player's operation can be executed smoothly, and the version number will be updated. If the version number has changed, it means that the status of the competing product has been modified by other operations. At this time, the system can immediately notify the player that the operation failed and suggest that he refresh and try again.

[0039] In addition, in order to further improve the response speed and processing power of the system, a cache mechanism can be introduced. The system can cache some auction data in memory to reduce frequent access to the database. When a player initiates an auction operation, the system first searches the cache for the data of the corresponding competing product. If the data exists, the operation is performed directly in the cache, and then the result is synchronized to the database. This can greatly reduce the response time of the operation and improve the user experience.

[0040] In order to ensure the stability of the system and the consistency of data, the system also needs to have a complete monitoring and fault recovery mechanism. The system can monitor the operating status of each node in real time. Once a node failure is found, the request can be quickly routed to other normal nodes to ensure the continuity of the auction operation and the consistency of the data. At the same time, the system also needs to conduct regular data backup and recovery drills to deal with possible emergencies.

[0041] In summary, by adopting distributed locking mechanism, optimistic locking strategy, caching mechanism and perfect monitoring and fault recovery mechanism, the performance and user experience of the auction system can be effectively improved, ensuring stable operation in high concurrency scenarios.

[0042] Although the specific implementation modes of the present invention are described above, those skilled in the art should understand that the specific implementation modes described are only illustrative and are not intended to limit the scope of the present invention. Equivalent modifications and changes made by those skilled in the art in accordance with the spirit of the present invention should be included in the scope of protection of the claims of the present invention.

Claims

1. A cross-server online game auction house with a multi-server architecture, characterized by: Here’s how to do it: A public server is set up as an auction server within the cross-server range, and an auction house that does not rely on database transaction operations is built on the auction server. The auction house uses the system resources of the auction server to improve the carrying capacity and supports cross-server sharing; and the auction server and all game servers in the cross-server area group support cross-server communication and remote calls with each other.

2. The multi-server architecture cross-server online game auction house according to claim 1, characterized in that: It includes a cross-server transaction operation consistency module, which is used to ensure the consistency of data writing related operations in the auction house during cross-server transaction operations, and specifically performs the following process: The auction server and the game server are regarded as nodes in the topological structure. Logically, a coordination node is abstracted from all the nodes, and the rest of the nodes are coordinated nodes. After a transaction operation is initiated, the coordinating node first makes all nodes try to enter the ready state; the ready state means that the necessary resources are obtained or occupied and the conditions for executing the transaction are met; If the readiness is successful, all nodes are notified to execute cross-server transactions; If readiness fails, all nodes are notified to roll back cross-server transactions.

3. The multi-server architecture cross-server online game auction house according to claim 1, characterized in that: The coordination node is undertaken by the game server.

4. The multi-server architecture cross-server online game auction house according to claim 1, characterized in that: It includes an isolation module, which is used to ensure the isolation of operations on the same competing product among different players, and specifically implements the following process: a corresponding operation certificate is assigned to each competing product. Only when the player obtains the operation certificate of the corresponding competing product can he perform the corresponding operation on this competing product, otherwise he can only wait or directly regard the operation as failed.

Images