Game server scheduling method and device and electronic device

Abstract

This application provides a game server scheduling method, apparatus, and electronic device. The method includes: responding to a microservice request received during the main game loop's processing of the current logical frame; predicting the remaining frame time of the current logical frame and the expected response latency of the microservice request; the remaining frame time refers to the available processing time not yet consumed within the processing cycle of the current logical frame; the expected response latency refers to the time elapsed from the initiation of the microservice request to its completion; selecting a target scheduling strategy from multiple preset scheduling strategies based on the relative relationship between the remaining frame time of the current logical frame and the expected response latency of the microservice request; and allocating a target thread to process the microservice request according to the target scheduling strategy, so that the target thread can process the microservice request. This application solves the technical problem of game "frame skipping" or "stuttering" caused by asynchronous requests from non-core microservices blocking the main game loop.

Description

Technical Field

[0001] This application relates to the fields of computer science and technology, and more specifically, to a game server scheduling method, apparatus, and electronic device. Background Technology

[0002] In a distributed game server architecture, the game logic server operates under strict constraints of the main game loop, meaning it must complete real-time calculations such as combat and movement within a tight frame budget (e.g., 33.3ms). Occasional network jitter or processing latency in non-core microservices (such as social, achievement, and logging) can cause synchronization blockages in the main game loop (e.g., combat calculations, movement synchronization), leading to "frame skipping" or "stuttering" issues within the game. Summary of the Invention

[0003] This application provides a game server scheduling method, apparatus, and electronic device to at least solve the technical problem in the related art where the game's main loop is blocked by asynchronous requests from non-core microservices, causing the game to "skip frames" or "lag".

[0004] According to one aspect of the embodiments of this application, a game server scheduling method is provided, comprising: responding to receiving a microservice request during the processing of a current logical frame in the main loop of a game, predicting the remaining frame time of the current logical frame, and predicting the expected response latency of the microservice request; wherein the remaining frame time refers to the available processing time that has not yet been consumed within the processing cycle of the current logical frame; and the expected response latency refers to the time taken from the initiation of the microservice request to its completion; selecting a target scheduling strategy from a plurality of preset scheduling strategies based on the relative relationship between the remaining frame time of the current logical frame and the expected response latency of the microservice request; and allocating a target thread to process the microservice request according to the target scheduling strategy, so that the target thread processes the microservice request.

[0005] According to another aspect of the embodiments of this application, a game server scheduling apparatus is also provided, comprising: a prediction module, configured to, in response to receiving a microservice request during the processing of a current logical frame in the game's main loop, predict the remaining frame time of the current logical frame and predict the expected response latency of the microservice request; the remaining frame time refers to the available processing time that has not yet been consumed within the processing cycle of the current logical frame; the expected response latency refers to the time taken from the initiation of the microservice request to its return completion; a selection module, configured to select a target scheduling strategy from a plurality of preset scheduling strategies based on the relative relationship between the remaining frame time of the current logical frame and the expected response latency of the microservice request; and a response module, configured to allocate a target thread for processing the microservice request according to the target scheduling strategy, so that the target thread processes the microservice request.

[0006] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, wherein a computer program is stored therein, wherein the computer program is configured to perform the steps in any of the above method embodiments when executed by a processor.

[0007] According to another aspect of the embodiments of this application, a computer program product or computer program is provided, the computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, causing the computer device to perform the steps in any of the method embodiments described above.

[0008] According to another aspect of the embodiments of this application, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to perform the steps of any of the above method embodiments through the computer program.

[0009] This application enables real-time monitoring of the remaining frame time of the current logical frame, allowing the game's main loop to accurately understand the processing capacity of the current logical frame and provide an accurate basis for scheduling decisions. By predicting the expected response latency of microservice requests, the game's main loop can assess the processing time of microservice requests in advance, avoiding blocking of the game's main loop due to excessive microservice request delays. By dynamically selecting a target scheduling strategy based on the relative relationship between the remaining frame time and the expected response latency, and allocating target threads to microservice requests according to the target scheduling strategy, the logical path can be adaptively and dynamically adjusted. This maximizes the utilization of the remaining frame time while ensuring the correctness of the game logic, improving processing efficiency and preventing frame timeouts caused by blocking of the game's main loop due to microservice requests. It solves the technical problem of game "frame skipping" or "stuttering" caused by asynchronous requests from non-core microservices blocking the game's main loop in related technologies. Through flexible switching of multiple preset scheduling strategies, the game's main loop can adapt to different network conditions and microservice loads, improving the robustness and stability of the system. It can eliminate more than 90% of the instantaneous stuttering caused by network jitter, improving players' online time and competitive experience. Attached Figure Description

[0010] Figure 1 This is a schematic diagram illustrating an application scenario of a game server scheduling method according to an embodiment of this application;

[0011] Figure 2 This is a flowchart illustrating an optional game server scheduling method according to an embodiment of this application;

[0012] Figure 3This is a structural diagram of an optional distributed game server architecture according to an embodiment of this application;

[0013] Figure 4 This is a flowchart of another optional dynamic adjustment target scheduling strategy according to an embodiment of this application;

[0014] Figure 5 This is an execution timing diagram of another optional third scheduling strategy according to an embodiment of this application;

[0015] Figure 6 This is a structural block diagram of another optional game server scheduling device according to an embodiment of this application;

[0016] Figure 7 This is a computer system architecture block diagram of an optional electronic device according to an embodiment of this application. Detailed Implementation

[0017] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0018] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application 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 this application 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 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.

[0019] According to one aspect of the embodiments of this application, a game server scheduling method is provided. Optionally, in this embodiment, the above-described game server scheduling method may be applied to, but is not limited to, [examples of applications]. Figure 1The hardware environment shown includes terminal device 102 and server 104. Server 104 can be connected to terminal device 102 via a network and can be used to provide services (e.g., application services, etc.) to terminal device 102 or clients installed on terminal device 102. A database can be set up on server 104 or independently of server 104 to provide data storage services for server 104.

[0020] The aforementioned network may include, but is not limited to, at least one of the following: wired network and wireless network. The aforementioned wired network may include, but is not limited to, at least one of the following: wide area network (WAN), metropolitan area network (MAN), and local area network (LAN). The aforementioned wireless network may include, but is not limited to, at least one of the following: Wireless Fidelity (WIFI) and Bluetooth. Terminal device 102 may be, but is not limited to, a personal computer (PC), mobile phone, tablet computer, etc. Server 104 may be, but is not limited to, a cloud server, server cluster, or other server types.

[0021] The game server scheduling method of this application embodiment can be executed by server 104, by terminal device 102, or by both server 104 and terminal device 102. Alternatively, the game server scheduling method of this application embodiment can be executed by a client installed on the terminal device 102.

[0022] Taking the game server scheduling method in this embodiment as an example, which is executed by server 104, Figure 2 This is a flowchart illustrating an optional game server scheduling method according to an embodiment of this application, as shown below. Figure 2 As shown, the process of this method may include the following steps:

[0023] Step S202: In response to receiving a microservice request during the main game loop's processing of the current logical frame, predict the remaining frame time of the current logical frame and predict the expected response latency of the microservice request; the remaining frame time refers to the available processing time that has not yet been consumed within the processing cycle of the current logical frame; the expected response latency refers to the time taken from the initiation of the microservice request to its return completion.

[0024] Step S204: Select a target scheduling strategy from multiple preset scheduling strategies based on the relative relationship between the remaining frame time of the current logical frame and the expected response latency of the microservice request.

[0025] Step S206: Assign a target thread to handle the microservice request according to the target scheduling strategy, so that the target thread can handle the microservice request.

[0026] The game server scheduling method in this embodiment can be applied to the fields of computer science and technology, specifically involving real-time task scheduling, microservice collaborative optimization, and distributed data consistency in large-scale online game server clusters. It is applied to scenarios where game logic servers and microservices work collaboratively in a distributed game server architecture. Here, the game logic server refers to a distributed service node responsible for executing the core business logic of the game, running on the server side, and independently handling player interaction, state calculation, and game rule determination (such as battle settlement, displacement synchronization, skill activation, item consumption, etc.).

[0027] In distributed game server clusters, logical scheduling and data consistency are core technologies for ensuring high system availability and real-time player interaction. Due to the highly time-sensitive and interactive nature of game services (such as skill judgment, position synchronization, and asset deduction), traditional microservice calling methods must balance real-time response, deterministic state, and system resilience. In a distributed game server architecture, the game logic server operates under strict constraints of the main game loop, meaning it must complete real-time calculations such as combat and movement within a strict frame budget (e.g., 33.3ms). Occasional network jitter or processing delays in non-core microservices (such as social, achievements, and logs) can cause synchronous blocking in the main game loop (such as combat calculations and movement synchronization), leading to "frame skipping" or "stuttering" issues within the game. Existing technologies mainly include synchronous blocking calls, hard-coded asynchronous processing, and flow control based on general-purpose circuit breakers. These methods differ significantly in terms of development cost, operational efficiency, and logical security as follows:

[0028] Synchronous blocking calls are relatively simple: after the logic server initiates a microservice request, it suspends the current execution flow until it receives a return result before continuing to the next process. Its implementation logic is intuitive, requiring no handling of complex asynchronous states and ensuring strong data consistency. However, in a distributed environment, if downstream services (such as social or logging services) experience occasional network fluctuations or processing delays, it can cause unpredictable blocking in the main logic thread, directly exceeding the game's frame budget and resulting in momentary lag spikes perceived by all players, severely impacting competitive fairness.

[0029] Hard-coded asynchronous processing technology involves programmers manually breaking down non-core logic into asynchronous callbacks or sending it to a message queue (MQ) for execution during the development phase. This approach achieves logic decoupling, eliminating the need for the main thread to wait for I / O returns and significantly improving system throughput. However, in high-concurrency scenarios, the uncontrollability of the asynchronous return order can easily lead to race conditions. Furthermore, due to the lack of a robust state backtracking mechanism, when data is returned late, the player's memory state may have already changed, resulting in serious logical vulnerabilities (such as data overwriting, duplicate item distribution, etc.). Moreover, maintenance costs increase exponentially with business complexity.

[0030] Flow control based on general-purpose circuit breakers utilizes third-party components such as Hystrix and Sentinel to dynamically trigger circuit breakers based on request error rates or average latency. This approach possesses basic self-healing capabilities, preventing fault propagation. However, general-purpose circuit breakers often rely on sliding time windows for statistical analysis, lacking awareness of the precision of game "logical frames" and unable to predict "imminent" frame skipping within millisecond-level budgets. Furthermore, degradation strategies are often "one-size-fits-all," failing to provide fine-grained path routing based on the player's current combat context semantics.

[0031] In summary, while synchronous blocking calls are simple to implement, any delay in the microservice will directly block the main game loop, causing frame timeouts; hard-coded asynchronous processing requires developers to manually write asynchronous callback logic for each interface, which is costly and error-prone; while flow control based on general circuit breakers can fail quickly when the service is abnormal, it lacks fine-grained management of frame budget and cannot dynamically adjust the scheduling strategy based on the remaining time of the current frame.

[0032] To at least partially solve the technical problem of game "frame skipping" or "stuttering" caused by asynchronous requests from non-core microservices blocking the main game loop, this embodiment predicts the remaining frame time of the current logical frame and the expected response latency of microservice requests in real time. Based on the relative relationship between the two, a target scheduling strategy is dynamically selected from multiple preset scheduling strategies to achieve adaptive dynamic adjustment of the logical path. Target threads are allocated to microservice requests according to the target scheduling strategy to achieve adaptive dynamic adjustment of the logical path, thereby avoiding frame timeouts caused by microservice requests blocking the main game loop.

