Data hotspot identification and computing power dynamic reservation scheduling method

Abstract

The invention relates to the technical field of computing power distribution, and discloses a data hotspot identification and computing power dynamic reservation scheduling method. According to the method, suspicion hotspot data are monitored and identified in real time, a shadow execution copy with a minimum resource quota is constructed for the suspicion hotspot data, part of real-time flow is mirrored to the shadow copy for pressure testing without influencing a main service, and after a pressure verification score is calculated to confirm a hotspot, shadow copy resources are improved to a high-performance level and directed diversion is carried out; meanwhile, the method comprises the steps of self-adaptive threshold adjustment and hot spot cooling and capacity reduction, interaction is carried out on the basis of a centralized controller, a container arrangement platform and a service grid, hot spots can be accurately recognized, the computing power can be dynamically adapted, the resource utilization rate is increased, and the service stability and the resource efficiency are balanced.

Description

Technical Field

[0001] The present invention relates to the field of computing power allocation technology, and in particular to a method for identifying data hotspots and dynamically reserving computing power. Background Art

[0002] With the increasing popularity of cloud computing and distributed systems, various online services and applications are facing the challenges of massive user access and data processing. Among them, the dynamic and uncertain nature of data access patterns is one of the key factors leading to system performance bottlenecks and resource waste. Especially in high-concurrency scenarios, certain specific data, such as popular products, breaking news, and high-frequency query keys, may be accessed in large quantities in a short period of time, forming so-called "data hotspots."

[0003] Traditional computing power reservation and scheduling strategies usually adopt static configuration or coarse-grained prediction based on historical experience; this approach has significant limitations: Over-reservation leads to resource waste: In order to cope with possible hot spots, the system often reserves computing resources that exceed actual demand. When the hot spot does not appear as expected or lasts for a short time, these reserved resources will be idle, resulting in huge computing power waste and increased operating costs; Insufficient reservation leads to performance bottlenecks: If the emergence of hot spots is not accurately predicted or responded to in a timely manner, the resources reserved by the system may not be enough to support the sudden increase in access pressure, resulting in severe service response delays. The number of requests increases dramatically, the request failure rate rises, and even the system crashes, seriously affecting user experience and business continuity; lack of dynamic adaptability: existing technologies are usually difficult to immediately identify and fine-tune hotspots in the early stage of formation, and are unable to recycle resources in time after the hotspots subside, resulting in poor system adaptability to dynamically changing load patterns; "tidal effect" is difficult to handle: many hotspots are sudden, short-term and unpredictable, rising and falling like the tide. Existing technologies find it difficult to "stress test" potential hotspots to confirm their true popularity without affecting the main business link, thereby avoiding misjudgment and unnecessary resource allocation.

[0004] Therefore, how to achieve accurate and dynamic identification of data hotspots, and on this basis, perform efficient and flexible computing power reservation and scheduling to avoid resource waste caused by excessive reservation, while effectively responding to performance bottlenecks caused by sudden hotspots, is a technical problem that needs to be urgently solved in the current cloud computing and distributed systems fields. Summary of the Invention

[0005] The purpose of the present invention is to solve the problems in the prior art of untimely data hotspot identification, inaccurate computing power reservation scheduling, low resource utilization, and insufficient ability to deal with sudden hotspots, thereby realizing dynamic adaptation of computing power resources, avoiding idle waste caused by excessive reservation, or causing performance bottlenecks. To this end, we propose a method for data hotspot identification and dynamic computing power reservation scheduling.

