Data hotspot identification and computing power dynamic reservation scheduling method

Abstract

The present application relates to the technical field of computing power allocation, and discloses a data hotspot identification and computing power dynamic reservation scheduling method. The present application identifies "suspected hotspot data" through real-time monitoring, constructs a shadow execution copy with a minimized resource quota for the "suspected hotspot data", mirrors part of the real-time traffic to the shadow copy for stress testing without affecting the main business, calculates a stress verification score to confirm the hotspot, and then improves the resource of the shadow copy to a high performance level and directs the flow. The shadow copy that does not pass the verification is destroyed to recycle the resources. The present application also includes adaptive threshold adjustment and hotspot cooling and capacity reduction steps, interacts with the centralized controller, container orchestration platform and service mesh, can accurately identify hotspots and dynamically adapt computing power, improves resource utilization, and balances service stability and resource efficiency.

Description

Technical Field

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

[0002] With the increasing prevalence of cloud computing and distributed systems, various online services and applications face the challenge 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 frequently queried key values, 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 typically employ static configuration or coarse-grained predictions based on historical experience. This approach has significant limitations: Over-reservation leads to resource waste: To cope with potential hotspots, systems often reserve more computing resources than actually needed. When the hotspots do not appear as expected or are short-lived, these reserved resources remain idle, resulting in significant computing power waste and increased operating costs. Insufficient reservation causes performance bottlenecks: If the occurrence of hotspots is not accurately predicted or responded to in a timely manner, the system's reserved resources may be insufficient to support the sudden surge in access pressure, leading to severe service response delays. Increased workloads, rising request failure rates, and even system crashes severely impact user experience and business continuity; lack of dynamic adaptability: existing technologies often struggle to identify and process hotspots in their early stages, and cannot promptly reclaim resources after the hotspots subside, resulting in poor system adaptability to dynamically changing load patterns; difficulty in handling "tidal effects": many hotspots are sudden, short-lived, and unpredictable, rising and falling like tides. Existing technologies struggle to conduct "stress tests" on potential hotspots to confirm their true intensity without affecting the main business chain, thus avoiding misjudgments and unnecessary resource allocation.

[0004] Therefore, how to accurately and dynamically identify data hotspots, and on this basis, efficiently and flexibly reserve and schedule computing power to avoid resource waste caused by excessive reservation, while effectively dealing with performance bottlenecks caused by sudden hotspots, is a technical problem that urgently needs to be solved in the field of cloud computing and distributed systems. Summary of the Invention

[0005] The purpose of this invention is to solve the problems of untimely data hotspot identification, inaccurate computing power reservation and scheduling, low resource utilization, and insufficient ability to deal with sudden hotspots in the existing technology, so as to realize dynamic adaptation of computing power resources, avoid idle waste caused by excessive reservation, or cause performance bottlenecks. To this end, we propose a data hotspot identification and dynamic computing power reservation and scheduling method.

[0006] To achieve the above objectives, this application adopts the following technical solution: a data hotspot identification and dynamic computing power reservation scheduling method, 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 an access request for a data identifier within a preset time window meet preset suspicion conditions, the data identifier is identified 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 assigned a preset minimum resource quota is created in real time in the computing resource pool; S3. Traffic mirroring and stress testing step: a small portion of the real-time traffic accessing "suspected hotspot data" is mirrored to the shadow execution copy according to a preset ratio, and the traffic of the main business link, i.e., the original business processing link that processes the "suspected hotspot data", is mirrored to the shadow execution copy. The response remains unaffected; S4. Hotspot Confirmation Step: Continuously monitor the performance metrics of the shadow execution replicas under mirrored traffic, and calculate a stress verification score based on the performance metrics. When the stress verification score exceeds the preset verification threshold, the "suspected hotspot data" is confirmed as "verified hotspot data"; S5. Computing Power Upgrade and Scheduling Step: For data identifiers confirmed as "verified hotspot data", immediately increase the resource quota of the shadow execution replicas serving it from the minimum resource quota to the preset high-performance resource quota, and instruct the load balancing module to redirect all subsequent traffic accessing the data identifier to the shadow execution replica with the increased resource quota; S6. Resource Reclamation Step: For shadow execution replicas whose stress verification score has never exceeded the verification threshold within the preset verification period, destroy them and reclaim their minimum resource quota.

