Game data processing method, system and storage medium

Abstract

The present invention relates to the technical field of intelligent optimization and load balancing, and in particular to a method, system, and storage medium for processing game data. The method comprises the following steps: acquiring game data and extracting game player features based on the game data to obtain game player data; identifying abnormal players based on the game player data to obtain abnormal player data; extracting server resource features and server communication features based on the game data to obtain server resource data and server communication data; performing load management anomaly analysis based on the server resource data and server communication data to obtain load management anomaly data; and performing correlation analysis based on the load management anomaly data and abnormal player data to obtain abnormal player load management data. The present invention improves user experience and ensures stable game operation based on intelligent optimization and load balancing technologies.

Description

Technical Field

[0001] The present invention relates to the technical field of intelligent optimization and load balancing, and in particular to a method, system and storage medium for processing game data. Background Art

[0002] Traditional game data processing methods typically rely on simple rules or thresholds for anomaly detection, failing to effectively identify complex in-game abnormalities, such as various cheating methods (hacks, packet tampering, script attacks, etc.) and server load issues caused by abnormal player behavior. This leaves game servers vulnerable to attacks in high-concurrency, high-traffic scenarios, resulting in a poor player experience and difficulty remediating vulnerabilities in a timely manner. Traditional load balancing mechanisms often rely on preset rules and simple load distribution strategies. When player behavior changes within a game, traditional load balancing mechanisms struggle to respond and adjust quickly, easily leading to localized resource overload, increased latency, and unstable services, impacting the user experience. Existing network attack detection methods (such as DDoS attacks and flooding attacks) typically rely on traffic monitoring and simple feature matching, failing to identify and respond to highly complex attack methods in real time. Inadequate analysis of attack sources and patterns results in long response times after an attack, causing game servers to become unavailable or significantly degraded in performance. Summary of the Invention

[0003] Based on this, it is necessary for the present invention to provide a method, system and storage medium for processing game data to solve at least one of the above technical problems.

[0004] To achieve the above-mentioned purpose, a method for processing game data includes the following steps:

[0005] Step S1: Obtaining game data, and extracting game player features based on the game data to obtain game player data; identifying abnormal players based on the game player data to obtain abnormal player data;

[0006] Step S2: extracting server resource features and server communication features based on the game data to obtain server resource data and server communication data; performing load management anomaly analysis based on the server resource data and server communication data to obtain load management anomaly data;

[0007] Step S3: performing correlation analysis based on the abnormal load management data and the abnormal player data, thereby obtaining abnormal player load management data;

[0008] Step S4: extracting CPU load features based on the game data to obtain CPU load data, and performing high load analysis based on the CPU load data to obtain CPU high load data;

[0009] Step S5: Perform game load balancing optimization analysis based on CPU high load data and abnormal player load management data to obtain game load balancing data.

[0010] By extracting the characteristics of game players and identifying abnormal players, the present invention can promptly detect possible cheating behaviors and malicious attacks, and then take effective countermeasures to prevent unnecessary pressure on server resources. The analysis of server resource data and communication data enables the system to accurately monitor load management anomalies. Through this multi-dimensional data analysis, the system's load problems and potential attack sources can be effectively detected, providing a basis for subsequent optimization and repair. By further performing correlation analysis, the relationship between abnormal players and load management anomalies can be clarified, and it is accurately located which players' behaviors may cause server load anomalies, so as to carry out targeted optimization and adjustment. Analysis based on CPU load data can effectively identify high system load conditions and adjust the load distribution strategy in real time to avoid server performance degradation or crashes caused by local resource overload. Ultimately, by comprehensively considering abnormal player behavior and server load, a dynamic load balancing optimization solution is provided, which enables the system to automatically respond to changes in player behavior and maintain the stability and smoothness of game services. In addition, the present invention also combines multiple modules such as anomaly detection, attack identification, and load analysis when processing game data. It can respond to complex network attacks such as DDoS and flood attacks in real time, greatly improving the server's ability to withstand pressure under high traffic and high concurrency conditions, effectively avoiding the game server's shutdown or performance degradation caused by attacks, and further improving the user experience and the reliability of game services.

[0011] Optionally, step S1 specifically includes:

[0012] Step S11: Obtaining game data, and extracting game player features based on the game data, thereby obtaining game player data;

[0013] Step S12: performing data packet tampering detection based on the game player data, thereby obtaining game player data packet tampering data;

[0014] Step S13: performing game time statistics on the game player data to obtain short-time game player data;

[0015] Step S14: performing kill count statistics on the game player data, thereby obtaining game player data with a high kill count;

[0016] Step S15: performing an intersection operation of potential abnormal players based on the short-time game player data and the high-kill game player data, thereby obtaining potential abnormal player data;

[0017] Step S16: Identify abnormal players based on the game player data packet tampering data, thereby obtaining abnormal player data.

[0018] By extracting player characteristics, the present invention enables a comprehensive understanding of player behavior patterns, thereby identifying possible anomalous behavior and laying the foundation for subsequent identification of abnormal players. By performing packet tampering detection on game data, it is possible to effectively detect whether players are influencing the game process through cheats or tampering tools, promptly identifying cheating behavior and preventing it from disrupting the gaming environment. Game time statistics and kill count statistics can help the system identify players who are excessively active or have abnormal kill counts within a short period of time. These player behaviors are often indicative of attack or cheating. Combining the intersection of short-term game data and high-kill count game data can further target potential anomalous player groups and improve the accuracy of anomaly detection. By combining packet tampering information with potential anomalous players, it is possible to efficiently identify players who both exhibit suspicious behavior and may cheat through tampering, thereby enhancing the reliability of anomalous player identification. This series of steps enables the system to quickly identify anomalous players and potential attackers in high-concurrency and high-traffic situations, thereby taking effective measures to prevent server overload or performance degradation caused by attacks, significantly improving the player's gaming experience. This approach enables dynamic detection and timely response, avoiding the limitations of traditional methods based on fixed rules or thresholds. It enables game servers to maintain stable operation in complex and changing environments, and effectively prevents in-game cheating and attacks from affecting the system.

[0019] Optionally, step S12 is specifically as follows:

[0020] Step S121: Calculate the client hash value based on the game player data to obtain the client hash value;

[0021] Step S122: Calculating a server hash value based on the game player data to obtain a server hash value;

[0022] Step S123: performing a preliminary judgment on whether the data packet has been tampered with based on the client hash value and the server hash value, thereby obtaining preliminary judgment data on whether the data packet has been tampered with;

[0023] Step S124: extracting data packet features from the game player data to obtain game player data packet data;

[0024] Step S125: performing distribution time statistics based on the game player data packet data, thereby obtaining the game player data packet distribution time data;

[0025] Step S126: performing sequence check on the game player data packet release time data to obtain out-of-order data packets;

[0026] Step S127: confirming the tampering of the data packet preliminary judgment data according to the disordered data packet, thereby obtaining the game player's data packet tampering data.

[0027] The present invention improves the accuracy and real-time performance of packet tampering detection through precise hash value calculation, packet feature extraction, and delivery time statistics. First, the calculation of hash values ​​between the client and server ensures the consistency of packet content during transmission, enabling rapid detection of potential tampering between the client and server. By initially determining whether a packet has been tampered with, cheating attempts in the game, such as hacking and malicious script attacks, can be effectively intercepted. Next, by extracting packet features and performing delivery time statistics, the packet analysis process is further refined, allowing for more accurate determination of packet legitimacy. Packet sequence verification effectively identifies out-of-order packets, promptly detecting network attacks or packet tampering, and preventing game process disruptions or errors caused by out-of-order packets. Finally, the combination of out-of-order packet confirmation and tampered data verification further enhances the identification of packet tampering, enabling the system to accurately identify and filter out maliciously tampered data, thereby ensuring the integrity and security of game data. This entire detection process not only accurately and timely identifies and prevents cheating, but also enhances the game server's protection capabilities, reduces the risk of system failures caused by packet tampering, and optimizes the player experience.

[0028] Optionally, step S2 is specifically:

[0029] Step S21: extracting server resource features and server communication features based on the game data, thereby obtaining server resource data and server communication data;

[0030] Step S22: performing memory leak anomaly analysis on the server resource data to obtain memory leak anomaly data;

[0031] Step S23: performing communication mode anomaly analysis on the server communication data to obtain communication mode anomaly data;

[0032] Step S24: performing load management anomaly integration according to the memory leak anomaly data and the communication mode anomaly data, thereby obtaining load management anomaly data.

[0033] The present invention can comprehensively monitor the status of the server by extracting server resources and communication characteristics, and promptly discover possible resource bottlenecks or abnormal behaviors. By performing memory leak anomaly analysis on server resource data, memory leak problems can be efficiently identified, memory resources can be prevented from being improperly consumed, and the stable operation of the game server can be guaranteed. At the same time, by performing communication mode anomaly analysis on server communication data, abnormal behaviors that may occur in communication, such as overload, delay, packet loss or communication congestion, can be effectively identified, and signs of network attacks or system failures can be quickly discovered. Finally, by integrating memory leak anomaly data and communication mode anomaly data, a more comprehensive load management anomaly detection mechanism is provided, which can comprehensively identify server load problems caused by abnormal player behavior or attacks. This integrated analysis method can not only improve the resource allocation efficiency of the server, but also respond quickly under high concurrency and high traffic conditions, avoiding system crashes or performance degradation caused by excessive server load, greatly improving the stability of game services and player experience.

[0034] Optionally, step S22 is specifically as follows:

[0035] Step S221: collecting memory data of server resource data to obtain memory data;

[0036] Step S222: performing memory allocation recording according to the memory data, thereby obtaining memory allocation data;

