Early warning method of network data, storage medium and equipment

Abstract

The invention discloses a network data early warning method, a storage medium and equipment, and is applied to the technical field of data processing. The method comprises the following steps: acquiring a data uploading request sent by a terminal device, and if an authentication result obtained according to uploading authentication information of the terminal device shows that the terminal device has an uploading permission, configuring a cache duration for to-be-uploaded data according to target user information; acquiring attribute information of the data to be uploaded and security level information of the data to be uploaded; processing the uploading purpose information to generate a data uploading processing factor; processing the attribute information of the to-be-uploaded data and the security level information of the to-be-uploaded data based on the data uploading processing factor, and generating a cache priority of the to-be-uploaded data; processing the cache priority of the to-be-uploaded data and the cache duration of the to-be-uploaded data based on a preset cache strategy to generate cache early warning information; and processing the to-be-uploaded data in the data uploading request based on the cache early warning information to generate data early warning information.

Description

Technical Field

[0001] This application relates to the field of data processing technology, specifically to a method, storage medium, and device for early warning of network data. Background Technology

[0002] In actual network data transmission, the number and types of terminal devices are vast and diverse, and data uploading lacks effective standards. Numerous terminal devices upload data arbitrarily, making it difficult for servers to quickly and accurately determine the legitimacy of the data source and the compliance of the upload request. For example, some unauthorized terminals may maliciously upload large amounts of invalid data, consuming server resources, interfering with normal data processing flows, and causing server inefficiency in processing data upload requests, or even data loss or incorrect processing.

[0003] Furthermore, existing technologies often employ a single, universal caching strategy when caching uploaded data, failing to fully consider the personalized needs of different users and the characteristics of the data itself. For users with varying data upload intervals and sizes, a uniform cache duration setting either leads to wasted cache space or fails to meet data processing requirements. For example, for users who upload data frequently but in small amounts, long-term caching will consume excessive cache space; while for users with long upload intervals and large data volumes, short cache durations may result in data being cleared before processing, affecting subsequent data analysis and use.

[0004] In the data processing workflow, there is insufficient understanding of the security level and importance of data, and the processing methods are simplistic. All data, regardless of its sensitivity or importance to the business, is encrypted, stored, and processed using similar methods. This results in high-security data potentially not receiving adequate protection, posing a risk of data leakage and threatening user privacy and business security; while low-importance data consumes excessive resources for processing and storage, leading to resource waste and reduced overall data processing efficiency.

[0005] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this disclosure, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0006] The purpose of this application is to provide a network data early warning method, storage medium, and device, which at least to some extent overcomes the problems existing in the prior art. It obtains data upload requests from terminal devices, which contain various key information. Next, it verifies the upload authentication information. If the device has the necessary permissions, it configures the cache duration based on the target user information and obtains the data's attributes and security level information. Then, it processes the upload purpose information to generate a data upload processing factor, and calculates the cache priority by combining the data attributes and security level information, quantifying it through a specific formula. Afterwards, based on a preset caching strategy, it generates relevant information according to the cache priority, adjusts the cache duration to obtain a cache adjustment factor, and then generates cache early warning information. Finally, it determines the data storage location and cache node information based on the cache early warning information, integrates them to generate data early warning information to characterize data cache security. The process also considers the load balancing of the target server cluster and cache task information to rationally allocate tasks, improve data processing efficiency, and achieve refined management of network data caching.

[0007] According to one aspect of the embodiments of this application, a network data early warning method is provided. The method includes: acquiring a data upload request sent by a terminal device, wherein the data upload request includes data to be uploaded, upload authentication information of the terminal device, upload purpose information, and target user information, wherein the target user information includes data upload interval information and data upload size information of the target user; if the authentication result obtained according to the upload authentication information of the terminal device indicates that the terminal device has upload permission, then configuring a cache duration for the data to be uploaded according to the target user information; acquiring attribute information and security level information of the data to be uploaded; processing the upload purpose information to generate a data upload processing factor; processing the attribute information and security level information of the data to be uploaded based on the data upload processing factor to generate a cache priority for the data to be uploaded; processing the cache priority and cache duration of the data to be uploaded based on a preset cache strategy to generate cache early warning information; and processing the data to be uploaded in the data upload request based on the cache early warning information to generate data early warning information.

[0008] According to another aspect of the embodiments of this application, a network data early warning device is provided, applied to a server. The device includes: an acquisition module, configured to acquire a data upload request sent by a terminal device, wherein the data upload request includes data to be uploaded, upload authentication information of the terminal device, upload purpose information, and target user information, wherein the target user information includes data upload interval information and data upload size information of the target user; acquire attribute information and security level information of the data to be uploaded; and a processing module, configured to configure a cache duration for the data to be uploaded based on the target user information if the authentication result obtained based on the upload authentication information of the terminal device indicates that the terminal device has upload permission; process the upload purpose information to generate a data upload processing factor; process the attribute information and security level information of the data to be uploaded based on the data upload processing factor to generate a cache priority for the data to be uploaded; process the cache priority and cache duration of the data to be uploaded based on a preset cache strategy to generate cache early warning information; and process the data to be uploaded in the data upload request based on the cache early warning information to generate data early warning information.

[0009] According to another aspect of the embodiments of this application, an electronic device is provided, including a computer-readable storage medium storing a computer program and a processor, wherein the computer program is read and executed by the processor to implement the method described in any of the above-described embodiments.

[0010] According to another aspect of the embodiments of this application, a computer-readable storage medium is provided, the computer-readable storage medium storing a computer program, which, when read and executed by a processor, implements the method described in any of the above claims.

[0011] This application begins with the server receiving a data upload request from a terminal device. The request includes the data to be uploaded, upload authentication information, upload purpose information, and target user information (covering data upload interval and size information). The server first verifies the upload authentication information. If the terminal device has the necessary permissions, it configures the cache duration for the data to be uploaded based on the target user information, and simultaneously obtains the data's attribute information and security level information.

