Game data processing method and system and storage medium

Abstract

The invention relates to the technical field of intelligent optimization and load balancing, in particular to a game data processing method and system and a storage medium. The method comprises the following steps: acquiring game data, and performing game player feature extraction according to the game data so as to obtain game player data; performing abnormal player identification according to the game player data to obtain abnormal player data; performing server resource feature extraction and server communication feature extraction according to the game data so as to obtain server resource data and server communication data; performing load management anomaly analysis according to the server resource data and the server communication data so as to obtain load management anomaly data; and performing association analysis according to the load management abnormal data and the abnormal player data so as to obtain abnormal player load management data. Based on the intelligent optimization and load balancing technology, the user experience is improved, and stable operation of the game is guaranteed.

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 usually rely on simple rules or thresholds for anomaly detection, and cannot effectively identify complex abnormal behaviors in games, such as various cheating methods (plug-ins, data packet tampering, script attacks, etc.) and server load problems caused by abnormal player behavior. This leads to game servers being vulnerable to attacks in high concurrency and high traffic conditions, poor player experience, and difficulty in timely repairing vulnerabilities. In traditional methods, load balancing mechanisms usually rely on preset rules and simple load distribution strategies. When the player behavior in the game changes, traditional load balancing mechanisms are difficult to respond and adjust quickly, which can easily cause local resource overload, increased latency, and unstable services, affecting user experience. Existing network attack detection methods (such as DDoS attacks, flood attacks, etc.) are usually based on traffic monitoring and simple feature matching, and cannot identify and respond to highly complex attack methods in real time. The analysis of attack sources and attack modes is not in-depth enough, resulting in a long response time after the attack occurs, causing the game server to be unavailable or performance to significantly degrade. 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 purpose, a method for processing game data includes the following steps:

[0005] Step S1: Acquire game data, and extract game player features based on the game data to obtain game player data; identify abnormal players based on the game player data to obtain abnormal player data;

[0006] Step S2: extracting server resource features and server communication features according to the game data, thereby obtaining server resource data and server communication data; performing load management anomaly analysis according to the server resource data and server communication data, thereby obtaining load management anomaly data;

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

[0008] Step S4: extracting CPU load features according to the game data to obtain CPU load data, and performing high load analysis according to 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] The present invention can timely discover possible cheating behaviors and malicious attacks by extracting the characteristics of game players and identifying abnormal players, 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 the behavior of which players may cause server load anomalies can be accurately located, so as to optimize and adjust them in a targeted manner. 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. Finally, 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 fluency 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, which can respond to complex network attacks in real time, such as DDoS and flood attacks, etc., greatly improving the server's ability to withstand pressure under high traffic and high concurrency conditions, and effectively avoiding the shutdown or performance degradation of game servers due to attacks, further improving user experience and the reliability of game services.

[0011] Optionally, step S1 specifically includes:

[0012] Step S11: acquiring 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 according to 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: Counting the number of kills of the game players, thereby obtaining the game players with high kill counts;