[0007] Preferably, the suspicion criteria in step S1 are determined by calculating the abnormal fluctuation index, which clearly defines the comprehensive consideration of the relative increase and instantaneous acceleration of the access rate:

[0008] ;in, The data are obtained 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, respectively, from the time series monitoring database. Used to measure the surge amplitude of flow. The burst acceleration used to measure traffic is multiplied to prioritize the identification of access patterns with burst potential.

[0009] Preferably, the principle for setting the minimum resource quota in step S2 is that the quota is numerically insufficient to keep the key performance indicators of the shadow execution replica below the normal service level when it is subjected to a preset proportion of mirror traffic, but sufficient to fully process the business logic of a single request without crashing directly due to insufficient resources; key performance indicators include CPU utilization, memory usage and request processing latency.

[0010] Preferably, the preset ratio of 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 commensurate test pressure to hotspots of different levels of suspicion, sufficient to expose their performance bottlenecks, while ensuring that the upper limit of this ratio does not exceed 5%, so as to strictly control the occupation of network resources of the main business link.

[0011] Preferably, the stress verification score in step S4 is calculated by weighted summation of multiple performance metrics collected from the shadow execution replica after max-min normalization, and the formula is as follows: ;in These are dimensionless values ​​calculated by comparing real-time collected response latency, CPU utilization, and request queue length with the upper and lower limits of their preset normal operating range; used to convert performance indicators of different physical units into a unified and comparable pressure contribution.

[0012] Preferred, For the corresponding Weighting coefficients, weighting coefficients The settings are based on the offline performance profiling results of the business to which the data identifier belongs, which are predetermined. The profiling is done by applying different types of loads to the business in the test environment to identify whether its performance bottleneck is I / O intensive, CPU intensive or memory intensive, and assigning the highest weight coefficient to the corresponding performance index of the first bottleneck to appear.

[0013] Preferably, the computing power enhancement and scheduling step in step S5 includes transactional operations with multiple concurrent actions: while requesting an increase in resource quota from the container orchestration platform, a preheating instruction is sent concurrently to a pre-built service dependency graph associated with the data identifier, such as a cache or database connection pool, to ensure that the entire call chain is active when the enhanced execution replica receives traffic.

[0014] 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 stress verification score trajectory of the final confirmation or rejection; a background regression analysis model periodically analyzes the database to automatically fine-tune the abnormal fluctuation index suspicion threshold in step S1 and the stress verification score verification threshold in step S4, so that the identification model can gradually reduce the false positive rate while maintaining a high recall rate.

[0015] Preferably, it also includes a hotspot cooling and resource scaling-down step linked to the stress verification score: For an elevated execution replica, the system continues to calculate its stress verification score under full real traffic using the same formula; when the stress verification score is stably lower than a preset safety threshold during a continuous cooling observation period, the system will trigger a multi-stage, smooth resource scaling-down process, rather than reclaiming all resources at once.

[0016] Preferably, the implementation of this method is a centralized verification scheduling controller, which interacts with the underlying container orchestration platform and service mesh through a declarative API. The specific interaction method is as follows: resource quotas are adjusted by modifying the requests and limits fields of container resources, and traffic mirroring and redirection are controlled by updating the mirror and route directives in the VirtualService or HTTPRoute rules of the service mesh.