[0037] Step S223: performing memory release statistics according to the memory data, thereby obtaining memory release data;

[0038] Step S224: performing memory leak comparison based on the memory release data and the memory allocation data, thereby obtaining memory leak data;

[0039] Step S225: locating the memory data leakage scale according to the memory leakage data, thereby obtaining memory leakage scale data;

[0040] Step S226: Generate a memory snapshot based on the memory data, thereby obtaining memory snapshot data;

[0041] Step S227: performing memory leak anomaly integration according to the memory leak scale data and the memory snapshot data, thereby obtaining memory leak anomaly data.

[0042] The present invention provides real-time monitoring of server resource usage through the collection of memory data, enabling a clear understanding of memory allocation and release conditions, thereby providing basic data for memory leak detection. By recording memory allocation and release, memory usage can be tracked in detail, identifying improperly released memory blocks or memory blocks that remain unreleased for extended periods, and promptly revealing potential memory leaks. Furthermore, through memory leak comparison, memory allocation and release data can be compared to accurately identify actual leak data, thus preventing game server performance degradation caused by memory leaks. Next, locating the scale of the memory leak helps operations and maintenance personnel pinpoint the specific location and impact of the leak, allowing them to take targeted remediation measures. Generating memory snapshots provides a detailed static view for analyzing memory status, helping to identify the root cause of the memory leak and the specific moment it occurred. Finally, by integrating memory leak scale data with memory snapshot data, specific memory leak anomalies can be comprehensively identified, allowing timely and effective optimization measures to prevent further expansion of the leak, thereby improving the operational efficiency and stability of the game server, thereby enhancing the player's gaming experience and avoiding game crashes or lags caused by memory leaks.

[0043] Optionally, step S23 is specifically as follows:

[0044] Step S231: extracting communication flow characteristics from the server communication data to obtain communication flow data;

[0045] Step S232: performing data packet transmission statistics based on the communication traffic data to obtain data packet transmission data;

[0046] Step S233: calculating the packet loss rate of the data packet transmission data, thereby obtaining the packet loss rate of the data packet;

[0047] Step S234: calculating the retransmission rate of the data packet transmission data, thereby obtaining the data packet retransmission rate;

[0048] Step S235: performing flood attack analysis based on the packet loss rate and the packet retransmission rate, thereby obtaining flood attack data;

[0049] Step S236: Identifying the attack source of the server communication data based on the flood attack data, thereby obtaining the flood attack source data;

[0050] Step S237: Obtaining standard traffic pattern data;

[0051] Step S238: marking the flood attack source data as having abnormal communication patterns according to the standard traffic pattern data, thereby obtaining abnormal communication pattern data.

[0052] The present invention provides comprehensive monitoring of server communication conditions by extracting communication traffic characteristics, enabling real-time monitoring of data packet traffic trends and providing a foundation for further analysis of network anomalies. By calculating data packet transmission statistics, characteristics such as packet transmission frequency and size can be understood, helping to detect abnormal communication behavior, such as a sudden increase in traffic. Calculating packet loss rate and retransmission rate can effectively identify abnormal conditions during communication. For example, a sharp increase in packet loss rate may indicate network congestion or attack behavior, while an abnormal increase in retransmission rate can indicate problems in data transmission. Especially during flood attacks, packet loss and retransmission rates typically increase significantly. By jointly analyzing packet loss rate and retransmission rate, it is possible to clearly determine whether a flood attack has occurred. Especially in situations such as a surge in traffic and severe packet loss, comprehensive analysis enables timely response and attack prediction. Identifying the source of a flood attack helps accurately locate the attacker, facilitating measures such as blocking and filtering the attack source to prevent the attack from spreading or affecting other normal users. At the same time, acquiring standard traffic pattern data provides a reference for benchmarking network traffic behavior, enabling more accurate identification and analysis of abnormal communication patterns originating from attack sources. Ultimately, by marking communication pattern anomalies in flood attack source data, malicious attack traffic can be effectively flagged, providing clear attack indicators for traffic filtering and defense systems. This ensures that game servers can operate stably in high-traffic, high-concurrency environments, allowing for timely identification and response to complex network attacks, and safeguarding players' gaming experience.

[0053] Optionally, step S235 is specifically as follows:

[0054] Perform packet loss rate statistics based on the packet loss rate to obtain a high packet loss rate;

[0055] Perform retransmission rate statistics based on the data packet retransmission rate to obtain a high data packet retransmission rate;

[0056] Performing duration analysis according to the high data packet loss rate and the high data packet retransmission rate, thereby obtaining high data packet loss rate duration data and high data packet retransmission rate duration data;

[0057] A flood attack is determined according to the high data packet loss rate duration data and the high data packet retransmission rate duration data, thereby obtaining flood attack data.

[0058] The present invention can more accurately identify network anomalies through statistical analysis of packet loss rates and retransmission rates, especially when subjected to flood attacks, where packet loss and retransmission rates tend to increase significantly. The statistical results of high packet loss rates and high packet retransmission rates can reveal potential network problems in the communication process, such as network congestion, packet loss, or malicious attacks. The duration analysis of packet loss rates and retransmission rates can further help identify whether these anomalies are manifestations of long-term attack behavior. By analyzing the duration of high packet loss rates and high retransmission rates respectively, the present invention can accurately determine whether these network problems are caused by flood attacks, and then confirm the occurrence of flood attacks. This method can not only identify potential attack patterns, but also conduct in-depth analysis based on the duration of the attack, helping network defense systems to promptly identify and respond to complex network attacks, avoiding the problem of slow response to attacks in traditional methods, ensuring that game servers maintain stable and efficient operation in high concurrency and high traffic environments, and significantly improving the detection and defense capabilities of network attacks.

[0059] Optionally, step S3 specifically includes:

[0060] Step S31: Calculating the Pearson correlation coefficient based on the abnormal load management data and the abnormal player data to obtain the Pearson correlation coefficient;

[0061] Step S32: performing correlation statistics according to the Pearson correlation coefficient to obtain a positive correlation Pearson correlation coefficient;

[0062] Step S33: performing abnormal time statistics based on the load management abnormality data and the abnormal player data, thereby obtaining the load management abnormal time data and the abnormal player time data;

[0063] Step S34: calculating the overlap of the abnormal load management time data and the abnormal player time data to obtain overlapping time data;

[0064] Step S35: Abnormal player load management integration is performed based on the overlapping time data and the positive correlation Pearson correlation coefficient, thereby obtaining abnormal player load management data.

[0065] By using the calculation of the Pearson correlation coefficient, the present invention can quantify the correlation between load management anomalies and abnormal player behavior, and further identify which player behaviors may have a greater impact on the server load. By performing correlation statistics, the positive correlation between load anomalies and player behavior can be clearly identified, thereby providing effective data support for further optimization. Based on the load management anomaly data and abnormal player data, abnormal time statistics are performed, and the time nodes of abnormal behaviors can be accurately obtained, and compared with the server load data to find out the specific time periods when abnormal events occur, ensuring that the system can respond effectively during these critical periods. The overlap calculation further improves the accuracy of the analysis, and can accurately identify the overlapping parts of load anomalies and player behavior anomalies, and then deeply analyze the specific impact of these overlapping time periods. This series of analyses can provide a scientific basis for the integration of abnormal player load management, effectively guide the system to optimize the load management of abnormal players, avoid excessive server load, and improve the smoothness of the game and the player experience.

[0066] Optionally, this specification also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements any one of the game data processing methods.

[0067] Optionally, this specification further provides a game data processing system for executing the game data processing method described above, the game data processing system comprising:

[0068] The abnormal player identification module is used to obtain game data and extract game player features based on the game data to obtain game player data; and identify abnormal players based on the game player data to obtain abnormal player data;

[0069] A load management anomaly analysis module is used to extract server resource features and server communication features based on game data, thereby obtaining server resource data and server communication data; and to perform load management anomaly analysis based on the server resource data and server communication data, thereby obtaining load management anomaly data;

[0070] A correlation analysis module is used to perform correlation analysis based on the abnormal load management data and the abnormal player data, thereby obtaining abnormal player load management data;

[0071] A high load analysis module is used to extract CPU load features based on game data to obtain CPU load data, and perform high load analysis based on the CPU load data to obtain CPU high load data;

[0072] The game load balancing optimization and analysis module is used to perform game load balancing optimization analysis based on CPU high load data and abnormal player load management data, thereby obtaining game load balancing data.

[0073] The present invention provides a game data processing system that can implement any game data processing method of the present invention and is used to combine the operations and signal transmission media between various modules to complete the game data processing method. The internal modules of the system cooperate with each other to enhance the user experience and ensure the stable operation of the game. BRIEF DESCRIPTION OF THE DRAWINGS

[0074] Other features, objects and advantages of the present invention will become more apparent upon reading the detailed description of non-limiting embodiments thereof made with reference to the following drawings:

[0075] Figure 1 1. A flowchart showing the steps of the method for processing game data of the present invention;

[0076] Figure 2 Detailed step flow diagram of step S1 in the present invention;

[0077] Figure 3 Detailed flowchart of step S12 in the present invention.

[0078] The purpose, features and advantages of the present invention will be further described with reference to the accompanying drawings and in conjunction with the embodiments. DETAILED DESCRIPTION

[0079] The following is a clear and complete description of the technical method of the present invention in conjunction with the accompanying drawings. Obviously, the embodiments described are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without making any creative work are within the scope of protection of the present invention.