[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 to obtain abnormal player data.

[0018] The present invention can fully understand the behavior patterns of players through the extraction of player features, and then identify possible abnormal behaviors, laying the foundation for subsequent abnormal player identification. By performing data packet tampering detection on game data, it can effectively find out whether the player affects the game process through plug-ins or tampering tools, timely identify cheating behavior, and prevent it from interfering with the game environment. Game time statistics and kill count statistics can help the system identify players who are too active or have abnormal kill counts in a short period of time. The behavior of these players is often an indication of attack or cheating. Combining the intersection operation of short-term game data and high-kill game data, it is possible to further lock potential abnormal player groups and improve the accuracy of abnormal detection. By combining data packet tampering information with potential abnormal players, it is possible to efficiently identify players who have both suspicious behaviors and may cheat by tampering means, and enhance the reliability of abnormal player identification. This series of steps enables the system to quickly identify abnormal players and potential attackers under high concurrency and high traffic conditions, and then take effective measures to avoid server overload or performance degradation caused by attacks, significantly improving the player's gaming experience. Through this method, dynamic detection and timely response can be achieved, avoiding the limitations of traditional methods based on fixed rules or thresholds, allowing the game server to maintain stable operation in a complex and changing environment, and effectively preventing the impact of in-game cheating and attacks on the system.

[0019] Optionally, step S12 is specifically:

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

[0021] Step S122: Calculate the server hash value according to the game player data to obtain the server hash value;

[0022] Step S123: Perform a preliminary judgment on data packet tampering based on the client hash value and the server hash value, thereby obtaining preliminary judgment data on data packet tampering;

[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 according to the data packet data of the game player, thereby obtaining the distribution time data of the data packet of the game player;

[0025] Step S126: performing a sequence check on the game player data packet release time data, thereby obtaining a disordered data packet;

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

[0027] The present invention improves the accuracy and real-time performance of data packet tampering detection through accurate hash value calculation, data packet feature extraction and release time statistics. First, the calculation of the hash values ​​of the client and the server ensures the consistency of the data packet content during the transmission process, and can quickly discover possible tampering behaviors between the client and the server. By preliminarily judging whether the data packet has been tampered with, cheating behaviors in the game, such as plug-in and malicious script attacks, can be effectively intercepted. Next, by extracting the characteristics of the data packet and performing release time statistics, the data packet analysis process is further improved, so that the legitimacy of the data packet can be more accurately judged. The sequence check of the data packet can effectively identify disordered data packets, timely discover network attacks or data packet tampering behaviors, and avoid game process confusion or errors caused by disordered packets. Finally, combined with the confirmation of disordered data packets and the verification of tampered data, the confirmation of data packet tampering behaviors is further deepened, so that the system can accurately identify and filter out malicious tampered data, and ensure the integrity and security of game data. In this way, the entire detection process can not only identify and prevent cheating behaviors in real time and accurately, but also improve the protection capability of the game server, reduce the risk of system failure caused by data packet tampering, and optimize the player experience.

[0028] Optionally, step S2 specifically includes:

[0029] Step S21: extracting server resource features and server communication features according to 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, thereby obtaining memory leak anomaly data;

[0031] Step S23: performing communication mode abnormality analysis on the server communication data, thereby obtaining communication mode abnormality 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 through the extraction of server resources and communication characteristics, and timely 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 blockage, 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, avoid system crashes or performance degradation caused by excessive server load, and greatly improve the stability of game services and player experience.

[0034] Optionally, step S22 is specifically:

[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 according to 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 the memory leakage scale data;

[0040] Step S226: Generate a memory snapshot according to 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, can clearly understand the allocation and release status of memory, and thus provides basic data for memory leak detection. By recording the memory allocation and release, the memory usage track can be tracked in detail, and memory blocks that are improperly released or have not been released for a long time can be found, and potential memory leak problems can be revealed in time. Further, through memory leak comparison, the data of memory allocation and release can be compared, and the actual leakage data can be accurately identified to avoid the performance degradation of the game server caused by memory leak. Next, the location of the memory leak scale can help operation and maintenance personnel to clarify the specific location and impact range of the leak, so as to take targeted repair measures. The generation of memory snapshots provides a detailed static view for analyzing the memory state, helping to identify the root cause of the memory leak and the specific time that caused the leak. Finally, by integrating the memory leak scale data with the memory snapshot data, the specific anomalies of the memory leak can be fully identified, and effective optimization measures can be taken in time to prevent the memory leak from further expanding, thereby improving the operating efficiency and stability of the game server, thereby improving the game experience of the players and avoiding game crashes or delays caused by memory leaks.

[0043] Optionally, step S23 is specifically:

[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 according to the communication flow data, thereby obtaining 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 according to 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 according to the flood attack data, thereby obtaining the flood attack source data;

[0050] Step S237: Obtain 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 the communication status of the server through the extraction of communication traffic characteristics, so that the traffic change trend of the data packet can be grasped in real time, and the basis for further analyzing network anomalies is provided. By calculating the statistics of data packet transmission, the characteristics of the transmission frequency and size of the data packet can be understood, which helps to find abnormal communication behaviors, such as a sudden increase in traffic. The calculation of packet loss rate and retransmission rate can effectively identify abnormal situations in the communication process. For example, a sharp increase in packet loss rate may indicate network congestion or attack behavior, and an abnormal increase in retransmission rate can indicate problems in data transmission, especially when suffering from flood attacks, packet loss and retransmission rates usually increase significantly. Through the joint analysis of packet loss rate and retransmission rate, it can be clearly judged whether a flood attack is encountered, especially in the case of a surge in traffic and serious packet loss, and a timely response and attack prediction can be made through comprehensive analysis. Identifying the source of flood attacks helps to accurately locate the source of the attacker, and facilitates the blocking and filtering measures to the attack source to prevent the attack from spreading or affecting other normal users. At the same time, obtaining standard traffic pattern data provides a reference for the benchmark of network traffic behavior, which can more accurately identify and analyze abnormal communication patterns from attack sources. Ultimately, by marking the communication pattern anomalies of flood attack source data, malicious attack traffic can be effectively marked, thereby providing clear attack instructions for traffic filtering and defense systems, ensuring that game servers can operate stably in high-traffic, high-concurrency environments, and promptly identifying and responding to complex network attacks to ensure players' gaming experience.

[0053] Optionally, step S235 is specifically:

[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 respectively according to the high data packet loss rate and the high data packet retransmission rate, so as to obtain high data packet loss rate duration data and high data packet retransmission rate duration data;

[0057] A flood attack is determined based on 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 rate and retransmission rate, especially when suffering from flood attack, the packet loss and retransmission rate tend to increase significantly. The statistical results of high packet loss rate and high packet retransmission rate can reveal potential network problems in the communication process, such as network congestion, packet loss or malicious attack. The duration analysis of packet loss rate and retransmission rate can further help identify whether these abnormal phenomena are manifestations of long-term attack behavior. By analyzing the duration of high packet loss rate and high retransmission rate respectively, the present invention can accurately determine whether these network problems are caused by flood attack, and then establish the occurrence of flood attack. This method can not only identify potential attack patterns, but also conduct in-depth analysis according to the duration of attack, help network defense system to timely identify and respond to complex network attacks, avoid the problem of slow response to attacks in traditional methods, ensure that the game server maintains stable and efficient operation in a high concurrency and high traffic environment, and significantly improve the detection and defense capabilities of network attacks.

[0059] Optionally, step S3 specifically includes:

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

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

[0062] Step S33: performing abnormal time statistics according to the load management abnormal 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, thereby obtaining the overlap time data;

[0064] Step S35: Abnormal player load management integration is performed according to the overlapping time data and the positive correlation Pearson correlation coefficient, so as to obtain 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 behaviors, 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 behaviors can be clearly identified, thereby providing effective data support for further optimization. Based on the load management abnormality data and abnormal player data, abnormal time statistics can be performed to accurately obtain the time node when the abnormal behavior occurs, and compare it with the server's load data to find out the specific time period when the abnormal event occurs, ensuring that the system can respond effectively during these critical periods. 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 fluency of the game and the player's experience.

[0066] Optionally, the present 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 described above.

[0067] Optionally, the present specification further provides a game data processing system, which is used to execute the game data processing method as described above, and the game data processing system includes:

[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, used for performing correlation analysis based on the load management abnormality data and the abnormal player data, so as to obtain the abnormal player load management data;

[0071] A high load analysis module is used to extract CPU load features according to game data to obtain CPU load data, and to perform high load analysis according to 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 and analysis based on CPU high load data and abnormal player load management data, so as to obtain game load balancing data.

[0073] A game data processing system of the present invention can implement any game data processing method of the present invention, and is used to combine the operation and signal transmission medium 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 from the detailed description of non-limiting embodiments thereof made with reference to the following drawings:

[0075] Figure 1 A schematic flow chart of 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 It is a detailed flowchart diagram of step S12 in the present invention.

[0078] The realization of the purpose, functional features and advantages of the present invention will be further explained in conjunction with embodiments and with reference to the accompanying drawings. 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 described embodiments 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 technicians in this field without creative work are within the scope of protection of the present invention.

[0080] In addition, the accompanying drawings are only schematic illustrations of the present invention and are not necessarily drawn to scale. The same reference numerals in the figures represent the same or similar parts, and their repeated description will be omitted. Some of the block diagrams shown in the accompanying drawings are functional entities and do not necessarily correspond to physically or logically independent entities. The functional entities can be implemented in software form, or implemented in one or more hardware modules or integrated circuits, or implemented in different networks and / or processor methods and / or microcontroller methods.

[0081] It should be understood that, although the terms "first", "second", etc. may be used herein to describe various units, these units should not be limited by these terms. These terms are used only to distinguish one unit from another unit. For example, without departing from the scope of the exemplary embodiments, the first unit may be referred to as the second unit, and similarly the second unit may be referred to as the first unit. The term "and / or" 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: Acquire game data, and extract game player features based on the game data to obtain game player data; identify 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 the log of the server side, the operation record of the player side, the real-time communication data, etc. The data obtained include player ID, login time, behavior pattern (such as operation records such as click, move, attack, death, pick up items), and game process data related to the player (such as score, win or lose results, etc.). Then, the game player feature extraction is performed for these data. Feature extraction includes statistics on the behavior frequency, the number of games participated in, the average game time, etc. of each player, and the basic behavior feature data of each player is obtained. For abnormal player identification, features such as the number of kills, the number of deaths, and the game time are used for screening, and a threshold is set (for example, the number of kills of the player exceeds 30 times / minute or the game time exceeds 3 hours) to determine whether it is an abnormal player. In addition, the behavior pattern of abnormal players can be further confirmed by the interactive data between the player and other players (such as the number of player PKs and the frequency of transactions with other players). Finally, combined with these 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 according to the game data, thereby obtaining server resource data and server communication data; performing load management anomaly analysis according to the server resource data and server communication data, thereby obtaining 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 (such as 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 usage and average usage of memory, and setting a threshold (such as 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 as a potential load abnormality. Server communication feature extraction focuses on features such as communication traffic, data packet size, and data packet sending frequency between the server and the client. For communication traffic, the data packet transmission volume per second is counted, and the traffic fluctuation range is set (for example, a transmission volume greater than 1MB per second is a high traffic state). Next, we analyze the load management anomaly based on the collected server resource data and communication data, and combine it with historical data (for example, the CPU usage rate exceeded 90% more than 5 times in the past hour) to further determine whether there is a server load anomaly. Finally, based on these data and analysis results, we obtain the load management anomaly data and form an anomaly report.

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

[0088] In this embodiment, the collected load management abnormal data includes indicators such as the server's CPU load, memory usage, and bandwidth occupancy. The CPU load data reflects the processing power of the server, while the memory usage and bandwidth occupancy data can reflect whether the server has signs of resource overload. At the same time, the collected abnormal player data includes the abnormal player's ID, their abnormal behavior characteristics, such as abnormal game time, excessive kill count, frequent operations, etc. Abnormal behavior can be determined by the player performing a large number of operations in a short period of time, or exceeding the normal game time. The Pearson correlation coefficient is used to quantify the correlation between load anomalies and abnormal player behavior. In order to calculate, the load management data and the abnormal player data must first be aligned on the time axis to ensure that the behavior analyzed is within the same time period. By performing correlation analysis on these two types of data points, the correlation between the two is obtained. For example, if a player performs a large number of kills during a period of high CPU load on the server, this indicates that the player's behavior may be directly related to the server's load anomaly. To this end, a threshold is set (for example, the Pearson correlation coefficient is 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, the overlap between abnormal players' activity time and load abnormalities can be analyzed. Specifically, the abnormal answering time of players is counted and compared with the time period of abnormal load to analyze the overlapping parts. For example, if a player frequently operates during the time period of abnormal server CPU load, it means that the player may be one of the causes of server overload. By comprehensively analyzing these data, abnormal player load management data can be obtained to help the platform identify which players' abnormal behaviors are strongly correlated with server load abnormalities. This analysis can provide strong support for subsequent load optimization and abnormal player management.

[0089] Step S4: extracting CPU load features according to the game data to obtain CPU load data, and performing high load analysis according to 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 to collect data related to CPU usage from the game server, usually using monitoring tools provided by the operating system. For example, in a Linux environment, the top command, mpstat command, or pidstat tool can be used to obtain CPU usage data. The collected data usually includes the overall load percentage of the CPU and the load of each core. The load value in each data record is displayed as a percentage, indicating the current CPU or core usage. For example, "CPU load is 85%" means that at this moment, the CPU usage is 85%. In order to obtain more detailed data, it can be set to collect data every 1 second or 5 seconds. The choice of this sampling interval usually depends on the frequency of changes in the server load. If high-frequency 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. The aspect that needs special attention is that in a multi-core processor system, it is not enough to rely solely on the overall CPU load. It is also necessary to obtain the usage of each CPU core to evaluate whether all cores are in a high-load state or some cores have local high-load problems. The load data of each core can be extracted through the performance counters of / proc / stat (Linux) or Windows provided by the operating system. Next, high-load analysis is performed. In this step, you need to define a specific threshold to determine whether the CPU enters a high-load state. This threshold is set by statistically analyzing the historical data of the normal load of the server. For example, if the CPU load is usually below 50%, then set 90% as the high-load threshold, or set it to 95% as a severe high-load indicator based on actual needs. The threshold setting needs to be adjusted according to the actual workload of the server. For example, if the CPU load of the server can reach 80% under high concurrency but does not affect normal operation, then the threshold should be appropriately increased. To determine whether there is a high load, it is also necessary to analyze the duration to ensure that the duration of the high-load state meets the set standard. The CPU load data is continuously recorded through the monitoring tool. When the CPU load exceeds the set threshold, it is necessary to determine how long the state lasts. Usually, the threshold is set to 90%, and the high-load state is required to last for no less than 5 minutes. If the CPU load is maintained above 90% for most of the time within 5 minutes, it is considered that the CPU is in a high-load state during this period. If the CPU load fluctuates continuously, you also need to pay attention to the trend of these fluctuations. If the high load state occurs intermittently, but each time it lasts for a long time or occurs frequently, it can also be considered as a potential high load situation. The system should monitor the high load with a rolling window to ensure that load fluctuations can be discovered in a timely manner. The generation of high load data is the key to this process.First, through the analysis of historical load data, record the time period when the CPU load exceeds the threshold each time, and attach the relevant timestamp. Each data point includes not only the load value, but also the specific time when the high load occurs, such as the start and end time of the period, the duration, and the load of each CPU core. In a multi-core system, in addition to recording the overall load, it is also necessary to pay attention to the usage of individual cores. For example, a core may be in a high load state for a long time, while other cores have lower loads, which may be caused by a specific process or task. In order to more accurately identify high loads, when recording the load data of each core, ensure that its timestamp is consistent with the global load data. In practical applications, all of this data needs to be stored through a log system, such as using ELK (Elasticsearch, Logstash, Kibana) log management system, Graylog, etc. for log recording and storage. These data can not only help administrators find the bottleneck of server resources in a timely manner, but also provide a basis for subsequent optimization. In subsequent analysis, by analyzing these high-load data, the system can determine whether the abnormal increase in server load is caused by a specific game player behavior, certain events or functions in the game. For example, when a player performs a large number of operations, it may cause abnormal CPU load on the server, which in turn leads to a decrease in the performance of the game server. Through these data analysis, the system can be further optimized and adjusted in combination with other modules (such as abnormal player detection, load balancing optimization, etc.). This process provides strong data support for the load balancing adjustment and performance optimization of the server, ensuring that the server can run stably under high concurrency and high load conditions.

[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 the historical record of CPU load, as well as the period and duration of high load state. For example, if the CPU load exceeds 90% for a period of time and the state lasts for more than 5 minutes, it is considered to be a high load state. Each record contains not only the total load percentage of the CPU, but also the usage of each CPU core. These data are collected through the API provided by the monitoring tool or the operating system (such as mpstat, pidstat or Windows performance monitoring under Linux). Abnormal player load management data includes load data related to specific players, which are extracted from the game server log. The specific content includes the behavior patterns of abnormal players (such as frequent operations, ultra-high kill counts, etc.), which may cause additional load on the server. The load data of each player is usually obtained by the game server through real-time monitoring, including the frequency of player operations, request processing time, memory consumption, etc. By combining with the CPU high load data, it is possible to identify which players' activities directly affect the server's load situation. First, these data are merged. By comparing the period of high CPU load with the behavior data of abnormal players, it is determined which players have performed a large number of game operations during the period of high CPU load. For example, if the CPU load of the server exceeds 90% continuously during a certain period of time, and it is found that some players have performed frequent operations (such as killing, character movement, etc.) during this period, these players can be marked as key players that may cause the server load to increase. Load balancing optimization analysis is performed based on these data. The core goal of load balancing is to evenly distribute the server load to different resources, so as to avoid excessive consumption of a certain part of resources and cause performance degradation. Based on the CPU high load data and abnormal player load data, dynamic load balancing algorithms can be applied for optimization. The specific operation is: in areas where player behavior is too concentrated, reduce the resource occupation of specific players and dispatch their requests to server nodes with lower loads. Assuming that the player behavior density in a certain area is high, the game sessions of these players can be migrated from the current node to a node with lighter resource load. Load balancers, such as load balancers based on Nginx or HAProxy, can be used to dynamically adjust the resource allocation of the server according to real-time CPU load data. In specific load balancing adjustments, specific thresholds and rules need to be set. For example, if the CPU load exceeds 90% and lasts for more than 3 minutes, the load transfer mechanism is started. For abnormal players, the 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. At this time, the server will balance the overall load by migrating the player sessions with higher loads to other servers or nodes. A load balancing strategy and a weight distribution model are also required.For example, a server node with an extremely high load is assigned a lower load weight, while a server node with a low load is assigned a higher weight. The weight value of each server node should be dynamically adjusted based on the CPU load, memory usage, and number of connections. In the load balancing system of the game server, the load of each node is monitored in real time, the load transfer rules are adjusted dynamically, and it is ensured that during high-load periods, the system can automatically identify high-load areas and allocate resources.

[0093] Optionally, step S1 specifically includes:

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

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

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

[0097] In this embodiment, the communication data packet of each player is extracted from the game data, specifically including the data packet transmission record between the client and the server. By comparing the client hash value with the server hash value, check 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 is an abnormal situation of retransmission or packet loss in the data packet. 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, the game time of each player is calculated, and the player's online time is counted through time series analysis, specifically by matching the player ID with the corresponding login and logout time. The system will record the time of each player's login and logout, calculate the game time of each session, and summarize the total time of the player during the entire game. Through data analysis, player data with frequent logins or abnormal game time in a short period of time is identified, such as players logging in multiple times in just a few minutes, or the game time of some players far exceeds the normal level. By setting a threshold, such as logging in more than 5 times in 1 hour, or a single game time of more than 30 hours, etc., it is marked as short-time game player data.

[0100] Step S14: Counting the number of kills of the game players, thereby obtaining the game players with high kill counts;

[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 player's kill count exceeds a certain threshold (such as more than 50 kills per hour), the player's kill count is considered to be abnormally high. By comparing the player's kill count with his overall game time, the player's behavioral characteristics are further analyzed and marked as high kill count game player data. Statistics use a cumulative method to sum and update the kill behavior data of each player 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, the data of short-time game players and the data of high-kill game players are screened to extract the intersection of the two. For example, players with extremely short game time and high kill counts are screened out, which may be abnormal players using plug-ins or scripts. This process is performed using set intersection operations to extract player data that frequently performs high kills in a short period of time. Multiple rules can be set: for example, when a player's game time is less than 30 minutes and the number of kills is greater than 20 times, the player is considered to have abnormal behavior. The potential abnormal player data finally obtained can be realized by database query, where the short-time player data and the high-kill player data are associated and matched according to the ID and timestamp, and the intersection part is extracted.

[0104] Step S16: Identify abnormal players based on the game player data packet tampering data to obtain 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 marks him 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 thresholds for data packet tampering detection and behavior analysis can be set to: when a player's behavior pattern is frequently abnormal and differs greatly from the normal characteristics of his communication data packet, he can be marked as an abnormal player.

[0106] Optionally, step S12 is specifically:

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

[0108] In this embodiment, the data packet content sent by the client to the game server is collected, including the player's operation data, location data, resource consumption and other information. These data will be processed by a standard hash algorithm. The commonly used hash algorithm is SHA-256. By inputting the data packet content into the SHA-256 algorithm, a unique 256-bit hash value is generated. The hash value is used to identify the uniqueness of the client data to prevent the data from being tampered with during transmission. The specific operation is: after the client data is extracted from the game client, the hash value of the client data packet is calculated using a standard hash function. Ensure that the content of the transmitted data remains consistent during each calculation and is not affected by any modification or tampering. The standard for hash value calculation 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: Calculate the server hash value according to the game player data to obtain the 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 the 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 potential abnormalities.

[0111] Step S123: Perform a preliminary judgment on data packet tampering based on the client hash value and the server hash value, thereby obtaining preliminary judgment data on data packet tampering;

[0112] In this embodiment, the hash values ​​calculated by the client and the server are compared to check whether they are consistent. The specific method is: a hash value is calculated from each data packet sent by 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 judged 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.

[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 communication data packet of the player, various features of the data packet are identified by extracting features from 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 behavior event data of the player is classified in detail, and the feature data related to the player's behavior is extracted for subsequent data analysis.

[0115] Step S125: performing distribution time statistics according to the data packet data of the game player, thereby obtaining the distribution time data of the data packet of the game player;

[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. The data packet issuance time statistics include: recording the time point when the player sends a data packet each time, and calculating the interval time between data packet sending. For example, by calculating the time difference between each two consecutive data packets, the player's activity level and sending frequency in a certain time period can be determined. In order to determine the regularity of the issuance time, a threshold can be set: if the interval between the sending of a data packet of a player is less than 0.5 seconds and occurs frequently, it is marked as a high-frequency sending of data packets. On this basis, the sending pattern of each player in a specific time period can be calculated to generate time distribution statistics.

[0117] Step S126: performing a sequence check on the game player data packet release time data, thereby obtaining a disordered data packet;

[0118] In this embodiment, a sequence check is performed based on the release time data, that is, checking 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 sending time. Then, the sorted data packet sequence is analyzed to find out whether there is any abnormal timestamp sequence. For example, if the timestamps of some data packets appear in reverse order (that is, 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, so as to obtain 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 is initially determined. The contents of the comparison include the timestamp, content, and transmission frequency of the data packet, etc., to find abnormal association patterns. For the detected out-of-order data packets, the system will check whether the hash value of the data packet is consistent with the hash value of the data packet on the client and server. 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 specifically includes:

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

[0123] In this embodiment, it is necessary to collect resource usage data and communication data of the server. Server resource feature extraction includes obtaining resource usage information such as CPU usage, memory usage, disk IO, network bandwidth, etc. from the server monitoring system. These data can be obtained through the tools provided by the server's operating system (such as the top command and vmstat command in the Linux system) or special monitoring tools (such as Prometheus, Zabbix, etc.). Server communication feature extraction includes capturing the communication data packets between the server and the client through network monitoring tools (such as Wireshark or tcpdump), and extracting the communication frequency, data packet size, communication protocol (such as TCP, UDP) and the number of requests processed per second. These resource data and communication data will be organized into structured table data and stored in a database or temporary cache for subsequent analysis. For each type of resource and communication feature, a certain threshold will be set. For example, when the CPU usage is greater than 80%, the memory usage exceeds 70%, and the bandwidth occupancy exceeds 90%, it will be marked as a high load state. Through the extraction of these features, the resource consumption and communication load of the server can be fully understood.

[0124] Step S22: performing memory leak anomaly analysis on the server resource data, thereby obtaining memory leak anomaly data;

[0125] In this embodiment, it is necessary to obtain the memory usage of the server. These data can be obtained through the memory statistics command of the operating system (such as free, top, etc. in Linux), or the memory usage data can be collected regularly through the system monitoring tool. Time series analysis is performed on the memory data to determine whether there is a memory leak phenomenon. The characteristics of memory leaks are usually manifested as a gradual increase in memory usage and a constant release amount, resulting in a continuous increase in memory occupancy. During the specific operation, an initial memory usage benchmark value is first set, and then the memory usage at regular intervals (for example, every minute or every hour) is calculated. By comparing two consecutive data, if it is found that the memory usage continues to increase for a long time (such as an increase of more than 10% per hour), and there is no corresponding release operation, it can be preliminarily determined that the memory leak is abnormal. On this basis, it is also possible to combine the system log file (such as / var / log / messages) to check whether there is abnormal error information related to memory allocation to further confirm the memory leak phenomenon. Finally, memory leak abnormal data is formed, including abnormal time period, abnormal memory usage and corresponding system resource consumption information.

[0126] Step S23: performing communication mode abnormality analysis on the server communication data, thereby obtaining communication mode abnormality data;

[0127] In this embodiment, data packets are collected by network data packet capture tools (such as Wireshark, tcpdump), and then the timing, communication protocol, data packet size, data packet frequency and other information of the communication are extracted therefrom. Under normal circumstances, the communication between the game server and the client should follow a certain mode, such as the request-response mode, or the stability of the data flow, etc. The abnormal communication mode is usually manifested as abnormal request frequency, too long response time for a single request, repeated data packets, or high-frequency data packet transmission, etc. In order to perform abnormal analysis, it is necessary to set the normal threshold of the communication mode, for example, the request frequency of a certain IP address should not exceed 10 times per second, and the size of a certain data packet should not exceed 1MB. If it is found that the data packet transmission frequency, data packet size or response time exceeds the threshold, it can be marked as abnormal communication mode. By statistically analyzing the communication timing of each client, it is checked whether there are abnormal burst traffic, retransmission requests or repeated data packets. Through the abnormal detection of these communication modes, abnormal player behavior or malicious communication attacks can be identified in time.

[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, it is necessary to perform correlation analysis on the memory leak abnormal data and the communication mode abnormal data. After combining these two types of abnormal data, analyze whether there is a correlation between the memory leak and the communication mode abnormality. For example, in a certain time period, if the memory leak and the communication mode abnormality occur at the same time, it may indicate that the server load is high and there is a problem with resource management. The integration process includes: correlating the timestamps of the memory leak data and the communication mode abnormal data, and checking whether there is an abnormal communication mode while the memory occupancy continues to increase; at the same time, it is also necessary to check whether the time period with high load coincides with the frequent exchange of communication data or abnormal data packet transmission. The integrated data can generate the final load management abnormal data by setting a certain correlation threshold (for example, if the memory usage is greater than 80% and the request frequency exceeds 10 times / second, it is considered to be a load management abnormality). Finally, combined with these abnormal information, it is possible to identify which server resources are overloaded and which communication requests are too frequent, thereby helping to optimize the server load and avoid performance degradation or downtime problems.

[0130] Optionally, step S22 is specifically:

[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 tool or third-party monitoring tool that the operating system comes with. For Linux systems, real-time monitoring can be performed using commands such as vmstat, free, and top. 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 (Performance Monitor) can be used to obtain memory usage. Through these tools, memory usage data is collected regularly 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 can ensure the integrity and real-time nature of the data by setting a data collection cycle (such as 1 minute) and a 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, the 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 log 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 memory application of the system log or a specific process can be monitored, such as the memory allocation of a process at a certain moment. Each memory allocation will record information such as memory address, allocation size, process ID, etc. These memory allocation data will generate a table to record 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, and memory release refers to the process of the system or application reclaiming memory space that is no longer used. 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 track the memory usage of the application through the ps command, the top command or through the analysis of the memory mapping file. For each memory release, the memory recovery size, the release time and the corresponding process information need to be recorded. In the Windows operating system, the memory release 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 is triggered when the release is released. The time granularity of data collection should ensure sufficient accuracy, and it is usually selected to collect once every 10 seconds or 1 minute, and analyze it together with the memory allocation data.

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

[0138] In the present embodiment, memory leak comparison is performed according to memory release data and memory allocation data. Memory leak generally refers to the failure of memory to be released normally after being allocated, resulting in waste of system resources. The comparison process needs to be analyzed by information such as the time and size of memory allocation records and memory release records. In the specific implementation, all memory allocation data and memory release data are first time-aligned, and it is checked whether there are unreleased memory blocks within a certain time period. For example, if a process allocates 100MB of memory, but there is no release operation during its life cycle, and the memory occupancy continues to grow, 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 the memory leakage scale data;

[0140] In the present embodiment, the memory data is leaked according to the memory leak data. First, the specific time period of the leak and its corresponding memory size are determined according to the time information and memory usage data in the memory leak data. In the specific operation, it can be determined whether the leaked memory is released on schedule by comparing the time difference between memory allocation and release. For example, if a process allocates memory multiple times within a specific time, but does not release it in time, when the leaked memory block accumulates to exceed the set threshold (for example, 500MB), the memory leak scale can be preliminarily determined. The memory leak scale positioning can also be combined with the memory allocation amount of the process, the memory usage trend and other indicators, through linear regression or other algorithm analysis, to further determine the memory range of the leak. For example, in a certain time period, the memory occupancy of process A continues to grow, and each time after the memory is allocated, there is no release, and when the cumulative leakage exceeds the set threshold, it is confirmed that the memory leak scale is large. The leakage scale data can be recorded as a specific memory block size and a time window in which the leakage occurs.

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

[0142] In this embodiment, a memory snapshot is generated based on memory data, and a memory snapshot refers to a complete record of the system memory state at a specific moment. When generating a memory snapshot, data can be captured using the system's own tools. For example, in Linux, a memory snapshot of a process can be obtained by using the gcore command, or by combining the ps command with the top command. In Windows, a memory snapshot can be obtained through a Windows debugging tool (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. Each snapshot data generated will be stored in a file or database as a basis for subsequent memory analysis. Each snapshot record includes the overall usage of the memory 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 needs to be associated with the corresponding memory snapshot data for analysis. 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:

[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 statistically analyzing these traffic data, the detailed information of the communication traffic can be obtained, including the distribution of the traffic, the fluctuation of the traffic, etc. 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 captured data packet size, transmission rate, protocol type and other parameters 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 according to the communication flow data, thereby obtaining data packet transmission data;

[0149] In this embodiment, in order to perform statistics on the transmission of data packets, it is first necessary to monitor the traffic of the network interface of the server 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 in the time period. In 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 the data packets lost during the transmission process 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 the data packets captured by tools such as Wireshark, the sending time and receiving time of each data packet can be clearly recorded. According to 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 1000 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 value (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, the retransmission of a data packet usually occurs when a packet loss or transmission delay occurs in the network. In order to calculate the retransmission rate, it is necessary to track the sending and confirmation (ACK) information of each data packet. In data packet capture tools such as Wireshark, data packets of the TCP protocol usually carry sequence numbers and confirmation numbers. By analyzing this information, the same data packets that are repeatedly sent, i.e., retransmission packets, can be identified. Each retransmission of a data packet will increase the number of retransmissions, so the retransmission rate can be calculated by counting the ratio between the number of retransmitted data packets and the total number of data packets. For example, within a certain period of time, 1000 data packets are sent, of which 100 data packets are retransmitted, and the retransmission rate is 10%. In this calculation process, special attention should be paid to TCP retransmission, the original data packets sent and the retransmitted data packets are identified, the differences between them are counted, and the retransmission rate is finally obtained. In implementation, when the retransmission rate exceeds a certain threshold (such as 10%), it can be regarded as a problem with the network quality, and further investigation is carried out.

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

[0155] In this embodiment, a flood attack usually causes a server processing capacity overload by sending a large number of invalid data packets, thereby affecting normal communication. According to the packet loss rate and retransmission rate obtained by 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 response time of the server will also be greatly delayed. By setting the thresholds of the packet loss rate and the 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 the flood attack. In further analysis, it is also possible to combine the fluctuations in the packet sending rate 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 the analysis.

[0156] Step S236: identifying the attack source of the server communication data according to 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 source IP address, transmission protocol, port number, etc. 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 initiated 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 for 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: Obtain 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 server network traffic 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 typical traffic size, packet interval, protocol type, source IP, destination IP and other information. 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 source of the flood attack can be further analyzed by using the standard traffic pattern data as a reference benchmark for normal traffic. When the server communication traffic and the standard traffic pattern data show a significant deviation (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 match the normal traffic pattern, the communication pattern is marked as abnormal. In this process, a threshold value (for example, more than 200% of the normal traffic benchmark) can be set to determine whether to mark it 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:

[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 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 in each time period, the packet loss rate in 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 in this time period is more serious and is marked as a high 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 confirmation 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 packet data, find out those data packets that need to be resent and count their number. 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, 1000 data packets are sent, of which 200 data packets are retransmitted, and 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 respectively according to the high data packet loss rate and the high data packet retransmission rate, so as to obtain 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 a set threshold (for example, more than 5%) or the retransmission rate exceeds a set threshold (for example, more than 10%), 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 continues to exceed 5% for 10 consecutive minutes in a certain period of time, the duration of the period is 10 minutes, which is marked as a high packet loss rate duration. Similarly, if the retransmission rate continues to exceed 10% in a certain period of time, the period is recorded as a high retransmission rate duration. By calculating these time periods, the duration of packet loss and retransmission phenomena can be understood, which helps to further analyze network performance issues.

[0169] A flood attack is determined based on 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 judge 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 peak traffic data can be combined, such as 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 centralized (for example, multiple attack packets are sent from a few IPs), it can be determined as a flood attack. By analyzing the data of these continuous periods, these periods can be marked as flood attack periods, thereby generating flood attack data. The data of the 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: Calculate the Pearson correlation coefficient based on the load management abnormal data and the abnormal player data to obtain the Pearson correlation coefficient;

[0173] In this embodiment, load management abnormal data and abnormal player data are collected from the system. Load management abnormal data includes key performance indicators such as CPU load, memory usage, bandwidth occupancy, etc., and abnormal player data includes player ID and abnormal behavior characteristics (such as abnormal game time, abnormal number of kills, etc.). These data are recorded in timestamps, so when processing, the two sets of data need to be aligned by timestamp first to ensure that each data point can be 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 for quantitatively describing the strength and direction of the relationship between two data sets. During the calculation process, the values ​​of load management abnormal data and abnormal player data are paired to obtain corresponding value pairs. Afterwards, the difference between each pair of data is calculated based on the mean of the data, and the overall correlation is calculated based on these differences. The obtained Pearson correlation coefficient value varies between -1 and 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 that there is 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 abnormalities.

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

[0175] In this embodiment, all Pearson correlation coefficient values ​​are sorted from high to low, and those correlation coefficient values ​​greater than 0 are screened out as positive correlation coefficients. Next, highly positively correlated items are screened out according to 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 and load management anomalies have a strong positive correlation. 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 according to the load management abnormal 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 timestamp. 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 of time is the load management abnormal 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, it is considered that the player's behavior in this time period is abnormal. By comparing and analyzing the timestamps of these 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 abnormal 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, thereby obtaining the overlap time data;

[0179] In this embodiment, the load management abnormal 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 according to the overlapping time data and the positive correlation Pearson correlation coefficient, so as to obtain 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 of 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 in the load management abnormal period is 5 minutes, and the Pearson correlation coefficient is 0.8, then the integration 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, those player behaviors that may cause or aggravate load management anomalies can be identified, providing a basis for subsequent load management optimization and abnormal player identification.

[0182] Optionally, the present 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 described above.

[0183] Optionally, the present specification further provides a game data processing system, which is used to execute the game data processing method as described above, and the game data processing system includes:

[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, used for performing correlation analysis based on the load management abnormality data and the abnormal player data, so as to obtain the abnormal player load management data;

[0187] A high load analysis module is used to extract CPU load features according to game data to obtain CPU load data, and to perform high load analysis according to 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 and analysis based on CPU high load data and abnormal player load management data, so as to obtain game load balancing data.

[0189] A game data processing system of the present invention can implement any game data processing method of the present invention, and is used to combine the operation and signal transmission medium 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 above description is only a specific embodiment of the present invention, so that those skilled in the art can understand or implement the present invention. Various modifications to these embodiments will be 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 will not be limited to the embodiments shown herein, but should conform to the widest scope consistent with the principles and novel features invented herein.

Claims

1. A method for processing game data, characterized in that: The following steps are involved: Step S1: Obtain game data, and extract game player features based on the game data to obtain game player data; Identify abnormal players based on game player data, thereby obtaining 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 load management abnormality data and the abnormal player data, thereby obtaining abnormal player load management data; Step S4: extracting CPU load features according to the game data to obtain CPU load data, and performing high load analysis according to 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, characterized in that: Step S1 is specifically as follows: Step S11: acquiring game data, and extracting game player features based on the game data, thereby obtaining game player data; Step S12: performing data packet tampering detection according to 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: Counting the number of kills of the game players, thereby obtaining the game players with high kill counts; Step S15: performing an intersection operation of potential abnormal players according to the short-time game player data and the high-kill game player data, thereby obtaining the potential abnormal player data; Step S16: Identify abnormal players based on the game player data packet tampering data to obtain abnormal player data.

3. The method for processing game data according to claim 2, characterized in that: Step S12 is specifically as follows: Step S121: Calculate the client hash value according to the game player data to obtain the client hash value; Step S122: Calculate the server hash value according to the game player data to obtain the server hash value; Step S123: Perform a preliminary judgment on data packet tampering based on the client hash value and the server hash value, thereby obtaining preliminary judgment data on data packet tampering; Step S124: extracting data packet features from the game player data to obtain game player data packet data; Step S125: performing distribution time statistics according to the data packet data of the game player, thereby obtaining the distribution time data of the data packet of the game player; Step S126: performing a sequence check on the game player data packet release time data, thereby obtaining a disordered data packet; Step S127: confirming the tampering of the data packet preliminary judgment data according to the disordered data packet, so as to obtain the game player's data packet tampering data.

4. The method for processing game data according to claim 1, characterized in that: Step S2 is specifically as follows: Step S21: extracting server resource features and server communication features according to the game data, thereby obtaining server resource data and server communication data; Step S22: performing memory leak anomaly analysis on the server resource data, thereby obtaining memory leak anomaly data; Step S23: performing communication mode abnormality analysis on the server communication data, thereby obtaining communication mode abnormality 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, characterized in that: 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 according to 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 the memory leakage scale data; Step S226: Generate a memory snapshot according to 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, characterized in that: 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 according to the communication flow data, thereby obtaining 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 according to 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 according to the flood attack data, thereby obtaining the flood attack source data; Step S237: Obtain 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, characterized in that: 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 respectively according to the high data packet loss rate and the high data packet retransmission rate, so as to obtain high data packet loss rate duration data and high data packet retransmission rate duration data; A flood attack is determined based on the high data packet loss rate duration data and the high data packet retransmission rate duration data, thereby obtaining flood attack data.

8. The method for processing game data according to claim 1, characterized in that: Step S3 is specifically as follows: Step S31: Calculate the Pearson correlation coefficient based on the load management abnormal data and the abnormal player data to obtain the Pearson correlation coefficient; Step S32: performing correlation statistics according to the Pearson correlation coefficient, thereby obtaining a positive correlation Pearson correlation coefficient; Step S33: performing abnormal time statistics according to the load management abnormal 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, thereby obtaining the overlap time data; Step S35: Abnormal player load management integration is performed according to the overlapping time data and the positive correlation Pearson correlation coefficient, so as to obtain abnormal player load management data.

9. 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 8 is implemented.

10. 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; A correlation analysis module, used for performing correlation analysis based on the load management abnormality data and the abnormal player data, so as to obtain the abnormal player load management data; A high load analysis module, used for extracting CPU load features according to game data, thereby obtaining CPU load data, and performing high load analysis according to the CPU load data, thereby obtaining CPU high load data; The game load balancing optimization analysis module is used to perform game load balancing optimization analysis based on CPU high load data and abnormal player load management data, so as to obtain game load balancing data.

Images