[0033] The game's main loop refers to the loop processing mechanism within the game server responsible for executing the core game logic. This mechanism continuously executes at fixed time intervals (typically 16.7ms corresponding to 60 frames per second, or 33.3ms corresponding to 30 frames per second), with each loop cycle called a logic frame. Within each logic frame, the game's main loop needs to complete a series of core logical operations, including player input processing, game state updates, physics calculations, collision detection, AI decision-making, and network synchronization, ensuring the continuity and consistency of the game world. The game's main loop typically runs on the main thread of the game logic server and is the most crucial execution unit of the game server; its performance and stability directly determine the overall service quality of the game server. The game's main loop has strict real-time requirements; it must complete all logical calculations within the preset frame period. Otherwise, it will cause game stuttering, increased latency, or logical errors, severely impacting the player's gaming experience.

[0034] The current logical frame refers to the logical frame that the game's main loop is currently processing; that is, the loop in which the main loop is executing at a given moment. The processing cycle of the current logical frame refers to the preset fixed time limit allocated by the game's main loop within the game logic server for processing a single logical frame, usually measured in milliseconds (ms), such as 16.7ms (60 FPS), 33.3ms (30 FPS), etc. The processing cycle of the current logical frame is determined by the preset frame cycle limit; for example, for a game with 30 frames per second, the frame cycle limit is 33.3ms. During the processing of the current logical frame, the game's main loop needs to execute various logical operations in a predetermined order, including processing player input, updating the game state, performing physics calculations, performing collision detection, running AI logic, and synchronizing network states. The current logical frame is the basic unit of execution in the game's main loop; the processing of each frame must be completed within the frame cycle limit, otherwise a frame timeout will occur, leading to game stuttering or frame skipping.

[0035] A microservice request is a remote call request initiated by a logic script (such as a player object or another service process) to a microservice in a distributed game server architecture while the main game loop is processing the current logic frame. Microservice requests are typically used to invoke non-core business logic, such as social services (friend relationships, chat messages, guild management), achievement services (achievement unlocking, task progress, reward distribution), logging services (game behavior recording, data analysis, anomaly monitoring), and payment services (item purchase, recharge, refund). Microservice requests are sent from the main game loop to the target service via network transmission protocols (such as Remote Procedure Call (RPC), Hypertext Transfer Protocol (HTTP), etc.), and the target service processes the request and returns the response to the main game loop. The processing time of a microservice request is affected by various factors, including network latency, microservice load, microservice processing capacity, and data query efficiency; therefore, the response latency of a microservice request is uncertain and fluctuates. If the response latency of a microservice request is too long, it will block the execution of the main game loop, causing the processing time of the current logic frame to exceed the frame period limit, thus causing game stuttering or frame skipping issues.

[0036] To address the technical issue of game "frame skipping" or "lag" caused by asynchronous requests from non-core microservices blocking the main game loop, this embodiment dynamically selects a target scheduling strategy based on the relative relationship between the remaining frame time of the current logical frame and the expected response latency of microservice requests. Target threads are then allocated to microservice requests according to the target scheduling strategy, achieving adaptive dynamic adjustment of the logical path. By predicting frame budget and implementing adaptive traffic distribution, the request latency for real-time services is significantly reduced. This strategy of "prioritizing core logic" ensures immediate response to game operations, eliminates the lag caused by microservice jitter, and thus avoids frame timeouts in the main game loop due to microservice request blocking.

[0037] The remaining frame time refers to the available processing time within the current logical frame's processing cycle that has not yet been consumed; it is the time difference between the current processing moment and the upper limit of the current logical frame's frame cycle. The remaining frame time reflects how much time the current logical frame has left to process the remaining logical operations, and is an important indicator of the current logical frame's processing capacity. A larger remaining frame time value indicates that the current logical frame has sufficient time to process subsequent operations; a smaller remaining frame time value indicates that the current logical frame is about to end, and the remaining processing time is limited. By monitoring the remaining frame time in real time, the game's main loop can dynamically adjust its scheduling strategy to ensure that all necessary logical operations are completed within the upper limit of the frame cycle.

[0038] Expected response latency refers to the time elapsed from the initiation of a microservice request to its completion. Specifically, it's the time from when the game's main loop sends the microservice request to when the main loop receives the response. Expected response latency is a prediction of the microservice request processing time made by the game's main loop before making scheduling decisions. It's used to assess whether the microservice request will complete within the remaining time of the current logical frame. Expected response latency can be obtained by averaging the historical response latencies of multiple historical requests of the same type as the microservice request, or by using more complex prediction algorithms (such as weighted averaging, exponential smoothing, machine learning, etc.).

[0039] For example, the game's main loop retrieves the historical response latency of multiple historical requests of the same type as the microservice request. A sliding window exponential smoothing algorithm is then used to weight these historical response latencies to obtain the expected response latency of the microservice request. Alternatively, the game's main loop retrieves multiple feature parameters related to the type of microservice request, including historical average response latency, current network round-trip time, the current load rate of the target microservice, the data size of the microservice request, and the priority of the microservice request. These feature parameters are then input into a pre-trained machine learning model, which outputs the expected response latency of the microservice request.

[0040] The relative relationship between the remaining time of the current logical frame and the expected response latency of the microservice request refers to the numerical comparison between the remaining frame time and the expected response latency. It is used to assess whether the microservice request can be processed within the remaining time of the current logical frame. For example, the relative relationship includes the following cases: First, the remaining frame time is greater than or equal to the expected response latency. This means that the current logical frame has sufficient time to accommodate the expected processing time of the microservice request, and the game's main loop can choose to synchronously wait for the response result of the microservice request without causing a frame timeout. Second, the remaining frame time is less than the expected response latency. This means that the remaining time of the current logical frame is insufficient to accommodate the expected processing time of the microservice request. Choosing to wait synchronously will cause a frame timeout, requiring a bypass or asynchronous strategy. Third, the target service called by the microservice request is unreachable. This means that the target microservice has failed or experienced a network interruption and cannot respond to the request normally. A bypass strategy must be chosen to use locally cached data for the response.

[0041] Multiple preset scheduling strategies refer to various microservice request scheduling strategies pre-configured in the game's main loop. Each preset scheduling strategy corresponds to a different execution path and processing method. These strategies provide the game's main loop with flexible scheduling options. The main loop can select the most suitable target scheduling strategy from among these preset strategies based on the relative relationship between the remaining frame time of the current logical frame and the expected response latency of the microservice request. This maximizes the utilization of the remaining frame time and improves the processing efficiency of the main loop while ensuring the correctness of the game logic. Each preset scheduling strategy corresponds to a specific relationship between the remaining frame time of the current logical frame and the expected response latency of the microservice request. For example, when the remaining frame time is greater than or equal to the expected response latency, the corresponding preset scheduling strategy can be a priority preemption strategy. That is, the game's main loop dynamically adjusts the processing order of microservice requests based on the priority of the microservice requests and the remaining frame time of the current logical frame. High-priority microservice requests can preempt the processing resources of low-priority microservice requests, ensuring that critical business logic is executed first. When the remaining frame time is less than the expected response latency, the corresponding preset scheduling strategy can be a fragmented processing strategy. That is, the game's main loop splits the microservice request into multiple small processing fragments, processes some fragments in the current logical frame, and delays the remaining fragments to subsequent logical frames, avoiding a single microservice request occupying too much of the remaining frame time. When the target service called by the microservice request is unreachable, the corresponding preset scheduling strategy can be a retry and fallback strategy. That is, the game's main loop submits the microservice request to a retry queue and uses an exponential backoff algorithm to attempt multiple retries. The interval between each retry increases exponentially. After a preset number of failed retries, historical data is retrieved from the local cache as the response result.

[0042] The target scheduling strategy refers to the scheduling strategy selected by the game's main loop from multiple preset scheduling strategies to handle the current microservice request. The selection of the target scheduling strategy is based on the relative relationship between the remaining frame time of the current logical frame and the expected response latency of the microservice request. By comparing the magnitudes of the remaining frame time and the expected response latency, the most suitable scheduling strategy for the current situation is determined. By flexibly adjusting the scheduling strategy according to real-time conditions, the game's main loop can maximize the utilization of the remaining frame time while ensuring the correctness of the game logic, thereby improving the processing efficiency and stability of the game's main loop.

[0043] A target thread is a processing thread allocated by the game's main loop to microservice requests according to a target scheduling strategy. It executes the specific processing logic for these requests. The target thread can be the main thread of the game's main loop itself, a worker thread in the game's main loop's worker thread pool, or the thread containing the microservice. The choice of target thread depends on the type of target scheduling strategy. For example, when the target scheduling strategy is a priority preemption strategy, the target thread is the main thread of the game's main loop. The game's main loop dynamically adjusts the processing order of microservice requests based on their priority. High-priority microservice requests can preempt the processing resources of low-priority microservice requests, ensuring that critical business logic is executed first. When the target scheduling strategy is a sharding strategy, the target thread is a worker thread in the game's main loop's worker thread pool. The game's main loop splits microservice requests into multiple small processing shards. Within the current logic frame, a worker thread processes some shards, while the remaining shards are deferred to subsequent logic frames. When the target scheduling strategy is a retry and rollback strategy, the target thread is a dedicated retry thread. The game's main loop submits microservice requests to a retry queue, and the retry thread uses an exponential backoff algorithm to attempt multiple retries. The interval between each retry increases exponentially. After a preset number of failed retries, historical data is retrieved from the local cache as the response result.

