KMS key pre-distribution and elastic scheduling method based on prediction driving

Abstract

The invention provides a KMS key pre-distribution and elastic scheduling method based on prediction driving, which comprises the following steps of: predicting a KMS key request quantity and a peak value QPS in future T hours, and outputting a confidence interval of a prediction result; dynamically calculating the size of a KMS pre-distribution key pool according to the prediction result, and selecting a proper key type; the pre-generated KMS key is safely stored according to a three-level structure of a hot pool, a warm pool and a cold pool; and according to comparison between the real-time request quantity and a prediction result, priority routing and security degradation processing of KMS key distribution are realized. According to the invention, the response speed of the key service is obviously improved through an intelligent pre-distribution mechanism. Compared with 215ms of a traditional real-time generation scheme, the method has a qualitative leap. The high-speed response capability directly improves the user experience, reduces the waiting time of service processing, improves the operation efficiency of the whole system, and is particularly important for time-sensitive applications.

Description

Technical Field

[0001] The present invention relates to the technical field of cloud computing security and key management, and in particular to a prediction-driven KMS key pre-allocation and elastic scheduling method. Background Art

[0002] With the growing demand for data encryption, key management systems (KMS) have become a critical infrastructure for ensuring information security. However, current KMS technology faces many challenges, which severely limit its application in actual business scenarios. Traditional KMS generally uses real-time key generation when processing burst requests. This method has obvious performance bottlenecks, especially in asymmetric encryption algorithms. Taking the RSA 2048-bit key as an example, a single generation process takes more than 100 milliseconds, which leads to a backlog of request queues in high-concurrency scenarios, significantly prolonging the response time and directly affecting the operating efficiency of related business systems.

[0003] In response to the performance issues of real-time generation, the industry has proposed a key pre-distribution scheme, but this type of static pre-distribution strategy still has inherent defects. Existing pre-distribution schemes usually use a fixed number of pre-generated key pools, which cannot be dynamically adjusted according to changes in business load. This leads to a double dilemma in resource allocation: during business troughs, a large number of pre-generated keys are idle, resulting in a waste of resources; during business peaks, the pre-distributed pool may be quickly exhausted, and the system is forced to degenerate to real-time generation mode, facing performance issues again. In addition, the secure storage of pre-distributed keys also poses a severe challenge. To ensure security, pre-generated keys must be encrypted and protected, but large-scale pre-generation not only significantly increases storage costs, but also expands the potential attack surface. If the storage system is hacked, a large amount of key material may be leaked, posing serious security risks.

[0004] These technical bottlenecks are particularly prominent in high-concurrency scenarios such as business application upgrades and marketing campaign launches. System response delays may extend from milliseconds to seconds, affecting user experience and increasing business risks. At the same time, in an industry environment with increasingly stringent compliance requirements, imperfect key lifecycle management also increases compliance risks, making it difficult to ensure the complete destruction and effective tracking of expired keys. The industry is in urgent need of a new key management technology solution that can balance performance, cost, and security to meet the multi-dimensional demands of modern information systems for key services. Summary of the invention

[0005] In order to overcome the shortcomings of the prior art, the present invention proposes a prediction-driven KMS key pre-allocation and elastic scheduling method, which deeply embeds the performance prediction results into the management system of the pre-generated key pool, and realizes the intelligence of the dynamic expansion and contraction strategy; based on the precise analysis of the load characteristics of different business scenarios, the dynamic adjustment of the proportion of the pre-generated key algorithm is realized; through the unique key sharding technology and the hot / warm / cold three-level storage structure, the storage cost is optimized while ensuring the security of the key; a complete set of real-time request routing and security degradation mechanisms are constructed to ensure the stability and reliability of the system under various complex situations.

[0006] To achieve the above object, the present invention proposes a prediction-driven KMS key pre-allocation and elastic scheduling method, comprising the following steps: Step S1: Predict the KMS key request volume and peak QPS in the next T hours, and output the confidence interval of the prediction result; Step S2: dynamically calculating the size of the KMS pre-allocated key pool according to the prediction result and selecting a suitable key type; Step S3: securely store the pre-generated KMS key according to the three-level structure of hot pool, warm pool and cold pool; Step S4: Based on the comparison between the real-time request volume and the prediction result, priority routing and security downgrade processing of KMS key allocation are implemented.