[0006] In order to achieve the above-mentioned purpose, the present application adopts the following technical solutions: a method for data hotspot identification and dynamic reservation and scheduling of computing power, comprising the following steps: S1. Preliminary identification step: real-time monitoring of access requests for each data identifier in the system. When the fluctuation characteristics of the access request of a data identifier within a preset time window meet the preset suspicion conditions, the data identifier is determined as "suspected hotspot data"; S2. Shadow verification environment construction step: for "suspected hotspot data", a shadow execution copy that processes its business logic and is given a preset minimum resource quota is created in the computing resource pool in real time; S3. Traffic mirroring and stress testing step: a small part of the real-time traffic accessing the "suspected hotspot data" is mirrored to the shadow execution copy according to a preset ratio. The main business link is the traffic of the original business processing link that processes the "suspected hotspot data". The response is not affected; S4. Hotspot confirmation step: continuously monitor the performance indicators of the shadow execution copy under the mirror traffic, and calculate a stress verification score based on the performance indicators. When the stress verification score exceeds the preset verification threshold, the "suspected hotspot data" is confirmed as "verified hotspot data"; S5. Computing power promotion and scheduling step: for the data identifier confirmed as "verified hotspot data", the resource quota of the shadow execution copy serving it is immediately increased from the minimum resource quota to the preset high-performance resource quota, and the load balancing module is instructed to redirect all subsequent traffic accessing the data identifier to the shadow execution copy with the increased resource quota; S6. Resource recovery step: for the shadow execution copy whose stress verification score has never exceeded the verification threshold within the preset verification period, it is destroyed and its minimum resource quota is recovered.

[0007] Preferably, the suspicion condition in step S1 is determined by calculating an abnormal fluctuation index, which clarifies the comprehensive consideration of the relative increase in access rate and instantaneous acceleration: ;in, The data are derived from the access rate statistics of the corresponding data identifiers in the current monitoring period, the historical moving average period and the previous monitoring period obtained from the time series monitoring database; Used to measure the surge amplitude of flow, Used to measure the burst acceleration of traffic. The multiplication of the two is intended to prioritize access patterns with burst potential.

[0008] Preferably, the setting principle of the minimized resource quota in step S2 is: the quota is not numerically sufficient to enable the shadow execution copy to maintain its key performance indicators below the normal service level when it is subjected to a preset proportion of mirror traffic, but is sufficient to completely process the business logic of a single request without directly crashing due to insufficient resources; the key performance indicators include CPU utilization, memory usage and request processing delay.

[0009] Preferably, the preset proportion of the mirrored traffic in step S3 is dynamically determined by a piecewise linear function based on the abnormal fluctuation index value, aiming to apply a test pressure commensurate with hotspots of different suspicion levels that is sufficient to expose their performance bottlenecks, while ensuring that the upper limit of the proportion does not exceed 5% to strictly control the occupation of network resources of the main business link.

[0010] Preferably, the stress verification score in step S4 is calculated by performing a maximum-minimum normalization process on multiple performance indicators collected from the shadow execution copy and then performing a weighted summation, and the formula is: ;in They are dimensionless values ​​calculated by comparing the real-time collected response delay, CPU utilization, and request queue length with the upper and lower limits of their preset normal operating ranges; they are used to convert performance indicators of different physical units into unified and comparable pressure contributions.

[0011] Preferably, For the corresponding The weight coefficient, weight coefficient The setting is predetermined based on the offline performance analysis results of the business to which the data identifier belongs. The analysis applies different types of loads to the business in a test environment to identify whether its performance bottleneck is I / O intensive, CPU intensive, or memory intensive, and assigns the highest weight coefficient to the corresponding performance indicator where the bottleneck first appears.

[0012] Preferably, the computing power promotion and scheduling steps in step S5 include transactional operations of multiple concurrent actions: while requesting an increase in resource quota from the container orchestration platform, preheating instructions are concurrently sent to downstream services in a pre-built service dependency graph associated with the data identifier, such as cache and database connection pool, to ensure that when the promoted execution copy receives traffic, its entire call chain is in an activated state.

[0013] Preferably, it also includes an adaptive threshold adjustment step based on the verification results: the system maintains a database that records historical verification cases, each case containing the abnormal fluctuation index value at the time of triggering, the traffic pattern signature, and the pressure verification score trajectory of the final confirmation or rejection; a background regression analysis model regularly analyzes the database to automatically fine-tune the abnormal fluctuation index suspicion threshold in step S1 and the pressure verification score verification threshold in step S4, so that the recognition model can gradually reduce the false alarm rate while maintaining a high recall rate.

