Resource hierarchical reservation and state regulation method in computing power tide scene

Abstract

The application discloses a resource hierarchical reservation and state regulation method in a computing power tide scene, comprising: obtaining joint prediction scene data containing predicted peak arrival time and stage, rollback and reconstruction time consumption; determining hierarchical commitment timing of resource batches based on the above data; when the commitment time corresponding to the current preparation state is reached, issuing a forward migration instruction to the resource node; in response to state rollback demand, using the next state recovery boundary in the timing combined with rollback and reconstruction time consumption to determine the actual available release duration of the candidate rollback state; when the duration meets the preconfigured gating condition, issue a rollback release instruction, otherwise keep the node state unchanged. The application can balance the contradiction between multi-stage resource on-time readiness and early occupation, and the use of physical time consumption constraints helps to suppress state oscillation caused by prediction correction, improving the overall stability and resource utilization of the computing power scheduling system.

Description

Technical Field

[0001] This invention relates to cloud computing resource scheduling and control technology, and in particular to a method for hierarchical reservation and state regulation of resources in a computing power tidal scenario. Background Technology

[0002] In modern distributed computing and microservice architectures, the demand for computing resources typically exhibits significant periodicity and sudden surges. To cope with the impact of high-concurrency business loads, it is necessary to start physical servers in advance, allocate storage quotas, or initialize container environments. The timeliness of resource preparation directly determines whether the underlying infrastructure can provide sufficient throughput capacity before the load peak arrives, which is of critical technical significance for achieving high availability of large-scale computing clusters, reducing response latency, and maintaining service level agreements (SLAs).

[0003] Existing resource scheduling schemes typically rely on shifting the overall startup time forward or setting up independent warm pools to achieve predictive scaling of computing power. In practice, they often use fixed empirical lead times to shift the entire scaling action forward, or calculate the single-point statistical quantiles of different resource layers to guide resource allocation.

[0004] In complex, multi-stage dependency environments, the actual arrival time of peak tides and the time taken for various asynchronous preparation tasks fluctuate significantly. Existing unidirectional shift mechanisms struggle to maintain joint matching of multiple stages on the timeline during execution, which can lead to some components becoming ready too early and running idle for extended periods, or some components being delayed and disrupting overall production. Furthermore, when faced with frequent fluctuations and corrections in business forecast metrics, existing control logic often lacks accurate measurement of physical recovery overhead when attempting to revoke triggered reserved operations, which can easily cause conflicts in the repeated rebuilding and release of computing slots and system states.

[0005] In summary, existing methods struggle to balance on-time readiness with avoiding premature quota locking when dealing with multi-level asynchronous resource preparation, and their jitter prevention and state management capabilities in the face of prediction bias remain insufficient.

[0006] Therefore, it is necessary to study a control method that can improve the timing rigor and scheduling security of resource allocation under complex multi-stage constraints. Summary of the Invention

[0007] The purpose of this invention is to provide a method for resource hierarchical reservation and state control in computing power tidal scenarios, in order to solve the above-mentioned problems existing in the prior art.

[0008] To address the aforementioned problems in existing technologies, this invention provides the following technical solution: a method for resource tiered reservation and state control in a computing power tidal scenario, comprising: Acquire joint prediction scenario data, which includes the predicted peak arrival time, stage preparation time, rollback time, and reconstruction time. The hierarchical commitment sequence of resource batches is determined based on the jointly predicted scenario data; When the control time reaches the commitment time corresponding to the current preparation state in the hierarchical commitment timing, a positive migration instruction is issued to the resource node; In response to the state rollback requirement, the actual available release duration of the candidate rollback state is determined by using the next state recovery boundary in the hierarchical commitment timing, combined with the rollback time and the reconstruction time. When the actual available release duration meets the pre-configured gating conditions, a rollback release command is issued to the resource node; otherwise, the current ready state of the resource node remains unchanged.

[0009] The process, after issuing a forward migration command to the resource node and bringing the resource node to an activation-ready state, also includes: Real-time acquisition of actual business load; When the actual business load exceeds the preset safety ratio of the existing service capacity, or when the actual time enters the pre-configured predicted peak activation range, a business traffic access instruction is issued to the resource node that is in the pending activation state and has passed the health check.

[0010] The computing power scale corresponding to a resource batch is determined in the following way: Based on the pre-configured target demand coverage ratio, extract the representative value of the distribution of predicted peak additional computing power demand; The total number of resource batches required is obtained by dividing the representative value of the distribution by the pre-configured single-batch serviceable capacity and rounding up.

[0011] Beneficial effects: This invention can balance the contradiction between timely resource readiness and premature occupation in multiple stages. By using physical time constraints, it can suppress state oscillations caused by prediction correction, thereby improving the overall stability and resource utilization of the computing power scheduling system. Attached Figure Description

[0012] Figure 1 This is a flowchart of the resource tiered reservation and state control method under the computing power tidal scenario of the present invention.

[0013] Figure 2 This is a flowchart of the method for determining the hierarchical commitment time series of resource batches based on the joint prediction scenario data of the present invention.

[0014] Figure 3 This is a flowchart of the method for determining the common offset based on the latest starting boundary at the scene level according to the present invention.

[0015] Figure 4 This is a flowchart of the method for triggering state rollback and determining candidate rollback states according to the present invention. Detailed Implementation