[0012] Next, the server processes the upload purpose information, sequentially generating classification information and data application scenario information for the data to be uploaded, thus deriving a data upload processing factor. This factor characterizes the data processing weight of different business data. Subsequently, combining the data upload processing factor, data attribute information (such as the comprehensive value of data timeliness, completeness, and relevance indicators), and security level information (level stratification and corresponding scores), the cache priority of the data to be uploaded is calculated, achieving precise quantification through a formula.

[0013] Next, based on the preset caching strategy, the server generates level range information and attribute tags according to cache priority. Then, based on the attribute tags, it adjusts the cache duration to obtain a cache adjustment factor. These factors are then combined to generate cache warning information. Finally, based on the cache warning information, the server determines the target storage location information and preset cache target node information for the data. After integration and processing, data warning information is generated to characterize the cached security of the data. This process also considers the real-time load balancing information and cache task information of the target server cluster, rationally allocating tasks to ensure server load balancing and improve data processing efficiency.

[0014] Other features and advantages of this application will be set forth in the following description and will be apparent in part from the description, or some features and advantages may be inferred from the description or determined without doubt, or may be learned by practicing embodiments of this application. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This invention provides a flowchart illustrating a network data early warning method according to an embodiment of this application. Figure 2 A schematic diagram of the structure of a network data early warning device provided in an embodiment of this application is shown. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort are within the scope of protection of this application.

[0018] It will be understood by those skilled in the art that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have a meaning consistent with their meaning in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless specifically defined as herein.

[0019] like Figure 1 As shown, one embodiment of this application provides a network data early warning method applied to a server. In some implementations, the method includes: S101. Obtain the data upload request sent by the terminal device.

[0020] In one implementation, the server is constantly listening, ready to capture data upload requests from terminal devices. Taking smart health monitoring as an example, numerous smart bracelets, smart body fat scales, and other terminal devices continuously collect users' health data. When these terminal devices meet preset upload conditions (such as a stable network connection and sufficient battery power), they initiate data upload requests to the server. The server, through a dedicated network interface and data receiving program, can accurately acquire these requests, ensuring the timeliness and integrity of data transmission. The types and content of the data to be uploaded are diverse, depending entirely on the functions and application scenarios of the terminal devices. In the field of smart health monitoring, terminal devices may collect users' physiological data, such as heart rate, blood pressure, blood sugar, sleep monitoring data (including sleep duration, sleep stage, etc.), and exercise data (steps, distance traveled, calories burned, etc.). In industrial IoT scenarios, the data uploaded by sensor devices may involve equipment operating parameters (temperature, pressure, speed, etc.) and fault alarm information. This data is the core object of subsequent analysis, decision-making, and business processing.

[0021] Uploading authentication information is crucial for ensuring the security and legitimacy of data uploads. Common authentication information includes device identifiers (such as device serial numbers and MAC addresses), user authentication information (username, password, encryption token, etc.), and digital certificates. Upon receiving an upload request, the server compares the authentication information with pre-stored legitimate device and user information in its database. For example, by verifying whether the device serial number is in the authorized list and whether the encryption token is bound to and verified with the user account, the server determines whether the terminal device is authorized to upload data. Only data uploaded by successfully authenticated devices will be further processed by the server, effectively preventing unauthorized device intrusion and data leakage risks.

[0022] The purpose information uploaded clarifies the application direction and business objectives of the data, providing crucial guidance for the server's subsequent data processing strategies. For example, in uploading healthcare data, the purpose might specify disease diagnosis assistance, health management plan development, or medical research. Based on these purposes, the server can rationally arrange the data processing flow and resource allocation. Data used for disease diagnosis assistance may be processed first and employ more precise analysis algorithms; while data used for medical research may be stored long-term and categorized, ensuring data privacy, for subsequent in-depth analysis.

[0023] Data upload interval information reflects the timing patterns of user data uploads, helping the server optimize resource allocation and data management strategies. Different users may have different data upload intervals based on their needs and device settings. For example, in a smart health monitoring scenario, some users may be set to upload data in real time to obtain timely health feedback; while others may choose to upload data daily, weekly, or monthly. Based on this upload interval information, the server can rationally plan data receiving tasks, avoiding excessive server load due to concentrated data uploads. Simultaneously, for users with longer upload intervals, the server can appropriately adjust caching strategies to ensure that data is not lost or expired before the next upload.

[0024] Data upload size information allows the server to know the scale of each data upload in advance, enabling targeted resource preparation. In smart health monitoring scenarios, smart bracelets upload relatively small amounts of data, perhaps only tens of KB, while smart medical devices (such as portable ECG monitors) can upload much larger amounts of ECG data, reaching hundreds of KB or even several MB. Based on this data size information, the server can pre-allocate sufficient storage resources and optimize data transmission protocols and caching strategies. For large data upload requests, techniques such as chunked transmission and asynchronous processing may be used to improve the efficiency of data upload and processing, ensuring the stability and integrity of data transmission.

[0025] Taking user Xiao Li as an example, before using a smart bracelet, based on his needs and data plan, he set the data upload interval on the corresponding app to once a day. This means all collected data would be uploaded at the end of the day. Therefore, the target user (Xiao Li)'s data upload interval information in this data upload request is "once a day." This allows the server to know when it can expect to receive data from Xiao Li's device and allocate resources accordingly for receiving and processing. Due to the types of health data collected and the frequency of recording by the smart bracelet, each uploaded data is approximately 50KB (including the size of the aforementioned heart rate, blood pressure, steps, etc., after processing and simple compression). This "50KB" is the data upload size information for the target user (Xiao Li). The server can use this information to prepare storage capacity and other aspects in advance to ensure successful reception and storage of this data.

[0026] S102. If the authentication result obtained from the upload authentication information of the terminal device indicates that the terminal device has upload permission, then configure the cache duration for the data to be uploaded based on the target user information.

[0027] In one implementation, after receiving a data upload request from a terminal device, the server's primary task is to verify the device's upload authentication information. This authentication information includes key components such as device identifiers (e.g., device serial number, MAC address), user authentication information (username, password, encrypted token, etc.), and digital certificates. The server performs a detailed comparison of this authentication information with pre-stored legitimate device and user information in its database. For example, in a smart health monitoring scenario, if a user uploads data using a smart bracelet, the server checks if the bracelet's serial number is in the authorized list. Simultaneously, it decrypts and compares the encrypted token to confirm its binding relationship with the user's account and verify the authentication. Only when all authentication information is verified correctly can the server determine that the terminal device has upload permissions and proceed to the next data processing step. If authentication fails, the server rejects the upload request, ensuring system data security and preventing unauthorized device intrusion and data leakage.