[0017] The technical effects and advantages of this invention are as follows: This invention avoids misjudging potential hotspots through a two-stage mechanism of preliminary identification and shadow verification. In particular, by conducting low-traffic stress tests in the shadow environment, it can verify the performance of suspected hotspots under real load without affecting the main business link, ensuring that only hotspots that truly require additional resources are confirmed, significantly improving the accuracy of hotspot identification. For verified hotspots, the resource quota of their service replicas can be increased and traffic redirected in real time, realizing dynamic and on-demand allocation of computing power, effectively coping with sudden traffic peaks and avoiding performance bottlenecks. For data that is not verified as a hotspot, the resources of its shadow replicas will be reclaimed in a timely manner, avoiding unnecessary long-term resource occupation and waste. The mechanism of on-demand allocation and timely reclamation greatly improves the utilization efficiency of computing resources. Attached Figure Description

[0018] The disclosure of this 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 this invention. In the drawings, the same reference numerals are used to refer to the same parts:

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

[0020] It is readily understood that, based on the technical solution of this invention, those skilled in the art can propose various interchangeable structural methods and implementations without altering the essential spirit of the invention. Therefore, the following detailed embodiments and accompanying drawings are merely illustrative examples of the technical solution of this invention and should not be considered as the entirety of the invention or as limitations or restrictions on the technical solution of this invention.

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

[0022] S1. Preliminary Identification Step: This step is the first line of defense in hotspot identification, aiming to quickly filter out "suspected hotspot data" with hotspot potential from massive data access requests. Specifically, the system monitors access requests for various data identifiers in real time, such as product ID, user ID, article ID, API path, etc. Statistical data of these access requests, such as access rate and request volume, are continuously collected and stored in the time-series monitoring database. The suspicion condition judge periodically, for example, every minute, retrieves the access rate statistics of the corresponding data identifier in the current monitoring period, historical moving average period, and the previous monitoring period from the time-series monitoring database. When the fluctuation characteristics of the access requests of a certain data identifier within a preset time window meet the preset suspicion conditions, the data identifier is identified as "suspected hotspot data" and added to the suspected hotspot data list. In a preferred embodiment, the suspicion conditions are determined by calculating an abnormal fluctuation index, the formula for which is: ;in, This indicates the access rate during the current monitoring period. This represents the access rate over a historical moving average period. This represents the access rate in the previous monitoring period; the first term of the formula The surge magnitude used to measure traffic is the multiple by which the current rate increases relative to the historical average, reflecting the degree of sudden increase in traffic; the second item The surge acceleration used to measure traffic is the rate of change of the current rate relative to the previous period, reflecting the instantaneous speed of traffic growth. Multiplying the two aims to comprehensively consider the absolute increase and growth rate of traffic, thereby prioritizing the identification of access patterns with explosive potential, namely, potential hotspots that not only experience a large increase in access volume but also a rapid growth rate. When the calculated abnormal fluctuation index value exceeds the preset abnormal fluctuation index suspicion threshold, the data is marked as "suspected hotspot data".

[0023] S2. Shadow Verification Environment Construction Steps: Once a data identifier is initially identified as "suspected hot data," the system will immediately activate the shadow verification environment construction module. For this "suspected hot data," the system will instantly create an independent shadow execution copy in the computing resource pool to handle its business logic. This shadow execution copy is a lightweight, isolated replica of the corresponding service on the main business chain, capable of fully handling business requests for this data identifier. This shadow execution copy is assigned a preset minimum resource quota. The principle for setting this minimum resource quota is that the quota is numerically insufficient to maintain the key performance indicators of the shadow execution copy below the normal service level when handling subsequent mirror traffic, including CPU utilization, memory usage, and request processing latency, but sufficient to fully handle the business logic of a single request without 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, thus exposing its hotspot attribute.

[0024] 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 working. 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, i.e., the original business processing link that processes the "suspected hotspot data," are unaffected. 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, thus achieving zero interference to the production environment. In a preferred embodiment, the preset ratio of the 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 aims to apply test pressure commensurate with the degree of suspicion of hotspots, sufficient to expose their performance bottlenecks. For example, the higher the abnormal fluctuation index value, the greater the suspicion of a 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 this mirroring ratio is strictly limited, for example, not exceeding 5%.