[0007] Furthermore, the prediction step in step S1 uses the Prophet-LightGBM hybrid model for prediction, including: Step S11: Perform baseline decomposition on the time series data through Prophet, and output trend terms, seasonal terms, and residual terms; Step S12: splicing the decomposed features and the service features into a combined feature vector, wherein the service features include time features and service features; Step S13: Perform residual prediction based on combined features through LightGBM, using the error propagation formula: ;

[0008] in, and They represent the lower and upper limits of the confidence interval respectively; : Calculate the lower limit of the confidence interval; : Calculate the upper limit of the confidence interval; Represents the predicted value of the Prophet model; Represents the Prophet forecast standard deviation; Indicates the half width of the LightGBM quantile difference; represents the overall prediction standard deviation.

[0009] Furthermore, the step of dynamically calculating the size of the pre-allocated key pool includes: Step S21: By formula: ;

[0010] Calculate the size of the pre-allocated key pool, where is the predicted key request volume; is the safety factor; is the minimum pool capacity; is the size of the pre-allocated key pool; Step S22: Based on the predicted load characteristics, automatically adjust the type ratio of pre-generated keys, including: when the QPS peak is greater than 5000 times / second, generate 80% ECDSA P-256 keys and 20% RSA-2048 keys; when the business tag is financial transaction, generate FIPS 186-5 standard ECDSA keys; when national encryption compliance requirements are detected, generate SM2 elliptic curve keys.

[0011] Furthermore, the three-level structure security storage steps include: Step S31: configure the hot pool to use memory to store pre-generated keys that will be called in the short term in the future, and encrypt them using the AES-GCM encryption algorithm; Step S32: configure the warm pool to use SSD to store mid-term pre-generated keys and encrypt them using the SM4 encryption algorithm; and Step S33: configure the cold pool to use object storage to store redundant keys, which is only enabled when the load is high and the prediction deviation exceeds a threshold.

[0012] Furthermore, the encryption step includes: Step S311: AES-NI instruction set is used to accelerate the hot pool, the GCM mode of Intel AES-NI is used for parallel processing, and the key block size is optimized to be aligned with the L1 cache line; Step S312: The SM4-CTR mode is used for the warm pool, and the parallel IO characteristics of the SSD are used to batch process the key blocks and pre-calculate the S-box lookup table and store it in the SSD controller cache.

[0013] Furthermore, the method further includes the steps of performing lifecycle management on the pre-allocated KMS key, including: Set the TTL of the key. When the expiration time exceeds the TTL and is not used, the key will be automatically destroyed. The key fragmentation storage technology is adopted to split a single key into multiple fragments for decentralized storage, meeting the kN security threshold, where at least k fragments are required to restore the complete key. The key fragmentation storage adopts a (3,5) threshold scheme to divide the key K into 5 fragments: K = s1 ⊕ s2 ⊕ s3 ⊕ s4 ⊕ s5.

[0014] Furthermore, the steps of implementing KMS key distribution include: adopting a hot pool priority strategy to preferentially distribute keys from the hot pool; when the keys in the hot pool are exhausted and the actual request volume is lower than the predicted low confidence interval, allocating keys from the warm pool and triggering an asynchronous supplementary pre-generation operation.

[0015] Furthermore, the asynchronous supplementary pre-generation operation adopts a double buffer queue design, including: setting an active queue for the current service key pool and a reserve queue for background key generation; when the remaining amount in the active queue is lower than the threshold, switching to the reserve queue to provide service, and asynchronously triggering the key supplement of the active queue, using a lock-free ring buffer.

[0016] Furthermore, the steps of implementing KMS key distribution also include: when the actual request volume exceeds the predicted high confidence interval, enabling the cold pool key, triggering emergency key generation, and giving priority to GPU acceleration; and the GPU acceleration adopts CUDA's parallelization solution to perform parallel optimization processing on RSA and ECDSA keys respectively.

[0017] Furthermore, the security downgrade process includes: automatically marking the affected keys as invalid when a storage node anomaly is detected; dynamically calculating the number of pre-generated keys that need to be supplemented based on a prediction model; starting the pre-generation process; and excluding the keys marked as invalid from the key distribution process.