[0028] The data upload interval information for target users reflects the time pattern of user data uploads and is one of the important bases for configuring cache duration. Different users will have different data upload intervals based on their own needs and device settings. In intelligent health monitoring scenarios, some users may set their data uploads to real-time to obtain timely health feedback; while others may choose to upload data once a day, once a week, or once a month. Taking a user who sets their data uploads to once a day as an example, the server expects to receive new data from that user's device every day. Based on this, when configuring cache duration, it is necessary to consider possible abnormal situations such as network problems and device failures. If a short cache duration is set, the data for that day may be lost in the event of an anomaly, affecting the continuity and integrity of the data; if the cache duration is too long, it will occupy too much cache space, resulting in resource waste. Therefore, for this type of user, the server may be configured with a cache duration of 48 hours (two days). This ensures that new data replaces old data in a timely manner under normal circumstances, and that in the event of an anomaly, the server retains the cached data from the previous day, waiting for subsequent attempts to upload or manual intervention, effectively balancing the relationship between data preservation and resource utilization.

[0029] The size of data uploaded by the target user also significantly impacts the cache duration configuration. Different terminal devices upload vastly different amounts of data. For example, in smart health monitoring scenarios, smart bracelets upload relatively small amounts of data, perhaps only tens of KB, while smart medical devices (such as portable ECG monitors) can upload large amounts of ECG data, reaching hundreds of KB or even several MB. For users with small and frequent data uploads, such as smart bracelet users, the cache duration can be appropriately shortened to improve cache space utilization due to faster data updates and smaller storage requirements. However, for users with large data uploads and longer upload intervals, such as users of portable ECG monitors, a longer cache duration is necessary to ensure data is not lost before the next upload. Simultaneously, the server needs to allocate sufficient storage resources in advance to store this data. For instance, assuming a user's device uploads approximately 100KB of data per upload, once a week, the server, considering the large data volume and low upload frequency, might configure a cache duration of 7 days (about a week and a half) to ensure data retention for a longer period, meeting user needs while making reasonable resource utilization.

[0030] In actual configuration of cache duration, the server does not rely solely on data upload intervals or sizes, but considers multiple factors comprehensively. Besides the two key factors mentioned above, the importance of the data, business needs, and the server's storage resources are also taken into account. For highly important data, such as data involving key user health indicators, even with short upload intervals and small data volumes, the server may appropriately extend the cache duration to ensure data security and integrity. For data with urgent business needs, such as data used for real-time diagnostics, the cache duration configuration will prioritize timeliness to prevent data staleness. Simultaneously, the server will dynamically adjust the cache duration based on its actual storage resources, optimizing resource allocation while ensuring data processing requirements are met.

[0031] Let's assume another user, Zhang, uses the same smart bracelet, but he sets his data upload interval to once a week, with each upload being approximately 100KB. Considering Zhang's low upload frequency, relatively large data volume, and potential network instability, the server might configure a cache duration of 7 days (about a week and a half) to ensure the data is retained for a longer period until the next normal upload or further processing, thus accommodating Zhang's usage habits and data upload characteristics. These examples of different users demonstrate how, after confirming the terminal device has upload permissions, the cache duration can be reasonably configured based on the target user information.

[0032] S103. Obtain the attribute information and security level information of the data to be uploaded.

[0033] In one implementation, the data to be uploaded has a rich variety of attributes, with different types of data possessing different attributes. Taking a smart health monitoring scenario as an example, the smart bracelet used by user Xiao Wang collects various health data. Heart rate data is numerical, measured in beats per minute. The normal heart rate range for a healthy adult is generally 60-100 beats per minute, so Xiao Wang's daily heart rate data might present a sequence like [70, 75, 80, 72, ...]. Sleep data is a data type combining classification and duration. It records different stages of Xiao Wang's nighttime sleep, such as light sleep, deep sleep, and REM sleep, as well as the corresponding duration of each stage, for example, "light sleep: 3 hours, deep sleep: 2 hours, REM sleep: 1 hour." Step count data is also numerical, measured in steps. If Xiao Wang walks 8000 steps a day, this is the value of the step count data. The differences in these data attributes determine their different needs and importance in subsequent processing.

[0034] The data to be uploaded all originates from specific terminal devices, such as Xiao Wang's smart bracelet. Data is collected through various sensors built into the bracelet: a heart rate sensor collects heart rate data, an accelerometer, along with related algorithms, counts steps, and a sleep monitoring module analyzes sleep stages and duration, thus clearly identifying the data source. Furthermore, each data point is accompanied by a corresponding time record. For example, heart rate data is recorded every 5 minutes, with each record including a specific time, such as "December 2, 2024, 10:00:00, Heart Rate: 75 beats / minute." This time signature not only facilitates subsequent chronological data organization but also helps analyze data trends, which is crucial for the effective use and analysis of the data.

[0035] Based on the degree of impact on user privacy and rights, the data to be uploaded is divided into different security levels. Taking Xiao Wang's smart bracelet data as an example, step count data belongs to a relatively low security level. Because step count data only reflects daily activity levels, even if leaked, the impact on Xiao Wang's personal privacy and other important rights is minimal. On the server side, this type of data usually uses conventional encryption methods, such as simple symmetric encryption algorithms, using a fixed key to encrypt the data during transmission and storage. Regarding access permissions, ordinary employees within the company who have received basic training and have access to view basic data can view it as long as it is used for reasonable purposes, such as analyzing the user's overall activity level and formulating general exercise suggestions.

[0036] Heart rate data is considered to have a slightly higher security level than step count data, and can be categorized as medium security. Since heart rate data directly reflects an individual's health condition, improper acquisition or leakage could lead to misleading health interpretations or privacy violations by malicious actors. Therefore, the server employs more complex encryption methods for this type of data, such as asymmetric encryption algorithms, using a public key for encryption before transmission, which can only be decrypted with the corresponding private key. Regarding access permissions, only qualified professionals with specialized health data analysis training can access and view this data when there is a clear analytical task, such as assessing whether Xiao Wang's recent heart health has undergone any abnormal changes.