[0025] S4. Hotspot Confirmation Steps: The hotspot confirmation module is responsible for determining whether a shadow execution replica is a true hotspot based on its performance under mirrored traffic. The performance metrics monitor continuously monitors the performance metrics of the shadow execution replica under mirrored traffic, such as CPU utilization, memory usage, request processing latency, request queue length, and error rate. Based on these performance metrics, the stress verification score calculator calculates a stress verification score. The stress verification score aims to quantify the "stress" or "health status" of the shadow replica under the current load. In a preferred embodiment, the stress verification score is calculated by performing a weighted sum of multiple performance metrics collected from the shadow execution replica after max-min normalization. The formula is: ;in, These are dimensionless values ​​calculated by comparing real-time collected response latency, 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 a unified, comparable stress contribution; for example, if the response latency exceeds the upper limit of the normal range, then... It will be close to 1 or higher, and vice versa; this move aims to convert the performance indicators of different physical units into a unified and comparable stress contribution, so that the stress verification score can comprehensively reflect the stress faced by the system. For the corresponding Weighting coefficients, weighting coefficients The settings are pre-determined based on the offline performance profiling results of the service to which the data identifier belongs. This profiling identifies performance bottlenecks—whether they are I / O-intensive, CPU-intensive, or memory-intensive—by applying different types of loads to the service in a test environment, and assigns the highest weight coefficient to the performance metric corresponding to the first bottleneck to appear. For example, if a service 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.

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

[0027] S5. Computing Power Upgrade and Scheduling Steps: For data identifiers confirmed as "verified hot data," the computing power upgrade and scheduling module will immediately initiate, providing sufficient computing power support. This step is a transactional operation involving multiple concurrent actions. First, the system will immediately increase the resource quota of the shadow execution replica serving it from the minimum resource quota to the preset high-performance resource quota. The high-performance resource quota is pre-configured based on business needs and expected load, sufficient to support the access volume of the hot data during peak periods. Simultaneously, the computing power upgrade and scheduling module will concurrently send requests to downstream services in a pre-built service dependency graph associated with the data identifier. Preheating commands are sent, such as for caching services, database connection pools, and message queues. These commands aim to activate the connections, caches, or preload data of downstream services in advance, ensuring that the entire call chain is active when the upgraded execution replica receives all traffic, thus avoiding performance bottlenecks caused by cold starts of downstream services. After the resource quota increase and downstream service preheating are completed, the load balancing module will be immediately instructed to redirect all subsequent traffic accessing the data identifier to the shadow execution replica with the increased resource quota. At this point, the shadow execution replica with the increased resource quota will become the primary service provider for this hot data, carrying all real traffic.

[0028] S6. Resource Recycling Step: The resource recycling module is responsible for cleaning up shadow execution replicas that fail verification to avoid resource waste. For shadow execution replicas whose stress verification score never exceeds the verification threshold within the preset verification period, it indicates that the "suspected hot data" is not a real hotspot, or its popularity is insufficient to trigger a computing power upgrade. In this case, the resource recycling 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 truly need additional resources will be allocated resources, thereby maximizing resource utilization.

[0029] Adaptive Threshold Adjustment Step: To continuously optimize the accuracy and efficiency of the method of this invention, the system also includes an adaptive threshold adjustment step based on verification results. The system maintains a database recording historical verification cases. Each case includes the abnormal fluctuation index value at the time of triggering, traffic pattern signatures (e.g., traffic growth curves, access source distribution), and the stress verification score trajectory for final confirmation or rejection. A background regression analysis model periodically analyzes this database. Through learning from historical data, the model can identify the correlation pattern between the abnormal fluctuation index value and the stress verification score verification results, and automatically fine-tune the suspected threshold for the abnormal fluctuation index in step S1 and the verification threshold for the stress verification score in step S4. For example, if a large number of suspected data within a certain abnormal fluctuation index range are ultimately rejected, the suspected threshold for the abnormal fluctuation index can be appropriately increased to reduce false alarms. Conversely, if some real hotspots are not identified in time, the threshold can be appropriately decreased. This aims to enable the identification model to maintain a high recall rate while not missing real hotspots, and gradually reduce the false alarm rate, i.e., not misjudging non-hotspots, thereby achieving intelligent and adaptive optimization.