[0016] Example 1: As Figure 1 As shown, this embodiment provides a method for hierarchical reservation and state control of computing power tidal load, including the following steps: Step 101: Obtain joint prediction scenario data, which specifically includes the predicted peak arrival time, stage preparation time, rollback time, and reconstruction time. In cloud computing environments, hierarchical reservation scheduling logic is implemented to address the issues of resource preparation delays and premature occupancy caused by sudden surges in computing power.

[0017] Specifically, the joint prediction scenario data is generated by extracting data based on the historical capacity sequence and actual peak event records of the business system.

[0018] In this process, the joint prediction scenario data is specifically manifested as structured data that maintains the correspondence between data in each prediction scenario. For example, it can be in the form of a two-dimensional matrix or a high-dimensional tensor. The aim is to maintain the inherent physical correlation between the arrival time of the prediction peak and the preparation time, backoff time and reconstruction time of each stage under the same prediction scenario. The data is not scattered and sampled independently during the data use process, thereby maintaining the effectiveness of the joint probability distribution.

[0019] Meanwhile, a resource status template is predefined in the system. This resource status template records the predecessor state, successor state, corresponding stage time consumption, and revocable flag of each preparation state in the computing power resource chain, providing basic data support for subsequent time-series constraints.

[0020] Step 102: Determine the hierarchical commitment time sequence of resource batches based on the joint prediction scenario data; For the defined resource batches, calculate the latest start time boundary for each intermediate preparation state. The calculation logic here is not to take confidence intervals for each preparation stage independently, but to inversely accumulate the preparation time of each stage within the same scenario to deduce the most unfavorable delay offset for the whole.

[0021] Through this joint constraint calculation across and within scenarios, a strictly non-decreasing hierarchical commitment timing is generated. This reduces the problem of premature resource reservation caused by independent calculation lead time, ensuring that each level of computing power resource preparation has a clear and non-conflicting time anchor point.

[0022] Step 103: When the control time reaches the commitment time corresponding to the current preparation state in the hierarchical commitment timing, a forward migration instruction is issued to the resource node; During system operation, the state machine is driven to undergo positive state transitions by comparing the control clock with the hierarchical commitment timing in real time. As long as the commitment time of the corresponding stage has not been reached, the currently reserved operation remains in a waiting state.

[0023] Once the time threshold is met, the controller injects the forward migration instruction into the resource nodes in the baseline or intermediate state, propelling the underlying computing resources sequentially towards the fully ready state. This feedforward control mechanism ensures that computing resources only perform actual physical locking or configuration loading actions at the safe latest time boundary.

[0024] Step 104: In response to the state rollback requirement, determine the candidate rollback state based on the current actual state and the target state, and use the next state recovery boundary in the hierarchical commitment sequence, combined with the rollback time and the reconstruction time, to determine the actual available release time of the candidate rollback state. When an external prediction model undergoes rolling corrections and requires a pullback in the target capacity level, the state rollback requirement is triggered. If the rollback is not executed unconditionally at this time, state oscillations are highly likely to occur because resources have just been released and then need to be rebuilt.

[0025] Therefore, the next state recovery boundary that must be restored in the future is extracted from the hierarchical commitment timeline, and the boundary time is subtracted in sequence from the real-time current time, the rollback time consumed by the rollback action, and the reconstruction time required to restore the original state.

[0026] After deducting the physical time consumption mentioned above, the remaining time window is the actual available release time. This parameter is used to truly reflect the idle period during which the corresponding resources can actually be reused by other services or generate effective billing revenue if a reverse rollback is performed at this time.

[0027] Step 105: When the actual available release duration meets the pre-configured gating conditions, a rollback release command is sent to the resource node; otherwise, the current ready state of the resource node remains unchanged.

[0028] Extract the order statistics of the actual available release time under multiple joint prediction scenarios as representative values, and compare them with the preset minimum useful release time for determination.

[0029] In the first operating condition, when the representative value is greater than or equal to the minimum useful release duration, it is determined that the pre-configured gating condition is met, and the rollback release instruction for reverse rollback of execution status is issued to the resource node, thereby safely releasing the corresponding computing or storage quota.

[0030] In the second scenario, if the actual available release time is shorter than the above threshold, it means that the potential release window has been severely compressed by the round-trip time. In this case, the system blocks the rollback action and keeps the current ready state of the resource node unchanged.

[0031] This application uses a dynamic gating mechanism based on real physical time consumption, which differs from the conventional approach of relying on experience to set a fixed cooldown time window. It achieves anti-jitter resource regulation while ensuring that computing power is ready on time.

[0032] This embodiment extracts the most unfavorable minimum offset across stages from the joint prediction scenario and uses common order statistics to shift the time baseline. This mechanism maintains the non-decreasing hard constraint of the timing of each preparation node, while helping to compress the invalid quota lock-up period of computing resources during idle stages, so that the entire preparation chain can be jointly ready with a predetermined empirical probability.

[0033] Example 2: Further explanation of the generation framework and resource batch partitioning logic for multi-stage hierarchical commitment timing.

[0034] In one possible implementation, the following steps are included: Step 201: Based on the pre-configured target demand coverage ratio, extract the distribution representative value of the predicted peak additional computing power demand from the predicted peak additional computing power demand associated with the joint prediction scenario data. In the resource scheduling pre-stage, macroscopic tidal service capacity requests are transformed into microscopic operational parameters for the control unit. Peak load forecast results are obtained from time series forecasting models or probabilistic regression forecasting models.

