Method and system for automatic scaling and load balancing of distributed game servers

Abstract

This invention relates to the fields of computer network technology and game server technology, specifically to a method and system for automatic scaling up and down and load balancing of distributed game servers. The method involves: configuring operational indicators and corresponding thresholds to trigger scaling up and down; collecting real-time data and comparing it with the thresholds; and determining whether to trigger a scaling up or down process based on the comparison result. If a scaling up process is triggered, server resources are automatically used to deploy new stateful service nodes, synchronize basic data and service registration, and allocate new users to the new stateful service nodes using a load balancing algorithm. If a scaling down process is triggered, stateful service nodes of the combat suit type are scaled down. This invention can achieve fully automated scaling up and down and precise load balancing, improving service response efficiency and optimizing resource utilization.

Description

Technical Field

[0001] This invention belongs to the field of computer network technology and game server technology, specifically relating to a method and system for automatic scaling and load balancing of distributed game servers. Background Technology

[0002] In a distributed mobile game server architecture, the Game service, which carries the core business, is a stateful service. It needs to be bound to core business data such as player character data and battle progress. The scaling up and down of such stateful services has always been a recognized technical pain point in the industry.

[0003] In existing technologies, the scaling up and down of distributed game servers mainly relies on manual intervention: operations and maintenance personnel need to estimate user growth based on experience, such as during game events or holidays when players may surge, and manually build new service nodes to handle the increased traffic. This traditional approach has many significant drawbacks: Firstly, the response is slow and the process is cumbersome. New server deployment usually takes several hours, which cannot quickly cope with sudden traffic peaks and can easily lead to server overload and response delays. Secondly, resource allocation is unbalanced, and manual estimation is prone to errors. Overestimation will lead to idle and wasted server resources, while underestimation may cause service crashes and seriously affect user experience. Third, uneven load distribution. The allocation of new server users relies on fixed manual rules, which can easily lead to some servers being congested while others are deserted, disrupting the game's ecological balance and reducing player retention. Therefore, there is an urgent need for a technical solution that can achieve automatic scaling and precise load balancing of stateful services to solve the problems of reliance on manual labor, slow response, low resource utilization, and uneven load distribution in existing technologies. Summary of the Invention

[0004] To address the problems of manual scaling, slow response, low resource utilization, and uneven load distribution in existing distributed game server scaling solutions, this invention provides a method and system for automatic scaling and load balancing of distributed game servers, achieving fully automated scaling and precise load balancing, improving service response efficiency, and optimizing resource utilization.

[0005] The technical solution of the present invention is as follows: The method for automatic scaling and load balancing of distributed game servers includes the following steps: Step 1: Configure the operational metrics and corresponding thresholds that trigger scaling up or down; Step 2: Collect real-time data and compare it with the threshold. Based on the comparison result, determine whether to trigger the expansion or contraction process. Step 3: If the expansion process is triggered, server resources will be automatically used to deploy new stateful service nodes, synchronize basic data and service registration, and allocate new users to the new stateful service nodes through a load balancing algorithm. Step 4: If the scaling down process is triggered, then scale down the stateful service nodes of the combat suit type.

[0006] Furthermore, the operational metrics include the number of registered users, the number of paying users, CPU utilization, and memory usage.

[0007] Furthermore, the threshold includes an expansion threshold and a reduction threshold; The expansion thresholds include: registered users ≥ 20,000, paying users ≥ 800, CPU utilization ≥ 75%, and memory usage ≥ 80%. The scaling-down thresholds include CPU utilization ≤30% and memory usage ≤40%.

[0008] Furthermore, expansion triggering: When the number of registered users or paying users of any game service node reaches the expansion threshold within 3 collection cycles, or when the CPU and memory usage exceed the expansion threshold within 5 collection cycles, the expansion process is automatically triggered. Scaling down trigger: When the CPU or memory usage of any combat suit is below the scaling down threshold within 15 collection cycles, the scaling down process is automatically triggered.