[0030] Hotspot Cooling and Resource Reduction Steps: This invention also includes a hotspot cooling and resource reduction step linked to the stress verification score, used to smoothly reclaim resources after the hotspot subsides. For an elevated execution replica, the system continues to calculate its stress verification score under full real traffic using the same formula as step S4. This stress verification score reflects the actual pressure on the replica under the current load after the hotspot subsides. When the stress verification score is consistently below a preset safety threshold during a sustained cooling observation period, it indicates that the hotspot data is no longer under high load, and its required computing power can be appropriately reduced. At this point, the system will trigger a multi-stage, smooth resource reduction process, rather than reclaiming all resources at once. For example, the resource quota can be reduced from a high-performance quota to a medium quota first, observed for a period of time, and if the stress verification score is still below the safety threshold, further reduction can be made until it is restored to the baseline level or completely reclaimed. This smooth reduction mechanism avoids performance fluctuations that may be caused by a sudden reduction in resources, ensuring service stability.

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

[0032] The specific interaction methods are as follows: Resource quota adjustment: The controller adjusts resource quotas by modifying the requests and limits fields of container resources in the container orchestration platform; for example, when creating a shadow execution replica in step S2, its requests and limits are set to the minimum resource quota; when the computing power is boosted in step S5, it is modified to a high-performance resource quota; Traffic mirroring and redirection: The controller controls traffic mirroring and redirection by updating the mirror and route directives in the VirtualService or HTTPRoute rules of the service mesh; for example, in step S3, some traffic is mirrored to the shadow execution replica by configuring the mirror directive; in step S5, all traffic accessing hot data is redirected to the boosted execution replica by modifying the route directive; This declarative API interaction method enables the method of this invention to be seamlessly integrated with mainstream cloud-native infrastructure, achieving efficient and reliable automated scheduling.

[0033] The technical scope of this invention is not limited to the content described above. Those skilled in the art can make various modifications and variations to the above embodiments without departing from the technical concept of this invention, and all such modifications and variations should fall within the protection scope of this invention.

Claims

1. A data hotspot identification and computing power dynamic reservation scheduling method, characterized in that, Comprising the following steps: S1. Preliminary identification step: real-time monitoring of access requests in the system for each data identifier, when the fluctuation characteristics of an access request for a data identifier within a preset time window meet the preset suspicious condition, the data identifier is determined as "suspicious hot data"; S2. Shadow verification environment construction step: for the "suspicious hot data", an instant shadow execution copy that processes its business logic is created in the computing resource pool, which is assigned a preset minimum resource quota; S3. Traffic mirroring and stress testing step: mirror a small part of the real-time real traffic accessing the "suspicious hot data" to the shadow execution copy according to a preset ratio, the traffic and response of the main business link, i.e. the original business processing link handling the "suspicious hot data", are not affected; S4. Hot spot 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 a preset verification threshold, the "suspicious hot data" is confirmed as "verified hot data"; S5. Computing power promotion and scheduling step: for the data identifier confirmed as "verified hot data", immediately promote the resource quota of the shadow execution copy serving it from the minimum resource quota to a preset high-performance resource quota, and instruct the load balancing module to redirect all subsequent traffic accessing the data identifier to the shadow execution copy with the promoted resource quota; S6. Resource recycling step: for the shadow execution copy whose stress verification score has always not exceeded the verification threshold within a preset verification period, it is destroyed and its minimum resource quota is recycled.