[0018] Compared with the prior art, the present invention has the following beneficial effects: 1. The present invention provides a prediction-driven KMS key pre-allocation and elastic scheduling method, which significantly improves the response speed of key services through an intelligent pre-allocation mechanism. In typical high-concurrency scenario tests such as large-scale business startup, shutdown and upgrade, 99% of the key request response time is controlled within 10ms, which is a qualitative leap compared to the 215ms of the traditional real-time generation solution. This high-speed response capability directly improves the user experience, reduces the waiting time for business processing, and improves the overall system operation efficiency, which is particularly important for time-sensitive applications.

[0019] 2. The present invention provides a prediction-driven KMS key pre-allocation and elastic scheduling method. The dynamic pre-allocation strategy intelligently adjusts the size of the pre-generated key pool, reducing its fluctuation by 42% and increasing the storage resource utilization to 91%. This efficient resource configuration mode effectively solves the common resource waste or shortage problems in traditional static pre-allocation solutions. The system can adaptively adjust resource allocation according to the predicted business load, ensuring the service quality during peak periods and avoiding a large number of idle resources during low periods, thereby reducing the overall operating costs of the enterprise.

[0020] 3. The present invention provides a prediction-driven KMS key pre-allocation and elastic scheduling method. The key fragmentation storage technology adopted reduces the risk of single-point leakage by 83%. By dividing the key and storing it in different media, even if a storage node is compromised, the attacker cannot obtain the complete key. Combined with the precise TTL (time to live) mechanism, the system achieves zero redundant key residue, ensuring that expired keys are destroyed in a timely manner without leaving any security risks. These security measures provide solid protection capabilities for enterprise key management in today's increasingly severe network security environment. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In order to more clearly illustrate the specific implementation methods of the present invention or the technical solutions in the prior art, the drawings required for use in the specific implementation methods or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some implementation methods of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0022] Figure 1 It is a schematic diagram of the system architecture of the present invention; Figure 2 is a key pre-distribution decision flow chart; Figure 3 This is a schematic diagram of key fragmentation storage; Figure 4 This is a schematic diagram of the security downgrade mechanism state machine. DETAILED DESCRIPTION

[0023] The technical solution of the present invention will be more clearly and completely explained below through description of preferred embodiments of the present invention in combination with the accompanying drawings.

[0024] Terminology explanation: Prophet-LightGBM hybrid model: a hybrid forecasting model that combines the Prophet time series forecasting model developed by Facebook and the LightGBM gradient boosting framework; QPS: number of queries per second; AES-GCM: A mode of Advanced Encryption Standard; RSA: an asymmetric encryption algorithm; ECDSA: Elliptic Curve Digital Signature Algorithm; SM2 / SM4: Cryptographic algorithm standards; TTL: Time to Live, which refers to the length of time data exists in the system; AES-NI: an instruction set specifically designed to accelerate AES encryption; Fragmented key storage: A technology that divides a key into multiple parts and stores them in a distributed manner. Only by obtaining a sufficient number of fragments can the complete key be restored. kN security threshold: In fragmented key storage, N represents the total number of fragments, and k represents the minimum number of fragments required to restore the key; Threshold scheme: For example, the (3,5) threshold scheme in this paper means that the key is divided into 5 pieces, and only any 3 of them are needed to restore the key; Information entropy: a measure of information uncertainty. A single-point leakage information entropy of 0 means that no useful information can be obtained from a single leakage point. Miller-Rabin test: A probabilistic primality testing algorithm used for primality verification in RSA key generation.

[0025] CUDA: A parallel computing platform and programming model developed by NVIDIA for GPU-accelerated computing. P99 latency: a performance indicator of system response time, indicating that 99% of requests can be responded to within this time; Hot pool / warm pool / cold pool: a three-level storage structure classified according to access frequency and response speed requirements; Pre-allocation strategy: A method of generating and reserving keys in advance to improve system response speed.

[0026] As a specific implementation method, the present invention proposes a prediction-driven KMS key pre-allocation and elastic scheduling method. Figure 1 As shown, the present invention predicts the key request volume and peak QPS in the next T hours through a performance prediction module, dynamically adjusts the pre-allocated key pool size and key type based on the prediction results, adopts a three-level storage architecture to store keys safely and efficiently, and implements intelligent routing and security degradation according to actual request conditions, thereby solving the performance bottleneck problem of the existing KMS system in high concurrency scenarios.