[0035] Let ρ be the target demand coverage ratio, and let Y be the peak additional computing power demand distribution feature vector. Extract the distribution representative value Q corresponding to the quantile under this distribution feature. ρ (Y). The extracted feature data characterizes the total additional computing load that the target cluster needs to reserve under the set statistical probabilities.

[0036] Step 202: Divide the distributed representative value by the pre-configured single-batch serviceable capacity and round up to obtain the total number of resource batches required. Obtain standardized fixed computing power metrics for each computing node and set them as the serviceable capacity c for a single batch. b The macroscopic load demand is discretized into a number of independently dispatchable entity control batches through division operations.

[0037] The formula for calculating batch quantity is B = ceiling(Q) ρ (Y) / c b ).

[0038] The numerator and denominator dimensions use the same unit of measurement for computing power capacity. The dimensionless quotient generated by the division operation is rounded up by ceiling and converted into the total number of task batches that the control system needs to directly manage.

[0039] like Figure 2 As shown, according to one aspect of this application, determining the hierarchical commitment time series of resource batches based on the jointly predicted scenario data includes: The latest start boundary of each stage in each prediction scenario is inferred by using the joint prediction scenario data. The median reference time and common offset for each stage are determined based on the latest start boundary at the scene level. The hierarchical commitment timeline is generated using the median reference time and the common offset.

[0040] Specifically, the latest start boundary at the scene level for each stage in each prediction scenario is inferred using the jointly predicted scenario data: Step 203: Subtract the pre-configured control delay and the cumulative value of the stage preparation time corresponding to the current stage to the final stage from the predicted peak arrival time to obtain the scenario-level latest start boundary. For independent resource batches identified as b and specific prediction scenarios identified as n, the system traces back the start nodes of each intermediate state along the time axis from the final service access status.

[0041] Assume that a total of m are defined for the corresponding batch. b A series of preparation migrations, with the peak arrival time recorded as a. n The delay required for the j-th migration process is set to d(b,l,n), and the control and routing delay is set to... b .

[0042] Control delay b This is a pre-configured system-level constant parameter that characterizes the inherent communication and routing latency between the controller issuing a migration command and the resource node beginning to execute physical preparation actions. Those skilled in the art can determine this parameter by measuring the actual end-to-end latency of the scheduling link in the target deployment environment.