[0044] Figure 3 A structural diagram of a distributed game server architecture provided in this application embodiment is shown below. Figure 3As shown, the distributed game server architecture includes a game logic layer, an interceptor layer, a logical frame budget-aware scheduling layer, a data layer, and a network communication layer (including the underlying communication protocol / microservice cluster). This embodiment achieves millisecond-level precise control of microservice calls by constructing a "logical frame budget-aware scheduling layer" between the game logic layer and the network communication layer. The logical frame budget-aware scheduling layer adds a frame budget monitoring module, an RPC (Remote Procedure Call) latency prediction engine, and an adaptive decision center. These components run within the game logic server process (i.e., the game's main loop). The frame budget monitoring module is responsible for quantifying the real-time running status of the game loop, using a high-precision clock to monitor the elapsed progress of each frame and calculate the remaining available time slices. The RPC latency prediction engine, based on historical call characteristics, uses a weighted moving average algorithm to dynamically evaluate the response time of microservice requests with different business semantics. The adaptive decision center serves as the core control unit, responsible for distributing various scheduling strategies based on the comparison between the remaining frame budget and the predicted latency. This embodiment also modifies the communication protocol middleware in the network communication layer, specifically modifying the RPC proxy to enable it to dynamically switch between multiple scheduling strategies based on latency prediction. Developers no longer need to manually write complex asynchronous callbacks and fault-tolerant logic for each interface; the communication protocol middleware layer automatically implements "dynamic asynchronization," significantly improving the throughput of single machines and clusters, and directly reducing the procurement and maintenance costs of server hardware. Simultaneously, the system's adaptive characteristics reduce the need for manual intervention, significantly decreasing long-term maintenance manpower investment.

[0045] Through the embodiments provided in this application, the remaining frame time of the current logical frame is monitored in real time, allowing the game's main loop to accurately understand the processing capacity of the current logical frame and provide an accurate basis for scheduling decisions. By predicting the expected response latency of microservice requests, the game's main loop can assess the processing time of microservice requests in advance, avoiding blocking of the game's main loop due to excessive delays in microservice requests. By dynamically selecting the target scheduling strategy based on the relative relationship between the remaining frame time and the expected response latency, and allocating target threads to microservice requests according to the target scheduling strategy, the logical path can be adaptively and dynamically adjusted. This maximizes the utilization of the remaining frame time while ensuring the correctness of the game logic, improving processing efficiency and avoiding frame timeouts caused by blocking of the game's main loop due to microservice requests. This solves the technical problem of game "frame skipping" or "stuttering" caused by asynchronous requests from non-core microservices blocking the game's main loop in related technologies. Through flexible switching of multiple preset scheduling strategies, the game's main loop can adapt to different network conditions and microservice loads, improving the robustness and stability of the system. It can eliminate more than 90% of the instantaneous stuttering caused by network jitter, improving players' online time and competitive experience.

[0046] In an exemplary embodiment, the game's main loop records the start timestamp of each logical frame when processing begins. In this embodiment, predicting the remaining time of the current logical frame includes: determining the timestamp difference between the current processing time of the current logical frame and the start timestamp of the current logical frame, and determining the difference between a preset upper limit of the frame period and the timestamp difference as the remaining time of the current logical frame.

[0047] The start timestamp of each logical frame refers to the timestamp recorded by the main game loop when each logical frame begins processing, used to mark the start time of that logical frame.

[0048] The preset frame cycle limit refers to the maximum allowed processing time set by the game's main loop for each logical frame. In other words, the game's main loop must complete all logical calculations for that logical frame within the preset frame cycle limit; otherwise, a frame timeout will occur. The preset frame cycle limit is determined by the game's frame rate. For example, for a game at 60 frames per second, the preset frame cycle limit is 16.7ms; for a game at 30 frames per second, the preset frame cycle limit is 33.3ms. The preset frame cycle limit remains constant throughout the entire game run, providing a stable time reference standard for the game's main loop.

[0049] Optionally, the remaining frame time of the current logical frame can be represented by the following formula (1):

[0050]

[0051] in, The remaining time of the current logical frame. The preset frame period upper limit, This represents the current processing time of the current logical frame. This is the start timestamp of the current logical frame. This is the timestamp difference between the current processing time and the start timestamp of the current logical frame, representing the processing time already consumed by the current logical frame. Using formula (1), the game's main loop can calculate in real-time how much remaining time the current logical frame has for subsequent operations, providing an accurate time basis for scheduling decisions.

[0052] For example, assuming a preset frame period upper limit The start timestamp of the current logical frame is 33.3ms. The current processing time is 1000ms. If it is 1020ms, then the timestamp difference is... The remaining frame time of the current logical frame is 20ms. =33.3ms-20ms=13.3ms, which means that the current logical frame has 13.3ms of remaining time to process subsequent operations.

[0053] This embodiment records the start timestamp of each logical frame and calculates the remaining time of the current logical frame based on the start timestamp, the current processing time, and a preset frame period upper limit. The game's main loop can accurately quantify the remaining processing capacity of each frame, providing accurate timing data for scheduling decisions. This allows for real-time reflection of the processing progress of the current logical frame, avoiding scheduling errors caused by inaccurate time calculations. Furthermore, this calculation method is simple and efficient, requiring only a single subtraction operation to obtain the remaining frame time, and will not significantly impact the performance of the game's main loop.

[0054] In an exemplary embodiment, predicting the expected response latency of a microservice request includes: averaging the historical response latencies corresponding to multiple historical requests of the same type as the microservice request to obtain the expected response latency of the microservice request.

[0055] Here, multiple historical requests refer to multiple microservice requests of the same type as the current microservice request that the game's main loop has processed before the current moment. Historical requests include all requests initiated by the game's main loop to the same type of microservice within a past period (such as the last hour, the last 1000 requests, etc.), which have been processed and have corresponding actual response latency data.

[0056] Historical response latency refers to the actual time elapsed from the initiation of multiple historical requests to their completion, that is, the time elapsed from the moment the game's main loop sends the historical request to the moment the game's main loop receives the response result of the historical request. Historical response latency is recorded immediately after the historical request is processed and stored in the historical request database for subsequent prediction.

[0057] Optionally, when the main game loop receives a microservice request during the processing of the current logical frame, it first determines the type of the microservice request, such as social service, achievement service, log service, payment service, etc. Then, the main game loop queries the historical request database for multiple historical requests of the same type as the microservice request and obtains the historical response latency corresponding to these historical requests. Next, the main game loop averages the multiple historical response latencies to calculate the arithmetic mean of the multiple historical response latencies, and determines the arithmetic mean as the expected response latency of the microservice request. If the number of historical requests is small (e.g., less than a preset threshold), the main game loop can use a weighted average method to give higher weight to recent historical response latencies to improve the timeliness of the prediction. Finally, the main game loop uses the calculated expected response latency for subsequent scheduling decisions, such as comparing it with the remaining frame time of the current logical frame and selecting a target scheduling strategy from multiple preset scheduling strategies.

[0058] This embodiment uses the average historical response latency of multiple historical requests of the same type as microservice requests to quickly and accurately predict the expected response latency of microservice requests, providing a reliable time basis for scheduling decisions. This prediction method based on historical data is simple and efficient, requiring no complex calculation models or large amounts of computing resources. Furthermore, this method is adaptive, automatically adjusting the prediction results based on changes in historical request response latency to adapt to dynamic changes in network conditions and microservice load. Through accurate prediction of expected response latency, the game's main loop can rationally select scheduling strategies, avoiding frame timeouts or resource waste caused by prediction errors, improving the processing efficiency and stability of the game's main loop, and enhancing game smoothness and player experience.

[0059] In one exemplary embodiment, with the development of Internet technology, the gaming industry has placed higher demands on server performance, stability, and scalability. Load balancing and data storage technologies have become key technologies for solving the problems of high-concurrency server access and resource allocation. Existing logical scheduling mostly adopts static logical scheduling strategies (such as hard-coded static synchronous or asynchronous modes). When downstream services experience occasional response delays, synchronous blocking calls will directly cause the main thread processing time to exceed the single-frame time limit, causing frame skipping and stuttering phenomena perceived by players, seriously damaging the smoothness and competitive fairness of real-time interactive games. At the same time, static logical scheduling strategies cannot dynamically adjust path strategies according to the server's real-time load level and the player's current business context (such as combat state, idle state, trading state). This results in unnecessary context switching overhead when the load is low, while in extremely high-concurrency environments, it is impossible to perform path bypassing or strategy degradation in a timely manner, making it difficult to achieve optimal resource scheduling under different load levels and business priorities.

[0060] Therefore, to address the problem that static logical scheduling strategies in related technologies cannot dynamically adjust path strategies based on the server's real-time load level and the player's current business context, resulting in unnecessary context switching overhead when the load is low, and the inability to perform path bypassing or strategy degradation in a timely manner under extremely high concurrency environments, this embodiment introduces a preset weight factor based on business semantic settings. By comparing the remaining frame time of the current logical frame with the product of the expected response latency of the microservice request and the preset weight factor, the game's main loop can accurately determine whether the current frame has sufficient remaining time to safely execute the synchronization strategy. This allows for dynamic adjustment of the path strategy based on the server's real-time load level and the player's current business context, achieving optimal resource scheduling under different load levels and business priorities.

[0061] In addition, by introducing a preset weight factor based on business semantics, the system can dynamically adjust the trigger threshold of the scheduling strategy according to the priority of different business scenarios and real-time load conditions, avoiding unnecessary context switching overhead when the load is low. At the same time, it can perform path bypass or strategy degradation in a timely manner in extremely high-concurrency environments, thereby improving the overall performance and resource utilization of the system.

[0062] In some embodiments, a target scheduling strategy is selected from multiple preset scheduling strategies based on the relative relationship between the remaining frame time of the current logical frame and the expected response latency of the microservice request. This includes: determining the first scheduling strategy among the multiple preset scheduling strategies as the target scheduling strategy in response to the fact that the remaining frame time of the current logical frame is greater than or equal to the product of the expected response latency of the microservice request and a preset weight factor; the first scheduling strategy refers to the strategy of suspending the execution of the current logical frame by the main game loop until the main game loop receives the response result of the microservice request before executing the subsequent instructions of the current logical frame.

[0063] The preset weight factor, set based on business semantics, is a coefficient greater than 0 and less than or equal to 1, with its value determined according to the message type of the microservice request. The preset weight factor is used to introduce the impact of semantics on response latency. Microservice requests with different business semantics have different weight factors, reflecting the different real-time requirements of different business scenarios. For example, for combat-oriented microservice requests (such as attack skill release, damage calculation, etc.), the preset weight factor can be set relatively large (e.g., 0.9), because combat scenarios have extremely high real-time requirements and need to use synchronous strategies as much as possible to ensure strong consistency of logic. For transaction-oriented microservice requests (such as item trading, asset transfer, etc.), the preset weight factor can be set relatively small (e.g., 0.8), because transaction scenarios need to ensure data consistency, but the real-time requirements are slightly lower than those of combat scenarios. For idle-oriented microservice requests (such as querying player information, updating non-critical data, etc.), the preset weight factor can be set relatively small (e.g., 0.7), because idle scenarios have lower real-time requirements and can use asynchronous or bypass strategies to save remaining frame time. In this way, the game's main loop can dynamically adjust the trigger threshold of the scheduling strategy based on the business semantics of microservice requests, achieving optimal resource scheduling in different business scenarios. The preset weight factor introduces the impact of semantics on response latency, enabling scheduling decisions to be differentiated according to the priority of business scenarios, avoiding the traditional "one-size-fits-all" resource allocation model.

[0064] The remaining frame time of the current logical frame is compared with the product of the expected response latency of the microservice request and a preset weighting factor. This aims to introduce the influence of business semantics on scheduling decisions, enabling differentiated processing based on the priority of business scenarios. By multiplying the preset weighting factor by the expected response latency to obtain a weighted expected response latency, and then comparing the remaining frame time with this weighted expected response latency, the game's main loop can dynamically adjust the trigger threshold of the scheduling strategy based on the business semantics of the microservice request. For high-priority business scenarios (such as combat), a larger preset weighting factor and a smaller weighted expected response latency make it easier to choose a synchronous strategy, ensuring strong and immediate consistency of the logic. For low-priority business scenarios (such as idle state), a smaller preset weighting factor and a larger weighted expected response latency make it easier to choose an asynchronous or bypass strategy, saving remaining frame time and improving system throughput. This weighted comparison mechanism based on business semantics avoids the traditional "one-size-fits-all" resource allocation model, achieving optimal resource scheduling under different business scenarios.

[0065] If the remaining time of the current logical frame is greater than or equal to the product of the expected response latency of the microservice request and the preset weighting factor, it means that the current logical frame has sufficient time to safely accommodate the expected processing time of the microservice request. Even if the actual response latency is slightly higher than the predicted value, it will not cause a frame timeout. In this case, the game's main loop chooses the first scheduling strategy, which is to synchronously wait for the response result of the microservice request, ensuring the real-time performance and consistency of the logic. The advantage of the synchronous strategy is that it ensures that the response result of the microservice request is immediately used for the calculation of the current logical frame, avoiding data consistency problems that may be caused by asynchronous processing. At the same time, since the remaining time of the frame is sufficient, synchronous waiting will not affect the timely completion of the current logical frame, and will not cause game stuttering or frame skipping. This decision-making mechanism based on the comparison of the remaining time of the frame and the weighted expected response latency avoids both frame timeouts caused by prediction errors and resource waste caused by excessive conservatism, achieving a balance between the accuracy and efficiency of scheduling decisions.

[0066] The first scheduling strategy refers to a strategy where the main game loop suspends the execution of the current logical frame until it receives the response to the microservice request before resuming execution of the subsequent instructions for that frame. Also known as a synchronous or blocking strategy, its core characteristic is that after initiating a microservice request, the main game loop pauses subsequent operations of the current logical frame, waits for the microservice request's response, and then continues executing the remaining instructions of the current logical frame. The first scheduling strategy is suitable when there is sufficient remaining time in the frame, ensuring that the microservice request's response is immediately used for the calculation of the current logical frame, guaranteeing real-time logic and data consistency. The implementation of the first scheduling strategy is as follows: the main game loop initiates a microservice request on the main thread, then enters a waiting state, where the main thread is blocked until it receives the microservice request's response. After receiving the response, the main game loop continues executing the subsequent instructions of the current logical frame.

[0067] In the first scheduling strategy, the target thread is the main thread of the game's main loop, responsible for initiating microservice requests and waiting for their responses. After initiating a microservice request, the main thread enters a waiting state, blocked until it receives the response. Upon receiving the response, the main thread continues executing subsequent instructions for the current logic frame. The main thread's role is to synchronously process microservice requests, ensuring that the responses are immediately used for calculations in the current logic frame, guaranteeing real-time logic and data consistency. By blocking and waiting, the main thread avoids race conditions and data consistency issues that might arise from asynchronous processing, ensuring the determinism and predictability of the game logic. This mechanism simplifies the system architecture, reduces development and maintenance costs, and is suitable for use when there is sufficient remaining time in the frame.

[0068] Optionally, the following decision formula can be established: If This indicates that the current frame has sufficient performance, and the first scheduling strategy (i.e., blocking synchronous call) is executed to ensure the immediate strong consistency of the logic. Among these, The remaining time of the current logical frame. For the expected response latency of microservice requests, A preset weighting factor is used. This decision-making formula clarifies the triggering condition for the synchronization strategy: when the remaining time budget of the current frame is greater than or equal to the product of the expected response latency of the microservice request and the weighting factor, the synchronization strategy is selected. The synchronization strategy ensures immediate strong consistency of the logic; that is, the response result of the microservice request is immediately used for the calculation of the current logical frame, without data delay or inconsistency issues. Simultaneously, the synchronization strategy is suitable when the current frame has sufficient performance, meaning the remaining frame time can safely accommodate the expected processing time of the microservice request without causing frame timeout.

[0069] Optional, Figure 4 A flowchart illustrating a dynamic adjustment target scheduling strategy provided in this application embodiment is shown below. Figure 4 As shown, the game's main loop initializes the frame monitor and sets the frame period upper limit. The game's main loop runs business logic code to process the current logic frame. During this processing, when a microservice call request is encountered, an interceptor is triggered. The prediction engine calculates the expected response latency of the target service. The adaptive scheduling center compares the remaining frame time of the current logical frame. Response time as expected Make path diversion decisions if If the first scheduling strategy (i.e., blocking synchronous call) is executed, the immediate strong consistency of the logic is ensured. After receiving the response result of the microservice request, the game's main loop continues to process the remaining calculations of the current logic frame. After completing the remaining calculations of the current logic frame, a synchronization packet is sent to the client to maintain a stable frame rate on the client. In this embodiment, by real-time frame budget monitoring and business semantic awareness-based dynamic path switching, the core issues of real-time performance assurance and dynamic path selection in related logic scheduling are solved. This achieves efficient scheduling of game server logic and deterministic maintenance of data, changing the traditional "one-size-fits-all" resource allocation model. It can dynamically allocate resources according to business scenarios, significantly improving server resource utilization and achieving optimal performance output under limited hardware resources.

[0070] This embodiment addresses the core issues of real-time performance assurance and dynamic path selection in related logic scheduling through real-time frame budget monitoring and business semantic awareness-based dynamic path switching. It achieves efficient scheduling of game server logic and deterministic data maintenance, changing the traditional "one-size-fits-all" resource allocation model. It dynamically allocates resources based on business scenarios, significantly improving server resource utilization and achieving optimal performance output with limited hardware resources. By introducing a preset weight factor based on business semantic settings, the game's main loop can dynamically adjust the trigger threshold of the scheduling strategy according to the message type of microservice requests, achieving optimal resource scheduling in different business scenarios. Simultaneously, by selecting the first scheduling strategy when there is sufficient remaining frame time, the game's main loop ensures the real-time performance and consistency of the logic, guaranteeing that the response results of microservice requests are immediately used for the calculation of the current logic frame, avoiding data consistency issues that may arise from asynchronous processing. Through this dynamic scheduling mechanism based on business semantics, the game's main loop can dynamically adjust the scheduling strategy according to the priority of different business scenarios while ensuring that frames do not time out. This avoids unnecessary context switching overhead in low-priority business scenarios and enables timely path bypassing or strategy degradation in extremely high-concurrency environments, thereby improving the overall performance and resource utilization of the system, enhancing the smoothness of the game and the player experience.

[0071] In one exemplary embodiment, the game's main loop updates the state of multiple player objects within the current logic frame; the microservice request is triggered by the target player object among the multiple player objects.

[0072] Within each logical frame, the main game loop needs to update the states of multiple player objects. These states include player location coordinates, movement speed, health, mana, equipment status, skill cooldowns, and inventory items. The main loop processes all online player state updates in a predetermined order within each logical frame, including handling player input, performing physics calculations, collision detection, updating AI logic, and synchronizing network status. When updating the states of multiple player objects within the same logical frame, the main loop needs to allocate processing time for each player object to ensure that all player object state updates are completed within the preset frame period limit.

[0073] During the main game loop's processing of the current logic frame, when the game logic of a player object (referred to as the target player object) needs to call a microservice, the target player object triggers a microservice request. The target player object is a specific player among multiple player objects, and its game logic needs to access non-core microservices (such as social services, achievement services, logging services, payment services, etc.) to complete certain operations. For example, when the target player object completes an achievement, it triggers a microservice request to the achievement service; when the target player object sends a chat message, it triggers a microservice request to the social service; when the target player object purchases an item, it triggers a microservice request to the payment service. The fact that the microservice request is triggered by the target player object means that the microservice request is associated with a specific player object and requires the context information of that player object (such as player ID, character ID, current state, etc.) to construct the request parameters. Simultaneously, the response result of the microservice request also needs to be applied to the target player object's state to complete the game logic loop.

[0074] In some embodiments, a target scheduling strategy is selected from multiple preset scheduling strategies based on the relative relationship between the remaining frame time of the current logical frame and the expected response latency of the microservice request. This includes: determining the second scheduling strategy among multiple preset scheduling strategies as the target scheduling strategy when the remaining frame time of the current logical frame is less than the product of the expected response latency of the microservice request and a preset weight factor, and the attribute label of the microservice request indicates that the microservice request does not have latency tolerance characteristics. The second scheduling strategy refers to the strategy of returning the original state of the target player object in the local cache before initiating the microservice request to the game's main loop.

[0075] In this context, the attribute tag for microservice requests indicates that a microservice request lacks latency tolerance. This means that when the game's main loop initiates a microservice request, it attaches an attribute tag to that request. This attribute tag indicates that delayed processing of the microservice request will affect the correctness of the game's core logic. The attribute tag can be a metadata field of the microservice request or a marker dynamically generated by the game's main loop in the interceptor based on the type and business semantics of the microservice request. Microservice requests with latency tolerance include non-core business logic such as logging, statistical analysis, and achievement unlocking. The processing results of these requests do not immediately affect the game's core logic (such as combat calculations and position synchronization) and can be delayed to subsequent logic frames or processed asynchronously. Microservice requests without latency tolerance include core business logic such as asset deduction, skill judgment, and position updates. The processing results of these requests must be immediately used for calculations in the current logic frame; otherwise, it will lead to logical errors or data inconsistencies. The introduction of attribute tags allows the game's main loop to perform fine-grained path routing based on the business semantics of microservice requests, selecting the most suitable scheduling strategy for different types of microservice requests, and improving the accuracy and efficiency of scheduling decisions.

[0076] If the remaining time of the current logical frame is less than the product of the expected response latency of the microservice request and the preset weight factor, it means that the remaining time of the current logical frame is insufficient to safely accommodate the expected processing time of the microservice request. Choosing to wait synchronously may result in frame timeout. Furthermore, if the microservice request cannot be delayed, the game's main loop selects the second scheduling strategy. The second scheduling strategy refers to the game's main loop returning the original state of the target player object from its local cache (such as L1 cache) before initiating the microservice request. Also known as a degradation strategy, the core characteristic of the second scheduling strategy is that the game's main loop does not wait for the actual response result of the microservice request but directly uses the player object state stored in the local cache as the response result. The response method of the second scheduling strategy is also called "soft landing," meaning that before initiating the microservice request, the game's main loop first saves the original state of the target player object to its local cache and then initiates the microservice request; when it detects that the remaining frame time is insufficient and the microservice request does not have latency tolerance, the game's main loop abandons waiting for the microservice request's response result and directly reads the original state of the target player object from the local cache, returning it as the response result to the game's main loop. The soft-landing feature of the second scheduling strategy (degradation strategy) does not block the main game loop, ensuring that the current logical frame is completed on time. In addition, it uses the cached old state as the response result. Although there may be problems with data inconsistency or staleness, it avoids direct failure or error throwing and provides an alternative solution. At the same time, the user experience is smooth and will not be interrupted suddenly.

[0077] In some embodiments, when the target service requested by a microservice is unreachable, a second scheduling strategy can be adopted. This means that the target microservice has failed or experienced a network interruption and cannot respond to the request normally; in this case, the second scheduling strategy must also be selected. By selecting the second scheduling strategy when the remaining frame time is insufficient or the target service is unreachable, the main game loop can avoid being blocked while waiting for microservice requests, ensuring that the current logical frame is completed on time, and maintaining the smoothness and stability of the game.

[0078] In the second scheduling strategy, the target thread is the main thread of the game's main loop, responsible for initiating microservice requests and reading the original state of the target player object from the local cache. Before initiating a microservice request, the main thread of the game's main loop saves the current state of the target player object to the local cache, and then initiates the microservice request. When it detects that the remaining frame time is insufficient and the microservice request does not have latency tolerance, or the target service is unreachable, the main thread of the game's main loop abandons waiting for the response result of the microservice request, directly reads the original state of the target player object from the local cache, and returns it as the response result to the game logic. The role of the main thread of the game's main loop is to quickly degrade, avoid blocking the game's main loop, and ensure that the current logic frame completes on time. By directly accessing the local cache, the main thread of the game's main loop can obtain the original state of the target player object in a very short time without waiting for network I / O or microservice responses, thus achieving rapid degrade. This mechanism ensures that the game's main loop maintains stable operation under extreme conditions, improving the game's robustness and player experience.

[0079] Optionally, the following decision formula can be established: If Furthermore, the attribute label of the microservice request indicates that the microservice request does not have latency tolerance, meaning that the remaining time of the current logical frame is insufficient to safely accommodate the expected processing time of the microservice request. Choosing to wait synchronously may lead to frame timeout. In this case, the game's main loop chooses the second scheduling strategy (i.e., the degradation strategy). Specifically, it retrieves the original state of the target player object before initiating the microservice request from the local L1 cache and assembles the logic, avoiding frame interruption caused by waiting in the game's main loop. The core idea of ​​the degradation strategy is to use the original state of the target player object in the local cache as a substitute when the microservice request cannot be responded to in a timely manner or cannot be responded to at all, ensuring that the game's main loop is not blocked and can continue to execute subsequent operations of the current logical frame. In addition, the degradation strategy can avoid frame interruption caused by waiting in the game's main loop, that is, the game's main loop will not pause because of waiting for the microservice request, thus ensuring that the current logical frame is completed within the preset frame period limit. At the same time, the degradation path uses the original state of the target player object as a substitute, that is, the state of the player object when the microservice request was initiated. This ensures the determinism and consistency of the data and avoids race condition problems that may be caused by asynchronous processing.

[0080] Optional, such as Figure 4 As shown, if Then, it further determines whether the attribute label of the microservice request indicates that the microservice request has latency tolerance characteristics. If the attribute label of the microservice request indicates that the microservice request does not have latency tolerance characteristics, then the second scheduling strategy (i.e., the degradation strategy) is executed. The main game loop abandons waiting for the response result of the microservice request and directly reads the original state of the target player object from the local cache (L1 cache) and returns it as the response result to the main game loop. After receiving the response result of the microservice request, the main game loop continues to process the remaining calculations of the current logical frame. After completing the remaining calculations of the current logical frame, it sends a synchronization packet to the client to maintain the client's frame rate stability.

[0081] In this embodiment, when the remaining frame time of the current logical frame is insufficient or the target service is unreachable, the second scheduling strategy is selected. This ensures that the game's main loop avoids blocking due to waiting for microservice requests, guaranteeing that the current logical frame completes within the preset frame period limit. The second scheduling strategy uses the original state of the player object in the local cache as the response result, achieving rapid degradation of microservice requests. This avoids frame timeouts caused by network jitter or service failures, and allows backend microservices to "soft-land" under extreme loads through adaptive degradation. This reduces the strong dependence on expensive, high-performance, low-latency hardware, improving the cost-effectiveness and scalability of the game server. This local cache-based degradation mechanism is simple and efficient, requiring no complex asynchronous callbacks or state backtracking logic, making it suitable for application in game server environments with extremely high real-time requirements. Furthermore, by saving the original state of the target player object to the local cache before initiating a microservice request, the second scheduling strategy ensures the use of deterministic and consistent data, avoiding race conditions and data inconsistency issues that may arise from asynchronous processing. Through this rapid degradation mechanism, the game's main loop can maintain stable operation under extreme conditions, improving the game's robustness and player experience.

[0082] In an exemplary embodiment, a target scheduling strategy is selected from multiple preset scheduling strategies based on the relative relationship between the remaining frame time of the current logical frame and the expected response latency of the microservice request. This includes: determining the third scheduling strategy among multiple preset scheduling strategies as the target scheduling strategy when the remaining frame time of the current logical frame is less than the product of the expected response latency of the microservice request and a preset weight factor, and the attribute label of the microservice request indicates that the microservice request has latency tolerance characteristics. The third scheduling strategy refers to the strategy whereby the game's main loop encapsulates the microservice request into an asynchronous task and submits it to a message queue, the game's main loop immediately continues execution, the asynchronous task is forwarded to the target service called by the microservice request through the message queue, and the target service returns the response result of the asynchronous task.

[0083] Among them, the attribute label of the microservice request indicates that the microservice request has the characteristic of latency tolerance. This means that when the main loop of the game initiates a microservice request, it attaches an attribute label to the microservice request. This attribute label is used to indicate that the microservice request can be processed in a delayed manner without affecting the correctness of the core logic of the game.

[0084] If the remaining time of the current logical frame is less than the product of the expected response latency of the microservice request and the preset weight factor, and the attribute label of the microservice request indicates that the microservice request has latency tolerance, it means that the remaining time of the current logical frame is insufficient to safely accommodate the expected processing time of the microservice request. However, the microservice request can be processed with a delay without affecting the correctness of the core game logic. In this case, the game's main loop chooses the third scheduling strategy, namely the asynchronous strategy, encapsulating the microservice request as an asynchronous task and submitting it to the message queue. The game's main loop immediately continues to execute the subsequent operations of the current logical frame. This decision-making mechanism avoids frame timeout problems caused by insufficient remaining time and makes full use of the latency tolerance feature of the microservice request, achieving a balance between the accuracy and efficiency of scheduling decisions. By choosing the third scheduling strategy when the remaining time of the frame is insufficient and the microservice request has latency tolerance, the game's main loop can avoid blocking, ensuring that the current logical frame is completed on time, while also ensuring that the microservice request is eventually processed and not lost due to delayed processing.

[0085] The third scheduling strategy refers to a strategy where the game's main loop encapsulates microservice requests as asynchronous tasks and submits them to a message queue. The main loop then immediately continues execution, forwarding the asynchronous tasks to the target service invoked by the microservice request via the message queue, and finally receiving the response from the target service. Also known as the asynchronous strategy or bypass strategy, the core characteristic of the third scheduling strategy is that the main loop does not wait for the response from the microservice request; instead, it encapsulates the request as an asynchronous task and submits it to the message queue, immediately continuing execution of subsequent operations in the current logical frame. The implementation of the third scheduling strategy is as follows: When the main loop initiates a microservice request, it encapsulates the request parameters and context information of the target player object into an asynchronous task and submits it to the message queue. The consumer thread of the message queue or the worker thread of the target service retrieves the asynchronous task from the message queue, processes it, and returns the response to the main loop. The main loop receives the response from the asynchronous task in subsequent logical frames or between frames and applies the response to the state of the target player object. The response result of an asynchronous task refers to the processing result returned to the main game loop after the target service has finished processing the asynchronous task. In other words, the response result of an asynchronous task is the asynchronous response result of a microservice request.

[0086] In this embodiment, in the third scheduling strategy, the target thread is either a message queue consumer thread or a target service worker thread. Message queue consumer threads are dedicated to retrieving and processing asynchronous tasks from the message queue. These threads are independent of the game's main loop thread and can concurrently process multiple asynchronous tasks, improving system throughput. Target service worker threads are the worker threads within the microservice, responsible for processing asynchronous tasks forwarded from the message queue, executing specific business logic, and returning the processing results to the game's main loop. The target thread's role is to asynchronously process microservice requests, avoiding blocking the game's main loop and ensuring that the current logic frame completes on time. After retrieving an asynchronous task from the message queue, the target thread parses the task parameters, executes the corresponding business logic, and returns the response result to the game's main loop. The concurrent processing capability of the target thread can fully utilize multi-core CPU resources, improving the overall system performance and response speed.

[0087] Optionally, the following decision formula can be established: If If the attribute tags of the microservice request indicate that the microservice request has latency tolerance characteristics, then the third scheduling strategy (i.e., asynchronous strategy or bypass strategy) is executed. Specifically, the microservice request is encapsulated as an asynchronous task and delivered to a distributed message queue. The game's main loop immediately returns and continues subsequent calculations. The message queue forwards the asynchronous task to the target service called by the microservice request, and the target service returns the response result of the asynchronous task. The core idea of ​​the bypass strategy is to process the microservice request asynchronously when the remaining frame time is insufficient but the microservice request has latency tolerance characteristics, thus avoiding blocking the game's main loop. The bypass strategy implements asynchronous task delivery through a message queue. The logic thread immediately returns and continues subsequent calculations without pausing due to waiting for the microservice request, thereby ensuring that the current logic frame is completed within the preset frame period limit. At the same time, the bypass strategy is suitable for microservice requests with latency tolerance characteristics, such as non-core business logic such as logging and statistical analysis. The processing results of these requests will not immediately affect the core logic of the game and can be processed with a delay.

[0088] Optional, such as Figure 4 As shown, if The system then further determines whether the attribute tags of the microservice request indicate that the microservice request has latency tolerance characteristics. If the attribute tags indicate that the microservice request has latency tolerance characteristics, the third scheduling strategy (i.e., bypass strategy) is executed. The game's main loop generates the Sequence_ID and Version_Tag of the target player object and suspends the microservice request to the asynchronous waiting pool. That is, the game's main loop encapsulates the microservice request as an asynchronous task and submits it to the distributed message queue. The game's main loop immediately returns and continues subsequent calculations. After the game's main loop completes the remaining calculations for the current frame, it normally sends out synchronization packets to maintain a stable client frame rate. The message queue forwards the asynchronous task to the target service called by the microservice request, and the target service returns the response result of the asynchronous task. After the response result of the asynchronous task is returned, a conflict resolution algorithm is triggered during the frame interval (Idle Time) to complete the final correction of the memory data through version verification.

[0089] In this embodiment, when the remaining time of the current logical frame is insufficient and the microservice request has latency tolerance characteristics, the third scheduling strategy is selected. This ensures that the game's main loop avoids blocking and that the current logical frame is completed within the preset frame period limit. The third scheduling strategy encapsulates microservice requests as asynchronous tasks and submits them to a message queue, achieving asynchronous processing of microservice requests. The game's main loop immediately continues executing the remaining logic of the current logical frame (without blocking), while the consumer thread of the message queue or the worker thread of the target service concurrently processes multiple asynchronous tasks. This asynchronous processing mechanism significantly improves the system's throughput, fully utilizing multi-core CPU resources and concurrent processing capabilities without increasing hardware performance requirements. This improves the overall system performance and response speed, avoiding frame timeout issues caused by network jitter or service latency. Furthermore, it significantly increases the carrying capacity (throughput) of single machines and clusters, directly reducing the procurement and maintenance costs of server hardware. Simultaneously, the system's adaptive characteristics reduce the need for manual intervention, significantly reducing long-term maintenance manpower investment. This message queue-based asynchronous mechanism is simple and efficient, requiring no complex blocking and waiting logic, making it suitable for application in game server environments with extremely high real-time requirements. Meanwhile, by introducing attribute tags for microservice requests, the game's main loop can perform fine-grained path routing based on the business semantics of microservice requests, selecting the most suitable scheduling strategy for different types of microservice requests and improving the accuracy and efficiency of scheduling decisions. Through this asynchronous processing mechanism, the game's main loop can make full use of the remaining frame time while ensuring that frames do not time out, thereby improving processing efficiency and enhancing game smoothness and player experience.

[0090] In an exemplary embodiment, the game's main loop updates the state of multiple player objects within the current logical frame; the microservice request is triggered by the target player object among the multiple player objects; the response result of the asynchronous task carries the original state version number of the target player object's original state when the microservice request was triggered.

[0091] In this embodiment, when the game's main loop encapsulates a microservice request as an asynchronous task and submits it to the message queue, it carries the original state version number of the target player object's original state at the time the microservice request was triggered as metadata within the asynchronous task. The original state version number is the version number of the target player object's original state at the time the microservice request was triggered, used to identify which version of the state the asynchronous task was calculated based on. The original state version number is a monotonically increasing integer used to identify the state version of the target player object at the time the microservice request was triggered. After the target service completes the asynchronous task, it returns the original state version number as metadata in the response result to the game's main loop. The introduction of the original state version number allows the game's main loop to determine whether the target player object's current state is consistent with its original state at the time the microservice request was triggered when receiving the response result of the asynchronous task, thereby selecting an appropriate data merging strategy and avoiding data consistency issues caused by asynchronous processing.

[0092] In some embodiments, the method further includes: in response to receiving the response result of the asynchronous task, obtaining the current state version number of the current state of the target player object; and in response to the original state version number being equal to the current state version number, merging the response result of the asynchronous task with the original state of the target player object.

[0093] Related technologies suffer from data race conditions and logical consistency bottlenecks under asynchronous communication mechanisms. For example, in hard-coded asynchronous processing, programmers manually break down non-core logic into asynchronous callbacks or deliver them to message queues (MQ) for execution during the development phase. This approach achieves logical decoupling, eliminating the need for the main thread of the game's main loop to wait for I / O returns, significantly improving system throughput. However, in high-concurrency scenarios, the uncontrollability of asynchronous return order can easily trigger race conditions. Furthermore, due to the lack of a robust state backtracking mechanism, when data is returned late, the player's memory state may have already changed, leading to serious logical vulnerabilities (such as data overwriting, duplicate item distribution, etc.). Moreover, maintenance costs increase exponentially with business complexity. In short, while asynchronous processing improves system throughput, the uncontrollability of asynchronous return order and the lack of a robust state backtracking mechanism can lead to serious logical vulnerabilities, affecting the correctness of game logic and data consistency.

[0094] To address the cross-frame asynchronous race condition issue arising from the third scheduling strategy (i.e., bypass strategy) mentioned above, this implementation returns the response result of the asynchronous task to the game's main loop via a message queue. The main loop receives the response result in subsequent logical frames or between frames and selects an appropriate data merging strategy based on the relationship between the original state version number and the current state version number. This involves introducing a "version vector label" and a "conflict resolution algorithm" to handle the logical backtracking and data alignment after the asynchronous task's response result is returned, ensuring the correctness of the game logic and data consistency. This embodiment combines technologies from multiple fields, including distributed system architecture, real-time performance monitoring, heuristic prediction algorithms, and multi-version concurrency control (MVCC) data processing, providing a highly efficient and flexible load balancing and data storage solution for game servers. Based on frame budget-aware adaptive path scheduling and version vector conflict resolution technology, this embodiment solves the core problems of traditional logical scheduling in terms of real-time performance assurance, dynamic path selection, and asynchronous data consistency through real-time frame budget monitoring, business semantic-aware dynamic path switching, and state backtracking compensation with version fingerprints. This achieves efficient scheduling of game server logic and deterministic data maintenance.

[0095] The original state version number of the target player object's original state (denoted as ). `<original state version number>` refers to the state version number of the target player object when the microservice request is triggered. The original state version number is a monotonically increasing integer; it increments each time the state of the target player object changes. The original state version number is used to identify which version of the state the microservice request was based on. The current state version number of the target player object (denoted as `<original state version number>`) is the current state version number of the target player object. The current state version number refers to the state version number of the target player object when the game's main loop receives the response result of the asynchronous task. The current state version number is also a monotonically increasing integer, incrementing each time the target player object's state changes. The difference between the original state version number and the current state version number lies in their point in time: the original state version number is the state version number when the microservice request is triggered, while the current state version number is the state version number when the asynchronous task's response result is received. By comparing the original state version number and the current state version number, the game's main loop can determine whether the target player object's state has changed between the microservice request being triggered and the asynchronous task's response result being received, thus selecting an appropriate data merging strategy.

[0096] In this embodiment, when the original state version number of the target player object's original state... Evolved to the current version number Then the conflict resolution function is called. A state check is performed. If the original state version number is equal to the current state version number, it means that the target player object's state has not changed during the process from the microservice request being triggered to receiving the asynchronous task's response. In other words, the target player object's current state is consistent with its original state when the microservice request was triggered. In this case, the game's main loop can directly merge the asynchronous task's response with the target player object's original state to obtain the updated player state. The equality of the original state version number with the current state version number indicates that the asynchronous task's response is still valid and can be safely applied to the target player object's state without causing data overwriting or logical errors. This merging strategy is called atomic merging, which directly merges the asynchronous task's response with the target player object's original state without requiring complex state backtracking or differential compensation.

[0097] To address the cross-frame asynchronous race condition problem arising from the third scheduling strategy (i.e., the bypass strategy), this embodiment establishes a formal conflict resolution model, such as... Figure 3 As shown, the system architecture provided in this embodiment, in addition to the frame budget monitoring module, RPC time prediction engine, and adaptive decision center, also includes a state alignment and conflict resolution module (ConsistencyController). This module is responsible for version verification of asynchronously returned data, logical barrier management, and state merging based on the differential compensation algorithm. The state alignment and conflict resolution module is a concrete implementation of the formal conflict resolution model, which forms the theoretical basis for the module. The formal conflict resolution model provides a mathematical model and algorithmic framework for version verification of asynchronously returned data, logical barrier management, and state merging based on the differential compensation algorithm, through version vector labels and conflict resolution algorithms. Based on the definition of the formal conflict resolution model, the state alignment and conflict resolution module implements the specific logic for version verification, logical barrier management, and state merging, ensuring that asynchronously returned data can be correctly applied to the state of the target player object, avoiding data consistency issues.

[0098] like Figure 4As shown, after the target service returns the response result of the asynchronous task requested by the microservice, operations such as conflict resolution, version verification, and updating memory data are triggered within the frame gap. The frame gap refers to the time interval between the completion of the current logical frame and the start of the next logical frame. The game's main loop performs some non-real-time operations within the frame gap, such as processing the response result of the asynchronous task, data synchronization, and logging. Processing the response result of the asynchronous task within the frame gap avoids blocking the current logical frame, ensuring that the current logical frame completes on time. After receiving the response result of the asynchronous task, the game's main loop first performs version verification, comparing the original state version number with the current state version number, and selecting an appropriate data merging strategy based on the relationship between the version numbers. Then, according to the selected data merging strategy, the response result of the asynchronous task is applied to the state of the target player object. Finally, the memory data of the target player object is updated to ensure the correctness of the game logic and data consistency.

[0099] Optionally, Figure 5 An execution timing diagram of a third scheduling strategy provided in an embodiment of this application is shown below. Figure 5 As shown, the game's main loop initiates a microservice request and triggers the third scheduling strategy (i.e., bypass strategy). The adaptive decision center records the original state version number of the target player object when the microservice request is triggered, and encapsulates the microservice request into an asynchronous task (carrying the original state version number) and submits it to the message queue. The message queue forwards the asynchronous task to the target service called by the microservice request. Simultaneously, the game's main loop continues to execute the remaining logic of the current logic frame (without blocking). After completing the calculation of the current logic frame, it sends a synchronization packet to the client. At the same time, the adaptive decision center receives the response result of the asynchronous task returned by the target service (carrying the original state version number) and compares it with the original state version number of the target player object. If the original state version number of the target player object... and current status version number If they are equal, perform an atomic merge to obtain the updated player state and update the target player object state.

[0100] This embodiment introduces a version verification mechanism for the original state version number and the current state version number. The game's main loop can accurately determine whether the state of the target player object has changed during the process from the triggering of the microservice request to receiving the response result of the asynchronous task. This allows for the selection of an appropriate data merging strategy, avoiding data consistency issues caused by asynchronous processing. Atomic merging is performed when the original state version number and the current state version number are equal. The game's main loop can directly merge the response result of the asynchronous task with the original state of the target player object without the need for complex state backtracking or differential compensation, thus improving processing efficiency. While ensuring data consistency, it can fully utilize the advantages of asynchronous processing to improve system throughput and response speed, thereby enhancing game smoothness and player experience.

[0101] In an exemplary embodiment, the method further includes: in response to the current state version number being greater than the original state version number, and the expected operation of the microservice request and the historical operation sequence executed by the game's main loop during the process of triggering the microservice request to receiving the response result of the asynchronous task satisfying the commutative law, determining the incremental state correction value of the target player object, and merging the incremental state correction value and the current state of the target player object to obtain the target state of the target player object.

[0102] In this case, a current state version number greater than the original state version number indicates that the target player object's state has changed between the triggering of the microservice request and the receipt of the asynchronous task's response. That is, the target player object's current state is inconsistent with its original state at the time the microservice request was triggered. In this situation, the target player object's state has already been modified by other operations in the game's main loop. Directly merging the asynchronous task's response with the target player object's original state would lead to data overwriting or logical errors. Therefore, the game's main loop needs to determine whether the expected operation of the microservice request and the historical operation sequence satisfy the commutative law. If they do, the asynchronous task's response needs to be adjusted using an incremental state correction value to ensure it is correctly applied to the target player object's current state. This is achieved by calculating the incremental state correction value and merging it with the target player object's current state to obtain the target player object's target state.

[0103] The expected operation of a microservice request refers to how the game's main loop predicts the type and parameters of the operation that the target service will perform based on the parameters and business logic of the microservice request. The expected operation includes the operation type and operation parameters. The operation type refers to the type of operation the target service will perform, such as increasing health, deducting asset balance, updating equipment status, increasing experience points, etc. The operation parameters refer to the specific value or status of the operation, such as the amount of health increase, the amount of asset balance deduction, the new value of equipment status, the amount of experience points increase, etc. The expected operation of a microservice request is used to determine whether it satisfies the commutative law with the historical operation sequence, thereby selecting an appropriate data merging strategy. For example, if the microservice request is "increase player experience points," then the expected operation of the microservice request is "increase experience points," and the operation parameter is the amount of experience points increased; if the microservice request is "deduct player asset balance," then the expected operation of the microservice request is "deduct asset balance," and the operation parameter is the amount of asset balance deducted.

[0104] The commutative law between the expected operation of a microservice request and the historical operation sequence executed during the process from triggering the microservice request to receiving the response from the asynchronous task means that the execution order of the expected operation of the microservice request and the historical operation sequence does not affect the final state result; that is, the expected operation of the microservice request and the historical operation sequence can be interchanged to obtain the same state result. In game logic, if the execution order of an operation and an operation sequence does not affect the final state result, then the operation and the operation sequence are said to satisfy the commutative law. For example, suppose the initial state is A, the expected operation of the microservice request is B (such as increasing health), and the historical operation sequence is C (such as deducting asset balance). If A+BC (execute B first, then C) and A-C+B (execute C first, then B) have the same result, then operation B and operation sequence C are said to satisfy the commutative law. By determining whether the expected operation of the microservice request and the historical operation sequence satisfy the commutative law, the game's main loop can decide whether it can adjust the response result of the asynchronous task through incremental state correction values ​​so that it can be correctly applied to the current state of the target player object.

[0105] The main game loop determines whether the expected operation and historical operation sequence of a microservice request satisfy the commutative law in the following ways: First, the main game loop obtains the type and parameters of the expected operation of the microservice request, such as increasing health, deducting asset balance, updating equipment status, etc.; second, the main game loop obtains the historical operation sequence, that is, all operations performed on the target player object by the main game loop during the process from triggering the microservice request to receiving the response result of the asynchronous task; then, the main game loop determines whether they satisfy the commutative law based on the type and parameters of the expected operation and historical operation sequence of the microservice request. The judgment methods include: if the expected and historical operation sequences of a microservice request are both incremental operations on the same state variable (such as increasing health or experience points), then the commutative law is satisfied; if the expected and historical operation sequences of a microservice request are both decremental operations on the same state variable (such as deducting health or asset balance), then the commutative law is satisfied; if the expected and historical operation sequences of a microservice request are operations on different state variables (such as increasing health and deducting asset balance), then the commutative law is satisfied; if the expected and historical operation sequences of a microservice request are a mixture of incremental and decremental operations on the same state variable (such as increasing health and deducting health), then the commutative law is not satisfied. In this way, the game's main loop can accurately determine whether the expected and historical operation sequences of a microservice request satisfy the commutative law, thereby selecting an appropriate data merging strategy.

[0106] The incremental state correction value of the target player object refers to the state correction amount calculated by the game's main loop based on the expected and historical operation sequences of the microservice requests. It is used to adjust the response results of asynchronous tasks so that they can be correctly applied to the current state of the target player object. The incremental state correction value is a vector containing the state correction amounts for all attributes of the target player object, such as health point correction, experience point correction, and equipment status correction.

[0107] Optionally, determining the incremental state correction value for the target player object includes using a differential compensation algorithm. This involves the game's main loop performing differential compensation on the target player object's state increment and historical operation sequence to obtain the incremental state correction value. The specific steps are: first, the game's main loop calculates the impact of the historical operation sequence on the target player object's state, obtaining the historical state change; then, the game's main loop calculates the difference between the state increment and the historical state change, obtaining the incremental state correction value; finally, the game's main loop applies the incremental state correction value to the target player object's current state to obtain the target state of the target player object.

[0108] The target state is the final state obtained by the game's main loop after receiving the response result of the asynchronous task. Based on the relationship between the original state version number and the current state version number, the loop selects an appropriate data merging strategy to correctly apply the asynchronous task's response result to the target player object's state. The target state includes the latest values ​​of all attributes of the target player object, such as health, experience points, equipment status, and inventory items. In this embodiment, the game's main loop first obtains the incremental state correction value, which is the state correction amount calculated by the game's main loop based on the expected operation and historical operation sequence of the microservice request. Then, the game's main loop obtains the current state of the target player object, which is the state of the target player object when the game's main loop receives the response result of the asynchronous task. Next, the game's main loop adds or subtracts the state correction amount of each attribute in the incremental state correction value from the corresponding attribute value in the target player object's current state to obtain the corresponding attribute value in the target player object's target state. For example, if the health modifier in the incremental state modifier is 100, and the target player's current health is 1000, then the target player's target health will be 1100. If the asset balance modifier in the incremental state modifier is -50, and the target player's current asset balance is 500, then the target player's target asset balance will be 450. In this way, the game's main loop can correctly apply the incremental state modifier to the target player's current state to obtain the target player's target state.

[0109] Optional, such as Figure 5 As shown, the adaptive decision center first obtains the current state version number and the original state version number of the target player object, and then calls the conflict resolution function. Perform a state determination, such as checking if the current state version number is greater than the original state version number; if the current state version number is greater than the original state version number... > Original state version number Then, the adaptive decision center obtains the expected operation and historical operation sequence of the microservice request and determines whether they satisfy the commutative law. If they satisfy the commutative law, the adaptive decision center calculates the incremental state correction value of the target player object, merges the incremental state correction value with the current state of the target player object, and obtains the target state of the target player object. Finally, the adaptive decision center feeds back the target state of the target player object to the main game loop, and the main game loop updates the state of the target player object.

[0110] This embodiment introduces a commutative law judgment mechanism, enabling the game's main loop to accurately determine whether the expected operation and historical operation sequence of a microservice request can be swapped in execution order. This allows for the selection of an appropriate data merging strategy, improving the accuracy and efficiency of scheduling decisions. When the current state version number is greater than the original state version number and the expected operation and historical operation sequence of the microservice request satisfy the commutative law, an incremental state correction value is calculated. The game's main loop can then adjust the response results of asynchronous tasks based on the impact of the historical operation sequence on the target player object's state, ensuring that the results are correctly applied to the target player object's current state. This avoids data overwriting or logical errors, guaranteeing the correctness of game logic and data consistency. Through this incremental state correction mechanism, the game's main loop can fully leverage the advantages of asynchronous processing while ensuring data consistency, thereby improving system throughput and response speed, enhancing game smoothness, and enhancing the player experience.

[0111] In one exemplary embodiment, the response result of the asynchronous task includes the state increment of the target player object.

[0112] The response results of asynchronous tasks include metadata such as the state increment of the target player object and the original state version number. The state increment refers to the amount of state change of the target player object calculated by the target service based on the parameters of the microservice request, such as the increase in health points, the increase in experience points, and changes in equipment status.

[0113] In some embodiments, determining the incremental state correction value of the target player object includes: performing differential compensation on the state increment of the target player object and the historical operation sequence executed by the game's main loop during the process from the triggering of the microservice request to the receipt of the response result of the asynchronous task, to obtain the incremental state correction value.

[0114] Differential compensation refers to an algorithm in the game's main loop that calculates incremental state correction values ​​based on the target player object's state increment and historical operation sequences. The core idea of ​​differential compensation is to consider the impact of historical operation sequences on the target player object's state. By calculating the difference between the state increment and the historical operation sequence, an incremental state correction value that can be correctly applied to the target player object's current state is obtained. The differential compensation algorithm ensures that the response results of asynchronous tasks are correctly applied to the target player object's current state, avoiding data overwriting or logical errors. The differential compensation algorithm is one of the core algorithms in the state alignment and conflict resolution module, used to solve cross-frame asynchronous race conditions generated in "bypass paths."

[0115] Optionally, the incremental state correction value can be expressed using the following formula (2):

[0116]

[0117] in, This represents the target state of the target player object, which is the final state obtained after the main game loop merges the incremental state correction value and the current state of the target player object. This represents the current state of the target player object, that is, the state of the target player object when the main game loop receives the response result of the asynchronous task. This indicates a state merging operation, which applies the incremental state correction value to the current state of the target player object to obtain the target state of the target player object. This represents the differential compensation function, which is an algorithmic function that calculates the incremental state correction value based on the state increment and the historical operation sequence. This represents the state increment of the target player object, that is, the amount of state change of the target player object calculated by the target service based on the parameters of the microservice request, such as the increase in health points, the increase in experience points, and the change in equipment status. This represents the historical operation sequence, which is all the operations performed on the target player object during the process from triggering the microservice request to receiving the response result of the asynchronous task in the game's main loop, including the type of operation, parameters, and execution order.

[0118] In this embodiment, by introducing a differential compensation algorithm, the game's main loop can calculate incremental state correction values ​​based on the target player object's state increment and historical operation sequences. This ensures that the response results of asynchronous tasks are correctly applied to the target player object's current state. The differential compensation algorithm analyzes the impact of historical operation sequences on the target player object's state and calculates incremental state correction values ​​that are correctly applied to the target player object's current state, avoiding data overwriting or logical errors. Through this differential compensation mechanism, the game's main loop can fully utilize the advantages of asynchronous processing while ensuring data consistency, thereby improving system throughput and response speed, enhancing game smoothness, and improving the player experience.

[0119] In an exemplary embodiment, in response to the current state version number being greater than the original state version number, and the expected operation of the microservice request not satisfying the commutative law with the historical operation sequence executed by the game's main loop during the process of triggering the microservice request and receiving the response result of the asynchronous task, the response result of the asynchronous task is discarded, and the original state of the target player object remains unchanged.

[0120] In this scenario, the current state version number is greater than the original state version number, and the expected operation of the microservice request and the historical operation sequence executed by the game's main loop during the process of triggering the microservice request and receiving the asynchronous task's response do not satisfy the commutative law. This means that the target player object's state has changed during the process of triggering the microservice request and receiving the asynchronous task's response; that is, the target player object's current state is inconsistent with its original state when the microservice request was triggered. Furthermore, the execution order of the expected operation of the microservice request and the historical operation sequence will affect the final state result; that is, the expected operation of the microservice request and the historical operation sequence cannot be interchanged, resulting in the same state result. In this situation, directly applying the asynchronous task's response result to the target player object's current state will lead to data overwriting or logical errors. This is because the asynchronous task's response result is calculated based on the original state, while the target player object's current state has been modified by the historical operation sequence. Since the commutative law is not satisfied, the asynchronous task's response result cannot be adjusted using incremental state correction values. Therefore, the game's main loop needs to discard the asynchronous task's response result, keeping the target player object's original state unchanged to avoid data overwriting or logical errors.

[0121] In this embodiment, the game's main loop determines whether the expected operation and historical operation sequence of the microservice request satisfy the commutative law in the following way: First, the game's main loop obtains the type and parameters of the expected operation of the microservice request, such as increasing health, deducting asset balance, updating equipment status, etc.; second, the game's main loop obtains the historical operation sequence, that is, all operations performed on the target player object by the game's main loop during the process of triggering the microservice request and receiving the response result of the asynchronous task; then, the game's main loop determines whether they satisfy the commutative law based on the type and parameters of the expected operation and the historical operation sequence of the microservice request. The judgment methods include: if the expected operation of the microservice request is an incremental operation (such as increasing health or experience points), and the historical operation sequence is a decremental operation (such as deducting health or asset balance), then the commutative law is not satisfied; if the expected operation of the microservice request is a decremental operation (such as deducting health or asset balance), and the historical operation sequence is an incremental operation (such as increasing health or experience points), then the commutative law is not satisfied; if the expected operation of the microservice request and the historical operation sequence involve different operation types of the same attribute (such as one increasing health and the other deducting health), then the commutative law is not satisfied. In this way, the game's main loop can accurately determine whether the expected operation of the microservice request and the historical operation sequence satisfy the commutative law, thereby selecting an appropriate data merging strategy.

[0122] Optional, such as Figure 5 As shown, the adaptive decision center first obtains the current state version number and the original state version number of the target player object, and then calls the conflict resolution function. Perform a state determination, such as checking if the current state version number is greater than the original state version number; if the current state version number is greater than the original state version number... > Original state version number If the adaptive decision center obtains the expected operation and historical operation sequence of the microservice request, it determines whether they satisfy the commutative law. If they do not satisfy the commutative law, the adaptive decision center discards the response result of the asynchronous task and sends the information to maintain the original state of the target player object unchanged to the main game loop.

[0123] This embodiment introduces a commutative law judgment mechanism, enabling the game's main loop to accurately determine whether the expected and historical operation sequences of microservice requests can be swapped in execution order. This allows for the selection of an appropriate data merging strategy, improving the accuracy and efficiency of scheduling decisions. By discarding the response results of asynchronous tasks while maintaining the original state of the target player object, the game's main loop avoids logical errors caused by non-compliance with the commutative law, ensuring the correctness of game logic and data consistency. Through this hard conflict blocking mechanism, the game's main loop can fully leverage the advantages of asynchronous processing while ensuring data consistency, thereby improving system throughput and response speed, enhancing game smoothness, and improving the player experience.

[0124] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0125] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as read-only memory (ROM) / random access memory (RAM), magnetic disk, optical disk), and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0126] According to another aspect of the embodiments of this application, a game server scheduling apparatus is also provided. This game server scheduling apparatus can be used to implement the game server scheduling method provided in the above embodiments, and details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that implements a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0127] Figure 6 This is a structural block diagram of an optional game server scheduling device according to an embodiment of this application, such as... Figure 6 As shown, the game server scheduling device includes:

[0128] The prediction module 602 is used to respond to a microservice request received during the main loop of the game processing the current logical frame, predict the remaining frame time of the current logical frame, and predict the expected response latency of the microservice request; the remaining frame time refers to the available processing time that has not yet been consumed within the processing cycle of the current logical frame; the expected response latency refers to the time taken from the initiation of the microservice request to its return completion.

[0129] The selection module 604 is used to select a target scheduling strategy from multiple preset scheduling strategies based on the relative relationship between the remaining frame time of the current logical frame and the expected response latency of the microservice request.

[0130] The response module 606 is used to allocate a target thread to handle microservice requests according to the target scheduling strategy, so that the target thread can handle the microservice requests.

[0131] It should be noted that the prediction module 602 in this embodiment can be used to execute the above step S202, the selection module 604 in this embodiment can be used to execute the above step S204, and the response module 606 in this embodiment can be used to execute the above step S206.

[0132] In an exemplary embodiment, the main game loop records the start timestamp of each logical frame when processing each logical frame begins; the prediction module 602 is further configured to determine the timestamp difference between the current processing time of the current logical frame and the start timestamp of the current logical frame, and to determine the difference between the preset frame period upper limit and the timestamp difference as the remaining frame time of the current logical frame.

[0133] In an exemplary embodiment, the prediction module 602 is further configured to average the historical response latency corresponding to multiple historical requests of the same type as the microservice request to obtain the expected response latency of the microservice request.