[0037] Assuming the smart bracelet can collect detailed electrocardiogram (ECG) waveform data (we assume the bracelet has this function), this type of data is considered high-security. ECG waveform data accurately reflects the electrophysiological activity of the heart; its leakage would not only severely infringe on personal privacy but could also be maliciously altered for misleading medical diagnoses, leading to serious consequences. The server employs multiple encryption protection mechanisms: first, advanced symmetric encryption algorithms are used to encrypt the original data; then, digital signature technology ensures the integrity and non-repudiation of the data; and strict monitoring is maintained throughout transmission and storage. Regarding access permissions, only professionals with explicit authorization from Xiao Wang (such as written authorization or electronic authorization after strict identity verification on the app), possessing professional medical qualifications (such as a cardiologist), and acting for legitimate medical diagnosis or research collaboration purposes, can view and use this data.

[0038] S104. Process the upload purpose information to generate a data upload processing factor.

[0039] In one implementation, after receiving the purpose information uploaded by the terminal device, the server performs in-depth analysis and processing to extract the specific data types involved, thereby generating classification information for the data to be uploaded. Taking user Xiao Zhao uploading data using a smart bracelet as an example, his upload purpose information indicates that he wants to upload heart rate, blood pressure, and step count data for generating a personal daily health report, providing health advice, and assisting medical professionals. Based on this information, the server classifies the data to be uploaded into cardiovascular health data (including heart rate and blood pressure data) and activity activity data (mainly step count data). Heart rate data reflects the frequency of heartbeats, such as a sequence of heart rate values ​​recorded by Xiao Zhao at different times of the day; blood pressure data reflects the intravascular pressure, presented as systolic / diastolic pressure pairs, such as combinations like "110 / 70"; step count data represents the number of steps Xiao Zhao took in a day, such as 10,000 steps taken that day. Through this classification, the server can more clearly understand the nature and characteristics of the data, providing a foundation for subsequent processing.

[0040] After obtaining the classification information, the server further analyzes the situation of each data category within the overall usage scenario, thereby generating corresponding data application scenario information. In generating personal daily health reports, this is crucial foundational data, requiring detailed statistical analysis, such as calculating the average heart rate and blood pressure fluctuation range, to assess Xiao Zhao's daily cardiovascular health status. When providing health advice to users, the system uses heart rate and blood pressure values ​​and trends to determine if they are within a healthy range. If abnormalities are found, corresponding suggestions are given regarding lifestyle adjustments, dietary structure, or seeking medical attention. When assisting medical professionals, this data can serve as a reference for doctors diagnosing cardiovascular-related diseases; the accuracy and completeness of the data must be ensured so that professionals can accurately analyze the condition. The personal daily health report primarily presents Xiao Zhao's daily exercise volume, combining it with other health data to comprehensively assess overall health levels. For example, the correlation between exercise volume and changes in heart rate and blood pressure can be analyzed. In providing health advice, based on step count, reasonable suggestions are given to increase or decrease Xiao Zhao's exercise intensity, encouraging him to maintain moderate exercise to maintain health. When used by medical professionals, activity level data can help understand Xiao Zhao's daily activity habits and aid in determining the relationship between certain diseases and exercise. By analyzing different categories of data across various application scenarios, the server can gain a more comprehensive understanding of the data's value and impact.

[0041] Based on a pre-defined data processing mapping table, the server processes the data application scenario information of the data to be uploaded, thereby generating a data upload processing factor. This factor is used to characterize the data processing weight information of different business data. Assume the company has a pre-defined data processing mapping table that specifies the weight of various data types under different data processing scenarios; a higher weight indicates that the data is more important in the corresponding business processing. For cardiovascular health data, the weight is assigned 0.6 in the scenario of generating a personal daily health report. This means that cardiovascular health data is relatively more important when generating this report, accounting for a larger proportion in the overall data consideration and having a higher impact on the final report's conclusions. In the scenario of providing health advice, the weight is assigned 0.5, indicating that it is also a relatively key reference in the business process of providing health advice, but its importance is slightly lower than in the report generation stage. In the scenario of assisting medical professionals, the weight is assigned 0.8, because for medical professionals, this type of data plays an extremely important role in accurately judging conditions, hence the higher weight. For activity activity data, a weight of 0.2 is assigned in the scenario of generating a personal daily health report, indicating that it is auxiliary reference data in the overall report generation and less important than cardiovascular health data. In the scenario of providing health advice, a weight of 0.3 is assigned, meaning it is a relatively important part when giving health advice related to exercise, but its overall importance is still lower than that of cardiovascular health data in the corresponding scenario. In the scenario of assisting medical professionals, a weight of 0.1 is assigned, indicating that for medical professionals, activity activity data plays a smaller role in assisting diagnosis compared to cardiovascular health data. Combining these weight assignments across different scenarios generates a data upload processing factor for the data uploaded by Xiao Zhao. This factor clearly reflects the data processing weight information for different business data in different data processing scenarios. The server can subsequently use this data upload processing factor to rationally allocate resources and prioritize data processing, better realizing various business functions based on uploaded data.

[0042] S105. Based on the data upload processing factor, process the attribute information and security level information of the data to be uploaded to generate the cache priority of the data to be uploaded.

[0043] In one implementation, the attribute information of the data to be uploaded is rich and diverse, with different types of data possessing different attributes. Taking the data collected by Xiao Sun's smart bracelet in a smart health monitoring scenario as an example, it includes heart rate data (numerical, ranging from approximately 60-100 beats / minute, recorded every 5 minutes), sleep data (a combination of classification and duration, recording stages such as light sleep, deep sleep, and REM sleep, and their corresponding durations), and step count data (numerical, measured in "steps"). This attribute information forms the basis for subsequent processing. Starting from this attribute information, target attribute indicator information is generated, specifically covering the following key indicators: Data timeliness index: set according to the real-time requirements of the data. Heart rate data and step count data are recorded frequently and can reflect the current physical state and activity status in a timely manner, so the timeliness index is set to "high"; while sleep data reflects the state over a period of time at night, and the timeliness is slightly weaker, so it is set to "medium".