[0080] In addition, the accompanying drawings are merely schematic illustrations of the present invention and are not necessarily drawn to scale. Identical reference numerals in the figures denote identical or similar parts, and thus repetitive descriptions thereof will be omitted. Some of the block diagrams shown in the accompanying drawings are functional entities that do not necessarily correspond to physically or logically separate entities. These functional entities may be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor and / or microcontroller approaches.

[0081] It should be understood that although the terms "first," "second," and the like may be used herein to describe various elements, these elements should not be limited by these terms. These terms are used solely to distinguish one element from another. For example, a first element may be referred to as a second element, and similarly, a second element may be referred to as a first element, without departing from the scope of the exemplary embodiments. The term "and / or" as used herein includes any and all combinations of one or more of the listed associated items.

[0082] To achieve this, please refer to Figures 1 to 3 The present invention provides a method for processing game data, the method comprising the following steps:

[0083] Step S1: Obtaining game data, and extracting game player features based on the game data to obtain game player data; identifying abnormal players based on the game player data to obtain abnormal player data;

[0084] In this embodiment, game data is obtained, and the data sources include but are not limited to server-side logs, player-side operation records, real-time communication data, etc. The data obtained includes player ID, login time, behavior patterns (such as operation records of clicks, moves, attacks, deaths, and picking up items), as well as game process data related to the player (such as scores, win-loss results, etc.). Next, game player feature extraction is performed on this data. Feature extraction includes statistics on each player's behavior frequency, number of game sessions participated, average game time, etc., to obtain basic behavioral feature data for each player. For abnormal player identification, features such as number of kills, number of deaths, and game time are used for screening, and a threshold is set (for example, a player's kill count exceeds 30 times / minute or the game time exceeds 3 hours) to determine whether it is an abnormal player. In addition, the behavior patterns of abnormal players can be further confirmed through the player's interaction data with other players (such as the number of player PKs and the frequency of transactions with other players). Finally, combined with this data, potential abnormal players are identified through rule setting or machine learning algorithms (such as decision trees or K-means clustering), and these players are marked as abnormal players to form an abnormal player data set.

[0085] Step S2: extracting server resource features and server communication features based on the game data to obtain server resource data and server communication data; performing load management anomaly analysis based on the server resource data and server communication data to obtain load management anomaly data;

[0086] In this embodiment, server resource feature extraction is first performed. Server resource data includes CPU usage, memory usage, disk read and write speed, network bandwidth usage, etc. For CPU usage, the CPU usage per minute and the CPU load change per second are taken into account when obtaining data points, and a threshold is set (for example, a CPU usage greater than 85% is considered high load). Memory usage data is obtained by real-time monitoring of memory usage at each moment, and statistics on the peak and average memory usage, and a threshold is set (for example, memory usage exceeding 90% is abnormal). Disk read and write and network bandwidth usage are monitored using throughput per second. When a certain set value is exceeded (for example, network bandwidth usage exceeds 75%), it can be considered a potential load anomaly. Server communication feature extraction focuses on features such as communication traffic, packet size, and packet sending frequency between the server and the client. For communication traffic, the packet transmission volume per second is counted, and a traffic fluctuation range is set (for example, a transmission volume greater than 1MB per second is a high traffic state). Next, we analyze load management anomalies using the collected server resource and communication data. Combined with historical data (for example, whether CPU usage exceeded 90% more than five times in the past hour), we can further determine whether server load anomalies exist. Ultimately, based on this data and analysis, we generate load management anomaly data and generate an anomaly report.

[0087] Step S3: performing correlation analysis based on the abnormal load management data and the abnormal player data, thereby obtaining abnormal player load management data;

[0088] In this embodiment, the collected load management anomaly data includes metrics such as the server's CPU load, memory usage, and bandwidth usage. CPU load data reflects the server's processing power, while memory usage and bandwidth usage data can indicate whether the server is experiencing resource overload. Furthermore, the collected abnormal player data includes the abnormal player's ID and their abnormal behavior characteristics, such as abnormal game time, excessive kill counts, and frequent operations. Abnormal behavior can be identified by players performing a large number of operations in a short period of time, or exceeding normal game time. The Pearson correlation coefficient is used to quantify the correlation between load anomalies and abnormal player behavior. To perform the calculation, the load management data and abnormal player data must first be aligned along the timeline to ensure that the analysis is conducted within the same time period. Correlation analysis is performed on these two data points to determine the correlation between the two. For example, if a player performs a large number of kills during a period of high server CPU load, this indicates that the player's behavior may be directly related to the server's load anomaly. To this end, a threshold is set (e.g., a Pearson correlation coefficient greater than 0.7). When the correlation exceeds this threshold, it can be determined that there is a strong connection between the player's behavior and the server load anomaly. Combined with abnormal time statistics, we can analyze the overlap between abnormal player activity times and load anomalies. Specifically, we count players' abnormal response times and compare them with the time periods of abnormal load to analyze the overlap. For example, if a player frequently operates during a period of abnormal server CPU load, this indicates that this player may be contributing to the server overload. By comprehensively analyzing this data, we can generate abnormal player load management data, helping the platform identify players whose abnormal behavior has a strong correlation with abnormal server load. This analysis can provide strong support for subsequent load optimization and abnormal player management.

[0089] Step S4: extracting CPU load features based on the game data to obtain CPU load data, and performing high load analysis based on the CPU load data to obtain CPU high load data;

[0090] In this embodiment, CPU load feature extraction is performed. The key to this process is collecting data related to CPU usage from the game server, typically using monitoring tools provided by the operating system. For example, in a Linux environment, you can use the top command, mpstat command, or pidstat tool to obtain CPU usage data. The collected data typically includes the overall CPU load percentage and the load of each core. The load value in each data record is displayed as a percentage, indicating the current CPU or core utilization. For example, "CPU load is 85%" means that the CPU utilization is 85% at that moment. To obtain more detailed data, data can be collected every 1 second or 5 seconds. The choice of this sampling interval generally depends on the frequency of server load fluctuations. If more frequent data collection is required, tools such as collectd and Prometheus can also be used. These tools can monitor and record server performance data in real time. A particular concern is that in multi-core processor systems, you cannot rely solely on the overall CPU load; you also need to obtain the usage of each CPU core to assess whether all cores are under high load or whether certain cores are experiencing localized high load issues. Using the operating system's / proc / stat (Linux) or performance counters in Windows, you can extract load data for each core. Next, perform high load analysis. In this step, you need to define a specific threshold to determine whether the CPU has entered a high load state. This threshold is set based on statistical analysis of historical data on normal server load conditions. For example, if the CPU load is mostly below 50%, set the high load threshold at 90%. Alternatively, you can set it to 95% to indicate a severely high load, depending on actual needs. The threshold setting should be adjusted based on the actual server workload. For example, if the server can experience a CPU load of 80% under high concurrency conditions without impacting normal operation, the threshold should be appropriately raised. To determine whether high load exists, you also need to analyze the duration of the high load state to ensure that it meets the set standard. Use monitoring tools to continuously record CPU load data. When the CPU load exceeds the set threshold, determine how long the state lasts. Typically, the threshold is set at 90%, and the high load state must last for at least five minutes. If the CPU load remains above 90% for most of the five-minute period, the CPU is considered to be in a high load state during that period. If the CPU load fluctuates, you should also pay attention to the trend of these fluctuations. If high load conditions occur intermittently but are long-lasting or recurring frequently, they can also be considered potential high load conditions. The system should monitor high load using a rolling window to ensure timely detection of load fluctuations. Generating high load data is key to this process.First, by analyzing historical load data, record each time period when the CPU load exceeded the threshold, along with the associated timestamps. Each data point includes not only the load value but also the specific moment of high load, such as the start and end time of the period, its duration, and the load of each CPU core. In multi-core systems, in addition to recording the overall load, it is also important to monitor the usage of individual cores. For example, a core may be highly loaded for extended periods while other cores are less loaded. This could be caused by a specific process or task. To more accurately identify high load, ensure that the timestamps of each core's load data are consistent with the global load data when recording the load data for each core. In practical applications, all of this data needs to be stored in a logging system, such as an ELK (Elasticsearch, Logstash, Kibana) log management system or Graylog. This data not only helps administrators identify server resource bottlenecks promptly but also provides a basis for subsequent optimization. Subsequent analysis of this high load data can determine whether the abnormal increase in server load is caused by specific player behavior, in-game events, or features. For example, when a player performs a large number of operations, it may cause abnormal CPU load on the server, leading to a decrease in game server performance. Through this data analysis, we can further combine other modules (such as abnormal player detection and load balancing optimization) to comprehensively optimize and adjust the system. This process provides strong data support for server load balancing adjustments and performance optimization, ensuring that the server can operate stably under high concurrency and high load.

[0091] Step S5: Perform game load balancing optimization analysis based on CPU high load data and abnormal player load management data to obtain game load balancing data.