[0134] In an exemplary embodiment, the selection module 604 is further configured to determine the first scheduling strategy among a plurality of preset scheduling strategies as the target scheduling strategy in response to the fact that the remaining frame time of the current logical frame is greater than or equal to the product between the expected response latency of the microservice request and the preset weight factor; the first scheduling strategy refers to the strategy of suspending the execution of the current logical frame by the main game loop until the main game loop receives the response result of the microservice request before executing the subsequent instructions of the current logical frame.

[0135] In an exemplary embodiment, the game's main loop updates the states of multiple player objects within the current logical frame; the microservice request is triggered by a target player object among the multiple player objects; the selection module 604 is further configured to, in response to the fact that the remaining frame time of the current logical frame is less than the product of the expected response latency of the microservice request and a preset weight factor, and that the attribute label of the microservice request indicates that the microservice request does not have latency tolerance characteristics, determine the second scheduling strategy among multiple preset scheduling strategies as the target scheduling strategy; the second scheduling strategy refers to the strategy by which the game's main loop returns the original state of the target player object before the microservice request was initiated from the local cache to the game's main loop.

[0136] In an exemplary embodiment, the selection module 604 is further configured to, in response to the fact that the remaining frame time of the current logical frame is less than the product of the expected response latency of the microservice request and the preset weight factor, and the attribute label of the microservice request indicates that the microservice request has latency tolerance characteristics, determine the third scheduling strategy among multiple preset scheduling strategies as the target scheduling strategy; the third scheduling strategy refers to the strategy in which the game main loop encapsulates the microservice request into an asynchronous task and submits it to the message queue, the game main loop immediately continues to execute, the asynchronous task is forwarded to the target service called by the microservice request through the message queue, and the response result of the asynchronous task is returned by the target service.