[0044] Data completeness index: Considering the impact of data completeness on the analysis results. Heart rate data should be as complete as possible; missing even one data point may affect the accurate analysis of heart health, so the completeness index is set to "high". Although sleep data is divided into stages, as long as the main stages are recorded, sleep quality can be roughly analyzed, so the completeness index is set to "medium". Occasionally missing a step count has little impact on the overall exercise situation, so the completeness index is set to "low".

[0045] Data Relevance Indicators: These measure the degree of correlation between data and overall health or business operations. Heart rate data has a strong correlation with overall cardiovascular health, so it is set to "High"; sleep data is closely related to overall physical recovery and mental state, so it is set to "Medium"; step count data is mainly related to physical activity, so its correlation is set to "Medium".

[0046] Processing target attribute indicator information to generate a weighted composite attribute value: To comprehensively consider the impact of different attribute indicators on the data, the target attribute indicator information needs to be quantified. Assume the company has set weights for each indicator: data timeliness has a weight of 0.4, data integrity has a weight of 0.3, and data relevance has a weight of 0.3. By assigning corresponding scores to each indicator (you can set the corresponding scores for different levels; here, high corresponds to 3, medium to 2, and low to 1), and then calculating according to the weights, the weighted composite attribute value is obtained.

[0047] Heart rate data: Timeliness indicator is "high", assigned a value of 3; Completeness indicator is "high", assigned a value of 3; Correlation indicator is "high", assigned a value of 3. Weighted calculated attribute composite value = 0.4×3 + 0.3×3 + 0.3×3 = 3.

[0048] Sleep data: Timeliness index is "Medium", assigned a value of 2; Completeness index is "Medium", assigned a value of 2; Relevance index is "Medium", assigned a value of 2. Weighted calculated attribute composite value = 0.4×2 + 0.3×2 + 0.3×2 = 2.

[0049] Step count data: Timeliness index is "High", assigned a value of 3; Completeness index is "Low", assigned a value of 1; Relevance index is "Medium", assigned a value of 2. Weighted calculated attribute composite value = 0.4×3 + 0.3×1 + 0.3×2 = 2.1.

[0050] Based on the impact of data on user privacy and business operations, security level information is processed to generate level stratification information and corresponding scores. Let's take the intelligent health monitoring scenario as an example: Heart rate data: Due to its involvement in cardiovascular health, disclosure may affect personal privacy and health interpretation. The security level is relatively high, belonging to the "medium security level", with a corresponding score of 3 (you can set your own scoring system; here, high level corresponds to 5, medium level corresponds to 3, and low level corresponds to 1).

[0051] Sleep data and step count data: Sleep data mainly relates to rest, while step count data only reflects activity level. Their privacy impact is relatively small, and their security level is low, both belonging to the "low security level", with a corresponding score set to 1.

[0052] Cache priority is calculated by combining data upload processing factors: Reviewing the data upload processing factors (using the same weighting assumptions from previous similar scenarios), in the scenario of generating a personal daily health report, cardiovascular health data (mainly heart rate data) has a weight of 0.6, and exercise and rest-related data (sleep and step count data) has a weight of 0.4 (totaling 1). Based on this, the weighted attribute comprehensive value, level stratification information, and corresponding score information are combined using the formula... (Where, P represents the cache priority of the data to be uploaded, F represents the data upload processing factor, A represents the weighted calculated attribute comprehensive value, and n represents the number of security level layers.) Represents the i-th security level layer. Calculate cache priority using the score corresponding to the i-th security level layer.

[0053] Heart rate data: The weighted average value is 3, the grade stratification information score is 3, and the data upload processing factor weight is 0.6. Cache priority calculation = 0.6 × (3 + 3) = 3.6.

[0054] Sleep data: The weighted composite value is 2, the corresponding score for the level stratification information is 1, and the weight of the data upload processing factor is 0.4. Cache priority calculation = 0.4 × (2 + 1) = 1.2.

[0055] Step count data: The weighted average value is 2.1, the corresponding score for the level stratification information is 1, and the weight of the data upload processing factor is 0.4. Cache priority calculation = 0.4 × (2.1 + 1) = 1.24.

[0056] By comparing these cache priority values, it can be seen that heart rate data has the highest cache priority (3.6), followed by step count data (1.24), and lastly sleep data (1.2). This indicates that when processing the data uploaded by Xiao Sun, the server will prioritize caching heart rate data to ensure that it can be stored and processed more promptly and properly, before processing step count data and sleep data.

[0057] S106. Based on the preset caching strategy, process the caching priority and caching duration of the data to be uploaded, and generate caching warning information.

[0058] In one implementation, taking user Xiao Li's data as an example, assume the calculated cache priority for heart rate data is 3.6, sleep data is 1.2, and step count data is 1.24. The company will set rules for dividing cache priority into three ranges: high priority (cache priority greater than 3), corresponding to heart rate data, meaning this data is relatively important in the overall data to be uploaded and requires key attention and priority processing; medium priority (cache priority between 1 and 3), sleep data and step count data both belong to this range, indicating that they are relatively less important, but still require reasonable caching arrangements; low priority (cache priority less than 1, this type of data does not appear in this example), this type of data is even less important in caching processing and may be subject to a more lenient caching strategy. Through this division, the server can clearly classify the priority of different data.

[0059] Based on the characteristics of the data and its role in the business, attribute labels are assigned to different data types. Heart rate data, reflecting cardiovascular health and playing a crucial role in analyzing user health, has a high caching priority; therefore, the attribute label is set as "Key Health Indicator Data." Sleep data helps understand the user's overall health status, but its importance is slightly less than heart rate data; therefore, the attribute label is set as "Daily Health Auxiliary Data." Step count data mainly reflects the user's exercise activity and plays a certain auxiliary role in the health monitoring system; therefore, the attribute label is set as "Exercise Activity Data." These attribute labels help the server more intuitively identify data characteristics, facilitating subsequent processing.