[0092] In this embodiment, the collected CPU high load data includes historical records of CPU load, as well as the periods and durations of high load states. For example, if the CPU load exceeds 90% for a period of time and this state persists for more than 5 minutes, it is considered a high load state. Each record contains not only the total CPU load percentage but also the usage of each CPU core. This data is collected using monitoring tools or APIs provided by the operating system (such as mpstat, pidstat in Linux, or Windows Performance Monitoring). Abnormal player load management data includes load data related to specific players, extracted from game server logs. Specifically, this includes abnormal player behavior patterns (such as frequent operations, extremely high kill counts, etc.), which may impose additional load on the server. Each player's load data is typically obtained by the game server through real-time monitoring, including the frequency of player operations, request processing time, memory consumption, etc. By combining this with the high CPU load data, it is possible to identify which players' activities directly affect the server load. First, this data is merged. By comparing the periods of high CPU load with the abnormal player behavior data, it is determined which players performed a large number of game operations during these periods of high CPU load. For example, if the server's CPU load consistently exceeds 90% during a certain period, and certain players are found to have frequently performed actions (such as kills and character moves) during this period, these players can be marked as key players who may be causing increased server load. Load balancing optimization analysis can then be conducted based on this data. The core goal of load balancing is to evenly distribute server load across different resources, preventing any one resource from being overconsumed and leading to performance degradation. Based on data on high CPU load and abnormal player load, dynamic load balancing algorithms can be applied for optimization. Specifically, in areas with high player activity, resource usage for specific players can be reduced, and their requests can be dispatched to less loaded server nodes. For example, if a certain area has a high concentration of player activity, these players' game sessions can be migrated from their current nodes to nodes with less resource load. Load balancers, such as those based on Nginx or HAProxy, can be used to dynamically adjust server resource allocation based on real-time CPU load data. Specific thresholds and rules must be set for load balancing adjustments. For example, if the CPU load exceeds 90% for more than three minutes, a load transfer mechanism is initiated. For abnormal players, server load can be reduced by limiting the maximum number of connections for certain players, reducing their request frequency, or temporarily allocating less computing resources. In this case, the server will migrate high-load player sessions to other servers or nodes to balance the overall load. A load balancing strategy using a weighted distribution model is also required.For example, server nodes with extremely high loads are assigned a lower load weight, while server nodes with low loads are assigned a higher weight. The weight of each server node should be dynamically adjusted based on CPU load, memory usage, and the number of connections. In the game server's load balancing system, the load of each node is monitored in real time, load transfer rules are dynamically adjusted, and the system is able to automatically identify high-load areas and allocate resources during high-load periods.

[0093] Optionally, step S1 specifically includes:

[0094] Step S11: Acquire game data, and extract game player features based on the game data to obtain game player data;

[0095] In this embodiment, when acquiring game data, real-time data is extracted from the game server log to record player behavior information in the game, including player login information, operational behavior (such as movement, attacking, chatting, etc.), game state changes, etc. Game data includes details such as each player's ID, operation type, timestamp, geographic location, resource usage, etc. Data collection uses a server-side logging system, combined with a database storage structure, to record data in chronological order and ensure data integrity. Each player's operational behavior needs to be captured in real time on the game server through an event triggering mechanism, and the event data is transmitted to the central server for storage through an API interface. This data will be used for subsequent player feature extraction, such as player game time and operation frequency.

[0096] Step S12: performing data packet tampering detection based on the game player data, thereby obtaining game player data packet tampering data;

[0097] In this embodiment, the communication data packets of each player are extracted from the game data, specifically including the data packet transmission records between the client and the server. By comparing the client hash value with the server hash value, it is checked whether the data packet has been tampered with during the transmission process. The SHA-256 algorithm is used to calculate the hash value, and the hash values ​​of the client and server data are calculated and compared respectively. If the hash values ​​do not match, it is considered that the data packet may have been tampered with. In addition, combined with the sending time and receiving time of the data packet, a timing analysis algorithm is used to determine whether there are any abnormalities in the data packet such as retransmission or packet loss. By comparing the original data of the data packet with the modified data, potential data packet tampering behavior is further identified and marked as data packet tampering data.

[0098] Step S13: performing game time statistics on the game player data to obtain short-time game player data;

[0099] In this embodiment, each player's gaming duration is calculated and statistically analyzed through time series analysis. Specifically, the system matches the player ID with the corresponding login and logout times. The system records the time of each player's login and logout, calculates the gaming duration of each session, and summarizes the player's total gaming time throughout the entire gaming process. Through data analysis, player data with frequent logins within a short period of time or abnormal gaming duration can be identified, such as players logging in multiple times within just a few minutes, or players whose gaming duration far exceeds the norm. By setting thresholds, such as logging in more than five times in an hour or a single gaming session exceeding 30 hours, players are marked as having short gaming time.

[0100] Step S14: performing kill count statistics on the game player data, thereby obtaining game player data with a high kill count;

[0101] In this embodiment, by recording the kill data of each player in the game, the number of kills of each player in a specific time period is calculated. For example, in a MOBA game, the number of times each player kills enemy players and the number of times the enemy structures are killed are counted. The time and event of each kill will be recorded by the game server and associated with the player's ID. If the number of kills of a player exceeds a certain threshold (such as more than 50 kills per hour), it is considered that the number of kills of the player is abnormally high. By comparing the number of kills of the player with the overall game time, the behavioral characteristics of the player are further analyzed and marked as high kill game player data. The statistics use a cumulative method to sum up the killing behavior data of each player and update it regularly.

[0102] Step S15: performing an intersection operation of potential abnormal players based on the short-time game player data and the high-kill game player data, thereby obtaining potential abnormal player data;

[0103] In this embodiment, data from players with short gaming sessions and high kill counts is filtered to extract the intersection of the two. For example, players with extremely short gaming sessions and high kill counts are identified as abnormal players using cheats or scripts. This process utilizes set intersection operations to extract data from players who frequently achieve high kill counts within a short period of time. Multiple rules can be set: for example, if a player's gaming session time is less than 30 minutes and their kill count is greater than 20, the player is considered to have abnormal behavior. The resulting data on potentially abnormal players can be obtained through database queries, where the short gaming session data and the high kill count data are correlated and matched based on ID and timestamp to extract the intersection.

[0104] Step S16: Identify abnormal players based on the game player data packet tampering data, thereby obtaining abnormal player data.

[0105] In this embodiment, the data of potential abnormal players is combined with the data packet tampering data to further screen out players whose communication data packets are inconsistent with the server when high-frequency operations or killing behaviors occur. By analyzing the relationship between each player's data packet transmission and player behavior, combined with the data packet tampering data, a multi-dimensional analysis is performed. For example, if a player frequently kills in a short period of time and data packet tampering behaviors occur frequently, the system will mark it as an abnormal player. The specific identification process includes comparing the player's behavior pattern and network data flow, and using anomaly detection algorithms (such as rule-based detection or clustering algorithms) to mark the real abnormal players. The threshold for data packet tampering detection and behavior analysis can be set as: when a player's behavior pattern is frequently abnormal and differs greatly from the normal characteristics of its communication data packet, it can be marked as an abnormal player.

[0106] Optionally, step S12 is specifically as follows:

[0107] Step S121: Calculate the client hash value based on the game player data to obtain the client hash value;

[0108] In this embodiment, the contents of data packets sent by the client to the game server are collected, including player operation data, location data, resource consumption, and other information. This data is processed using a standard hash algorithm, most commonly SHA-256. By inputting the data packet contents into the SHA-256 algorithm, a unique 256-bit hash value is generated. This hash value is used to uniquely identify the client data and prevent data tampering during transmission. Specifically, after extracting the client data from the game client, a standard hash function is used to calculate the hash value of the client data packet. Each calculation ensures that the transmitted data content remains consistent and is not affected by any modification or tampering. The hash value calculation standard depends on the original content of the client data. The client data and hash value storage will be uploaded to the database and compared with the data on the game server.

[0109] Step S122: Calculating a server hash value based on the game player data to obtain a server hash value;

[0110] In this embodiment, the data packets received by the server from the client are recorded, including the player's action instructions, status information and other relevant data. The server calculates a SHA-256 hash value based on this data. This process is similar to the client hash value calculation, but in this step, the source of the data packet is the data received by the server. A unique hash value is calculated for each data packet on the server side to identify the original content of each data packet. All server-side communication data is recorded in the log and tracked in combination with a timestamp. These data packets will be used as input for the hash calculation, and a 256-bit hash value will be generated through SHA-256, and the hash value of each data packet will be recorded. The hash value calculation process ensures that the server data has not been tampered with. If the data packet is modified on the server side, the hash value will change, indicating a potential abnormality.

[0111] Step S123: performing a preliminary judgment on whether the data packet has been tampered with based on the client hash value and the server hash value, thereby obtaining preliminary judgment data on whether the data packet has been tampered with;

[0112] In this embodiment, the hash values ​​calculated by the client and the server are compared to check whether they are consistent. The specific approach is: a hash value is calculated for each data packet sent from the client, and compared with the hash value calculated when the server receives the data packet. If the hash values ​​of the client and the server are inconsistent, it can be preliminarily determined that the data packet has been tampered with during transmission. At this time, the time when the hash value is inconsistent, the relevant content of the data packet, the player ID and other information can be recorded. As a judgment criterion, when the difference between the two hash values ​​is greater than a preset threshold (for example, the difference in SHA-256 values ​​exceeds 50%), the data packet is determined to be tampered data and marked as preliminary judgment data for data packet tampering. Through this judgment process, normal data transmission can be filtered out, and the communication content where data tampering may occur can be focused on analysis.

[0113] Step S124: extracting data packet features from the game player data to obtain game player data packet data;

[0114] In this embodiment, after obtaining the player's communication data packet, the data packet is subjected to feature extraction to identify various features of the data packet. The feature extraction process includes: analyzing the size, frequency, transmission content type (such as action instructions, position changes, resource changes, etc.) of the data packet, the identifier and timestamp of the data packet, etc. The feature extraction tool can use Python's pandas library to store and analyze data tables, and extract key feature data by checking the relevant fields of each data packet one by one. Features include the frequency of data packet transmission (for example, the number of data packets per unit time), the distribution of data packet size (whether there are abnormal large packets or frequent communications), etc. In the data packet feature extraction process, each behavioral event data of the player is classified in detail, and feature data related to the player's behavior is extracted for subsequent data analysis.

[0115] Step S125: performing distribution time statistics based on the game player data packet data, thereby obtaining the game player data packet distribution time data;