[0137] In an exemplary embodiment, the game's main loop updates the state of multiple player objects within the current logical frame; the microservice request is triggered by a target player object among the multiple player objects; the response result of the asynchronous task carries the original state version number of the target player object's original state when the microservice request was triggered; the response module 606 is further configured to, in response to receiving the response result of the asynchronous task, obtain the current state version number of the target player object's current state; and, in response to the original state version number being equal to the current state version number, merge the response result of the asynchronous task with the original state of the target player object.

[0138] In an exemplary embodiment, the response module 606 is further configured to respond to the fact that the current state version number is greater than the original state version number, and the expected operation of the microservice request and the historical operation sequence executed by the game's main loop during the process of triggering the microservice request to receiving the response result of the asynchronous task satisfy the commutative law, determine the incremental state correction value of the target player object, and merge the incremental state correction value and the current state of the target player object to obtain the target state of the target player object.

[0139] In an exemplary embodiment, the response result of the asynchronous task includes the state increment of the target player object; the response module 606 is further configured to perform differential compensation on the state increment of the target player object and the historical operation sequence executed by the game's main loop during the process from the triggering of the microservice request to the receipt of the response result of the asynchronous task, to obtain an incremental state correction value.

[0140] In an exemplary embodiment, the response module 606 is further configured to respond to the current state version number being greater than the original state version number, and the expected operation of the microservice request not satisfying the commutative law with the historical operation sequence executed by the game's main loop during the process of triggering the microservice request and receiving the response result of the asynchronous task, thereby discarding the response result of the asynchronous task and keeping the original state of the target player object unchanged.