[0043] For the j-th migration, work backwards to find the latest start boundary in this scenario, z （b,j,n） =a n -∑(d(b,l,n)- b The index variable l of the accumulation operator ∑ inside the formula traverses from the current j to the end m. bTo provide a unified evaluation baseline for subsequent activation processes, a separate one-dimensional end-time boundary is established as a completion marker; that is, the latest start boundary is calculated as z. {b,mb+1,n} =a n - b .

[0044] In actual operation, the calculation module verifies the theoretical time span of adjacent preparation stages in the derivation output. When the latest start boundary interval between adjacent states is less than the minimum time granularity that the system can schedule, the control side merges them into a single migration step.

[0045] When the time difference between the latest start boundaries of two adjacent states is less than the clock resolution of the pre-configured scheduling system, the control side merges these adjacent states and issues instructions as a physical process.

[0046] Among them, such as Figure 3 As shown, determining the common offset based on the latest start boundary at the scene level includes steps 204 to 206: Unlike existing technologies that calculate independent quantiles for each stage to determine the lead time, the following steps determine the common offset by a joint constraint mechanism that extracts the minimum offset across stages within a single scene and then takes the order statistics across scenes: Step 204: Calculate the median reference time of the latest start boundary at the scene level for the same stage across all predicted scenarios; Establish reference baselines for statistical dimensions for each independent preparation stage to avoid extreme time interference from single device failures or occasional network jitters that could disrupt the entire reserved chain.

[0047] Specifically, a historical observation set with a total sample size of N is read, and the median feature, i.e., the median reference time, is extracted for each preparation stage labeled j. The operation rule is defined as Z_median. _{b,j} =median(z （b,j,n） ).

[0048] The computational operations are performed independently along the orthogonal time dimension of a specific preparation phase, completing data filtering and outputting a smoothed reference timeline for the corresponding node. For example, the median can adopt the lower median convention (or other conventions).

[0049] Step 205: Within the same prediction scenario, calculate the minimum offset of the latest start boundary at the scenario level relative to the corresponding median reference time for all stages. To maintain the correlation between the time required for each preparation stage and the underlying physical server load at that time, the data deviation of each stage is cross-scanned within a single prediction scenario. The reference baseline array generated in step 204 is received, and the time deviation of different stages in the specific scenario n is calculated.

[0050] Extract the infimum of the time difference at each stage, expressed as g. _{b,n} =min(z （b,j,n） -Z_median _{b,j} Here, the search index j covers a range extending from initial state 1 to the state marked m. b The +1 ending state. The generated single quantized scalar, i.e., the minimum offset, reflects the degree of offset of the bottleneck position with the most unfavorable latency risk in the current associated scenario.

[0051] Step 206: Select the one-sided order statistic of the minimum offset as the common offset according to the pre-configured stage chain joint readiness ratio. A data pool containing N scenario bottleneck feature scalars is generated through aggregation, and the minimum offset scalars are reorganized using an ascending sorting algorithm. To set a clear baseline for the system's readiness probability, the joint readiness ratio η of the corresponding stage chain is loaded. b Calculate the number of sample indices r required to cover the target area. b =ceiling(η b *N).

[0052] The reverse mapping rule is used to locate the truncation position of the ascending column, and the sorted index is extracted and denoted as idx. b =Nr b +1. Based on the aforementioned sorting results, read the data located at idx. b The variable term representing the position is the common offset, i.e., q. b =g _{b,( idx b)} By extracting the common offset value, the timing misalignment caused by truncating the discrete quantiles at each stage is eliminated.

[0053] Correspondingly, the hierarchical commitment time series is generated using the common offset, specifically as follows: Step 207: Add the median reference time to the common offset to obtain the hierarchical commitment time series.

[0054] The common offset is added as a constant to the median reference time corresponding to each independent preparation stage, and the corresponding output time series is θ. _{b,j} =Z_median _{b,j} +q b .

[0055] At the temporal evolution level, the basic feature reference baseline exhibits a non-decreasing property, and the new time boundary sequence after applying the same common parameters can continue to maintain a monotonically increasing property. The generated hierarchical commitment data sequence is imported into the controller's decision unit pool as the final result, indicating the trigger line for initiating the next state extrapolation for the corresponding batch.

[0056] Existing technologies that independently calculate quantiles for each stage may apply extreme values ​​driven by different scenarios to different stages, causing the sum of the lead times for each stage to exceed the actual lead time required in any real-world scenario, resulting in systematic premature reservation. This method, through a joint constraint of taking the minimum offset within a scenario and then taking the order statistics across scenarios, ensures that the extracted common offset only reflects the most unfavorable joint scenario, avoiding the excessive advance caused by independent calculations and objectively shortening the idle waiting time between resource locking and actual deployment.

[0057] Because each stage shares the same common offset, rather than taking independent quantiles, when the peak arrival time of a certain scenario is earlier than expected, it generates time compression in the same direction for all stages. This compression is fully captured by the minimum offset within the scenario. Compared to independent calculation methods, which may apply extreme values ​​of different scenarios to different stages (leading to an exaggeration of the overall lead time), the common offset of this method only reflects the truly unfavorable joint scenario, objectively compressing the invalid waiting time of each stage.

[0058] In some embodiments, d(b,l,n) of the historical sample is the end-to-end time (including instruction propagation) measured from the controller's perspective, or Δ. b The time consumed by each stage is negligible relative to the overall time required. The measured preparation time for each stage already includes the corresponding instruction propagation delay, or the controller uses a pipelined pre-issue instruction approach.

[0059] The instruction delays at intermediate migration stages are absorbed by the historically observed stage preparation time d(b,l,n), or the controller pre-issues the next stage instruction during the execution of the previous stage (pipeline type), causing the intermediate instruction delays to overlap with the execution time.

[0060] Example 3: Further explanation of the positive state transition and final service activation mechanism of the controlled physical entity.

[0061] In one possible implementation, issuing a forward migration command to the resource node specifically includes the following steps: Step 301: The forward migration instruction issued to the resource node requires the resource node to perform physical resource preparation actions such as quota locking, runtime startup, or image loading step by step without skipping intermediate states. When injecting instructions into the underlying infrastructure, the scheduling system maps abstract control nodes to concrete physical or virtual entities. Specifically: The resource nodes can be deployed using virtual machines, container groups, or bare-metal physical machines. To prevent race conditions or missing dependencies in the underlying state machine, the forward migration instructions generated by the controller encapsulate the expected predecessor state parameters. After receiving the instruction, the controlled node compares its current actual state with the expected predecessor state, and grants migration permission only when the states are strictly consistent, thereby physically restricting the node from crossing intermediate states.

[0062] For example, for underlying entities in an initial unallocated state, the quota locking is performed, and computing resource allocation slots are reserved by calling the application programming interface of the cloud platform; For an entity in a locked state, the runtime startup is executed, and the operation instructions instruct the entity to load the core operating system kernel; For entities that are ready to run, the image loading process is executed, and control instructions drive a background process to pull the business container image from a remote distributed repository and decompress it to the local machine. This series of progressively increasing physical resource preparation actions substantially consumes distributed computing power, storage resources, or network bandwidth resources.

[0063] In some optional implementations, to enhance control reliability in high-concurrency environments, the controller synchronously appends the current predicted version number identifier when issuing migration instructions. The execution node only accepts and executes the state transition logic if the predicted version number carried in the received instruction and the expected predecessor state both match the corresponding variable stored internally in the current node.

[0064] As an optional capacity replenishment scheme, if the current time is later than the promised time, the controller can start additional resource instances in parallel while performing the forward migration.

[0065] As an alternative to addressing the risk of sudden delays, if the current system clock parameters indicate that the time is later than the target time limit of the hierarchical commitment timing plan, the controller adds a delay risk flag to the controlled node and, while performing normal forward state migration, triggers a predefined on-demand fallback resource startup interface in parallel to call additional public cloud on-demand instances to supplement potential capacity gaps.

[0066] Step 302: Obtain the actual business load in real time; Once the underlying resources have completed the entire forward migration process and generated a node cluster in an inactive state, a traffic polling mechanism is initiated. Through an edge network gateway or application-layer load balancer, the number of concurrent data packet requests entering the system or the number of active Transmission Control Protocol (TCP) connections is periodically collected. The collection period can be determined by those skilled in the art based on the timeliness requirements of the service's response to load changes, and the statistical results are quantified and represented as the actual service load. This data provides real-time basis for subsequent activation determination when switching to the production network.

[0067] Step 303: When the actual business load exceeds the preset safety ratio of the existing service capacity, or when the actual time enters the pre-configured predicted peak activation range, a business traffic access instruction is issued to the resource node that is in the pending activation state and has passed the health check.

[0068] In the resource access decision-making process, a dual-path parallel decision-making branch mechanism based on capacity characteristics and time characteristics was deployed to control the timing of cold standby resources accessing the production service network.

[0069] In the first operating condition, namely the capacity-triggered branch where a sudden increase in load occurs, the real-time ratio of the actual business load to the existing service capacity is calculated.

[0070] The preset security ratio can be determined based on the target business system's tolerance for response latency. The lower the tolerance, the lower the security ratio should be set to provide earlier activation triggering. Those skilled in the art can determine the appropriate value by analyzing the time window from triggering capacity expansion to capacity exhaustion in historical load curves.

[0071] In the second scenario, namely the timed triggering branch based on the planned timeline, even if the actual business load has not yet exceeded the set proportional threshold, if the system clock comparison result indicates that the actual time has entered the pre-configured predicted peak activation range, the controller executes the same activation strategy and issues the corresponding business traffic access command. In both triggering scenarios, the target objects for issuing commands are subject to pre-filter constraints, strictly limited to resource nodes that simultaneously possess both the pending activation state and the heartbeat probe health check mark as passed. Through the node health status verification blocking mechanism, data traffic is avoided from being introduced to abnormal nodes with communication blockages or process freezes.

[0072] Example 4: Further explanation of the finite backoff gating algorithm based on round-trip margin.

[0073] like Figure 4 As shown, in one possible implementation, prior to responding to the state rollback request, the following steps are also included: Step 401: Obtain the target state and the current actual state corresponding to the prediction update; During system operation, the system periodically receives the latest peak parameters output by the external prediction model. The planned water level corresponding to the new prediction data is extracted and converted into the target state to be achieved.

[0074] At the same time, by reading the underlying resource status records, the current physical preparation progress of the batch resources is extracted as the current actual status.

[0075] As a filtering scheme for invalid control signals, the prediction version number is checked for monotonically before receiving the new prediction trigger comparison logic. If the read new prediction version number is not higher than the currently effective version number, the control terminal directly discards the batch of update data, preventing erroneous state overwriting caused by network out-of-order delivery or dirty data injection.

[0076] Step 402: When the target state is lower than the current actual state, the state rollback requirement is triggered; The comparison operator is used to compare the topological depth of the two states in the resource preparation chain.

[0077] If the comparison results indicate that the updated model requires capacity shrinkage, that is, the preparation stage number of the mapping is less than the actual stage number that the entity has reached, then it is determined that the previous reserved action was over-pre-empted.

[0078] Based on this depth difference, the logic unit generates an internal cancellation signal, formally triggering the state adjustment process and terminating the original feedforward advancement plan.

[0079] Step 403: Among the intermediate states corresponding to the current actual state and the target state, eliminate states where there is an operation that cannot be cancelled, and determine the candidate rollback state.

[0080] Starting from the current actual state and ending at the target state, traverse all intermediate preparation nodes on the state machine chain.

[0081] During the traversal, the physical operation attributes attached to each node are checked, and the revocable flags corresponding to each preparation state in the resource state template are read. Based on the revocable flags, those physical stages involving uninterruptible input / output write operations or forced state locking are identified and eliminated. The remaining set of nodes is marked as the set that can be safely revoked, forming the candidate rollback state sequence for subsequent time verification.

[0082] Using the next-state recovery boundary in the hierarchical commitment timeline, and combining the rollback time and the reconstruction time, the actual available release duration of the candidate rollback state is determined, specifically including steps 404 and 405: Step 404: Obtain the next state recovery boundary corresponding to the current preparation state from the hierarchical commitment timing. For each candidate node retained after filtering, it is accessed through a time-series schedule. By querying the index, the latest anchor point at which the resources in this batch must restart the forward migration to the next stage to meet the new predicted peak, if they were to revert to the current candidate node, is extracted. This parameter is defined as the next state recovery boundary. This data extraction provides a mandatory deadline constraint for the reverse operation.

[0083] Step 405: For each predicted scenario, subtract the real-time current time, the corresponding rollback time, and the reconstruction time from the next state recovery boundary in sequence to obtain the round-trip margin, and use the round-trip margin as the actual available release time.

[0084] The objective of this step is to evaluate the actual economic benefits of the reverse operation. Let the batch number be b, the current state be k, and the scenario of reverting to state h be explored. Assume the variable at the current time is t, and the next state recovery boundary record obtained through table lookup is λ. _{b,k} In a specific prediction scenario n, the rollback time variable required to release resources is u. _{b,k,h,n} The reconstruction time required to rebuild from state h to state k is r. _{b,k,h,n} The execution time subtraction operation is calculated using the formula w. _{b,k,h,n} =λ _{b,k} -tu _{b,k,h,n} -r _{b,k,h,n} The difference parameter w in the calculated output. _{b,k,h,n} This constitutes the round-trip margin. The physical meaning of this parameter is the actual available release time for the underlying computing resources to be truly idle and reused by other bypass services to share costs, after deducting the inherent time constraints of the system in the two-way physical actions of cancellation and reconstruction.

[0085] As an example: Suppose the control module obtains the parameter t=0.3 at the current time, and for a specific candidate backoff state, queries to obtain the next state recovery boundary parameter λ. _{b,k} =0.8. Based on the historical feature database, the current rollback time u is estimated to be 0.8. _{b,k,h,n} =0.1, reconstruction time r_ {b,k,h,n} =0.2. Applying the above subtraction formula, the round-trip margin calculation result for this single scenario is 0.8 - 0.3 - 0.1 - 0.2 = 0.2, representing the effective time window in which the system can produce real scheduling value after deducting all transitional overhead. λ _{b,k} Take the commitment time θ of the (k+1)th stage in the hierarchical commitment time series. _b,k+1 .

[0086] When the actual available release duration meets the pre-configured gating conditions, a rollback release instruction is issued to the resource node, including instructions 406 to 408: Step 406: Select the order statistics of the round-trip margin corresponding to the same candidate rollback state under different prediction scenarios as representative values; Because tidal loads have a random distribution, the system avoids relying on measurements from a single scenario.

[0087] For the same alternative state, extract the round-trip margin set generated in all associated prediction scenarios in the previous steps, and reorganize it in ascending order according to the numerical value.

[0088] The order index is determined based on the preset rollback and recovery ratio requirements, and the data at that index position is extracted as the overall representative value W. _{b,k,h} By employing order statistics features, the system gains anti-interference characteristics when processing fluctuating scene data.

[0089] Step 407: When the representative value is greater than or equal to the pre-configured minimum useful release duration, it is determined that the pre-configured gating condition is met. After obtaining the time representative value for cross-scenario convergence, the execution logic determines the branch.

[0090] In the first working condition, that is, in the branch that meets the gating conditions, when the calculated and extracted representative value is greater than or equal to the minimum useful release duration threshold set globally by the system, the engine determines that the current rollback operation is not only physically feasible in terms of time, but also that the generated idle period is sufficient to cover the communication handshake and context switching costs of the secondary scheduling. Then, the rollback permission is granted, allowing the process to guide the release operation.

[0091] In the second scenario, i.e., the branch that refuses to roll back, if the representative value is lower than the minimum useful release time mentioned above, it means that the remaining window has been severely occupied by the system's bidirectional switching time. In this situation, the system determines that performing the undo action will cause ineffective fluctuations and resource waste, and then locks the current state machine, keeping the original ready state unchanged, thus shielding the fluctuations caused by the predicted rollback.

[0092] The minimum useful release duration is a pre-configured system parameter, and its value should not be less than the time overhead required for the system to perform a complete scheduling and allocation action (including communication handshake and context switching). The specific value should be determined by those skilled in the art based on the allocation response time of the actual scheduling system.

[0093] The determination of the minimum useful release duration must meet the following constraints: its value should not be less than the sum of the communication handshake time and context switch time required for the scheduling system to complete one resource reallocation, so that the release window has actual resource reuse value. Those skilled in the art can determine this parameter based on the actual allocation response time measurement of the target scheduling system. When the ratio is greater than or equal to the preset safety ratio, the system is determined to be in or about to enter an overload risk zone, and ready resources are activated, the routing table is updated, and external client requests are allowed to flow into the target node.

[0094] Step 408: From the candidate rollback states that meet the pre-configured gating conditions, based on the pre-recorded amount of releasable resources corresponding to each candidate rollback state, select the rollback target state with the largest amount of released resources, and send the rollback release instruction to the resource node to roll back to the target state.

[0095] For the available set that passes the time-gated check, a deep optimization logic is executed. The available unbindable computing power or storage unit quotas for each node within the set are read, and the target is locked onto the deepest candidate state capable of releasing the maximum resource output. After the decision is finalized, the system reassembles the control message and sends a rollback release instruction carrying the updated target parameters to the underlying execution entity, driving the physical layer to release excess reservations.

[0096] By introducing the next-state recovery boundary and deducting the time consumed by bidirectional physical reset, a round-trip margin with absolute physical significance is calculated. This method upgrades the traditional blind debouncing based on a fixed cooling window to dynamic gating based on the actual available release time, suppressing invalid rollback instructions with no actual scheduling reuse value. At the same time, since the forward migration constraint described in step 301 requires nodes not to cross intermediate states and to meet the dual matching conditions of version number and expected predecessor state, the time window constraint imposed on the reverse operation by the gating rollback mechanism in this step reduces the risk of conflict caused by concurrent forward / reverse instructions competing for the same intermediate state in the underlying hardware resource state machine.

[0097] Unlike existing technologies that use a fixed cooling time window to prevent frequent rollbacks, the above method dynamically calculates the actual available release window based on the actual physical round-trip time and performs gating judgment.

[0098] Example 5: Further explanation of the offline closed-loop update and distribution degradation strategy for historical samples.

[0099] As a data foundation supporting the accuracy of the entire reserved scheduling system, in one possible implementation, the predicted scenario data and the corresponding stage preparation time, rollback time and reconstruction time are obtained by extracting from the pre-stored historical observation sample set. The historical observation sample set is updated in a closed loop as follows: Step 501: After the peak computing power tide ends and the resource release is completed, extract the corresponding actual peak deviation and the measured time consumption of each stage. Once the monitoring system determines that the actual load has been continuously lower than the pre-set exit threshold during the business cycle, the gateway component cuts off the access channel for new traffic.

[0100] When existing services have finished running or reached a migrateable state, the controller calls the state machine reverse interface and executes unloading, memory clearing, and computing slot return step by step according to the revocable order specified in the resource state template.

[0101] In the process of business migration and degradation, an extended alternative scheduling strategy is provided. The scheduling center can take over the remaining offline computing tasks in standby status by adopting cross-regional heterogeneous resource packing algorithm or energy scheduling strategy based on electricity price trough perception, so as to optimize energy consumption costs.

[0102] After the physical entity unbinding operation is completed, the raw log data of this operation cycle is parsed, and the time difference between the peak arrival time output by the prediction model and the actual traffic surge time is extracted to form the actual peak deviation parameter. At the same time, based on the runtime stamp records fed back by each computing node, the independent physical time slices corresponding to the forward loading, reverse release and reconstruction operations are quantified and extracted, and recorded as the measured time consumption.

[0103] Step 502: Bind the actual peak deviation to the resource pressure corresponding to the measured time at the time of occurrence in a hierarchical manner, and write it into the pre-stored historical observation sample set.

[0104] If the extracted time metric data is removed from the resource context at the time of execution, it will lose its guiding value for similar scenarios in the future.

[0105] When the acquisition system generates the aforementioned time-consuming records, it identifies global hardware load metrics, such as the overall CPU utilization or mirror storage queue depth, and maps them to structured resource pressure hierarchical labels.

[0106] Perform a context association operation to encapsulate the independently extracted time feature data and the corresponding load labels into a joint feature entity.

[0107] After the association and binding are completed, the verified joint feature entities are appended and stored in the pre-configured long-term storage medium of the system, forming the pre-stored historical observation sample set. By performing offline data writing, a data iteration closed loop is provided for the joint scenario prediction sample model required for subsequent prediction and control cycles.

[0108] Specifically, the extraction of the corresponding stage preparation time, rollback time, and reconstruction time from a pre-stored historical observation sample set includes: Step 503: When the number of valid samples in the pre-stored historical observation sample set of the target resource pressure stratification is lower than the preset sample size threshold, the target resource pressure stratification is merged with the adjacent pressure stratification to obtain the merged sample distribution; when the number of valid samples is not lower than the preset sample size threshold, the samples corresponding to the target resource pressure stratification are used as the merged sample distribution. Before initiating a new round of tiered reservation time calculations, the system sends a retrieval command to the database engine to obtain prior data. Considering the rarity of specific high-load concurrency states, the number of valid sample entries accumulated within individual target resource pressure tiers may be insufficient.

[0109] The number of extracted valid sample entries is compared with the preset sample size threshold, which can be configured to be 50 or 100. If a shortage of data is detected, the data control module will not perform high-dimensional fitting inference operations, but will instead trigger a robust degradation response action, merging the sample group of the current query dimension upwards or expanding it to adjacent pressure layers with similar physical load characteristics, thereby expanding the data pool base.

[0110] Step 504: Based on the merged sample distribution, extract the order statistic with the longer processing time as the corresponding stage preparation time, rollback time, or reconstruction time. The order statistic with the longer processing time is either an order statistic biased towards the high-time-consuming side or an order statistic with a high quantile.

[0111] For the expanded sample space that has undergone stress stratification and merging, the system regenerates the empirical cumulative distribution sequence. To prevent the system from generating overly optimistic resource startup configurations when sample evidence is insufficient, this data degradation strategy introduces a time safety margin mechanism.

[0112] When extracting time index parameters, the order statistic of the long-tailed, high-time-consuming side of the skewed distribution curve is selected as a safety baseline, replacing the conventional median or mean calculation logic. The aforementioned conservative time index is extracted and defined as the stage preparation time, the rollback time, or the reconstruction time that must be referenced in subsequent prediction cycles.

[0113] By employing a conservative value selection mechanism, the data model reduces the risk of delayed system command issuance caused by missing local features, ensuring the robustness of the tidal reservation architecture under small sample edge conditions.

[0114] By binding the actual pressure layer back to the measured time after the peak ends and introducing a conservative degradation mechanism to merge adjacent pressure layers, the estimated time under extreme edge load conditions of the system still has a safe baseline support, which improves the robustness of the global data base and the rigor of time series calculation in complex business environments.

[0115] Assume a resource batch contains four migration preparations, with a control and routing latency of five seconds, resulting in ten joint scenarios. The peak arrival times for the ten scenarios are 600, 620, 590, 610, 605, 615, 595, 625, 585, and 630 seconds, respectively. The time consumption samples for the four stages are taken from the resource pressure records of the same scenario.

[0116] After reverse calculation using the aforementioned formula, the median reference time for the five time series boundaries is: [402, 410, 510, 570, 600] s; The ten joint bottleneck offsets are: [-5,0,-15,0,-25,10,-47,20,-36,15]s; If the on-time readiness ratio of the stage chain is 0.8 and the sample size is 10, then the single-sided order position is: r=[0.8×10]=8,k=10 8 + 1 = 3; The third value after sorting the joint bottleneck offset in ascending order is -25s, therefore the tiered commitment time is: [402,410,510,570,600]+[-25,-25,-25,-25,-25]=[377,385,485,545,575]s; The timing sequence is strictly non-decreasing. Eight out of the ten joint scenarios have a joint bottleneck offset of at least -25 seconds; therefore, all eight scenarios simultaneously satisfy all five boundaries, resulting in an empirical coverage ratio of exactly 0.8. The computation incorrectly concatenates favorable scenarios selected separately at different stages into a single, non-existent joint scenario.

[0117] In some scenarios, assuming the current time is 300 seconds, resources are in the second ready state, and the new prediction gives a second-state recovery boundary of 480 seconds. After subtracting the rollback and reconstruction times for ten scenarios, the round-trip margin is: [72,60,76,64,55,68,51,82,59,65]s; The rollback recovery ratio is set to 0.8. Selecting the third value in ascending order within the same single-sided sequence yields 59 seconds. If the minimum useful release time is 30 seconds, then 59 seconds is not less than 30 seconds, and rollback is permitted.

[0118] If the next prediction advances the recovery boundary to 430 seconds again, with other time consumption remaining unchanged, the round-trip margin becomes: [22,10,26,14,5,18,1,32,9,15]s; The third value in ascending order is nine seconds, which is less than thirty seconds, and the controller maintains the current state. This shows that the same candidate state will not mechanically revert to a simple change in predicted direction, but rather the decision is made based on whether an actual usable window exists after the revert.

Claims

1. A method for hierarchical resource reservation and state control in a computing power tidal scenario, characterized in that, include: Acquire joint prediction scenario data, including predicted peak arrival time, stage preparation time, rollback time, and reconstruction time; The hierarchical commitment sequence of resource batches is determined based on the jointly predicted scenario data; When the control time reaches the commitment time corresponding to the current preparation state in the hierarchical commitment timing, a positive migration instruction is issued to the resource node; In response to the state rollback requirement, the actual available release duration of the candidate rollback state is determined by using the next state recovery boundary in the hierarchical commitment timing, combined with the rollback time and the reconstruction time. When the actual available release duration meets the pre-configured gating conditions, a rollback release command is issued to the resource node; otherwise, the current ready state of the resource node remains unchanged.

2. The method according to claim 1, characterized in that, Determining the hierarchical commitment time series of resource batches based on the jointly predicted scenario data includes: The latest start boundary of each stage in each prediction scenario is inferred by using the joint prediction scenario data. The common offset is determined based on the latest start boundary at the scene level; The hierarchical commitment timing is generated using the common offset.

3. The method according to claim 2, characterized in that, Using the jointly predicted scenario data, the latest start boundary of each stage in each predicted scenario is inferred, specifically as follows: The scenario-level latest start boundary is obtained by subtracting the pre-configured control delay and the cumulative value of the stage preparation time corresponding to the current stage to the final stage from the predicted peak arrival time.

4. The method according to claim 2, characterized in that, Determining the common offset based on the latest start boundary at the scene level includes: Calculate the median reference time of the latest start boundary at the scene level for the same stage across all predicted scenarios; Within the same prediction scenario, calculate the minimum offset of the latest start boundary at the scenario level relative to the corresponding median reference time for all stages. According to the pre-configured stage chain joint readiness ratio, the one-sided order statistic of the minimum offset is selected as the common offset. Specifically, the generation of the hierarchical commitment time series using the common offset is as follows: The median reference time is added to the common offset to obtain the hierarchical commitment time series.

5. The method according to claim 1, characterized in that, Issue forward migration instructions to resource nodes, specifically including: The forward migration instruction issued to the resource node requires the resource node to perform physical resource preparation actions such as quota locking, runtime startup, or image loading step by step without skipping intermediate states.

6. The method according to claim 1, characterized in that, Prior to responding to the state rollback request, it also includes: Obtain the target state corresponding to the prediction update and the current actual state; When the target state is lower than the current actual state, the state rollback requirement is triggered; Among the intermediate states corresponding to the current actual state and the target state, states with non-cancellable operations are eliminated to determine the candidate rollback states.

7. The method according to claim 6, characterized in that, Using the next-state recovery boundary in the hierarchical commitment timeline, and combining the rollback time and the reconstruction time, the actual available release duration of the candidate rollback state is determined, specifically as follows: Obtain the next state recovery boundary corresponding to the current preparation state from the hierarchical commitment timing; The round-trip margin is obtained by subtracting the current time, the corresponding rollback time, and the reconstruction time from the next state recovery boundary in sequence, and the round-trip margin is used as the actual available release time.

8. The method according to claim 7, characterized in that, When the actual available release duration meets the pre-configured gating conditions, a rollback release instruction is issued to the resource node, including: The order statistics of the round-trip margin corresponding to the same candidate rollback state under different prediction scenarios are selected as representative values. When the representative value is greater than or equal to the pre-configured minimum useful release duration, it is determined that the pre-configured gating condition is met. From the candidate rollback states that meet the pre-configured gating conditions, select the rollback target state with the largest amount of released resources, and issue a rollback release command to the resource node to roll back to the rollback target state.

9. The method according to claim 1, characterized in that, The joint prediction scenario data is obtained by extracting from a pre-stored historical observation sample set; the historical observation sample set is updated in a closed loop as follows: After the peak computing power surge ends and resources are released, the corresponding actual peak deviation and the measured time consumption of each stage are extracted. The actual peak deviation and the measured time consumption are hierarchically bound to the resource pressure corresponding to the occurrence, and written into the pre-stored historical observation sample set.

10. The method according to claim 9, characterized in that, The preparation time, rollback time, and reconstruction time for the aforementioned stages are obtained by extracting data from a pre-stored historical observation sample set. Specifically, this includes: When the number of valid samples in the pre-stored historical observation sample set of the target resource pressure stratification is lower than the preset sample size threshold, the target resource pressure stratification will be merged with the adjacent pressure stratification. Based on the merged sample distribution, the order statistic with the longer processing time is extracted as the corresponding stage preparation time, rollback time, or reconstruction time.

Images