[0027] The performance prediction module of the present invention uses the Prophet-LightGBM hybrid model for prediction. The model first performs baseline decomposition of the time series data through Prophet, and outputs the trend term Tt, the seasonal term St, and the residual term Rt. The Prophet model was developed by Facebook and can handle factors such as trend changes, seasonality, and holidays in time series very well. Subsequently, the decomposed features are concatenated with the business features into a combined feature vector, where the business features include time features and business features. Time features include hourly granularity period coding (sin / cos transformation), week numbers, and holiday flags; business features include business upgrade event timestamps (unique hot coding) and real-time concurrency of the API gateway (sliding window mean). Finally, LightGBM performs residual prediction based on the combined features to obtain the final prediction value Q pred = T t + S t + LightGBM(R t ). LightGBM is an efficient gradient boosting framework with the advantages of fast training speed, low memory usage, and strong processing capabilities for large-scale data. Combining Prophet with LightGBM fully utilizes Prophet's advantages in processing time series features and LightGBM's strengths in model training efficiency and prediction accuracy.

[0028] The performance prediction module also calculates the confidence interval of the prediction result through the error propagation formula, which is: ;

[0029] in, and They represent the lower and upper limits of the confidence interval respectively; : Calculate the lower limit of the confidence interval; : Calculate the upper limit of the confidence interval; Represents the predicted value of the Prophet model; Represents the Prophet forecast standard deviation; Indicates the half width of the LightGBM quantile difference; Represents the total prediction standard deviation. The confidence interval generation method includes: Prophet uses Monte Carlo simulation to generate the basic confidence interval, performs quantile regression on LightGBM (quantile=0.05 and 0.95), and finally calculates the confidence interval through the error propagation formula. The confidence interval reflects the uncertainty of the prediction result. The system can adjust the pre-allocation strategy according to the size of the confidence interval to deal with possible deviations.

[0030] Based on the output results of the performance prediction module, such as Figure 2 As shown, the pre-allocation strategy generation module dynamically calculates the pre-allocated key pool size and selects the appropriate key type. The dynamic pool size calculation adopts the formula: ;

[0031] Calculate the size of the pre-allocated key pool, where is the predicted key request volume; is the safety factor, the default value is 0.2; is the minimum pool capacity; is the size of the pre-allocated key pool. The role of the safety factor α is to add a certain margin on the basis of the predicted value to cope with the prediction error and sudden business growth. The determination of the α value is based on historical data analysis. When α=0.1, the resource utilization rate is 92%, the request satisfaction rate is 96.3%, and the timeout rate is 3.7%; when α=0.2, the resource utilization rate is 85%, the request satisfaction rate is 99.1%, and the timeout rate is 0.4%; when α=0.3, the resource utilization rate is 79%, the request satisfaction rate is 99.6%, and the timeout rate is 0.1%. α=0.2 is selected through Pareto optimal analysis to achieve the best balance of satisfaction rate>99% and utilization rate>85%. The minimum pool capacity Nmin is set to prevent the system from working properly due to too few pre-generated keys due to too low predicted values ​​under low load conditions.

[0032] The key type selection is based on the predicted load characteristics and business tags, and the type ratio of pre-generated keys is automatically adjusted. Different key types differ in generation speed, security, and applicable scenarios. For example, RSA keys have higher security, but longer generation time (such as RSA 2048 key generation requires >100ms); while ECDSA keys have fast generation speed (generation time 5ms) and are suitable for high-concurrency scenarios. The decision tree rules based on QPS threshold and business tags are as follows: When the QPS peak is greater than 5000 times / second, 80% ECDSA P-256 keys (generation time 5ms) and 20% RSA-2048 keys (generation time 120ms) are generated; when the business tag is financial transaction, FIPS 186-5 standard ECDSA keys are generated; when national encryption compliance requirements are detected, SM2 elliptic curve keys (certified by the National Cryptography Administration) are generated.

[0033] A three-level structure is used for secure key storage, including hot pool, warm pool and cold pool. The hot pool uses memory as the storage medium to store pre-generated keys that will be called within the next 2 hours, and is encrypted using the AES-GCM encryption algorithm. The key access delay in the hot pool is less than 1ms. The warm pool uses a solid-state drive (SSD) to store pre-generated keys for the next 2-12 hours, and is encrypted using the national secret SM4 encryption algorithm. The key access delay in the warm pool is less than 10ms. The cold pool uses object storage to store redundant keys, which is enabled only when the load is high and the prediction deviation exceeds the threshold. The key access delay in the cold pool is less than 100ms.