[0141] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0142] According to another aspect of the embodiments of this application, a computer-readable storage medium is provided, the computer-readable storage medium including a stored program, wherein the program executes the steps in any of the above method embodiments when it is run.

[0143] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as USB flash drives, ROMs, RAMs, portable hard drives, magnetic disks, or optical disks.

[0144] According to another aspect of the embodiments of this application, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. The processor is configured to perform the steps of any of the method embodiments described above via the computer program. In an exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.

[0145] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.

[0146] According to another aspect of the embodiments of this application, a computer program product is also provided, comprising a computer program / instructions containing program code for performing the methods shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via communication section 709, and / or installed from removable medium 711. When the computer program is executed by central processing unit 701, it performs various functions provided in the embodiments of this application. The sequence numbers of the embodiments of this application above are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0147] Figure 7 A schematic block diagram of a computer system architecture for implementing embodiments of the present application is shown. Figure 7 As shown, the computer system 700 includes a Central Processing Unit (CPU) 701, which performs various appropriate actions and processes based on programs stored in ROM 702 or loaded into RAM 703 from storage section 708. Random access memory 703 also stores various programs and data required for system operation. The CPU 701, ROM 702, and RAM 703 are interconnected via bus 704. Input / output (I / O) interface 705 is also connected to bus 704.