[0009] Furthermore, step 3 specifically involves: After the expansion is triggered, cloud server resources are called through automated scripts to quickly build new stateful service nodes. The deployment process includes automating environment configuration, basic data synchronization, and registration and integration with Proxy Service, WorldService, game Server, or Battle Server. The new stateful service node is independently connected to the local MySQL storage, and synchronizes basic game data through data snapshot technology, and allocates new users to the new stateful service node; The load balancing algorithm is a hybrid balancing algorithm that combines round-robin with load weight. It dynamically allocates newly registered users or cross-server requests to stateful service nodes with lower loads. The allocation weight is negatively correlated with the current CPU utilization and memory usage of the stateful service nodes, ensuring that the load deviation of each stateful service node does not exceed 10%.

[0010] Furthermore, the execution process of the hybrid load balancing algorithm includes: initializing a list of stateful service nodes and a corresponding weight list; allocating requests according to the weight of the current stateful service node; prioritizing the allocation of requests to stateful service nodes with larger weights; until the weight of the stateful service node is 0, then the allocation of requests to the current stateful service node is completed. Repeat the above process until all nodes in the stateful service node list have been allocated. Then reset the remaining weights and allocation pointers, and repeat the allocation process.

[0011] Furthermore, step 4 specifically involves: performing a scaling-down operation on stateful service nodes of the combat suit type. First, the service status of the target scaling-down combat suit node is switched to unavailable, so that the subsequent service request allocation strategy no longer selects the target scaling-down node; after all players on the target scaling-down node have completed the offline operation, the server resources of the target scaling-down node are automatically released, and the removal of the entire combat suit node is completed.

[0012] Furthermore, the stateful service node is a service node bound to core business data and communicates based on Netty.

[0013] A distributed game server auto-scaling and load balancing system includes: Metrics configuration module: Used to configure the operational metrics that trigger scaling up or down and their corresponding thresholds; Monitoring, data collection and trigger determination module: used to collect operational indicator data of each service node in real time, compare the indicator data with the threshold, and determine whether to trigger scaling up or down. Scaling up and down execution module: When the scaling up process is triggered, it calls server resources to deploy new stateful service nodes, synchronizes basic data and service registration, and allocates new users to the new stateful service nodes through a load balancing algorithm. Load balancing module: When the scaling-down process is triggered, stateful service nodes of the combat suit type are scaled down to release the resources of redundant stateful service nodes.

[0014] Compared with the prior art, the present invention has the following beneficial effects: (1) Breaking through the technical limitations of scaling up and down stateful services: For the first time, fully automated scaling up and down of distributed game stateful services based on operational indicators has been realized, eliminating the dependence on manual intervention and solving the pain points of slow response and cumbersome process in traditional solutions. It can quickly cope with sudden traffic peaks.

[0015] (2) Significantly improved response efficiency: By deploying new service nodes through automated scripts, the deployment time is shortened to minutes (≤5 minutes). Compared with the traditional manual deployment that takes several hours, the expansion response speed is greatly improved, effectively avoiding user loss due to server overload.

[0016] (3) Resource utilization optimization: Based on preset operation indicators and thresholds, the expansion and contraction are dynamically triggered, avoiding the problem of idle or insufficient resources caused by manual estimation errors. The contraction mechanism can release redundant resources in a timely manner, reducing server operating costs by more than 30%.

[0017] (4) Precise and balanced load distribution: A hybrid load balancing algorithm combining round-robin and load weight is adopted. The weight is negatively correlated with the CPU and memory usage of the nodes, ensuring that the load deviation of each service node does not exceed 10%, avoiding the situation of crowded or deserted new servers, maintaining the balance of the game ecosystem, and improving the player experience and retention rate.

[0018] (5) Significantly reduced operation and maintenance costs: The entire process is automated and requires no manual intervention, saving more than 90% of the manpower costs for expansion and contraction operations and maintenance. At the same time, it reduces service risks caused by human error and improves service stability. Attached Figure Description