[0116] In this embodiment, the sending time of each data packet is extracted. The timestamp field in the data packet is extracted, and each timestamp value is counted to form a data packet sending time series for each player. Data packet release time statistics include: recording the time point each time a player sends a data packet, and calculating the interval between data packet transmissions. For example, by calculating the time difference between each two consecutive data packets, the player's activity level and sending frequency within a certain time period can be determined. To determine the regularity of the release time, a threshold can be set: if a player's data packet sending interval is less than 0.5 seconds and occurs frequently, it is marked as a high-frequency data packet transmission. Based on this, the sending pattern of each player within a specific time period can be calculated to generate time distribution statistics.

[0117] Step S126: performing sequence check on the game player data packet release time data to obtain out-of-order data packets;

[0118] In this embodiment, a sequence check is performed based on the release time data, that is, to check whether the data packets are sent in the normal order. First, the data packets of each player are sorted by timestamp to ensure that the data packets are arranged in the order of the sending time. Subsequently, the sorted data packet sequence is analyzed to find out whether there are any abnormal timestamp sequences. For example, if the timestamps of some data packets appear in reverse order (i.e., the timestamps become smaller), it can be determined that the data packets are out of order. Out of order data packets usually indicate that an abnormality may have occurred during the data transmission process, such as malicious tampering or network interference. Through sequence verification, out of order data packets can be distinguished from normal data packets, and these data packets can be further analyzed.

[0119] Step S127: confirming the tampering of the data packet preliminary judgment data according to the disordered data packet, thereby obtaining the game player's data packet tampering data.

[0120] In this embodiment, for those data packets that are determined to be out of order and inconsistent with the normal order, they are compared with the tampered data that has been preliminarily determined. The content of the comparison includes the timestamp, content, and transmission frequency of the data packet, and abnormal correlation patterns are sought. For the detected out-of-order data packet, the system checks whether the hash value of the data packet is consistent with the hash value of the data packet on the client and server sides. If the hash values ​​are inconsistent and the data packet is out of order, it is further confirmed that the data packet is tampered data. In this process, by comparing the time and content characteristics of the out-of-order data packet with the normal data packet, combined with the data packet's transmission history information, a final confirmation is made as to whether data tampering has occurred.

[0121] Optionally, step S2 is specifically:

[0122] Step S21: extracting server resource features and server communication features based on the game data, thereby obtaining server resource data and server communication data;

[0123] In this embodiment, it is necessary to collect server resource usage data and communication data. Server resource feature extraction involves obtaining resource usage information such as CPU usage, memory usage, disk I / O, and network bandwidth from the server monitoring system. This data can be obtained using tools built into the server's operating system (such as the top command or vmstat command in Linux) or specialized monitoring tools (such as Prometheus and Zabbix). Server communication feature extraction involves capturing communication packets between the server and client using network monitoring tools (such as Wireshark or tcpdump) to extract features such as communication frequency, packet size, communication protocol (such as TCP, UDP), and number of requests processed per second. This resource and communication data is organized into structured tabular data and stored in a database or temporary cache for subsequent analysis. For each type of resource and communication feature, a certain threshold is set. For example, when CPU usage exceeds 80%, memory usage exceeds 70%, and bandwidth utilization exceeds 90%, it will be marked as a high load state. By extracting these features, a comprehensive understanding of the server's resource consumption and communication load can be achieved.

[0124] Step S22: performing memory leak anomaly analysis on the server resource data to obtain memory leak anomaly data;

[0125] In this embodiment, it is necessary to obtain the server's memory usage. This data can be obtained using the operating system's memory statistics commands (such as free and top in Linux), or by regularly collecting memory usage data through system monitoring tools. Time series analysis is performed on the memory data to determine whether there is a memory leak. The characteristics of a memory leak are usually manifested as a gradual increase in memory usage while the released amount remains unchanged, resulting in a continuous increase in memory usage. In the specific operation, an initial memory usage baseline value is first set, and then the memory usage is calculated at regular intervals (for example, every minute or every hour). By comparing two consecutive data points, if it is found that the memory usage continues to increase over a long period of time (such as an increase of more than 10% per hour) and there is no corresponding release operation, it can be preliminarily determined to be a memory leak anomaly. Based on this, the system log file (such as / var / log / messages) can be combined to check whether there are abnormal error messages related to memory allocation to further confirm the memory leak. Ultimately, memory leak anomaly data is generated, including the abnormal time period, abnormal memory usage, and corresponding system resource consumption information.

[0126] Step S23: performing communication mode anomaly analysis on the server communication data to obtain communication mode anomaly data;

[0127] In this embodiment, data packets are collected using a network packet capture tool (such as Wireshark or tcpdump), from which information such as communication timing, communication protocol, packet size, and packet frequency is extracted. Under normal circumstances, communication between a game server and a client should follow a certain pattern, such as a request-response pattern or data flow stability. Abnormal communication patterns are typically manifested as abnormal request frequency, excessively long response times for single requests, repeated packets, or high-frequency packet transmission. To perform abnormality analysis, normal thresholds for communication patterns need to be set. For example, the request frequency for a certain IP address should not exceed 10 times per second, and the size of a certain packet should not exceed 1MB. If the packet transmission frequency, packet size, or response time exceeds the threshold, it can be marked as a communication pattern abnormality. By statistically analyzing the communication timing of each client, it is checked whether there are abnormal bursts of traffic, retransmitted requests, or repeated packets. By detecting these abnormalities in communication patterns, abnormal player behavior or malicious communication attacks can be identified in a timely manner.

[0128] Step S24: performing load management anomaly integration according to the memory leak anomaly data and the communication mode anomaly data, thereby obtaining load management anomaly data.

[0129] In this embodiment, memory leak anomaly data and communication pattern anomaly data need to be correlated and analyzed. After combining these two types of anomaly data, an analysis is performed to determine whether there is a correlation between memory leaks and communication pattern anomalies. For example, if both memory leaks and communication pattern anomalies occur within a specific time period, this may indicate high server load and resource management issues. The integration process includes correlating the memory leak data and communication pattern anomaly data based on their timestamps to check whether abnormal communication patterns occur while memory usage continues to increase. Furthermore, it is necessary to examine whether periods of high load coincide with frequent communication data exchange or abnormal data packet transmission. The integrated data can be combined to generate final load management anomaly data by setting certain correlation thresholds (for example, if memory usage is greater than 80% and the request frequency exceeds 10 requests per second, it is considered a load management anomaly). Ultimately, combining this anomaly information can identify which server resources are overloaded and which communication requests are too frequent, thereby helping to optimize server load and avoid performance degradation or downtime.

[0130] Optionally, step S22 is specifically as follows:

[0131] Step S221: collecting memory data of server resource data to obtain memory data;

[0132] In this embodiment, it is necessary to collect basic data related to memory, especially memory usage, through the operating system of the server. These data are usually obtained through the monitoring tools that come with the operating system or third-party monitoring tools. For Linux systems, commands such as vmstat, free, and top can be used for real-time monitoring. These tools can provide detailed usage of system memory, such as free memory, used memory, swap area usage, and other information. In Windows systems, Task Manager or Performance Monitor can be used to obtain memory usage. Through these tools, memory usage data is collected at regular intervals (such as every 10 seconds) to obtain information such as the total amount of memory, available memory, cache, swap space, etc. during each collection. The collected memory data needs to be stored in a database or data cache for subsequent analysis. This process ensures the integrity and real-time nature of the data by setting the data collection cycle (such as 1 minute) and the collection frequency (once per second).

[0133] Step S222: performing memory allocation recording according to the memory data, thereby obtaining memory allocation data;

[0134] In this embodiment, memory allocation records are performed based on memory data, which mainly depends on the system's memory management and allocation mechanism. Memory allocation records refer to detailed data during memory allocation, which are usually implemented through a memory allocation tracking tool provided by the operating system. In Linux, memory usage can be viewed through the / proc / meminfo file, and detailed records of each memory allocation and release can be obtained in combination with the logs of malloc or free calls. In the Windows operating system, memory allocation can be tracked through Event Tracing for Windows (ETW). In specific operations, the system log or the memory application status of a specific process can be monitored, such as the memory allocation status of a process at a certain moment. Each memory allocation will record information such as the memory address, allocation size, process ID, etc. These memory allocation data will generate a table recording the time, size, type, etc. of the memory allocation for subsequent analysis and comparison.

[0135] Step S223: performing memory release statistics according to the memory data, thereby obtaining memory release data;

[0136] In this embodiment, memory release statistics are performed based on memory data. Memory release refers to the process by which the system or application reclaims memory space that is no longer in use. By collecting the memory release records of each process in the system, the amount of memory released by each process can be counted. In Linux, memory release statistics can be used to track the memory usage of applications through the ps command, the top command, or by analyzing memory-mapped files. For each memory release, the recovered size of the memory, the time of release, and the corresponding process information need to be recorded. In the Windows operating system, the memory release status of each process can be recorded through the performance monitor. The recorded data includes the amount of memory released by each process, the timestamp of the release, and whether the memory optimization policy was triggered when the release occurred. The time granularity of data collection should ensure sufficient accuracy. It is usually selected to collect data every 10 seconds or 1 minute and analyze it together with the memory allocation data.

[0137] Step S224: performing memory leak comparison based on the memory release data and the memory allocation data, thereby obtaining memory leak data;