[0014] Preferably, it also includes a hotspot cooling and resource reduction step linked to the pressure verification score: for a promoted execution copy, the system continues to calculate its pressure verification score under the same formula when taking on all real traffic; when the pressure verification score is stably lower than a preset safety water level threshold during a continuous cooling observation period, the system will trigger a multi-stage, smooth resource reduction process rather than recovering all resources at one time.

[0015] Preferably, the implementation carrier of this method is a centralized verification scheduling controller, which interacts with the underlying container orchestration platform and service grid through a declarative API; its specific interaction method is: adjusting resource quotas by modifying the requests and limits fields of container resources, and controlling traffic mirroring and redirection by updating the mirror and route instructions in the VirtualService or HTTPRoute rules of the service grid.

[0016] Technical effects and advantages of the present invention: In the present invention, the two-stage mechanism of preliminary identification and shadow verification is adopted to avoid misjudgment of potential hotspots. In particular, by conducting a small-flow stress test in a shadow environment, the performance of suspected hotspots under real load can be verified without affecting the main business link, ensuring that only hotspots that really need additional resources will be confirmed, significantly improving the accuracy of hotspot identification, and for verified hotspots, the resource quota of their service copies can be instantly increased and traffic can be redirected, realizing dynamic and on-demand allocation of computing power, effectively responding to sudden traffic peaks, and avoiding performance bottlenecks. For data that has not been verified as a hotspot, the resources of its shadow copies will be promptly recovered, avoiding unnecessary long-term occupation and waste of resources. The mechanism of on-demand allocation and timely recovery greatly improves the utilization efficiency of computing resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The disclosure of the present invention is illustrated with reference to the accompanying drawings. It should be understood that the drawings are for illustrative purposes only and are not intended to limit the scope of protection of the present invention. In the drawings, the same reference numerals are used to refer to the same components: Figure 1 It is the workflow diagram of the present invention. DETAILED DESCRIPTION

[0018] It is easy to understand that according to the technical solution of the present invention, without changing the essential spirit of the present invention, a person skilled in the art can propose a variety of interchangeable structural modes and implementation modes. Therefore, the following specific embodiments and drawings are only exemplary descriptions of the technical solution of the present invention and should not be regarded as the entire invention or as a limitation or restriction of the technical solution of the present invention.

[0019] Reference Figure 1 As shown, the present invention provides a method for data hotspot identification and dynamic reservation and scheduling of computing power, aiming to achieve accurate identification and verification of data hotspots, dynamic allocation of computing power and efficient resource recovery through a multi-stage and refined strategy, thereby optimizing system performance and improving resource utilization.

[0020] S1. Preliminary identification step: This step is the first line of defense for hotspot identification, and is intended to quickly screen out "suspected hotspot data" with hotspot potential from massive data access requests. Specifically, the system monitors access requests for each data identifier in real time, such as product ID, user ID, article ID, API path, etc. The statistical data of these access requests, such as access rate and request volume, will be continuously collected and stored in the time series monitoring database. The suspect condition judge will periodically, for example, every minute, obtain the access rate statistics of the corresponding data identifier in the current monitoring period, historical moving average period, and previous monitoring period from the time series monitoring database. When the fluctuation characteristics of the access request of a certain data identifier within a preset time window meet the preset suspect condition, the data identifier is determined as "suspected hotspot data" and is added to the list of suspected hotspot data. In a preferred embodiment, the suspect condition is determined by calculating the abnormal fluctuation index. The calculation formula of the abnormal fluctuation index is: ;in, Indicates the access rate of the current monitoring period. Indicates the access rate of the historical moving average period, Indicates the access rate of the last monitoring cycle; the first term of the formula It is used to measure the surge amplitude of traffic, that is, the increase multiple of the current rate relative to the historical average level, reflecting the degree of sudden increase in traffic; the second item The burst acceleration used to measure traffic, that is, the rate of change of the current rate relative to the previous cycle, reflects the instantaneous speed of traffic growth; the multiplication of the two is intended to comprehensively consider the absolute increase and growth rate of traffic, so as to prioritize the identification of access patterns with explosive potential, that is, those potential hotspots that not only have a large increase in access volume but also a fast growth rate; when the calculated abnormal fluctuation index value exceeds the preset abnormal fluctuation index suspicion threshold, the data identifier is marked as "suspected hotspot data."