[0019] Figure 1 This is a flowchart of the method of the present invention. Detailed Implementation

[0020] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments.

[0021] A method for automatic scaling and load balancing of a distributed game server, comprising the following steps: Step 1: Configure the operational metrics and corresponding thresholds that trigger scaling up or down; the operational metrics include the number of registered users, the number of paying users, CPU utilization, and memory usage; the thresholds include scaling up thresholds and scaling down thresholds; In a preferred embodiment of the present invention, the expansion threshold is ≥20,000 registered users (which can be configured according to the specific project), ≥800 paying users, CPU utilization ≥75%, and memory usage ≥80%, while the reduction threshold is ≤30% CPU utilization and ≤40% memory usage.

[0022] Step 2: Collect real-time operational indicator data of each stateful service node, compare the real-time data with preset thresholds, and determine whether to trigger the expansion or contraction process based on the comparison results. The expansion trigger conditions are: the number of registered users or paying users of any game service node reaches the expansion threshold in several collection cycles, or the CPU and memory usage exceeds the expansion threshold in several collection cycles, and the expansion process is automatically triggered. The scaling down trigger condition is: when the CPU or memory usage of any combat suit is lower than the scaling down threshold within 15 collection cycles, the scaling down process is automatically triggered.

[0023] Each of the above-mentioned data collection cycles can be manually set and can be configured according to actual conditions.

[0024] Step 3: If the expansion process is triggered, server resources are automatically allocated to deploy new stateful service nodes, synchronize basic data and service registration, and new users are assigned to the new stateful service nodes through a load balancing algorithm; the stateful service nodes are service nodes bound to core business data and communicate based on Netty. The specific deployment process includes using automated scripts to call cloud server resources, quickly building new stateful service nodes, and automating environment configuration, basic data synchronization, and registration and integration with Proxy Service, WorldService, game Server, or Battle Server. The new stateful service nodes are independently connected to local MySQL storage, and basic game data is synchronized through data snapshot technology. Only newly added users are allocated to the new stateful service nodes, without migrating existing player data. The load balancing algorithm is a hybrid algorithm combining round-robin and load weight, which dynamically allocates newly registered users or cross-server requests to stateful service nodes with lower loads. The allocation weight is negatively correlated with the current CPU utilization and memory usage of the stateful service nodes, ensuring that the load deviation of each stateful service node does not exceed 10%. The execution process of the hybrid load balancing algorithm includes: initializing a list of stateful service nodes and a corresponding weight list; allocating requests according to the weight of the current stateful service node, prioritizing the allocation of requests to stateful service nodes with larger weights, until the weight of the stateful service node is 0, at which point the allocation of the current stateful service node is complete; repeating the above process until all nodes in the list of stateful service nodes have been allocated, then resetting the remaining weights and allocation pointers, and repeating the allocation process.

[0025] Step 4: If the scaling down process is triggered, execute the corresponding scaling down operation; For stateful service nodes of the combat suit type, a scaling-down operation is performed. First, the service status of the target combat suit node to be scaled down is switched to unavailable, so that the subsequent service request allocation strategy will no longer select the target scaling-down node. After all players on the target scaling-down node have completed the offline operation, the server resources of the target scaling-down node are automatically released, and the entire combat suit node is removed.

[0026] A distributed game server auto-scaling and load balancing system includes: Metrics configuration module: Used to configure the operational metrics that trigger scaling up or down and their corresponding thresholds; Monitoring, data collection and trigger determination module: used to collect operational indicator data of each service node in real time, compare the indicator data with the threshold, and determine whether to trigger scaling up or down. Scaling up and down execution module: When the scaling up process is triggered, it calls server resources to deploy new stateful service nodes, synchronizes basic data and service registration, and allocates new users to the new stateful service nodes through a load balancing algorithm. Load balancing module: When the scaling-down process is triggered, the battle server will be scaled down to release the resources of redundant stateful service nodes.