[0060] Another implementation method (based on a preset cache mapping table): In addition to the above methods, this can also be achieved by obtaining a preset cache mapping table. The preset cache mapping table aggregates a large amount of user experience regarding data caching priorities, comprehensively considering user habits, data importance, and actual business needs. It clearly defines the cache priority range and characteristic descriptions corresponding to different health data types. For example, key cardiovascular health data (like heart rate and blood pressure) has a cache priority in the range of 0.8-1.0; sleep-related data has a priority range of 0.4-0.6; and activity activity data (typically steps) has a priority range of 0.2-0.4. Based on this table, when Zhang uploads health data, the calculated cache priority for heart rate data is 0.9, which falls within the priority range corresponding to "critical cardiovascular health data." Therefore, strict caching rules can be generated for heart rate data, such as ensuring data integrity is above 99%, a cache duration of at least 48 hours, and the use of advanced encryption methods. Zhang's sleep data has a cache priority of 0.5, matching the priority range of "sleep-related data," with corresponding rules including ensuring data integrity is around 90% and setting the cache duration to 72 hours. With this initial data caching information generated based on the preset cache mapping table, the server further refines the cache priority level ranges and clarifies attribute labels, laying the foundation for subsequent processing.

[0061] Based on the initial caching durations set for Xiao Li's various data sets (e.g., 48 hours for heart rate data, 72 hours for sleep data, and 96 hours for step count data), the caching durations were adjusted according to attribute tags. For "key health indicator data" (heart rate data), due to its high importance, the adjustment rule corresponding to the attribute tag was to appropriately extend the caching duration by 20% from the original 48 hours, with a caching adjustment factor calculated as 1 + 20% = 1.2. This means its caching duration should be adjusted accordingly based on this factor. "Daily health auxiliary data" (sleep data) has relatively stable importance and timeliness requirements; according to the adjustment rule corresponding to its attribute tag, its caching duration remains unchanged, i.e., the caching adjustment factor is 1. "Activity activity data" (step count data) is relatively less critical, and the data volume may be large; therefore, the adjustment rule is to appropriately shorten the caching duration by 10% from the original 96 hours, with a caching adjustment factor calculated as 1 - 10% = 0.9. Subsequent adjustments to the caching duration will be based on this factor.

[0062] High-priority data (taking heart rate data as an example): Heart rate data falls within the high-priority range and has a cache adjustment factor of 1.2. Combined with an initial cache duration of 48 hours, the adjusted cache duration is 48 × 1.2 = 57.6 hours (approximately two and a half days). The caching strategy employs highly reliable storage methods, such as redundant storage technology to ensure data is not lost due to hardware failures, a high level of encryption (e.g., asymmetric encryption combined with digital signatures) to guarantee data security, prioritizing the retention of this data when cache space is limited, and checking the integrity of cached data at regular intervals (e.g., every 6 hours). This caching strategy effectively ensures the security and reliability of high-priority heart rate data.

[0063] Medium-priority data (taking sleep data and step count data as examples): Sleep data falls within the medium-priority range, with a cache adjustment factor of 1 and a cache duration of 72 hours (three days). The caching strategy uses conventional storage media, employs standard symmetric encryption, checks the integrity of cached data daily, and cleans up cached data according to a first-in, first-out (FIFO) principle when the cache space is nearing its limit (i.e., clearing older sleep data first). Step count data also falls within the medium-priority range, but with a cache adjustment factor of 0.9, the cache duration is adjusted to 96 × 0.9 = 86.4 hours (approximately three and a half days). Data compression techniques can be used to reduce storage space, and a relatively basic encryption method is used. The integrity of cached data is checked every 12 hours. When cache space is limited, step count data can be cleared first based on its creation time to free up space for caching more important data. These caching strategies for medium-priority data meet data storage requirements while making efficient use of resources.

[0064] S107. Based on the cache warning information, process the data to be uploaded in the data upload request and generate data warning information.

[0065] In one implementation, the server determines the target storage location information and preset cache target node information for various types of data to be uploaded, based on the caching priority and caching strategy of different data.

[0066] High-priority data (taking heart rate data as an example): Heart rate data is considered high-priority data, and its caching strategy requires a highly reliable storage method. This includes using redundant storage technology to ensure data is not lost due to hardware failures, employing a high level of encryption (such as asymmetric encryption combined with digital signatures) to guarantee data security, adjusting the cache duration to approximately 57.6 hours (two and a half days), prioritizing the retention of this data when cache space is limited, and checking the integrity of the cached data at regular intervals (e.g., every 6 hours). Based on this, the target storage location allocated to the server for heart rate data is likely a specific partition within a high-performance storage disk array in the company's data center. This partition possesses high-speed read / write capabilities, high reliability, and redundant backup functions. For example, the storage path could be "Data Center Storage Array / Health Monitoring Data / Cardiovascular Data / Heart Rate Data Partition," facilitating subsequent rapid and accurate reading and processing of this critical data. To meet high reliability requirements, the preset cache target node information points to multiple cache server nodes that serve as backups for each other, such as node numbers "Node1, Node2, Node3". These nodes are distributed in different data center areas and are connected through an internal high-speed network. When one node fails, data can be quickly retrieved from other backup nodes to ensure that the cache service is uninterrupted.

[0067] Medium-priority data (taking sleep data as an example): Sleep data is considered medium-priority data and is cached using conventional storage media. The encryption method employs the company's standard symmetric encryption. The integrity of the cached data is checked daily. When the cache space approaches its limit, cached data is cleared according to the first-in, first-out (FIFO) principle (i.e., older sleep data is cleared first). The cache duration remains unchanged at 72 hours (three days). The generated target storage location information may be a regular partition on a general storage disk in the data center, such as "Data Center Storage Array / Health Monitoring Data / Daily Auxiliary Data / Sleep Data Partition." This partition meets basic data storage requirements, and its read / write speed and reliability meet standard business requirements. The preset cache target node information may correspond to some nodes in a load-balanced cache server cluster, with node numbers assumed to be "Node4, Node5." These nodes will dynamically allocate cache tasks based on the current load to ensure that sleep data is cached in an orderly manner.