[0138] In the present embodiment, memory leak comparison is performed based on memory release data and memory allocation data. Memory leak generally refers to memory that fails to be normally released after being allocated, resulting in a waste of system resources. The comparison process needs to be analyzed by information such as the time and size of the memory allocation record and the memory release record. In specific implementation, all memory allocation data and memory release data are first time-aligned, and a check is performed to see if there are any unreleased memory blocks within a certain time period. For example, if a process allocates 100MB of memory, but does not release an operation within its life cycle, and the memory usage continues to grow, then there may be a memory leak. In order to accurately identify leaks, a threshold value needs to be set. If the allocated memory exceeds a certain amount (e.g., 50MB) and is not released for more than 30 minutes, it is marked as a potential leak. The compared data will include the size of the leaked memory block, the time period of the leak, etc., and will be stored for further analysis.

[0139] Step S225: locating the memory data leakage scale according to the memory leakage data, thereby obtaining memory leakage scale data;

[0140] In the present embodiment, according to memory leak data, memory data is carried out leakage scale location, first according to the time information and memory usage data in the memory leak data, determine the specific time period of leakage and its corresponding memory size. In specific operation, can determine whether the memory of leakage is released on schedule by comparing the time difference of memory allocation and release. For example, if a process repeatedly allocates memory within a specific time, but does not release in time, when the accumulated memory block of leakage exceeds the set threshold value (for example 500MB), the memory leak scale can be preliminarily determined. The memory leak scale location can also be combined with the memory allocation amount of the process, the memory usage trend and other indicators, by linear regression or other algorithm analysis, further determine the memory range of leakage. For example, in a certain time period, the memory occupancy of process A continues to grow, and does not release after each memory allocation, when the accumulated leakage exceeds the set threshold value, then it is confirmed that the memory leak scale is large. The leakage scale data can be recorded as the time window of specific memory block size and leakage occurrence.

[0141] Step S226: Generate a memory snapshot based on the memory data, thereby obtaining memory snapshot data;

[0142] In this embodiment, a memory snapshot is generated based on memory data. A memory snapshot refers to a complete record of the system memory status at a specific moment. When generating a memory snapshot, the system's built-in tools can be used to capture data. For example, in Linux, a memory snapshot of a process can be obtained through the gcore command, or a memory snapshot can be obtained by combining the ps command and the top command. In Windows, a memory snapshot can be obtained through Windows debugging tools (such as WinDbg). The content of the memory snapshot includes information such as the process ID, the size of the memory occupied by the process, and the status of each memory area. By regularly collecting memory snapshots (such as once every 5 minutes), the memory usage status of the entire system or a single process can be obtained. The snapshot data generated each time will be stored in a file or database as a basis for subsequent memory analysis. Each snapshot record includes the overall memory usage and the specific memory data occupied by each process, and the timestamp of the snapshot will also be recorded.

[0143] Step S227: performing memory leak anomaly integration according to the memory leak scale data and the memory snapshot data, thereby obtaining memory leak anomaly data.

[0144] In this embodiment, memory leak anomalies are integrated based on memory leak scale data and memory snapshot data. During the integration process, the memory leak scale data and the corresponding memory snapshot data need to be correlated and analyzed. Through the memory leak scale data, the time period in which the leak occurred and the amount of leaked memory can be determined; through the memory snapshot data, the specific memory status of the system and process within the time period can be analyzed. For example, if the memory leak scale data indicates that a process leaked 100MB of memory, and the memory snapshot data shows that the memory allocation and release of the process in the same time period are inconsistent, and the process memory continues to grow, the abnormal nature of the memory leak is further confirmed. After integration, the memory leak anomaly data formed will include information such as the specific time of the leak, the leaked process, the size of the leaked memory, and possible system bottlenecks, which is convenient for further diagnosis and optimization.

[0145] Optionally, step S23 is specifically as follows:

[0146] Step S231: extracting communication flow characteristics from the server communication data to obtain communication flow data;

[0147] In this embodiment, the network traffic of the server is monitored in real time and data is captured by a network monitoring tool or a data packet capture tool (such as Wireshark, tcpdump). These tools can capture all data packets passing through the network interface in real time and extract the communication traffic characteristics therein, including the size of the data packet, the sending frequency, the target IP address, the source IP address, the protocol type, the port number and other information. By making statistics on these traffic data, the detailed information of the communication traffic can be obtained, including the distribution of the traffic, the fluctuation of the traffic and so on. In the data capture process, the duration and frequency of the packet capture can be set, for example, a data packet is captured every 10 seconds, and the parameters such as the captured data packet size, transmission rate, protocol type and so on are stored. Then, by analyzing these communication traffic data, the characteristics of each IP in the network are extracted.

[0148] Step S232: performing data packet transmission statistics based on the communication traffic data to obtain data packet transmission data;

[0149] In this embodiment, in order to perform statistics on data packet transmission, it is first necessary to monitor the traffic of the server's network interface and record the transmission time, size, source address and destination address of each data packet. The number of data packets sent per unit time can be counted by analyzing the transmission queue of the network interface or using network traffic statistics tools (such as NetFlow, sFlow). These tools can record and output detailed information of each data packet sent in real time, including source IP, destination IP, data packet size, transmission protocol, etc. In implementation, a time window (for example, every minute) can be set to count the number and size of data packets within the time period. During the statistical process, the data packet transmission volume during the normal traffic period and the abnormal traffic period can be compared to determine whether there is an abnormal transmission volume, thereby extracting the data of data packet transmission and providing basic data for subsequent analysis.

[0150] Step S233: calculating the packet loss rate of the data packet transmission data, thereby obtaining the packet loss rate of the data packet;

[0151] In this embodiment, the packet loss rate refers to the ratio of data packets lost during transmission to the number of data packets sent. In order to calculate the packet loss rate, it is first necessary to record and count the number of data packets sent and received. By using tools such as Wireshark to capture data packets, the sending time and receiving time of each data packet can be clearly recorded. Based on the captured data, it is possible to compare whether each data packet successfully reaches the target host and count the difference between the number of data packets actually received and the number of data packets sent. The calculation formula for the packet loss rate is: packet loss rate = (number of data packets sent - number of data packets received) / number of data packets sent. For example, if 1,000 data packets are sent and 950 data packets are received within a certain period of time, the packet loss rate is 5%. In actual operation, a threshold (such as a packet loss rate exceeding 5%) can be set to mark possible network problems or anomalies.

[0152] Step S234: calculating the retransmission rate of the data packet transmission data, thereby obtaining the data packet retransmission rate;

[0153] In this embodiment, data packet retransmission typically occurs when the network experiences packet loss or transmission delays. To calculate the retransmission rate, it is necessary to track the transmission and acknowledgment (ACK) information for each data packet. In packet capture tools such as Wireshark, TCP protocol data packets typically carry sequence numbers and acknowledgment numbers. By analyzing this information, it is possible to identify duplicated identical data packets, i.e., retransmitted packets. Each retransmission of a data packet increases the number of retransmissions, so the retransmission rate can be calculated by calculating the ratio between the number of retransmitted packets and the total number of packets. For example, if 1000 data packets are sent within a certain time period, and 100 of them are retransmitted, the retransmission rate is 10%. During this calculation, special attention should be paid to TCP retransmissions, identifying the original data packets sent and the retransmitted data packets, and calculating the difference between them to ultimately determine the retransmission rate. In practice, if the retransmission rate exceeds a certain threshold (e.g., 10%), it can be considered a network quality issue and further investigation should be conducted.

[0154] Step S235: performing flood attack analysis based on the packet loss rate and the packet retransmission rate, thereby obtaining flood attack data;

[0155] In this embodiment, a flood attack usually causes the server processing capacity to be overloaded by sending a large number of invalid data packets, thereby affecting normal communication. Based on the packet loss rate and retransmission rate obtained from previous statistics, the network traffic under normal conditions and the traffic under abnormal conditions can be compared. For example, when a flood attack occurs, the packet loss rate and retransmission rate will usually increase abnormally, and the server's response time will also be significantly delayed. By setting thresholds for the packet loss rate and retransmission rate (for example, the packet loss rate exceeds 5% and the retransmission rate exceeds 10%), if these abnormal conditions occur at the same time, it can be preliminarily determined that the system may be affected by a flood attack. In further analysis, the fluctuation of the packet sending rate can also be combined to determine whether it is an abnormal traffic pattern caused by a flood attack. The characteristics of a flood attack are usually manifested in the sending of a large number of data packets in a short period of time, as well as extremely high packet loss and retransmission rates, so these parameters are the key to analysis.

[0156] Step S236: Identifying the attack source of the server communication data based on the flood attack data, thereby obtaining the flood attack source data;

[0157] In this embodiment, when performing flood attack analysis, it is necessary to identify the source of the attack through features such as the source IP address, transmission protocol, and port number. By analyzing a large number of network data packets, especially data packets related to abnormal packet loss rate and retransmission rate, the source of the attack can be determined. Using traffic analysis tools (such as NetFlow, sFlow) or manually parsing captured network data, the source IP address that initiates the flood attack can be identified. The behavior patterns of these IP addresses can be further analyzed. For example, some IPs may initiate a large number of requests within a specific time period, and these requests cause a large number of packet losses or retransmissions on the server side. By comparing normal traffic patterns and abnormal traffic patterns, the IP address of the attack source is identified and compared with the preset attack threshold. If the number of requests from a certain IP address exceeds the set threshold (for example, more than 500 requests are sent within 10 seconds), the IP address is marked as a possible source of attack.

[0158] Step S237: Obtaining standard traffic pattern data;