[0021] S2. Shadow verification environment construction steps: Once a data identifier is preliminarily identified as "suspected hotspot data", the system will immediately start the shadow verification environment construction module; for the "suspected hotspot data", the system will instantly create an independent shadow execution copy in the computing resource pool to process its business logic; this shadow execution copy is a lightweight, isolated replica of the corresponding service on the main business link, which can fully process business requests for the data identifier; the shadow execution copy is assigned a preset minimum resource quota; the setting principle of the minimum resource quota is: the quota is not numerically sufficient to enable the shadow execution copy to maintain its key performance indicators below the normal service level when it bears subsequent mirror traffic, including CPU utilization, memory usage and request processing delay, but it is sufficient to fully process the business logic of a single request without directly crashing due to insufficient resources. This means that if the data identifier is indeed a hotspot, then under the minimum resource quota, the performance indicators of the shadow copy will quickly deteriorate, thereby exposing its hotspot properties.

[0022] S3. Traffic mirroring and stress testing steps: After the shadow execution replica is successfully built and started, the traffic mirroring and stress testing module will begin operation. The traffic mirrorer will mirror a small portion of the real-time traffic accessing the "suspected hotspot data" to the shadow execution replica according to a preset ratio. The key here is that the traffic and response of the main business link, that is, the original business processing link that handles the "suspected hotspot data", are not affected by anything. This means that all requests from real users are still processed by the service replica on the main business link, and the shadow replica is only used to receive mirrored traffic for testing, thereby achieving zero interference with the production environment. In a preferred embodiment, the preset ratio of mirrored traffic is dynamically determined by the mirrored traffic ratio controller based on the abnormal fluctuation index value calculated in step S1 through a piecewise linear function. This dynamic adjustment is intended to apply appropriate test pressure to hotspots of different suspicion levels, sufficient to expose their performance bottlenecks. For example, a higher abnormal fluctuation index value indicates a greater suspicion of the hotspot, and the mirroring ratio can be appropriately increased to accelerate the verification process. At the same time, in order to strictly control the occupation of network resources and potential risks of the main business link, the upper limit of the mirroring ratio is strictly limited, for example, not exceeding 5%.

[0023] S4. Hotspot Confirmation Step: The hotspot confirmation module is responsible for determining whether the shadow execution replica is a true hotspot based on its performance under mirrored traffic. The performance indicator monitor continuously monitors the performance indicators of the shadow execution replica under mirrored traffic, such as CPU utilization, memory usage, request processing latency, request queue length, error rate, etc. Based on these performance indicators, the stress verification score calculator calculates a stress verification score. The stress verification score is intended to quantify the "stress" or "health" of the shadow replica under the current load. In a preferred embodiment, the stress verification score is calculated by performing maximum-minimum normalization processing on multiple performance indicators collected from the shadow execution replica and then taking a weighted sum. The formula is: ;in, The dimensionless values ​​are calculated by comparing the real-time collected response delay, CPU utilization, and request queue length with the upper and lower limits of their preset normal operating ranges. They are used to convert performance indicators of different physical units into unified and comparable pressure contributions. For example, if the response delay exceeds the upper limit of the normal range, then It will be close to 1 or higher, and vice versa. This is to convert the performance indicators of different physical units into a unified and comparable pressure contribution, so that the pressure verification score can comprehensively reflect the pressure faced by the system. For the corresponding The weight coefficient, weight coefficient The setting is predetermined based on the offline performance analysis results of the business to which the data identifier belongs. This analysis identifies whether its performance bottleneck is I / O intensive, CPU intensive, or memory intensive by applying different types of loads to the business in the test environment, and assigns the highest weight coefficient to the corresponding performance indicator where the bottleneck first appears. For example, if a business is CPU intensive, then It will be set higher so that the increase in CPU utilization has a greater impact on the stress verification score.