[0148] The following components are connected to the I / O interface 705: an input section 706 including a keyboard, mouse, etc.; an output section 707 including a cathode ray tube (CRT), liquid crystal display (LCD), and speakers, etc.; a storage section 708 including a hard disk, etc.; and a communication section 709 including a network interface card, such as a local area network card or modem, etc. The communication section 709 performs communication processing via a network such as the Internet. A drive 710 is also connected to the input / output interface 705 as needed. A removable medium 711, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 710 as needed so that computer programs read from it can be installed into the storage section 708 as needed.

[0149] Specifically, according to embodiments of this application, the processes described in the various method flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 709, and / or installed from removable medium 711. When the computer program is executed by central processing unit 701, it performs various functions defined in the system of this application.

[0150] It should be noted that, Figure 7 The computer system 700 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0151] Obviously, those skilled in the art should understand that the modules or steps of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those described herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, this application is not limited to any particular combination of hardware and software.

[0152] The above are merely preferred embodiments of this application and are not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the principles of this application should be included within the protection scope of this application.

Claims

1. A game server scheduling method, characterized in that, include: In response to receiving a microservice request during the main game loop's processing of the current logical frame, the remaining frame time of the current logical frame is predicted, and the expected response latency of the microservice request is predicted; the remaining frame time refers to the available processing time that has not yet been consumed within the processing cycle of the current logical frame; the expected response latency refers to the time taken from the initiation of the microservice request to its return completion. Based on the relative relationship between the remaining frame time of the current logical frame and the expected response latency of the microservice request, a target scheduling strategy is selected from multiple preset scheduling strategies. According to the target scheduling policy, a target thread is allocated to process the microservice request, so that the microservice request can be processed by the target thread.

2. The method according to claim 1, characterized in that, The game's main loop records the start timestamp of each logical frame when it begins processing; predicting the remaining time of the current logical frame includes: The timestamp difference between the current processing time of the current logical frame and the start timestamp of the current logical frame is determined, and the difference between the preset frame period upper limit and the timestamp difference is determined as the remaining frame time of the current logical frame.

3. The method according to claim 1, characterized in that, The prediction of the expected response latency for the microservice request includes: The expected response latency of the microservice request is obtained by averaging the historical response latency of multiple historical requests of the same type as the microservice request.

4. The method according to claim 1, characterized in that, The step of selecting a target scheduling strategy from multiple preset scheduling strategies based on the relative relationship between the remaining frame time of the current logical frame and the expected response latency of the microservice request includes: In response to the fact that the remaining frame time of the current logical frame is greater than or equal to the product of the expected response latency of the microservice request and a preset weight factor, the first scheduling strategy among the plurality of preset scheduling strategies is determined as the target scheduling strategy; the first scheduling strategy refers to the strategy in which the game main loop suspends the execution of the current logical frame until the game main loop receives the response result of the microservice request before executing the subsequent instructions of the current logical frame.

5. The method according to claim 1, characterized in that, The game's main loop updates the states of multiple player objects within the current logical frame; the microservice request is triggered by a target player object among the multiple player objects; the selection of a target scheduling strategy from multiple preset scheduling strategies based on the relative relationship between the remaining frame time of the current logical frame and the expected response latency of the microservice request includes: In response to the fact that the remaining frame time of the current logical frame is less than the product of the expected response latency of the microservice request and the preset weight factor, and the attribute label of the microservice request indicates that the microservice request does not have latency tolerance characteristics, the second scheduling strategy among the multiple preset scheduling strategies is determined as the target scheduling strategy; the second scheduling strategy refers to the strategy of returning the original state of the target player object in the local cache before initiating the microservice request to the game main loop.

6. The method according to claim 1, characterized in that, The step of selecting a target scheduling strategy from multiple preset scheduling strategies based on the relative relationship between the remaining frame time of the current logical frame and the expected response latency of the microservice request includes: In response to the fact that the remaining frame time of the current logical frame is less than the product of the expected response latency of the microservice request and the preset weight factor, and the attribute label of the microservice request indicates that the microservice request has latency tolerance characteristics, the third scheduling strategy among the multiple preset scheduling strategies is determined as the target scheduling strategy; the third scheduling strategy refers to the strategy in which the game main loop encapsulates the microservice request into an asynchronous task and submits it to the message queue, the game main loop immediately continues to execute, and forwards the asynchronous task to the target service called by the microservice request through the message queue, and the target service returns the response result of the asynchronous task.

7. The method according to claim 6, characterized in that, The main game loop updates the state of multiple player objects within the current logic frame; the microservice request is triggered by the target player object among the multiple player objects; the response result of the asynchronous task carries the original state version number of the target player object's original state when the microservice request was triggered; The method further includes: In response to receiving the response result of the asynchronous task, obtain the current state version number of the target player object's current state; In response to the original state version number being equal to the current state version number, the response result of the asynchronous task is merged with the original state of the target player object.

8. The method according to claim 7, characterized in that, The method further includes: In response to the current state version number being greater than the original state version number, and the expected operation of the microservice request satisfying the commutative law with the historical operation sequence executed by the game's main loop during the process of triggering the microservice request and receiving the response result of the asynchronous task, the incremental state correction value of the target player object is determined, and the incremental state correction value and the current state of the target player object are merged to obtain the target state of the target player object.

9. The method according to claim 8, characterized in that, The response result of the asynchronous task includes the state increment of the target player object; determining the incremental state correction value of the target player object includes: The incremental state correction value is obtained by differentially compensating the state increment of the target player object and the historical operation sequence executed by the main game loop during the process from the triggering of the microservice request to the receipt of the response result of the asynchronous task.

10. The method according to claim 7, characterized in that, The method further includes: If the current state version number is greater than the original state version number, and the expected operation of the microservice request does not satisfy the commutative law with the historical operation sequence executed by the game's main loop during the process of triggering the microservice request and receiving the response result of the asynchronous task, the response result of the asynchronous task is discarded, and the original state of the target player object remains unchanged.

11. A game server scheduling device, characterized in that, include: The prediction module is used to respond to a microservice request received during the main game loop's processing of the current logical frame, predict the remaining frame time of the current logical frame, and predict the expected response latency of the microservice request; the remaining frame time refers to the available processing time that has not yet been consumed within the processing cycle of the current logical frame; the expected response latency refers to the time taken from the initiation of the microservice request to its return completion. The selection module is used to select a target scheduling strategy from multiple preset scheduling strategies based on the relative relationship between the remaining frame time of the current logical frame and the expected response latency of the microservice request. The response module is used to allocate a target thread to process the microservice request according to the target scheduling policy, so that the target thread can process the microservice request.

12. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 10.

Images