[0068] Low-priority data (taking step count data as an example): Step count data is considered low-priority data. During storage, data compression techniques can be used to reduce space usage. A relatively basic encryption method is used. The integrity of cached data is checked every 12 hours. When cache space is limited, step count data can be prioritized for caching based on its creation time to free up space for more important data. The cache duration is adjusted to approximately 86.4 hours (three and a half days). The target storage location is likely a large-capacity disk partition in the data center with relatively low storage costs and slightly slower read / write speeds, with a path like "Data Center Storage Array / Health Monitoring Data / Exercise Data / Step Count Data Partition," suitable for storing data with less stringent read / write speed requirements. The cache server nodes corresponding to the preset cache target node information are likely nodes with relatively abundant remaining resources and slightly weaker performance, such as "Node6, Node7," primarily responsible for managing the cache of step count data and systematically cleaning up data to free up space when resources are scarce.

[0069] The server integrates and processes the target storage location information and preset cache target node information for different types of data (heart rate, sleep, step count data) to ensure that each piece of data can be accurately stored in the corresponding location according to the established rules and cached and transferred normally on the corresponding cache nodes. The system records the actual storage location of each piece of data and its distribution on the cache nodes, forming a record similar to a storage log. For example, "Heart rate data has been successfully stored in 'Data Center Storage Array / Health Monitoring Data / Cardiovascular Data / Heart Rate Data Partition', and the cache is distributed on Node1, Node2, and Node3 nodes; sleep data is stored in 'Data Center Storage Array / Health Monitoring Data / Daily Auxiliary Data / Sleep Data Partition', and the cache is located on Node4 and Node5 nodes; step count data is stored in 'Data Center Storage Array / Health Monitoring Data / Exercise Data / Step Count Data Partition', and the cache is handled by Node6 and Node7 nodes." This facilitates subsequent operation and maintenance personnel to view and manage the data storage status.

[0070] Based on the established caching strategy and corresponding node configuration, in subsequent data access tests, if complete data can be successfully retrieved from the corresponding storage location and cache node as expected, and the data integrity remains good within the specified inspection time, then the data processing result meets the requirements. For example, when a health manager wants to view Xiao Wang's heart rate data to analyze his cardiovascular health, being able to quickly retrieve encrypted data from the specified storage location and cache node, and obtain a complete and accurate heart rate data sequence through decryption and other operations, indicates that this set of processing procedures for heart rate data has generated good data processing results. Similarly, for sleep data and step count data, if relevant business personnel can accurately retrieve the data as needed for generating health reports, providing health advice, and other operations, it also means that the data processing has achieved the expected goals.

[0071] Another implementation method (considering server cluster load): Obtain real-time load balancing information and cache task information within a preset period for the target server cluster. For example, the company obtains real-time load balancing information at a certain moment through a dedicated monitoring system. Server1's CPU utilization is 30%, memory utilization is 40%, and network bandwidth utilization is 20%, etc. Simultaneously, within a preset period (e.g., the past hour), the server cluster receives health data caching tasks from numerous users. The workload varies across different servers; Server1 received 100 data blocks to be uploaded and has completed 60, etc. Based on the cache task information within the preset period, the target server cluster is processed to generate preset cache progress information for several servers. The calculation method is to divide the number of completed cache tasks by the total number of received cache tasks, and then multiply by 100%. Based on the preset cache progress information of each server, combined with the caching priority and caching duration requirements of different data to be uploaded, target cache progress information is generated. For example, Server1 initially had a preset cache progress of 60%. After being assigned some step data caching tasks, considering that step data has low priority and long caching time, its impact on the overall progress is minimal. After comprehensive evaluation, the target cache progress information was adjusted to 62%. Finally, the target cache progress information is processed to generate target servers. Assuming a preset threshold of 70%, servers with target cache progress information lower than this value (such as Server1 and Server3, with target cache progress information of 62% and 64% respectively) will be selected as the servers to cache the data to be uploaded next. This avoids excessive server load and ensures that caching tasks are completed relatively evenly and efficiently. Subsequent new data to be uploaded will be preferentially assigned to these target servers for caching processing. They will cache the data in appropriate locations according to their respective cache warning information and requirements, and perform related management and maintenance.

[0072] The network data early warning method provided in this application starts by obtaining a data upload request from a terminal device. The request includes the data to be uploaded, upload authentication information, upload purpose information, and target user information (covering data upload interval and size information). The server first verifies the upload authentication information. If the terminal device has permission, it configures the cache duration for the data to be uploaded based on the target user information, and simultaneously obtains the data's attribute information and security level information.

[0073] Next, the server processes the upload purpose information, sequentially generating classification information and data application scenario information for the data to be uploaded, thus deriving a data upload processing factor. This factor characterizes the data processing weight of different business data. Subsequently, combining the data upload processing factor, data attribute information (such as the comprehensive value of data timeliness, completeness, and relevance indicators), and security level information (level stratification and corresponding scores), the cache priority of the data to be uploaded is calculated, achieving precise quantification through a formula.

[0074] Next, based on the preset caching strategy, the server generates level range information and attribute tags according to cache priority. Then, based on the attribute tags, it adjusts the cache duration to obtain a cache adjustment factor. These factors are then combined to generate cache warning information. Finally, based on the cache warning information, the server determines the target storage location information and preset cache target node information for the data. After integration and processing, data warning information is generated to characterize the cached security of the data. This process also considers the real-time load balancing information and cache task information of the target server cluster, rationally allocating tasks to ensure server load balancing and improve data processing efficiency.

[0075] refer to Figure 2 As shown, another embodiment of this application provides a network data early warning device applied to a server. In some embodiments, the device includes: The acquisition module 201 is used to acquire a data upload request sent by a terminal device, wherein the data upload request includes data to be uploaded, upload authentication information of the terminal device, upload purpose information, and target user information, wherein the target user information includes data upload interval information and data upload size information of the target user; and to acquire attribute information and security level information of the data to be uploaded. The processing module 202 is configured to: if the authentication result obtained from the upload authentication information of the terminal device indicates that the terminal device has upload permissions, configure a cache duration for the data to be uploaded based on the target user information; process the upload purpose information to generate a data upload processing factor; process the attribute information and security level information of the data to be uploaded based on the data upload processing factor to generate a cache priority for the data to be uploaded; process the cache priority and cache duration of the data to be uploaded based on a preset cache strategy to generate cache warning information; and process the data to be uploaded in the data upload request based on the cache warning information to generate data warning information.