[0024] When the calculated stress verification score exceeds the preset verification threshold, it indicates that the shadow execution copy can no longer effectively process the mirror traffic under the minimum resource quota, and the "suspected hotspot data" is confirmed as "verified hotspot data."

[0025] S5. Computing power promotion and scheduling step: For data identifiers that are confirmed as "verified hot data", the computing power promotion and scheduling module will be started immediately to provide it with sufficient computing power support; this step is a transactional operation that includes multiple concurrent actions; first, the system will immediately increase the resource quota of the shadow execution copy serving it from the minimum resource quota to the preset high-performance resource quota; the high-performance resource quota is pre-configured according to business needs and expected load, which is sufficient to support the access volume of the hot data during peak hours; at the same time, the computing power promotion and scheduling module will concurrently send a request to a pre-built downstream service in the service dependency graph associated with the data identifier. Send preheating instructions, such as cache services, database connection pools, message queues, etc.; these preheating instructions are designed to activate the connection, cache or preload data of downstream services in advance to ensure that when the promoted execution copy receives all traffic, its entire call chain is in an activated state, avoiding performance bottlenecks caused by cold start of downstream services; after the resource quota is increased and the downstream service preheating is completed, the load balancing module will be instructed immediately to redirect all subsequent traffic accessing the data identifier to the shadow execution copy with the increased resource quota; at this time, the shadow execution copy with the increased resource quota will become the main service provider for the hot data, carrying all real traffic.

[0026] S6. Resource recovery step: The resource recovery module is responsible for cleaning up shadow execution copies that fail verification to avoid resource waste. For shadow execution copies whose pressure verification scores never exceed the verification threshold within the preset verification cycle, it indicates that the "suspected hot spot data" is not a real hot spot, or its heat is not enough to trigger a computing power increase. In this case, the resource recovery module will send a destruction instruction to the computing resource pool to destroy it and reclaim its previously allocated minimum resource quota. This ensures that only businesses that really need additional resources are allocated resources, thereby maximizing resource utilization.

[0027] Adaptive threshold adjustment step: In order to enable the method of the present invention to continuously optimize its recognition accuracy and efficiency, the system also includes an adaptive threshold adjustment step based on the verification results; the system maintains a database that records historical verification cases; each case includes the abnormal fluctuation index value at the time of triggering, the traffic pattern signature, such as the traffic growth curve, the access source distribution, etc., and the pressure verification score trajectory that is finally confirmed or rejected; a background regression analysis model will regularly analyze the database; by learning from historical data, the model can identify the correlation pattern between the abnormal fluctuation index value and the pressure verification score verification result, and automatically fine-tune the abnormal fluctuation index suspicion threshold in step S1 and the pressure verification score verification threshold in step S4; for example, if it is found that the suspected data within a certain abnormal fluctuation index range is ultimately rejected in large quantities, the abnormal fluctuation index suspicion threshold can be appropriately increased to reduce false alarms; conversely, if it is found that some real hotspots are not identified in time, the threshold can be appropriately lowered; this is intended to enable the recognition model to maintain a high recall rate while not missing real hotspots, and gradually reduce the false alarm rate, that is, not misjudge non-hotspots, thereby achieving intelligent and adaptive optimization.

