A game order processing method, device and equipment and storage medium
By writing order messages into the message middleware and database in the game and consuming them in real time or with delay, the problems of high order message retries and high latency are solved, and more efficient order processing is achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- GUANGZHOU YIHU NETWORK TECH CO LTD
- Filing Date
- 2023-05-31
- Publication Date
- 2026-07-31
AI Technical Summary
In the game, order messages suffer from high retries and high latency due to network failures or middleware malfunctions.
Order messages are written to both the message middleware and the database. The message middleware is consumed in real time, while the database is consumed at a later time. This approach, which uses the message middleware as the primary means and the database as a secondary means, avoids duplicate consumption and message loss.
This reduces the number of retries and processing latency for order messages, thereby improving the efficiency and success rate of order message processing.
Smart Images
Figure CN116617672B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of computer processing technology, and more particularly to a method, apparatus, device, and storage medium for processing game orders. Background Technology
[0002] In different games, manufacturers usually provide virtual items such as props and decorations. Users can control a character in the game to generate orders and order virtual items. The system processes the orders and writes the data of the virtual items into the character's data.
[0003] Currently, orders are mostly transmitted in the system in the form of messages. The messages are written to the queue of the message middleware to wait for processing. During the message transmission and storage process, messages may be lost due to factors such as network failures and middleware failures, resulting in a high number of retries and high latency in order processing. Summary of the Invention
[0004] This invention provides a method, apparatus, device, and storage medium for processing game orders, in order to solve the problems of high order retries and high latency in games.
[0005] According to one aspect of the present invention, a method for processing game orders is provided, comprising:
[0006] Upon receiving an order message, the order message is written to both the message middleware and the database. The order message indicates that a virtual character in the game has ordered virtual items.
[0007] The order message in the message middleware is consumed in real time to write the virtual item to the virtual character in the game;
[0008] Update the status of the order message consumed from the message middleware to the message middleware and the database;
[0009] If the status is unprocessed or processing failed, the order message in the database is consumed with a delay in order to write the virtual item to the virtual character in the game;
[0010] The status of the order message consumed from the database is updated in the message middleware and the database.
[0011] According to another aspect of the present invention, a game order processing apparatus is provided, comprising:
[0012] The order message storage module is used to write the order message into the message middleware and the database respectively when an order message is received. The order message indicates that a virtual character in the game has ordered virtual items.
[0013] The middleware consumption module is used to consume the order messages in the message middleware in real time, so as to write the virtual items to the virtual character in the game;
[0014] The first state synchronization module is used to update the state of the order message consumed from the message middleware to the message middleware and the database.
[0015] The database consumption module is used to delay consuming the order message in the database if the status is unprocessed or processing failed, so as to write the virtual item to the virtual character in the game;
[0016] The second state synchronization module is used to update the status of the order messages consumed from the database to the message middleware and the database.
[0017] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising:
[0018] At least one processor; and
[0019] A memory communicatively connected to the at least one processor; wherein,
[0020] The memory stores a computer program that can be executed by the at least one processor, which enables the at least one processor to perform the game order processing method according to any embodiment of the present invention.
[0021] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing a computer program configured to cause a processor to execute and implement the game order processing method according to any embodiment of the present invention.
[0022] In this embodiment, upon receiving an order message, the message is written to both the message middleware and the database. The order message indicates that a virtual character in the game has ordered virtual items. The message middleware is consumed in real-time to write the virtual items to the virtual character in the game. The status of the consumed order message is updated in both the message middleware and the database. If the status is "unprocessed" or "processed failed," the consumption of the order message in the database is delayed to write the virtual items to the virtual character in the game. The status of the consumed order message in the database is then updated in both the message middleware and the database. This embodiment primarily uses the message middleware and secondarily uses the database to process order messages. The two processes are staggered in time and work together to avoid duplicate consumption of order messages, improving the efficiency of order message processing. The database persists the order messages, preventing message loss and reducing the number of retries and processing latency.
[0023] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description
[0024] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0025] Figure 1 This is a flowchart of a game order processing method according to Embodiment 1 of the present invention;
[0026] Figure 2 This is a schematic diagram of the structure of a game order processing device according to Embodiment 2 of the present invention;
[0027] Figure 3 This is a schematic diagram of the structure of an electronic device provided in Embodiment 3 of the present invention. Detailed Implementation
[0028] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.
[0029] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.
[0030] Example 1
[0031] Figure 1 This is a flowchart of a game order processing method provided in Embodiment 1 of the present invention. This embodiment is applicable to situations where database-assisted message middleware is used to process order messages in a game. This method can be executed by a game order processing device, which can be implemented in hardware and / or software and can be configured in an electronic device. Figure 1 As shown, the method includes:
[0032] Step 101: Upon receiving an order message, write the order message to both the message middleware and the database.
[0033] In this embodiment, message middleware and database can be deployed in the game system. Message middleware is a middleware used for establishing channels and sending data or files in network communication, such as ActiveMQ, RabbitMQ, RocketMQ, Kafka, etc. Databases include relational databases (such as MySQL), distributed databases, etc.
[0034] In practical applications, middleware supports publish / subscribe mechanisms, allowing users to control their virtual characters to order virtual items in the game using in-game currency. In this case, the relevant business components in the game system act as message publishers, generating order messages (i.e., orders recorded in the form of messages). That is, the order message indicates that a virtual character in the game has ordered virtual items, and the order message is published to a specified topic, such as the topic for ordering virtual items.
[0035] Both the message middleware and the database can connect to subscribers of messages for this topic. When an order message for a specified topic is received, considering that the message middleware and the database are independent of each other, the same order message can be written to the message middleware and the database respectively.
[0036] For relational databases such as MySQL, table scanning consumes significant performance. To address this, you can periodically search the table that records order messages in the database, delete order data outside a preset time period (such as the last 3 months), and retain order data within the time period (such as the last 3 months). This keeps the table size at a low level, prevents the table from growing, and reduces the performance consumption of relational databases due to table scanning.
[0037] In addition, the table structure can be indexed by time (especially date) or partitioned by time (especially date), thereby improving the efficiency of querying order messages in the table and reducing the time spent querying order messages in the table.
[0038] Step 102: Consume order messages in the real-time message middleware to write virtual items to virtual characters in the game.
[0039] As the main component for processing order messages, the message middleware can consume order messages in real time, call the service responsible for delivery in the game system, and write virtual items to virtual characters in the game, ensuring the real-time processing of order messages.
[0040] In one embodiment of the present invention, the message middleware is configured with a real-time message queue and a delayed message queue. In this embodiment, step 102 may include the following steps:
[0041] Step 1021: Call the preset first script to consume order messages in the real-time message queue in real time, so as to write virtual items to virtual characters in the game under the condition of locking the order messages.
[0042] When order messages are written to the message middleware, they are initially stored in the real-time message queue, meaning that the order messages in the real-time message queue are in an unprocessed state.
[0043] For real-time message queues, a first script can be pre-built, started, and used to traverse and consume order messages in the real-time message queue in real time. Under the condition of locking the order messages, virtual items can be written to virtual characters in the game.
[0044] Since both the message middleware and the database can consume order messages independently, locking can be implemented based on the identifier of the order message (such as ID) to avoid duplicate consumption of order messages.
[0045] When the first script consumes order messages in the real-time message queue, it determines whether the order message has a lock based on the order message's identifier. If there is no lock, it can lock the order message based on the order message's identifier, call the service responsible for delivery in the game system, and write virtual items to the virtual character in the game. If there is a lock, it can confirm that the order message processing has failed.
[0046] In one embodiment of the present invention, step 1021 may further include the following steps:
[0047] Step 10211: Create multiple partitions in the message middleware.
[0048] Step 10212: Create multiple first processes for the preset first script.
[0049] Step 10213: In each partition, the first process is invoked to consume order messages in the real-time message queue in real time, so as to write virtual items to virtual characters in the game under the condition of locking the order messages.
[0050] Generally, users have high requirements for the real-time processing of orders. Since the order messages in the real-time consumption queue are in an unprocessed state, the timeliness of consuming the order messages in the real-time consumption queue is also high.
[0051] In message queues like Kafka, topics are managed by partitions. One partition is consumed by one subscriber. Therefore, multiple partitions can be created for a topic that orders virtual items in message queues like Kafka. Correspondingly, multiple first processes can be instantiated and created for the first script.
[0052] Because the message middleware mechanism can allocate partitions and first processes, and the first process can be responsible for one or more partitions, the number of partitions and the number of first processes can be the same or different, provided that each partition is consumed by at least one first process.
[0053] In each partition, the first process assigned to that partition can be called to consume order messages in the real-time message queue. Under the condition of locking the order messages, virtual items can be written to virtual characters in the game, so as to achieve concurrent consumption of order messages by the first process, improve the speed of order message processing, and thus improve the real-time performance of order message processing.
[0054] Furthermore, since not too many partitions can be added in the message middleware, multiple first coroutines can be created in the first process to call the first process to read multiple batches of order messages from the real-time message queue according to the offset, where each batch contains multiple order messages.
[0055] Each first coroutine is invoked to execute the same batch of order messages. Under the condition of locking the order messages, virtual items are written to virtual characters in the game, achieving concurrent consumption of order messages within the first process, further improving the speed of order message processing, and thus further improving the real-time performance of order message processing.
[0056] Because order messages are read from multiple batches according to the offset, the offset is committed in advance, ignoring the ACK (Acknowledge character) for each batch. Therefore, order messages may be lost in some cases.
[0057] If it is determined that an order message in a certain batch has been lost during consumption, the lost order message can be recovered according to the offset offer (i.e., reverse offset offer). At this time, the status of the order message is processing failure.
[0058] Step 1022: If the status of the order message in the message consumption middleware is failure, then write the order message to the delayed message queue.
[0059] If the order message status in the message consumption middleware is failed, the order message can be written to the delayed message queue and waited for a retry, that is, the virtual item is rewritten to the virtual character in the game.
[0060] Step 1023: Call the preset second script to delay the consumption of order messages in the delayed message queue, so as to rewrite virtual items to the virtual character in the game under the condition of locking the order messages.
[0061] For delayed message queues, a second script can be pre-built, started, and used to traverse and consume order messages in the real-time delayed message queue. Under the condition of locking the order messages, virtual items can be written to virtual characters in the game.
[0062] Since both the message middleware and the database can consume order messages independently, locking can be implemented based on the identifier of the order message (such as ID) to avoid duplicate consumption of order messages.
[0063] When the second script consumes order messages in the delayed message queue, it determines whether the order message has a lock based on the order message's identifier. If there is no lock, it can lock the order message based on the order message's identifier, call the service responsible for delivery in the game system, and write virtual items to the virtual character in the game. If there is a lock, it can confirm that the order message processing has failed.
[0064] Furthermore, the delayed message queue includes multiple sub-message queues with configured levels. Each sub-message queue is configured with a second script and a delay time. The level and the length of the delay time are positively correlated; that is, the higher the level, the longer the delay time, and vice versa.
[0065] Generally, the delay time should not be too long and should not exceed the message processing time set by the message middleware. If the delay time exceeds the message processing time set by the message middleware, it may cause the message middleware to consider that the subscriber is abnormal.
[0066] When order messages are written to the delayed message queue, they are initially stored in the lowest-level sub-message queue.
[0067] During retries, for each sub-message queue, the second script is invoked to consume the order messages in the current sub-message queue, so that, under the condition of locking the order messages, virtual items are rewritten to the virtual character in the game at intervals of delay.
[0068] If the status of an order message in the message consumption middleware is "processing failed", then the first failure count for the order message can be accumulated.
[0069] In addition, if the status of an order message in the consumption database is "processing failed", this status can be ignored and the first failure count will not be accumulated for the order message.
[0070] If the first number of failures does not reach the preset first upper limit, the order message will be rewritten into the current sub-message queue, waiting for the next retry.
[0071] If the first number of failures reaches the preset first upper limit and the current sub-message queue is not at the highest level, then the order message is rewritten into the next sub-message queue in the direction of level improvement. That is, the level of the next sub-message queue is higher than the level of the current sub-message queue, and a new retry mechanism is attempted.
[0072] If the first failure count reaches the preset first upper limit and the current sub-message queue is at the highest level, then the order message is ignored.
[0073] Since some faults last for a long time, the retry mechanism of the message middleware can be gradually increased to handle long-term fault conditions and improve the success rate of order message processing.
[0074] In one example, the delayed message queue includes three sub-message queues with configured levels. The lowest-level sub-message queue has a delay of 1 minute, the middle-level sub-message queue has a delay of 5 minutes, and the highest-level sub-message queue has a delay of 10 minutes. The first upper limit for each sub-message queue is 3. Order messages in the lowest-level sub-message queue are retried every 1 minute, with a maximum of 3 retries. If the retries exceed 3, the order message is written to the middle-level sub-message queue. Order messages in the middle-level sub-message queue are retried every 3 minutes, with a maximum of 3 retries. If the retries exceed 3, the order message is written to the highest-level sub-message queue. Order messages in the highest-level sub-message queue are retried every 1 minute, with a maximum of 3 retries. If the retries exceed 3, the order message is ignored.
[0075] Step 103: Update the status of the order message in the message middleware to the message middleware and the database.
[0076] The status of order message processing includes successful processing (i.e., successfully writing virtual items to virtual characters in the game) and failed processing (i.e., failing to write virtual items to virtual characters in the game).
[0077] Upon receiving the status of an order message from the message consumption middleware, the status of the order message in the message consumption middleware can be updated to the message middleware and the database, so that the processing method for the order message in the message middleware and the database can be determined according to the status.
[0078] Step 104: If the status is unprocessed or processing failed, delay consuming the order message in the database to write virtual items to the virtual character in the game.
[0079] As a component that assists in processing order messages, the database can delay consuming order messages in the database that are in an unprocessed or failed processing state, call the service responsible for delivery in the game system, and write virtual items to virtual characters in the game to ensure the success rate of order message processing.
[0080] The database persists order messages, which can avoid the problem of order message loss due to queues and ensure the integrity of order message processing.
[0081] Furthermore, delayed consumption means that when the database receives an order message, it does not immediately consume the order message. Instead, it consumes the order message after a certain period of time, based on the time the order message was received (or the time the order message was generated).
[0082] If order messages are consumed from the database in real time, then when an order message is received by both the message middleware and the database at the same time, it will be consumed by both sides, resulting in wasted resources. Therefore, the database does not compete with the message middleware for order messages. The message middleware consumes order messages first (in real time), while the database consumes order messages with a delay. This creates a misalignment in the time of processing order messages, improving resource utilization.
[0083] In one embodiment of the present invention, step 104 may include the following steps:
[0084] Step 1041: Call the preset third script to delay the consumption of order messages in the database that are in an unprocessed state, so as to write virtual items to the virtual character in the game under the condition of locking the order messages.
[0085] When order messages are written to the database, the initial state is unprocessed, meaning that no process calls the game's system service responsible for delivery to write virtual items to virtual characters in the game.
[0086] For order messages with an unprocessed status, a third script can be pre-built, started, and after a delay, query the database for order messages with an unprocessed status. Under the condition of locking the order message, virtual items can be written to the virtual character in the game.
[0087] Since both the message middleware and the database can consume order messages independently, locking can be implemented based on the identifier of the order message (such as ID) to avoid duplicate consumption of order messages.
[0088] When the third script encounters an order message in the consumption database that is in an unprocessed state, it determines whether the order message is locked based on its identifier. If there is no lock, it can lock the order message based on its identifier, call the delivery service in the game system, and write virtual items to the virtual character in the game. If there is a lock, it can confirm that the order message processing has failed.
[0089] In one embodiment of the present invention, step 1041 may further include the following steps:
[0090] Step 10411: Create a second process for the preset third script.
[0091] Step 10412: Call the second process to consume unprocessed order messages in the database for a preset time delay, so as to write virtual items to the virtual character in the game while locking the order messages.
[0092] In this embodiment, a third script can be instantiated and a second process can be created. The second process consumes unprocessed order messages in the database after a preset delay. Under the condition of locking the order messages, virtual items are written to the virtual character in the game.
[0093] The duration of the first delay is longer than the duration of subsequent delays.
[0094] Because of the time misalignment between the database and the message middleware, the consumption of order messages in the database that are in an unprocessed state is delayed by a preset time. The initial delay is relatively long, such as 1 minute. That is, based on the current time, order messages in an unprocessed state from 1 minute ago are retrieved from the database.
[0095] Once an order message with an unprocessed status is retrieved, it is processed, and virtual items are written to the virtual character in the game while the order message is locked.
[0096] If the second process can retrieve order messages with an unprocessed status, it indicates that there has been a delay in processing the order messages. If it exits at this point, the next check will be after the same delay (e.g., 1 minute), and another batch of users' orders will be delayed, which will degrade the user experience. Therefore, the second process will continue to query the database to see if there are any unprocessed order messages. In cases where there is a delay, the duration will be reduced, such as 5 seconds. That is, based on the current time, the database will be retrieved for order messages with an unprocessed status from 5 seconds ago.
[0097] In general, writing virtual items to virtual characters in a game relies on different services in the game system. If order messages are executed sequentially, a delay in the response of a certain order message will cause delays and timeouts. Therefore, multiple second coroutines can be created in the second process to support concurrent processing of order messages.
[0098] Since the second process reads unprocessed order messages in batches and hands them over to the second coroutine for concurrent processing, the previous batch of order messages may still be being processed while the second process is reading the current batch of order messages. Therefore, the first maximum value of the order message number (such as ID) read by the second process in the previous batch is determined.
[0099] The second process is invoked to read a new batch of order messages from the database after a preset delay. These messages are in an unprocessed state and have a number greater than the first maximum value, thus avoiding the repeated reading of the same order messages.
[0100] Each second coroutine is invoked to execute the same batch of order messages. Under the condition of locking the order messages, virtual items are written to the virtual characters in the game, achieving concurrent consumption of order messages within the second process, improving the speed of order message processing, and thus improving the real-time performance of order message processing.
[0101] Step 1042: Call the preset fourth script to delay the consumption of order messages in the database that are in the state of processing failure, so as to rewrite virtual items into the virtual character in the game under the condition of locking the order message.
[0102] After the order message is written to the database, its status may be updated to "processing failed," meaning that at least one process called the service responsible for delivery in the game's system, and the process of writing virtual items to virtual characters in the game failed.
[0103] For order messages with a status of "processing failed", a fourth script can be pre-built, started, and after a delay, query the database for order messages with a status of "processing failed". Under the condition of locking the order message, virtual items are written to the virtual character in the game.
[0104] Since both the message middleware and the database can consume order messages independently, locking can be implemented based on the identifier of the order message (such as ID) to avoid duplicate consumption of order messages.
[0105] When the fourth script encounters an order message in the consumption database that has failed to be processed, it determines whether the order message has a lock based on its identifier. If there is no lock, it can lock the order message based on its identifier, call the service responsible for delivery in the game system, and write virtual items to the virtual character in the game. If there is a lock, it can confirm that the order message processing has failed.
[0106] The third and fourth scripts are independent of each other and are processed in parallel, which can improve the efficiency of processing order messages.
[0107] In one embodiment of the present invention, step 1042 may further include the following steps:
[0108] Step 10421: Determine the second maximum value of the order message number read in the previous batch by the preset fourth script.
[0109] Step 10422: Call the fourth script to read a new batch of order messages from the database within a preset time range. These messages have a status of "processing failed" and an order number greater than the second maximum value.
[0110] Step 10423: Call the fourth script to execute the order message, so as to rewrite the virtual items into the virtual character in the game under the condition of locking the order message.
[0111] In this embodiment, the fourth script queries the database in batches for order messages with a status of processing failure within a preset time range. To avoid repeatedly reading the same order messages, the second maximum value of the order message number (such as ID) read by the fourth script in the previous batch can be determined. Then, a new batch of order messages with a status of processing failure and a number greater than the second maximum value can be read from the database, and these order messages can be executed. Under the condition of locking the order messages, virtual items are rewritten to the virtual character in the game.
[0112] In general, since there may be many order messages with a status of "processing failed", and considering that the timeliness of processing these order messages is not very high, the fourth script will not keep retrying to execute the order messages. Instead of pulling out all order messages that meet the conditions (status of "processing failed" and number greater than the second maximum value), it limits the number of rows by time range.
[0113] Step 10424: If the status of the order message in the message consumption middleware or database is "processing failed", then accumulate the second failure count for the order message.
[0114] For the same order message, if it is stored in both the consumption middleware and the database, regardless of whether the order message status in the consumption middleware or the consumption database is "processing failed", a second failure count can be accumulated for that order message in the database.
[0115] Step 10425: Determine whether the second number of failures has reached the preset second upper limit; if yes, proceed to step 10426; otherwise, return to step 10421.
[0116] Step 10426: Ignore order messages.
[0117] For order messages with a status of "processing failed", a second upper limit can be set, which is the maximum number of retries. During each retry, it is determined whether the second failure count has reached the preset second upper limit.
[0118] If the second failure count reaches the second upper limit, the order message can be ignored. In this case, for the same order message, if the first failure count of the message middleware has not reached the first upper limit, it can continue to retry.
[0119] If the second number of failures does not reach the second maximum value, you can wait for the next retry.
[0120] Furthermore, this second upper limit value is configurable; for example, it can be set as a parameter when the fourth script starts and can be adjusted when the fourth script starts.
[0121] In some cases, a failure in the service responsible for shipping may last for an extended period, and the second failure count may easily reach the second upper limit. Once the service responsible for shipping is restored, the second upper limit can be modified to allow for continued retrying, which facilitates the management of order message processing.
[0122] Step 105: Update the status of the order messages in the consumption database to the message middleware and the database.
[0123] The status of order message processing includes successful processing (i.e., successfully writing virtual items to virtual characters in the game) and failed processing (i.e., failing to write virtual items to virtual characters in the game).
[0124] Upon receiving the status of an order message from the consumer database, the status of the order message in the consumer database can be updated to the message middleware and the database, so that the processing method for the order message in the message middleware and the database can be determined according to the status.
[0125] In this embodiment, upon receiving an order message, the message is written to both the message middleware and the database. The order message indicates that a virtual character in the game has ordered virtual items. The message middleware is consumed in real-time to write the virtual items to the virtual character in the game. The status of the consumed order message is updated in both the message middleware and the database. If the status is "unprocessed" or "processed failed," the consumption of the order message in the database is delayed to write the virtual items to the virtual character in the game. The status of the consumed order message in the database is then updated in both the message middleware and the database. This embodiment primarily uses the message middleware and secondarily uses the database to process order messages. The two processes are staggered in time and work together to avoid duplicate consumption of order messages, improving the efficiency of order message processing. The database persists the order messages, preventing message loss and reducing the number of retries and processing latency.
[0126] Example 2
[0127] Figure 2 This is a schematic diagram of a game order processing device provided in Embodiment 2 of the present invention. Figure 2 As shown, the device includes:
[0128] The order message storage module 201 is used to write the order message into the message middleware and the database respectively when an order message is received. The order message indicates that a virtual character in the game has ordered virtual items.
[0129] The middleware consumption module 202 is used to consume the order message in the message middleware in real time, so as to write the virtual item to the virtual character in the game;
[0130] The first state synchronization module 203 is used to update the status of the order message consumed in the message middleware to the message middleware and the database;
[0131] The database consumption module 204 is used to delay consuming the order message in the database if the status is unprocessed or processing failed, so as to write the virtual item to the virtual character in the game;
[0132] The second state synchronization module 205 is used to update the status of the order message consumed from the database to the message middleware and the database.
[0133] In one embodiment of the present invention, the message middleware is configured with a real-time message queue and a delayed message queue, and the order message is initially stored in the real-time message queue when it is written to the message middleware;
[0134] The middleware consumption module 202 includes:
[0135] The first script consumption module is used to call a preset first script to consume the order messages in the real-time message queue in real time, so as to write the virtual items to the virtual character in the game under the condition that the order messages are locked;
[0136] The delayed message queue writing module is used to write the order message into the delayed message queue if the status of consuming the order message in the message middleware is failure.
[0137] The second script consumption module is used to call a preset second script to delay the consumption of the order message in the delayed message queue, so as to rewrite the virtual item to the virtual character in the game under the condition that the order message is locked.
[0138] In one embodiment of the present invention, the first script consumption module includes:
[0139] A partition creation module is used to create multiple partitions in the message middleware;
[0140] The first process creation module is used to create multiple first processes from a preset first script.
[0141] The first process consumption module is used to call the first process in each of the partitions to consume the order messages in the real-time message queue in real time, so as to write the virtual items to the virtual character in the game under the condition of locking the order messages.
[0142] In one embodiment of the present invention, the first process consumption module includes:
[0143] The first coroutine creation module is used to create multiple first coroutines in the first process;
[0144] The displacement reading module is used to call the first process to read multiple batches of the order messages from the real-time message queue according to the displacement in real time, with each batch containing multiple order messages;
[0145] The first coroutine consumption module is used to call each of the first coroutines to execute the same batch of order messages, so as to write the virtual items to the virtual character in the game under the condition of locking the order messages.
[0146] In one embodiment of the present invention, the first process consumption module further includes:
[0147] The loss determination module is used to determine whether the order messages in a certain batch have been lost during the consumption process;
[0148] The displacement recovery module is used to recover the lost order message according to the displacement.
[0149] In one embodiment of the present invention, the delayed message queue includes multiple sub-message queues with configured levels. Each sub-message queue is configured with a second script and a delay time. The level is positively correlated with the length of the delay time. When the order message is written to the delayed message queue, it is initially stored in the sub-message queue with the lowest level.
[0150] The second script consumption module includes:
[0151] The sub-message queue consumption module is used to call the second script to consume the order message in the current sub-message queue for each of the sub-message queues, so as to rewrite the virtual item to the virtual character in the game at each interval of the delay time while locking the order message;
[0152] The first failure count accumulation module is used to accumulate the first failure count for the order message if the status of the order message consumed in the message middleware is processing failure;
[0153] The sub-message queue writing module is used to rewrite the order message into the current sub-message queue if the first number of failures has not reached a preset first upper limit value.
[0154] The sub-message queue modification module is used to rewrite the order message into the next sub-message queue in the direction of upgrading the level if the first failure count reaches a preset first upper limit value and the current level of the sub-message queue is not the highest level.
[0155] The first order message ignoring module is used to ignore the order message if the first number of failures reaches a preset first upper limit and the current sub-message queue is at the highest level.
[0156] In one embodiment of the present invention, the database consumption module 204 includes:
[0157] The third script consumption module is used to call a preset third script to delay the consumption of the order messages in the database that are in an unprocessed state, so as to write the virtual items to the virtual character in the game under the condition that the order messages are locked;
[0158] The fourth script consumption module is used to call a preset fourth script to delay the consumption of the order messages in the database that are in a processing failure state, so as to rewrite the virtual items into the virtual character in the game under the condition that the order messages are locked.
[0159] In one embodiment of the present invention, the third script consumption module includes:
[0160] The second process creation module is used to create a second process from a preset third script;
[0161] The delayed consumption module is used to call the second process to consume the order messages in the database that are in an unprocessed state for a preset time, so as to write the virtual items to the virtual character in the game under the condition that the order messages are locked, wherein the duration of the first delay is longer than the duration of subsequent delays.
[0162] In one embodiment of the present invention, the delayed consumption module includes:
[0163] The second coroutine creation module is used to create multiple second coroutines in the second process;
[0164] The first number determination module is used to determine the first maximum value of the number of the order message read by the second process in the previous batch;
[0165] The first batch reading module is used to call the second process to read a new batch of order messages from the database that are in an unprocessed state and whose numbers are greater than the first maximum value after a preset delay.
[0166] The second coroutine consumption module is used to call each of the second coroutines to execute the order message, so as to write the virtual item to the virtual character in the game under the condition that the order message is locked.
[0167] In one embodiment of the present invention, the fourth script consumption module includes:
[0168] The second number determination module is used to determine the second maximum value of the number of the order message read in the previous batch by the preset fourth script;
[0169] The second batch reading module is used to call the fourth script to read a new batch of order messages from the database within a preset time range. These messages have a status of processing failure and a number greater than the second maximum value.
[0170] The batch consumption module is used to call the fourth script to execute the order message, so as to rewrite the virtual item to the virtual character in the game under the condition that the order message is locked;
[0171] The second failure count accumulation module is used to accumulate a second failure count for the order message if the status of consuming the message middleware or the order message in the database is a processing failure.
[0172] The upper limit determination module is used to determine whether the second failure count has reached the preset second upper limit value; if yes, the second order message ignore module is executed; if no, the execution returns to the second number determination module.
[0173] The first order message ignore module is used to ignore the order message.
[0174] In one embodiment of the present invention, it further includes:
[0175] The table lookup module is used to search the database for a table that records the order message, the table being indexed or partitioned by time;
[0176] The order data deletion module is used to delete order data outside a preset time period from the table.
[0177] The game order processing device provided in this embodiment of the invention can execute the game order processing method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects for executing the game order processing method.
[0178] Example 3
[0179] Figure 3A schematic diagram of an electronic device 10 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.
[0180] like Figure 3 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.
[0181] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.
[0182] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as the game order processing method.
[0183] In some embodiments, the game order processing method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the game order processing method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform the game order processing method by any other suitable means (e.g., by means of firmware).
[0184] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.
[0185] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.
[0186] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.
[0187] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).
[0188] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.
[0189] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.
[0190] Example 4
[0191] This invention also provides a computer program product, which includes a computer program that, when executed by a processor, implements the game order processing method provided in any embodiment of this invention.
[0192] In implementing the computer program product, computer program code for performing the operations of this invention can be written in one or more programming languages or a combination thereof. Programming languages include object-oriented programming languages such as Java, Smalltalk, and C++, as well as conventional procedural programming languages such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).
[0193] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.
[0194] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.
Claims
1. A method of processing a game order, characterized by, include: Upon receiving an order message, the order message is written to both the message middleware and the database. The order message indicates that a virtual character in the game has ordered virtual items. The order message in the message middleware is consumed in real time to write the virtual item to the virtual character in the game; Update the status of the order message consumed from the message middleware to the message middleware and the database; If the status is unprocessed or processing failed, the order message in the database is consumed with a delay in order to write the virtual item to the virtual character in the game; Update the status of the order messages consumed from the database to the message middleware and the database; The message middleware is configured with a real-time message queue and a delayed message queue. When an order message is written to the message middleware, it is initially stored in the real-time message queue. The delayed message queue includes multiple sub-message queues with configured levels. Each sub-message queue is configured with a second script and a delay time. The level is positively correlated with the length of the delay time. The delay time does not exceed the message processing time set by the message middleware. When an order message is written to the delayed message queue, it is initially stored in the sub-message queue with the lowest level. The real-time consumption of the order message in the message middleware to write the virtual item to the virtual character in the game includes: The system calls a preset first script to consume the order messages in the real-time message queue in real time, and writes the virtual items to the virtual character in the game while locking the order messages; If the status of consuming the order message in the message middleware is failed, the order message is written to the delayed message queue and waits for a retry. For each of the sub-message queues, the second script is invoked to consume the order message in the current sub-message queue, so that, under the condition of locking the order message, the virtual item is rewritten to the virtual character in the game at each delay interval; If the status of the order message in the message middleware is "processing failed", then the first failure count is accumulated for the order message; If the first number of failures does not reach the preset first upper limit, the order message will be rewritten into the current sub-message queue. If the first number of failures reaches a preset first upper limit and the current level of the sub-message queue is not the highest level, then the order message is rewritten into the next sub-message queue in the direction of increasing the level. If the first number of failures reaches a preset first upper limit and the current sub-message queue is at the highest level, then the order message is ignored.
2. The method of claim 1, wherein, The step of calling a preset first script to consume the order messages in the real-time message queue in real time, and writing the virtual items to the virtual character in the game under the condition that the order messages are locked, includes: Create multiple partitions in the message middleware; Multiple first processes are created for the preset first script; In each of the partitions, the first process is invoked to consume the order messages in the real-time message queue in real time, so as to write the virtual items to the virtual character in the game under the condition that the order messages are locked.
3. The method of claim 2, wherein, In each of the partitions, the first process is invoked to consume the order messages in the real-time message queue in real time, so as to write the virtual items to the virtual character in the game under the condition that the order messages are locked, including: Create multiple first coroutines in the first process; The first process is invoked to read multiple batches of order messages from the real-time message queue in real time according to the offset, with each batch containing multiple order messages; Each of the first coroutines is invoked to execute the same batch of order messages, so as to write the virtual items to the virtual character in the game under the condition that the order messages are locked.
4. The method of claim 3, wherein, The step of calling the first process in each of the partitions to consume the order messages in the real-time message queue in real time, so as to write the virtual items to the virtual character in the game under the condition of locking the order messages, further includes: It was determined that the order message in a certain batch was lost during consumption; The lost order message is recovered according to the displacement.
5. The method of claim 1, wherein, The delayed consumption of the order message in the database to write the virtual item to the virtual character in the game includes: A preset third script is invoked to delay the consumption of the order messages in the database that are in an unprocessed state, so as to write the virtual items to the virtual character in the game under the condition that the order messages are locked; The preset fourth script is invoked to delay the consumption of the order message in the database that is in the state of processing failure, so as to rewrite the virtual item into the virtual character in the game under the condition that the order message is locked.
6. The method of claim 5, wherein, The step of calling a preset third script to delay consuming the order messages in the database that are currently in an unprocessed state, in order to write the virtual items to the virtual character in the game while the order messages are locked, includes: Create a second process for the pre-defined third script; The second process is invoked to consume the order messages in the database that are in an unprocessed state for a preset time delay, so as to write the virtual items to the virtual character in the game under the condition that the order messages are locked, wherein the duration of the first delay is longer than the duration of subsequent delays.
7. The method of claim 6, wherein, The step of calling the second process to consume the order messages in the database that are in an unprocessed state after a preset delay, and then writing the virtual items to the virtual character in the game while the order messages are locked, includes: Multiple second coroutines are created within the second process; Determine the first maximum value of the order message number read by the second process in the previous batch; The second process is invoked to read a new batch of order messages from the database that are in an unprocessed state and whose numbers are greater than the first maximum value after a preset delay. Each of the second coroutines is invoked to execute the order message, so as to write the virtual item to the virtual character in the game under the condition that the order message is locked.
8. The method according to claim 5, characterized in that, The step of calling a preset fourth script to delay consuming the order message in the database that is in a processing failed state, in order to rewrite the virtual item into the virtual character in the game under the condition that the order message is locked, includes: Determine the second maximum value of the order message number read in the previous batch by the preset fourth script; The fourth script is invoked to read a new batch of order messages from the database within a preset time range. These messages have a status of "processing failed" and a number greater than the second maximum value. The fourth script is invoked to execute the order message, so as to rewrite the virtual item into the virtual character in the game under the condition that the order message is locked; If the status of consuming the message middleware or the order message in the database is "processing failed", then the second failure count is accumulated for the order message; Determine whether the second failure count has reached a preset second upper limit; if yes, ignore the order message; if no, return to execute the second maximum value of the order message number read in the previous batch by the fourth script.
9. The method according to any one of claims 1-8, characterized in that, Also includes: Search the database for a table that records the order messages, the table being indexed or partitioned by time; Delete the order messages outside the preset time period from the table.
10. A game order processing apparatus characterized by comprising: include: The order message storage module is used to write the order message into the message middleware and the database respectively when an order message is received. The order message indicates that a virtual character in the game has ordered virtual items. The middleware consumption module is used to consume the order messages in the message middleware in real time, so as to write the virtual items to the virtual character in the game; The first state synchronization module is used to update the state of the order message consumed from the message middleware to the message middleware and the database. The database consumption module is used to delay consuming the order message in the database if the status is unprocessed or processing failed, so as to write the virtual item to the virtual character in the game; The second state synchronization module is used to update the status of the order message consumed from the database to the message middleware and the database. The message middleware is configured with a real-time message queue and a delayed message queue. When an order message is written to the message middleware, it is initially stored in the real-time message queue. The delayed message queue includes multiple sub-message queues with configured levels. Each sub-message queue is configured with a second script and a delay time. The level is positively correlated with the length of the delay time. The delay time does not exceed the message processing time set by the message middleware. When an order message is written to the delayed message queue, it is initially stored in the sub-message queue with the lowest level. The middleware consumption module includes: The first script consumption module is used to call a preset first script to consume the order messages in the real-time message queue in real time, so as to write the virtual items to the virtual character in the game under the condition that the order messages are locked; The delayed message queue writing module is used to write the order message into the delayed message queue if the status of consuming the order message in the message middleware is failed, and wait for retry; The sub-message queue consumption module is used to call the second script to consume the order message in the current sub-message queue for each of the sub-message queues, so as to rewrite the virtual item to the virtual character in the game at each interval of the delay time while locking the order message; The first failure count accumulation module is used to accumulate the first failure count for the order message if the status of the order message consumed in the message middleware is processing failure; The sub-message queue writing module is used to rewrite the order message into the current sub-message queue if the first number of failures has not reached a preset first upper limit value. The sub-message queue modification module is used to rewrite the order message into the next sub-message queue in the direction of upgrading the level if the first failure count reaches a preset first upper limit value and the current level of the sub-message queue is not the highest level. The first order message ignoring module is used to ignore the order message if the first number of failures reaches a preset first upper limit and the current sub-message queue is at the highest level.
11. An electronic device, comprising: The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the game order processing method according to any one of claims 1-9.
12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method for processing game orders as described in any one of claims 1-9.