2. The data hotspot identification and computing power dynamic reservation scheduling method according to claim 1, characterized in that: The suspicious condition in the step S1 is judged by calculating an abnormal fluctuation index, which clearly shows the comprehensive consideration of the relative increase of the access rate and the instantaneous acceleration: ; wherein, The data of the current monitoring period, the historical moving average period and the last monitoring period are respectively obtained from the corresponding data identifiers in the time series monitoring database. The surge amplitude is used to measure the flow, The spike acceleration is used to measure the flow, and the multiplication of the two aims to identify the access mode with the potential of explosion in priority.

3. The data hotspot identification and computing power dynamic reservation scheduling method according to claim 1, characterized in that: The setting principle of the minimum resource quota in step S2 is that the quota is not enough in value to maintain the key performance indicators of the shadow execution copy below the normal service level when it bears the mirror traffic of the preset ratio, but it is enough 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 scheduling method according to claim 1, characterized in that: The preset ratio of the mirror traffic in step S3 is dynamically determined according to the abnormal fluctuation index value through a piecewise linear function, aiming to apply a test pressure to hot spots of different suspicious degrees that is commensurate with them and enough to expose their performance bottlenecks, while ensuring that the upper limit of the ratio does not exceed 5% to strictly control the occupation of network resources of the main business link.

5. The data hotspot identification and computing power dynamic reservation scheduling method according to claim 1, characterized in that: The calculation of the pressure verification score in the step S4 is obtained by weighting and summing the maximum-minimum normalized processing of the plurality of performance indexes collected from the shadow performing the copy, and the formula is: ; wherein respectively are the dimensionless values calculated by comparing the real-time collected response delay, CPU utilization, request queue length with the upper and lower limits of the preset normal operation range; For converting performance indicators in different physical units into unified and comparable pressure contribution.

6. The data hotspot identification and computing power dynamic reservation scheduling method according to claim 5, characterized in that: The corresponding weight coefficient, the weight coefficient The setting is determined in advance based on the offline performance profiling result of the business to which the data belongs; the profiling identifies whether the performance bottleneck of the business is I / O intensive, CPU intensive or memory intensive by applying different types of load to the business in a test environment, and gives the highest weight coefficient to the corresponding performance indicator that first appears bottleneck.

7. The data hotspot identification and computing power dynamic reservation scheduling method according to claim 1, characterized in that: The computing power promotion and scheduling step in step S5 contains transactional operations of multiple concurrent actions: while requesting resource quota promotion from the container orchestration platform, concurrently send a preheating instruction to the downstream services in a pre-constructed service dependency graph associated with the data identifier, including cache and database connection pool, to ensure that the entire call link is in an active state when the promoted execution copy receives traffic.

8. The data hotspot identification and computing power dynamic reservation scheduling method according to claim 1, characterized in that: An adaptive threshold adjustment step based on the verification result is also included: the system maintains a database recording historical verification cases, each case containing the abnormal fluctuation index value at the time of triggering, the traffic pattern signature, and the final confirmed or rejected pressure verification score trajectory; a background regression analysis model periodically 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 gradually reduces the false positive rate while maintaining a high recall rate.

9. The data hotspot identification and computing power dynamic reservation scheduling method according to claim 8, characterized in that: A hot spot cooling and resource scaling step linked with the pressure verification score is also included: for an executive copy that has been promoted, the system continues to calculate its pressure verification score under the condition of undertaking all real traffic according to the same formula; when the pressure verification score is stably below a preset safety water level threshold for a certain cooling observation period, the system will trigger a multi-stage, smooth resource scaling process, rather than recycling all resources at once.

10. The data hotspot identification and computing power dynamic reservation scheduling method according to any one of claims 1-9, characterized in that: The implementation carrier of the method is a centralized verification scheduling controller, which interacts with the underlying container orchestration platform and service mesh through a declarative API; the specific interaction method is to adjust the resource quota by modifying the requests and limits fields of the container resource, and to control the mirroring and redirection of traffic by updating the mirror and route instructions in the VirtualService or HTTPRoute rules of the service mesh.

Images