[0028] Hotspot cooling and resource scaling down step: The present invention also includes a hotspot cooling and resource scaling down step linked to the pressure verification score, which is used to smoothly reclaim resources after the hotspot subsides. For a promoted execution copy, the system will continue to calculate its pressure verification score under the same formula as step S4 when taking on all real traffic. This pressure verification score now reflects the actual pressure of the copy under the current load after the hotspot subsides. When the pressure verification score is stably lower than a preset safety water level threshold during a continuous cooling observation period, it indicates that the hotspot data is no longer in a high-load state and the computing power required can be appropriately reduced. At this time, the system will trigger a multi-stage, smooth resource scaling down process instead of reclaiming all resources at once. For example, the resource quota can be reduced from the high-performance resource quota to the medium quota first, and then observed for a period of time. If the pressure verification score is still lower than the safety water level, it can be further reduced until it returns to the baseline level or is completely recovered. This smooth scaling down mechanism avoids performance jitter that may be caused by a sudden reduction in resources, ensuring the stability of the service.

[0029] Implementation carrier and interaction mode: The implementation carrier of the method of the present invention is a centralized verification scheduling controller; the controller is the core brain of the entire system, responsible for coordinating the work of various modules; the controller interacts with the underlying container orchestration platform and service grid through a declarative API, such as Kubernetes, Istio, and Linkerd.

[0030] The specific interaction method is as follows: resource quota adjustment: the controller adjusts the resource quota by modifying the requests and limits fields of the container resources in the container orchestration platform; for example, when creating a shadow execution copy in step S2, its requests and limits are set to the minimum resource quota; when the computing power is promoted in step S5, it is modified to the high-performance resource quota; traffic mirroring and redirection: the controller controls the mirroring and redirection of traffic by updating the mirror and route instructions in the VirtualService or HTTPRoute rules of the service grid; for example, in step S3, part of the traffic is mirrored to the shadow execution copy by configuring the mirror instruction; in step S5, all traffic accessing hotspot data is redirected to the promoted execution copy by modifying the route instruction; this declarative API interaction method enables the method of the present invention to be seamlessly integrated with mainstream cloud native infrastructure to achieve efficient and reliable automated scheduling.

[0031] The technical scope of the present invention is not limited to the contents of the above description. Those skilled in the art can make various deformations and modifications to the above embodiments without departing from the technical idea of ​​the present invention, and these deformations and modifications should all fall within the protection scope of the present invention.

Claims

1. Data hotspot identification and computing power dynamic reservation scheduling method, characterized by: The following steps are involved: S1. Preliminary Identification Step: Real-time monitoring of access requests for each data identifier in the system. When the fluctuation characteristics of access requests for a data identifier within a preset time window meet the preset suspicion criteria, the data identifier is identified as "suspicious hotspot data." S2. Shadow Verification Environment Construction Step: For the "suspicious hotspot data," a shadow execution replica is instantly created in the computing resource pool to process the business logic of the data identifier and is assigned a preset minimum resource quota. S3. Traffic mirroring and stress testing: A small portion of the real-time traffic accessing the "suspected hotspot data" is mirrored to the shadow execution replica at a preset ratio. The traffic and response of the main business link, i.e., the original business processing link that handles the "suspected hotspot data", remain unaffected. S4. Hotspot confirmation step: continuously monitor the performance indicators of the shadow execution copy under the mirror traffic, and calculate a stress verification score based on the performance indicators. When the stress verification score exceeds the preset verification threshold, the "suspected hotspot data" is confirmed as "verified hotspot data"; S5. Computing power promotion and scheduling step: for the data identifier confirmed as "verified hotspot data", the resource quota of the shadow execution copy serving it is immediately increased from the minimum resource quota to the preset high-performance resource quota, and the load balancing module is instructed to redirect all subsequent traffic accessing the data identifier to the shadow execution copy with the increased resource quota; S6. Resource recovery step: For the shadow execution copies whose stress verification scores never exceed the verification threshold within the preset verification period, they are destroyed and their minimized resource quotas are recovered.

2. The data hotspot identification and computing power dynamic reservation scheduling method according to claim 1 is characterized by: The suspicion condition in step S1 is determined by calculating the abnormal fluctuation index, which clarifies the comprehensive consideration of the relative increase in access rate and instantaneous acceleration: ;in, The data are derived from the access rate statistics of the corresponding data identifiers in the current monitoring period, the historical moving average period and the previous monitoring period obtained from the time series monitoring database; Used to measure the surge amplitude of flow, Used to measure the burst acceleration of traffic. The multiplication of the two is intended to prioritize access patterns with burst potential.