[0027] Example 1: Capacity expansion scenario during traffic transfer This embodiment uses a scenario of a surge in player registrations during a game's user acquisition period as an example to illustrate the implementation process of the present invention in detail: Metric Configuration: The metric configuration module allows you to preset operational metrics and thresholds. The expansion threshold for registered users is 20,000 (this can be configured according to the specific project), the expansion threshold for paying users is 800, the expansion threshold for CPU utilization is 75%, and the expansion threshold for memory usage is 80%. The reduction thresholds are CPU utilization ≤30% and memory usage ≤40%. A monitoring module is also set up.

[0028] Monitoring, data collection, and trigger determination: After the game's traffic acquisition was launched, the number of player registrations increased rapidly. The monitoring, data collection, and trigger determination module collected operational indicator data from each Game service node in real time. When it was detected that the number of registered users on stateful service node A reached 20,000 for three consecutive data collection periods, the expansion process was triggered.

[0029] Scaling up / down execution: After receiving the scaling up / down trigger signal, the scaling up / down execution module uses an automated script to call cloud server resources and start the deployment process of the new stateful service node B. The system automates environment configuration, including installing dependencies required for the game service to run and configuring network parameters. Basic game data, including game item information, basic configuration, map data, etc., is synchronized through data snapshot technology. The new stateful service node B is independently connected to local MySQL storage to ensure data isolation and consistency. After stateful service node B completes deployment, it automatically registers and connects with the Proxy Service, the cross-server WorldService, the Game, and the game server to complete service access. The entire deployment process takes 5 minutes.

[0030] Load balancing: After detecting that stateful service node B is online, the load distribution weight is adjusted through a hybrid load balancing algorithm to distribute the subsequent newly registered users to stateful service nodes, ensuring load balancing among all stateful service nodes.

[0031] Example 2: This example uses a scenario with 3 service nodes to illustrate the execution logic of the hybrid load balancing algorithm in detail: Assuming the current list of stateful service nodes is [A, B, C], and the weight list calculated based on the current CPU and memory usage of each node is [3, 2, 1] (weights are negatively correlated with load), the algorithm execution process is as follows: Initialization: Node list [A,B,C], weight list [3,2,1], current pointer index=0, remaining weights remainingW=[3,2,1]; First request: The pointer points to A, an allocation request is made, the remaining weight of A changes from 3 to 2, and the allocation result is A; Second request: A's remaining weight > 0, continue to allocate to A, remaining weight 2 → 1, allocation result: A; Third request: A's remaining weight > 0, continue to allocate to A, remaining weight 1 → 0, allocation result: A; Fourth request: A's remaining weight = 0, the pointer moves to B, allocation request, B's remaining weight 2 → 1, allocation result: B; 5th request: B's remaining weight > 0, continue to allocate to B, remaining weight 1 → 0, allocation result: B; 6th request: B's remaining weight = 0, the pointer moves to C, allocation request, C's remaining weight 1→0, allocation result: C; Request 7: One round of allocation is completed. Reset the remaining weights [3,2,1] and pointer index=0. Repeat the allocation logic of step 2. Allocation result: A; Subsequent requests are distributed cyclically according to the above process to ensure that the load on each stateful service node is evenly distributed.

[0032] Example 3: Scaling-down scenario For example, in a game, a combat server is selected for each battle. In this embodiment, there are a total of 10 online combat servers. If the number of online players, CPU, bandwidth, and memory parameters of a combat server fall below a certain threshold, the monitoring module will detect this and trigger scaling down. This simply involves switching the status of a particular combat server to unavailable. In subsequent combat server selection strategies, it will not be selected again. Once all players on the combat server have logged off, the entire combat server node can be removed.

[0033] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent structural or procedural transformations made based on the content of the present invention's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for automatic scaling and load balancing of distributed game servers, characterized in that, Includes the following steps: Step 1: Configure the operational metrics and corresponding thresholds that trigger scaling up or down; Step 2: Collect real-time data and compare it with the threshold. Based on the comparison result, determine whether to trigger the expansion or contraction process. Step 3: If the expansion process is triggered, server resources will be automatically used to deploy new stateful service nodes, synchronize basic data and service registration, and allocate new users to the new stateful service nodes through a load balancing algorithm. Step 4: If the scaling down process is triggered, then scale down the stateful service nodes of the combat suit type.