[0159] In this embodiment, standard traffic pattern data refers to the typical characteristics of network traffic under normal circumstances. These data are usually obtained by monitoring the network traffic of servers in normal operation. Normal traffic data over a period of time can be collected through tools such as Wireshark and NetFlow as a benchmark for the standard traffic pattern. Standard traffic pattern data should include information such as typical traffic size, packet interval, protocol type, source IP, destination IP, etc. During collection, different time periods can be selected for multiple sampling to ensure the representativeness and accuracy of the traffic pattern. Traffic data under normal circumstances should be collected within each hour to obtain traffic patterns under different load conditions. By analyzing these data, the distribution pattern of traffic under normal circumstances can be identified, and a comparison benchmark can be provided for subsequent abnormal traffic analysis.

[0160] Step S238: marking the flood attack source data as having abnormal communication patterns according to the standard traffic pattern data, thereby obtaining abnormal communication pattern data.

[0161] In this embodiment, the standard traffic pattern data is used as a reference benchmark for normal traffic, and the source of the flood attack can be further analyzed. When the server communication traffic deviates significantly from the standard traffic pattern data (such as a sharp increase in traffic in a short period of time, frequent requests from certain source IP addresses, abnormal data packet size, etc.), it can be judged as abnormal traffic. Specifically, when the identified attack source IP is compared with the standard traffic pattern data, if the communication frequency of the source IP is significantly higher than the normal level, and the data packet size, data transmission rate, etc. of the source IP do not conform to the normal traffic pattern, the communication pattern is marked as abnormal. In this process, a threshold value can be set (for example, exceeding 200% of the normal traffic benchmark) to determine whether it is marked as an abnormal traffic pattern, and ultimately abnormal data is marked for each abnormal source IP or communication pattern.

[0162] Optionally, step S235 is specifically as follows:

[0163] Perform packet loss rate statistics based on the packet loss rate to obtain a high packet loss rate;

[0164] In this embodiment, a data packet capture tool (such as Wireshark, tcpdump) is first used to capture all data packets passing through the network in real time, and the sending time, receiving time, and corresponding source IP and destination IP of each data packet are recorded. During the data capture process, the packet loss situation is counted by comparing the sending and receiving records of each data packet. The specific statistical method is: within the captured time period, each sent data packet is compared one by one to see whether it is successfully received. If a data packet is not confirmed to be received, it is considered to be a packet loss. The packet loss rate is calculated by the following formula: Packet loss rate = (number of lost data packets / number of sent data packets) * 100%. By counting the packet loss situation in each time period, the packet loss rate within a time period can be obtained, and the time period with a higher packet loss rate can be marked. For example, if the packet loss rate exceeds 5%, it is considered that the packet loss situation in this time period is more serious and is marked as a high data packet loss rate.

[0165] Perform retransmission rate statistics based on the data packet retransmission rate to obtain a high data packet retransmission rate;

[0166] In this embodiment, data packets are captured by tools such as Wireshark or tcpdump to identify the sequence number and acknowledgment number of each TCP data packet. According to the TCP protocol, when a data packet is not confirmed, retransmission is triggered. By analyzing the captured data, the data packets that need to be resent are found and their number is counted. The retransmission rate calculation formula is: retransmission rate = (number of retransmitted data packets / total number of data packets) * 100%. For example, within a certain period of time, 1,000 data packets are sent, of which 200 data packets are retransmitted, the retransmission rate is 20%. If the retransmission rate exceeds the set threshold (for example, more than 10%), it is marked as a high data packet retransmission rate. This data helps to analyze network transmission quality and abnormal situations.

[0167] Performing duration analysis according to the high data packet loss rate and the high data packet retransmission rate, thereby obtaining high data packet loss rate duration data and high data packet retransmission rate duration data;

[0168] In this embodiment, the captured network traffic data is divided into time periods (for example, one time period every 10 seconds or every 1 minute), and then the packet loss rate and retransmission rate of each time period are calculated. For each time period, if the packet loss rate exceeds the set threshold (for example, more than 5%) or the retransmission rate exceeds the set threshold (for example, more than 10%), then the time period is recorded as a high packet loss rate or high retransmission rate time period. Next, the duration of each high packet loss rate and high retransmission rate time period is counted, that is, the start time and end time of each time period are counted, and the time difference between these time periods is calculated. For example, if the packet loss rate exceeds 5% for 10 consecutive minutes in a certain period of time, the duration of this period is 10 minutes, which is marked as a high packet loss rate duration. Similarly, if the retransmission rate exceeds 10% for a certain period of time, then this period is recorded as a high retransmission rate duration. By calculating these time periods, it is possible to understand the duration of packet loss and retransmission phenomena, which helps to further analyze network performance issues.

[0169] A flood attack is determined according to the high data packet loss rate duration data and the high data packet retransmission rate duration data, thereby obtaining flood attack data.

[0170] In this embodiment, a flood attack usually causes a long period of packet loss and retransmission in the network. Therefore, it is necessary to determine whether it is a flood attack based on the duration of the packet loss rate and the retransmission rate. The specific operation is: first, compare the duration of the high packet loss rate with the duration of the high retransmission rate. If the duration of the two coincides and lasts for a long time (for example, more than 5 minutes), it may indicate the presence of a flood attack. For further judgment, the traffic peak data can be combined, for example, whether there is an abnormal frequency of data packet transmission during the period of high packet loss rate and high retransmission rate. If large-scale data packets are sent during these periods of high packet loss rate and high retransmission rate, and the source IP is concentrated (for example, multiple attack packets are sent from a few IPs), it can be determined to be a flood attack. By analyzing the data of these continuous time periods, these periods can be marked as flood attack periods, thereby generating flood attack data. The data of a flood attack not only includes the attack period, but also needs to include information such as the attack source IP, the affected target address, and the traffic characteristics of the attack.

[0171] Optionally, step S3 specifically includes:

[0172] Step S31: Calculating the Pearson correlation coefficient based on the abnormal load management data and the abnormal player data to obtain the Pearson correlation coefficient;

[0173] In this embodiment, load management anomaly data and abnormal player data are collected from the system. Load management anomaly data includes key performance indicators such as CPU load, memory usage, and bandwidth usage, while abnormal player data includes player IDs and abnormal behavior characteristics (e.g., abnormal game duration, abnormal kill count, etc.). These data are recorded in timestamp units. Therefore, when processing, the two sets of data must first be aligned by timestamp to ensure that each data point is correctly matched. The Pearson correlation coefficient is calculated to measure the linear correlation between load management anomalies and abnormal player behavior. The Pearson correlation coefficient is a statistical method used to quantitatively describe the strength and direction of the relationship between two data sets. During the calculation process, the values ​​of the load management anomaly data and the abnormal player data are paired to obtain corresponding value pairs. Next, the difference between each pair of data is calculated based on the data mean, and the overall correlation is calculated based on these differences. The resulting Pearson correlation coefficient value ranges from -1 to 1: a value close to 1 indicates a strong positive correlation between load anomalies and abnormal player behavior, a value close to -1 indicates a strong negative correlation, and a value close to 0 indicates almost no correlation between the two. Through this calculation process, we can effectively determine which abnormal player behaviors have a strong relationship with abnormal server load, providing a basis for further analysis of the causes of the abnormality.

[0174] Step S32: performing correlation statistics according to the Pearson correlation coefficient to obtain a positive correlation Pearson correlation coefficient;

[0175] In this embodiment, all Pearson correlation coefficient values ​​are sorted from high to low, and those with correlation coefficients greater than 0 are screened as positive correlation coefficients. Next, highly positively correlated items are screened based on a set threshold (for example, a correlation coefficient greater than 0.7), and the positive correlation coefficient values ​​are recorded and the number of these values ​​is counted. For example, if the proportion of Pearson correlation coefficients greater than 0.7 reaches more than 70%, it is considered that these abnormal player behaviors have a strong positive correlation with load management anomalies. Finally, based on the statistical results, the positively correlated players and load anomaly data are marked for further analysis.

[0176] Step S33: performing abnormal time statistics based on the load management abnormality data and the abnormal player data, thereby obtaining the load management abnormal time data and the abnormal player time data;

[0177] In this embodiment, the load abnormality data and the player abnormal behavior data are segmented into time windows according to the timestamps. In each time window, check whether load abnormality and player behavior abnormality occur. If the CPU load in a certain period of time exceeds the set threshold (for example, the CPU load exceeds 90%), then the period is the load management abnormality time. Similarly, for abnormal player data, if a player's behavior (such as the number of kills) in this time period exceeds the normal range, then the player's behavior in this time period is considered abnormal. By comparing and analyzing the timestamps of the two data sources, the data of load management abnormality time and abnormal player behavior time can be counted. The specific statistical method is to segment by time window (such as 10 seconds, 30 seconds or 1 minute), and count the abnormal frequency in each time window, so as to obtain load management abnormality time data and abnormal player time data.

[0178] Step S34: calculating the overlap of the abnormal load management time data and the abnormal player time data to obtain overlapping time data;

[0179] In this embodiment, the load management abnormality time data and the abnormal player time data are compared by time period to identify the overlapping parts between them. The specific operation is to first determine the start time and end time of each time period, and then calculate whether the time periods of the two data sets have an intersection. If there is an intersection, the duration of the overlapping time period is calculated. For example, if the load management anomaly in a certain period of time lasts for 10 minutes, and the abnormal player behavior occurs within 5 minutes, the overlap of the time period is 5 minutes. By calculating the overlap of all time periods, the overlapping time data can be obtained. If the overlapping time exceeds the set threshold (for example, more than 3 minutes), it is considered that there is a strong relationship between the abnormal behavior of the player and the load anomaly, which is worthy of further analysis.

[0180] Step S35: Abnormal player load management integration is performed based on the overlapping time data and the positive correlation Pearson correlation coefficient, thereby obtaining abnormal player load management data.