3. The data hotspot identification and computing power dynamic reservation and scheduling method according to claim 1 is characterized by: The principle for setting the minimum resource quota in step S2 is: the quota is not numerically sufficient to enable the shadow execution copy to maintain its key performance indicators below the normal service level when it is subjected to the preset proportion of mirror traffic, but is sufficient to completely process the business logic of a single request without directly crashing due to insufficient resources; the key performance indicators include CPU utilization, memory usage and request processing delay.

4. The data hotspot identification and computing power dynamic reservation and scheduling method according to claim 1 is characterized by: The preset ratio of the mirrored traffic in step S3 is dynamically determined by a piecewise linear function based on the abnormal fluctuation index value. This is intended to apply appropriate test pressure to hotspots of different suspicion levels, sufficient to expose their performance bottlenecks, while ensuring that the upper limit of this ratio does not exceed 5% to strictly control the occupation of network resources on the main service link.

5. The data hotspot identification and computing power dynamic reservation and scheduling method according to claim 1 is characterized by: The stress verification score in step S4 is calculated by performing a maximum-minimum normalization process on multiple performance indicators collected from the shadow execution copy and then performing a weighted summation. The formula is: ;in, They are dimensionless values ​​calculated by comparing the real-time collected response delay, CPU utilization, and request queue length with the upper and lower limits of their preset normal operating ranges; they are used to convert performance indicators of different physical units into unified and comparable pressure contributions.

6. The data hotspot identification and computing power dynamic reservation and scheduling method according to claim 5 is characterized by: described For the corresponding The weight coefficient, the weight coefficient The setting is predetermined based on the offline performance analysis results of the business to which the data identifier belongs; the analysis identifies whether its performance bottleneck is I / O intensive, CPU intensive, or memory intensive by applying different types of loads to the business in a test environment, and assigns the highest weight coefficient to the corresponding performance indicator where the bottleneck first occurs.

7. The data hotspot identification and computing power dynamic reservation and scheduling method according to claim 1 is characterized by: The computing power promotion and scheduling steps in step S5 include transactional operations of multiple concurrent actions: while requesting an increase in resource quota from the container orchestration platform, preheating instructions are concurrently sent to downstream services in a pre-built service dependency graph associated with the data identifier, such as cache and database connection pool, to ensure that when the promoted execution copy receives traffic, its entire call chain is in an activated state.

8. The data hotspot identification and computing power dynamic reservation and scheduling method according to claim 1 is characterized by: It also includes an adaptive threshold adjustment step based on the verification results: the system maintains a database that records historical verification cases, each case containing the abnormal fluctuation index value at the time of triggering, the traffic pattern signature, and the pressure verification score trajectory of the final confirmation or rejection; a background regression analysis model regularly analyzes the database to automatically fine-tune the abnormal fluctuation index suspicion threshold in step S1 and the pressure verification score verification threshold in step S4, so that the recognition model can gradually reduce the false alarm rate while maintaining a high recall rate.

9. The data hotspot identification and computing power dynamic reservation and scheduling method according to claim 8, characterized in that: It also includes a hotspot cooling and resource reduction step linked to the pressure verification score: for a promoted execution copy, the system continues to calculate its pressure verification score under the same formula when taking on all real traffic; when the pressure verification score is stably lower than a preset safety water level threshold during a continuous cooling observation period, the system will trigger a multi-stage, smooth resource reduction process instead of reclaiming all resources at once.

10. The method for identifying data hotspots and dynamically reserving computing power according to any one of claims 1 to 9, characterized in that: This method is implemented as a centralized validation scheduling controller that interacts with the underlying container orchestration platform and service grid through a declarative API. The specific interaction method is to adjust resource quotas by modifying the requests and limits fields of container resources, and to control traffic mirroring and redirection by updating the mirror and route instructions in the service grid's VirtualService or HTTPRoute rules.

Images