2. The method and system for automatic scaling and load balancing of a distributed game server according to claim 1, characterized in that, The operational metrics include the number of registered users, the number of paying users, CPU utilization, and memory usage.

3. The method for automatic scaling and load balancing of a distributed game server according to claim 2, characterized in that, The thresholds include expansion thresholds and reduction thresholds; The expansion thresholds include: registered users ≥ 20,000, paying users ≥ 800, CPU utilization ≥ 75%, and memory usage ≥ 80%. The scaling-down thresholds include CPU utilization ≤30% and memory usage ≤40%.

4. The method for automatic scaling and load balancing of a distributed game server according to claim 3, characterized in that, Expansion Trigger: When the number of registered users or the number of paying users of any game service node reaches the expansion threshold within 3 collection cycles, or when the CPU and memory usage exceed the expansion threshold within 5 collection cycles, the expansion process is automatically triggered. Scaling down trigger: When the CPU or memory usage of any combat suit is below the scaling down threshold within 15 collection cycles, the scaling down process is automatically triggered.

5. The method for automatic scaling and load balancing of a distributed game server according to claim 1, characterized in that, Step 3 specifically involves: After the expansion is triggered, cloud server resources are called through automated scripts to quickly build new stateful service nodes. The deployment process includes automating environment configuration, basic data synchronization, and registration and integration with Proxy Service, WorldService, game Server, or Battle Server. The new stateful service node is independently connected to the local MySQL storage, and synchronizes basic game data through data snapshot technology, and allocates new users to the new stateful service node; The load balancing algorithm is a hybrid balancing algorithm that combines round-robin with load weight. It dynamically allocates newly registered users or cross-server requests to stateful service nodes with lower loads. The allocation weight is negatively correlated with the current CPU utilization and memory usage of the stateful service nodes, ensuring that the load deviation of each stateful service node does not exceed 10%.

6. The method for automatic scaling and load balancing of a distributed game server according to claim 5, characterized in that, The execution process of the hybrid load balancing algorithm includes: initializing a list of stateful service nodes and a corresponding weight list; allocating requests according to the weight of the current stateful service node, prioritizing the allocation of requests to stateful service nodes with larger weights, until the weight of the stateful service node is 0, at which point the allocation of requests to the current stateful service node is complete. Repeat the above process until all nodes in the stateful service node list have been allocated. Then reset the remaining weights and allocation pointers, and repeat the allocation process.

7. The method for automatic scaling and load balancing of a distributed game server according to claim 1, characterized in that, Step 4 specifically involves performing a scaling-down operation on stateful service nodes of the combat suit type. First, the service status of the target combat suit node to be scaled down is switched to unavailable, so that the subsequent service request allocation strategy will no longer select the target scaling-down node. Once all players on the target shrinking node have logged off, the server resources of that target shrinking node will be automatically released, completing the removal of the entire combat server node.

8. The method for automatic scaling and load balancing of a distributed game server according to claim 1, characterized in that, The stateful service node is a service node bound to core business data and communicates based on Netty.

9. A distributed game server automatic scaling and load balancing system, characterized in that, include: Metrics configuration module: Used to configure the operational metrics that trigger scaling up or down and their corresponding thresholds; Monitoring, data collection and trigger determination module: used to collect operational indicator data of each service node in real time, compare the indicator data with the threshold, and determine whether to trigger scaling up or down. Scaling up and down execution module: When the scaling up process is triggered, it calls server resources to deploy new stateful service nodes, synchronizes basic data and service registration, and allocates new users to the new stateful service nodes through a load balancing algorithm. Load balancing module: When the scaling-down process is triggered, stateful service nodes of the combat suit type are scaled down to release the resources of redundant stateful service nodes.

Images