[0034] Encryption optimization measures are also used to improve encryption efficiency. The memory hot pool uses the AES-NI instruction set acceleration, uses Intel AES-NI's GCM mode for parallel processing, and optimizes the key block size to 64KB alignment (matching the L1 cache line). Test data shows that for a 4KB data block, traditional encryption takes 0.8ms, but only 0.12ms after AES-NI optimization; for a 64KB data block, traditional encryption takes 12.4ms, but only 1.05ms after AES-NI optimization. The SSD warm pool uses the SM4-CTR mode, taking advantage of the parallel IO characteristics of the SSD, batch-processing 512 key blocks / requests, and pre-calculating the S-box lookup table and storing it in the SSD controller cache.

[0035] Perform lifecycle management on pre-allocated KMS keys, including TTL setting, automatic destruction, and key fragmentation storage. Set TTL (time to live) for pre-allocated keys. TTL refers to the time interval from key pre-generation to automatic destruction. When the key's life span exceeds TTL and is not used, the system will automatically destroy it and release the corresponding storage resources. Figure 3As shown in the figure, the key fragmentation storage adopts the (3,5) threshold scheme to divide the key K into 5 fragments: K = s1 ⊕ s2 ⊕s3 ⊕ s4 ⊕ s5. Any 3 or more fragments can restore K, and the single-point leakage information entropy is 0. The key fragmentation storage technology splits a single key into multiple fragments for distributed storage, meeting the kN security threshold, that is, only by obtaining at least k fragments can the complete key be restored. This method increases the security of the key. Even if a storage node is leaked, the attacker cannot obtain the complete key. The system meets the kN security threshold. For example, 2 fragments are required to restore the key among 3-5 fragments.

[0036] The elastic scheduling module implements priority routing and security downgrade processing of KMS key allocation based on the comparison between the real-time request volume and the prediction results. The real-time request routing adopts the hot pool priority strategy, which gives priority to allocating keys from the hot pool, because the keys in the hot pool are stored in the memory and have the fastest access speed, which can achieve low-latency key allocation. When the keys in the hot pool are exhausted and the actual request volume is not greater than the predicted low confidence interval, the keys are allocated from the warm pool and the asynchronous supplement pre-generation operation is triggered. The asynchronous supplement pre-generation adopts a double buffer queue design to prevent competition, setting the active queue (Queue_A) for the current service key pool and the reserve queue (Queue_B) for the background generation queue. When the remaining amount of Queue_A is less than 30%, it switches to Queue_B to provide services, and asynchronously triggers the key replenishment of Queue_A, and uses a lock-free ring buffer to improve concurrency performance.

[0037] When the actual request volume is greater than the predicted high confidence interval, the cold pool key is enabled and the emergency key generation is triggered at the same time, with GPU acceleration being preferred. The GPU emergency generation algorithm is implemented based on the parallelization scheme of CUDA. For RSA key generation optimization, the parallelization implementation of the Miller-Rabin test is used (each CUDA core processes a different candidate prime number), and modular exponentiation is accelerated through shared memory; for ECDSA optimization, the lookup table of elliptic curve base point multiplication is pre-calculated on the GPU, and the NVIDIAcuRAND library is used to accelerate random number generation. Performance comparison shows that 82 keys can be generated per second when using a Xeon CPU, while 1056 keys can be generated per second when using an A100 GPU.

[0038] The security downgrade mechanism is used to handle storage node anomalies. When a storage node anomaly is detected (such as disk failure, network interruption, etc.), the system will automatically mark the affected keys as invalid, dynamically calculate the number of pre-generated keys required to be supplemented based on the prediction model, start the pre-generation process, and exclude the keys marked as invalid from the key distribution process to avoid using unavailable keys.