[0076] The computer-readable storage medium provided in the above embodiments of this application and the network data early warning method provided in the embodiments of this application are based on the same inventive concept and have the same beneficial effects as the methods adopted, run or implemented by the applications stored therein.

[0077] This application provides a computer program product, including a computer program, which is executed by a third processor to implement the method described above.

[0078] The computer program products provided in the above embodiments of this application and the network data early warning method provided in the embodiments of this application are based on the same inventive concept and have the same beneficial effects as the methods adopted, run or implemented by the applications stored therein.

[0079] The various embodiments in this application are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of the network data early warning method, electronic device, electronic device, and readable storage medium are basically similar to the network data early warning method embodiments described above, so the description is relatively simple. Relevant parts can be referred to in the description of the network data early warning method embodiments described above.

Claims

1. A method for early warning of network data, characterized in that, The method includes: Obtain a data upload request sent by a terminal device, wherein the data upload request includes data to be uploaded, upload authentication information of the terminal device, upload purpose information, and target user information, wherein the target user information includes data upload interval information and data upload size information of the target user; If the authentication result obtained from the upload authentication information of the terminal device indicates that the terminal device has upload permission, then configure the cache duration for the data to be uploaded based on the target user information; Obtain the attribute information and security level information of the data to be uploaded; The upload purpose information is processed to generate a data upload processing factor; Based on the data upload processing factor, the attribute information and security level information of the data to be uploaded are processed to generate the cache priority of the data to be uploaded; Based on the preset caching strategy, the caching priority and caching duration of the data to be uploaded are processed to generate caching warning information; The data to be uploaded in the data upload request is processed based on the cache warning information to generate data warning information, wherein the data warning information is used to characterize the cache security of the data to be uploaded.

2. The method according to claim 1, characterized in that, The upload purpose information is processed to generate a data upload processing factor, including: The upload purpose information is processed to generate classification information for the data to be uploaded; The classification information of the data to be uploaded is processed to generate data application scenario information of the data to be uploaded; The data application scenario information of the data to be uploaded is processed to generate a data upload processing factor, wherein the data upload processing factor is used to characterize the data processing weight information of different business data.

3. The method according to claim 1, characterized in that, Based on the data upload processing factor, the attribute information and security level information of the data to be uploaded are processed to generate a cache priority for the data to be uploaded, including: The attribute information of the data to be uploaded is processed to generate target attribute index information of the data to be uploaded; The target attribute index information of the data to be uploaded is processed to generate a weighted comprehensive attribute value; The security level information of the data to be uploaded is processed to generate level stratification information and score information corresponding to the level stratification information; Based on the data upload processing factor, the weighted calculated attribute comprehensive value, the level stratification information, and the score information corresponding to the level stratification information are processed to generate the cache priority of the data to be uploaded; The method includes a calculation formula for obtaining the cache priority of the data to be uploaded, the calculation formula being: ； Where P represents the cache priority of the data to be uploaded, F represents the data upload processing factor, A represents the weighted calculated attribute comprehensive value, and n represents the number of security level layers. Represents the i-th security level layer. This represents the score corresponding to the i-th security level layer.

4. The method according to claim 1, characterized in that, Based on a preset caching strategy, the caching priority and caching duration of the data to be uploaded are processed to generate cache warning information, including: Process the cache priority of the data to be uploaded, and generate cache priority level range information and attribute tags of the data to be uploaded; Based on the attribute tags of the data to be uploaded, the caching duration of the data to be uploaded is processed to generate a caching adjustment factor for the data to be uploaded. The cache priority level range information and the cache adjustment factor of the data to be uploaded are processed to generate cache warning information.

5. The method according to claim 4, characterized in that, The cache priority of the data to be uploaded is processed to generate cache priority level range information and attribute tags for the data to be uploaded, including: The cache priority of the data to be uploaded is processed to generate initial data cache information, wherein the initial data cache information includes several cache rules set by the target user for different types of data to be uploaded; Based on the initial data cache information, the data to be uploaded is processed to generate cache priority level range information and attribute tags for the data to be uploaded.

6. The method according to claim 4, characterized in that, Based on the cache warning information, the data to be uploaded in the data upload request is processed to generate data warning information, including: Based on the cache warning information, the data to be uploaded in the data upload request is processed to generate target storage location information and preset cache target node information; The target storage location information and the preset cache target node information are processed to generate data warning information.

7. The method according to claim 6, characterized in that, The target storage location information and the preset cache target node information are processed to generate data early warning information, including: Obtain real-time load balancing information and cache task information within a preset period from the target server cluster, wherein the target server cluster includes several servers; The target server cluster is processed based on the cache task information within the preset period to generate preset cache progress information for several servers. The cache priority and cache duration are processed based on several servers respectively to generate target cache progress information; The target cache progress information is processed to generate data warning information, wherein the data warning information is used to characterize the cache security of the data to be uploaded.

8. A network data early warning device, characterized in that, The device includes: The acquisition module is used to acquire data upload requests sent by terminal devices, wherein the data upload request includes data to be uploaded, upload authentication information of the terminal device, upload purpose information, and target user information, wherein the target user information includes data upload interval information and data upload size information of the target user; and to acquire attribute information and security level information of the data to be uploaded. The processing module is configured to: if the authentication result obtained from the upload authentication information of the terminal device indicates that the terminal device has upload permissions, configure a cache duration for the data to be uploaded based on the target user information; process the upload purpose information to generate a data upload processing factor; process the attribute information and security level information of the data to be uploaded based on the data upload processing factor to generate a cache priority for the data to be uploaded; process the cache priority and cache duration of the data to be uploaded based on a preset cache strategy to generate cache warning information; and process the data to be uploaded in the data upload request based on the cache warning information to generate data warning information.

9. An electronic device, characterized in that, The method includes a computer-readable storage medium storing a computer program, which is read and executed by the processor to implement the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that is read and executed by a processor to implement the method as described in any one of claims 1-7.

Images