[0181] In this embodiment, the overlap time data and the Pearson correlation coefficient are combined, and weighted according to the length of the overlap time and the value of the Pearson correlation coefficient to obtain a comprehensive score for the load management of each abnormal player. The specific operation is that for each abnormal player, the overlap time with the load management anomaly is calculated, and different weights are assigned according to the value of the Pearson correlation coefficient. For example, if the overlap of a player's abnormal behavior within the load management anomaly period is 5 minutes, and the Pearson correlation coefficient is 0.8, then the integrated score of the player's abnormal behavior and load anomaly is high. Finally, the relevant data of all abnormal players and load management anomalies are integrated to obtain the abnormal player load management data. Through this integration process, it is possible to identify player behaviors that may cause or aggravate load management anomalies, providing a basis for subsequent load management optimization and abnormal player identification.

[0182] Optionally, this specification also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements any one of the game data processing methods.

[0183] Optionally, this specification further provides a game data processing system for executing the game data processing method described above, the game data processing system comprising:

[0184] The abnormal player identification module is used to obtain game data and extract game player features based on the game data to obtain game player data; and identify abnormal players based on the game player data to obtain abnormal player data;

[0185] A load management anomaly analysis module is used to extract server resource features and server communication features based on game data, thereby obtaining server resource data and server communication data; and to perform load management anomaly analysis based on the server resource data and server communication data, thereby obtaining load management anomaly data;

[0186] A correlation analysis module is used to perform correlation analysis based on the abnormal load management data and the abnormal player data, thereby obtaining abnormal player load management data;

[0187] A high load analysis module is used to extract CPU load features based on game data to obtain CPU load data, and perform high load analysis based on the CPU load data to obtain CPU high load data;

[0188] The game load balancing optimization and analysis module is used to perform game load balancing optimization analysis based on CPU high load data and abnormal player load management data, thereby obtaining game load balancing data.

[0189] The present invention provides a game data processing system that can implement any game data processing method of the present invention and is used to combine the operations and signal transmission media between various modules to complete the game data processing method. The internal modules of the system cooperate with each other to enhance the user experience and ensure the stable operation of the game.

[0190] The foregoing description is intended only to provide specific embodiments of the present invention, which will enable those skilled in the art to understand and implement the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention is not intended to be limited to the embodiments shown herein, but is to be construed in the widest possible manner consistent with the principles and novel features disclosed herein.

Claims

1. A method for processing game data, characterized in that: The following steps are involved: Step S1: Obtaining game data and extracting game player features based on the game data to obtain game player data; Identify abnormal players based on game player data to obtain abnormal player data; Step S2: extracting server resource features and server communication features based on the game data, thereby obtaining server resource data and server communication data; Perform load management anomaly analysis based on server resource data and server communication data to obtain load management anomaly data; Step S3: performing correlation analysis based on the abnormal load management data and the abnormal player data to obtain abnormal player load management data. Step S3 is specifically as follows: Step S31: Calculate the Pearson correlation coefficient based on the load management abnormality data and the abnormal player data, and align the timestamps of the load management abnormality data and the abnormal player data to obtain the Pearson correlation coefficient; Step S32: performing correlation statistics according to the Pearson correlation coefficient to obtain a positive correlation Pearson correlation coefficient; Step S33: performing abnormal time statistics based on the load management abnormality data and the abnormal player data, thereby obtaining the load management abnormal time data and the abnormal player time data; Step S34: calculating the overlap of the abnormal load management time data and the abnormal player time data to obtain overlapping time data; Step S35: performing abnormal player load management integration based on the overlap time data and the positive correlation Pearson correlation coefficient, thereby obtaining abnormal player load management data; Step S4: extracting CPU load features based on the game data to obtain CPU load data, and performing high load analysis based on the CPU load data to obtain CPU high load data; Step S5: Perform game load balancing optimization analysis based on CPU high load data and abnormal player load management data to obtain game load balancing data.

2. The method for processing game data according to claim 1, wherein: Step S1 is specifically as follows: Step S11: Obtaining game data, and extracting game player features based on the game data, thereby obtaining game player data; Step S12: performing data packet tampering detection based on the game player data, thereby obtaining game player data packet tampering data; Step S13: performing game time statistics on the game player data to obtain short-time game player data; Step S14: performing kill count statistics on the game player data, thereby obtaining game player data with a high kill count; Step S15: performing an intersection operation of potential abnormal players based on the short-time game player data and the high-kill game player data, thereby obtaining potential abnormal player data; Step S16: Identify abnormal players based on the game player data packet tampering data, thereby obtaining abnormal player data.

3. The method for processing game data according to claim 2, wherein: Step S12 is specifically as follows: Step S121: Calculate the client hash value based on the game player data to obtain the client hash value; Step S122: Calculating a server hash value based on the game player data to obtain a server hash value; Step S123: performing a preliminary judgment on whether the data packet has been tampered with based on the client hash value and the server hash value, thereby obtaining preliminary judgment data on whether the data packet has been tampered with; Step S124: extracting data packet features from the game player data to obtain game player data packet data; Step S125: performing distribution time statistics based on the game player data packet data, thereby obtaining the game player data packet distribution time data; Step S126: performing sequence check on the game player data packet release time data to obtain out-of-order data packets; Step S127: confirming the tampering of the data packet preliminary judgment data according to the disordered data packet, thereby obtaining the game player's data packet tampering data.

4. The method for processing game data according to claim 1, wherein: Step S2 is specifically as follows: Step S21: extracting server resource features and server communication features based on the game data, thereby obtaining server resource data and server communication data; Step S22: performing memory leak anomaly analysis on the server resource data to obtain memory leak anomaly data; Step S23: performing communication mode anomaly analysis on the server communication data to obtain communication mode anomaly data; Step S24: performing load management anomaly integration according to the memory leak anomaly data and the communication mode anomaly data, thereby obtaining load management anomaly data.

5. The method for processing game data according to claim 4, wherein: Step S22 is specifically as follows: Step S221: collecting memory data of server resource data to obtain memory data; Step S222: performing memory allocation recording according to the memory data, thereby obtaining memory allocation data; Step S223: performing memory release statistics according to the memory data, thereby obtaining memory release data; Step S224: performing memory leak comparison based on the memory release data and the memory allocation data, thereby obtaining memory leak data; Step S225: locating the memory data leakage scale according to the memory leakage data, thereby obtaining memory leakage scale data; Step S226: Generate a memory snapshot based on the memory data, thereby obtaining memory snapshot data; Step S227: performing memory leak anomaly integration according to the memory leak scale data and the memory snapshot data, thereby obtaining memory leak anomaly data.

6. The method for processing game data according to claim 4, wherein: Step S23 is specifically as follows: Step S231: extracting communication flow characteristics from the server communication data to obtain communication flow data; Step S232: performing data packet transmission statistics based on the communication traffic data to obtain data packet transmission data; Step S233: calculating the packet loss rate of the data packet transmission data, thereby obtaining the packet loss rate of the data packet; Step S234: calculating the retransmission rate of the data packet transmission data, thereby obtaining the data packet retransmission rate; Step S235: performing flood attack analysis based on the packet loss rate and the packet retransmission rate, thereby obtaining flood attack data; Step S236: Identifying the attack source of the server communication data based on the flood attack data, thereby obtaining the flood attack source data; Step S237: Obtaining standard traffic pattern data; Step S238: marking the flood attack source data as having abnormal communication patterns according to the standard traffic pattern data, thereby obtaining abnormal communication pattern data.

7. The method for processing game data according to claim 6, wherein: Step S235 is specifically as follows: Perform packet loss rate statistics based on the packet loss rate to obtain a high packet loss rate; Perform retransmission rate statistics based on the data packet retransmission rate to obtain a high data packet retransmission rate; Performing duration analysis according to the high data packet loss rate and the high data packet retransmission rate, thereby obtaining high data packet loss rate duration data and high data packet retransmission rate duration data; A flood attack is determined according to the high data packet loss rate duration data and the high data packet retransmission rate duration data, thereby obtaining flood attack data.

8. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the method for processing game data according to any one of claims 1 to 7 is implemented.

9. A system for processing game data, characterized in that: A system for processing game data according to claim 1, wherein the system comprises: The abnormal player identification module is used to obtain game data and extract game player features based on the game data to obtain game player data; and identify abnormal players based on the game player data to obtain abnormal player data; A load management anomaly analysis module is used to extract server resource features and server communication features based on game data, thereby obtaining server resource data and server communication data; and to perform load management anomaly analysis based on the server resource data and server communication data, thereby obtaining load management anomaly data; The correlation analysis module is used to perform correlation analysis based on the load management abnormality data and the abnormal player data to obtain the abnormal player load management data, specifically: calculating the Pearson correlation coefficient based on the load management abnormality data and the abnormal player data, and aligning the timestamps of the load management abnormality data and the abnormal player data to obtain the Pearson correlation coefficient; performing correlation statistics based on the Pearson correlation coefficient to obtain the positive correlation Pearson correlation coefficient; performing abnormal time statistics based on the load management abnormality data and the abnormal player data to obtain the load management abnormal time data and the abnormal player time data; calculating the overlap between the load management abnormal time data and the abnormal player time data to obtain the overlap time data; performing abnormal player load management integration based on the overlap time data and the positive correlation Pearson correlation coefficient to obtain the abnormal player load management data; A high load analysis module is used to extract CPU load features based on game data to obtain CPU load data, and perform high load analysis based on the CPU load data to obtain CPU high load data; The game load balancing optimization and analysis module is used to perform game load balancing optimization analysis based on CPU high load data and abnormal player load management data, thereby obtaining game load balancing data.

Images