[0039] The present invention has significant advantages over traditional solutions. In terms of storage security and cost, the single-point leakage risk of the full-memory storage solution is 100%, and the storage cost is 482,000 yuan / month, while the single-point leakage risk of the three-level fragmentation storage solution of the present invention is reduced to 17%, and the storage cost is only 154,000 yuan / month. Under concurrent requests of large-scale business applications, the average response time of the traditional solution is 214ms, the P99 delay is 1852ms, and the key generation failure rate is 3.7%; while the average response time of the present invention is only 9.6ms, the P99 delay is 28ms, and the key generation failure rate is reduced to 0.05%. According to actual tests, compared with the fixed pool solution, the resource consumption of the present invention is reduced by 57%, and the key generation time is greatly reduced from 102ms of static RSA pre-generation to 8.2ms.

[0040] like Figure 4 As shown, the mechanism achieves adaptive service level adjustment based on resource usage and external conditions.

[0041] The system is initially in the Initial state and immediately enters the Normal state after startup. In the Normal state, the system provides full-function services, all user requests are processed normally, and key allocation is unlimited. When the system key pool resource utilization rate reaches 80% saturation, the system automatically switches from the Normal state to the HotActive state. In the HotActive state, the system begins to take measures to control resource consumption, but still maintains the ability to respond to all user requests.

[0042] When the key pool resource saturation in the HotActive state further drops to 20%, the system enters the WarmStandby state. At this time, the system enters the resource protection mode and starts to implement flow control measures for non-critical service requests. If the warm pool utilization rate exceeds 90% or the warm pool replenishment is not completed, the system enters the WarmBackup state, which is a composite state containing multiple sub-states.

[0043] In the WarmBackup state, the system processes through two parallel paths: on the one hand, the AsyncGen mechanism is started to reserve URL layer keys to ensure the resources required for key services; on the other hand, the RaiseLimit operation is triggered to issue a non-zero network limit warning to remind the administrator of the system resource shortage. At this stage, the system ensures the continuity of core business by limiting non-priority requests.

[0044] When the system detects an emergency such as a DoS attack or storage failure, it will switch directly to the ColdEmergency state regardless of the state it is in. In this state, the system activates the VIPOnly mode, provides services only to VIP users, and implements a strict resource allocation policy. The ColdEmergency state includes two key operations: the VIPOnly [switch VIP priority] mechanism to ensure the service quality of high-value users; and the ColdBackup [downgrade all keys] operation, which downgrades all key services to maximize system resource conservation.

[0045] This state machine design implements a smooth degradation strategy for the system in the face of different loads and security threats, and ensures the availability of key services under extreme conditions through a multi-level protection mechanism, while maximizing resource utilization efficiency. This mechanism is particularly suitable for key management systems that require high reliability and security, and provides an effective framework for the system's flexible scheduling.

[0046] The prediction-driven KMS key pre-allocation and elastic scheduling method realizes the intelligent allocation and dynamic scheduling of key resources through the deep integration of prediction algorithm and key management, improves the performance and security reliability of the KMS system in high-concurrency scenarios, and provides efficient and stable key management services for various business applications.

[0047] The above specific implementations are only descriptions of the preferred implementations of the present invention, and do not limit the protection scope of the present invention. Without departing from the design concept and spirit of the present invention, various modifications, substitutions and improvements made by ordinary technicians in this field to the technical solution of the present invention based on the text description and drawings provided by the present invention should all fall within the protection scope of the present invention. The protection scope of the present invention is determined by the claims.

Claims

1. A prediction-driven KMS key pre-allocation and elastic scheduling method, characterized in that: The following steps are involved: Step S1: Predict the KMS key request volume and peak QPS in the next T hours, and output the confidence interval of the prediction result; Step S2: dynamically calculating the size of the KMS pre-allocated key pool according to the prediction result and selecting a suitable key type; Step S3: securely store the pre-generated KMS key according to the three-level structure of hot pool, warm pool and cold pool; Step S4: Based on the comparison between the real-time request volume and the prediction result, priority routing and security downgrade processing of KMS key allocation are implemented.

2. According to the prediction-driven KMS key pre-allocation and elastic scheduling method according to claim 1, it is characterized in that: The prediction step in step S1 uses the Prophet-LightGBM hybrid model for prediction, including: Step S11: Perform baseline decomposition on the time series data through Prophet, and output trend terms, seasonal terms, and residual terms; Step S12: splicing the decomposed features and the service features into a combined feature vector, wherein the service features include time features and service features; Step S13: Perform residual prediction based on combined features through LightGBM, using the error propagation formula: ； in, and They represent the lower and upper limits of the confidence interval respectively; : Calculate the lower limit of the confidence interval; : Calculate the upper limit of the confidence interval; Represents the predicted value of the Prophet model; Represents the Prophet forecast standard deviation; Indicates the half width of the LightGBM quantile difference; represents the overall prediction standard deviation.

3. According to the prediction-driven KMS key pre-allocation and elastic scheduling method of claim 1, it is characterized in that: The step of dynamically calculating the size of the pre-allocated key pool comprises: Step S21: By formula: ； Calculate the size of the pre-allocated key pool, where is the predicted key request volume; is the safety factor; is the minimum pool capacity; is the size of the pre-allocated key pool; Step S22: Based on the predicted load characteristics, automatically adjust the type ratio of pre-generated keys, including: when the QPS peak is greater than 5000 times / second, generate 80% ECDSA P-256 keys and 20% RSA-2048 keys; when the business tag is financial transaction, generate FIPS 186-5 standard ECDSA keys; when national encryption compliance requirements are detected, generate SM2 elliptic curve keys.

4. According to the prediction-driven KMS key pre-allocation and elastic scheduling method according to claim 1, it is characterized in that: The three-level structure safe storage step includes: Step S31: configure the hot pool to use memory to store pre-generated keys that will be called in the short term in the future, and encrypt them using the AES-GCM encryption algorithm; Step S32: configure the warm pool to use SSD to store mid-term pre-generated keys and encrypt them using the SM4 encryption algorithm; and Step S33: configure the cold pool to use object storage redundant keys, which are only enabled when the load is high and the prediction deviation exceeds a threshold.

5. According to claim 4, a prediction-driven KMS key pre-allocation and elastic scheduling method is characterized in that: The encryption step comprises: Step S311: AES-NI instruction set is used to accelerate the hot pool, the GCM mode of Intel AES-NI is used for parallel processing, and the key block size is optimized to be aligned with the L1 cache line; Step S312: The SM4-CTR mode is used for the warm pool, and the parallel IO characteristics of the SSD are used to batch process the key blocks and pre-calculate the S-box lookup table and store it in the SSD controller cache.

6. According to the prediction-driven KMS key pre-allocation and elastic scheduling method of claim 1, it is characterized in that: It also includes steps for lifecycle management of pre-allocated KMS keys, including: Set the TTL of the key. When the expiration time exceeds the TTL and is not used, the key will be automatically destroyed. The key fragmentation storage technology is adopted to split a single key into multiple fragments for decentralized storage, meeting the kN security threshold, where at least k fragments are required to restore the complete key. The key fragmentation storage adopts a (3,5) threshold scheme to divide the key K into 5 fragments: K = s1 ⊕ s2 ⊕ s3 ⊕ s4 ⊕ s5.

7. According to claim 1, a prediction-driven KMS key pre-allocation and elastic scheduling method is characterized in that: The steps of implementing KMS key distribution include: adopting a hot pool priority strategy to preferentially distribute keys from the hot pool; when the keys in the hot pool are exhausted and the actual request volume is lower than the predicted low confidence interval, distributing keys from the warm pool and triggering an asynchronous supplementary pre-generation operation.

8. The prediction-driven KMS key pre-allocation and elastic scheduling method according to claim 7 is characterized in that: The asynchronous supplementary pre-generation operation adopts a double buffer queue design, including: setting an active queue for the current service key pool and a reserve queue for background key generation; when the remaining amount in the active queue is lower than a threshold, switching to the reserve queue to provide services, and asynchronously triggering key supplementation in the active queue, using a lock-free ring buffer.

9. The prediction-driven KMS key pre-allocation and elastic scheduling method according to claim 1 is characterized in that: The steps of implementing KMS key distribution also include: when the actual request volume exceeds the predicted high confidence interval, enabling the cold pool key, triggering emergency key generation, and giving priority to GPU acceleration; and the GPU acceleration adopts CUDA's parallelization solution to perform parallel optimization processing on RSA and ECDSA keys respectively.

10. The prediction-driven KMS key pre-allocation and elastic scheduling method according to claim 1, characterized in that: The security downgrade process includes: automatically marking the affected key as invalid when a storage node anomaly is detected; dynamically calculating the number of pre-generated keys required to be supplemented based on a prediction model; starting a pre-generation process; and excluding the keys marked as invalid from the key distribution process.

Images