A Dynamic Weighted Resource Allocation Method Based on FIFO Queues

Abstract

This invention discloses a dynamic weighted resource allocation method based on a FIFO queue, relating to the field of resource scheduling technology. The method includes: S1, real-time collection of connection queue monitoring data and preprocessing of the data; S2, identification of pre-order blocking requests corresponding to each request and further calculation of the pre-order blocking propagation value; S3, calculation of connection contention constraint values ​​corresponding to each request, and determination of the blocking type for each request based on the pre-order blocking propagation value; S4, calculation of the FIFO order compensation value and dynamic weight allocation value corresponding to each request, determination of the priority request set for this round, and then, based on the blocking type, execution of connection acquisition qualification allocation and generation of the next round's priority retention flag, outputting dynamic weighted resource allocation data. This method solves the problem of inaccurate characterization of pre-order blocking propagation in existing shared connection resource allocation processes, leading to an imbalance in connection acquisition qualification allocation under a FIFO queue.

Description

Technical Field

[0001] This invention relates to the field of resource scheduling technology, specifically to a dynamic weighted resource allocation method based on a FIFO queue. Background Technology

[0002] With the widespread deployment of database connection pools, transaction processing engines, application service thread pools, and distributed storage-related data processing architectures in high-concurrency scenarios, queue scheduling and resource allocation mechanisms for shared connection resources have gradually become an important research direction in resource management technology. Especially in operating environments with multiple concurrent requests, limited connection resources, and significant fluctuations in lock waiting, dynamically adjusting resource allocation order based on request queuing status, contention status, and system feedback has become a crucial technical path to improve connection utilization efficiency, mitigate congestion propagation, and maintain service stability. To address these needs, various resource management solutions based on weight updates, resource prediction, queue scheduling, and dynamic allocation have emerged in existing technologies.

[0003] For example, application CN120909763A discloses an online resource allocation method and system based on multiplicative weight updates, belonging to the field of computer resource scheduling technology. To address the problems of low resource utilization, difficulty in guaranteeing service quality, and limited feedback information in multi-user shared scenarios, this invention mainly adopts a multiplicative weight update strategy based on binary queue states, combined with a truncated simplex projection mechanism to dynamically adjust the resource allocation ratio.

[0004] For example, application CN108121601B discloses a weighted application resource scheduling device and method, belonging to the field of big data application processing technology. The resource scheduling device of this invention includes an application request receiving module, a resource prediction module, a process acquisition module, a resource scheduling module, and a recycling module. The resource prediction module is used to acquire the load characteristics of I / O application requests and calculate the read / write operation threshold of the I / O application load. The process acquisition module is used to acquire the read / write operation values ​​processed by process n to obtain the read / write operation value of the nth process (n≥1). The resource scheduling module is used to perform process resource scheduling based on the read / write operation threshold of the I / O application load and the acquired read / write operation value of the nth process.

[0005] However, most existing technologies focus on dynamically adjusting resource allocation ratios based on weights, load characteristics, or feedback results, paying more attention to improving overall resource utilization or optimizing local service quality. They lack specific characterization of the blocking propagation relationship between preceding and subsequent requests in FIFO queue scenarios, making it difficult to identify the impact of preceding blocking caused by persistent preceding connection constraints, delayed transaction commits, or lock wait propagation. Furthermore, existing technologies typically do not integrate connection contention states and FIFO priority constraints into the same resource allocation mechanism, easily leading to situations where subsequent requests cross excessively long priority levels to compete, first-arriving requests remain indefinitely, or highly contentious requests repeatedly occupy processing opportunities. This makes it difficult to balance FIFO priority constraints, connection contention suppression, and dynamic weight allocation.

[0006] Therefore, to address the above issues, there is an urgent need for a dynamic weighted resource allocation method based on FIFO queues. Summary of the Invention

[0007] Technical problems to be solved To address the shortcomings of existing technologies, this invention provides a dynamic weighted resource allocation method based on a FIFO queue, which solves the problem that the pre-order blocking propagation in the existing shared connection resource allocation process is difficult to accurately characterize, leading to an imbalance in the allocation of connection acquisition qualifications under the FIFO queue.

[0008] Technical solution To achieve the above objectives, the present invention provides the following technical solution: a dynamic weighted resource allocation method based on a FIFO queue, comprising: S1, collecting connection queue monitoring data, and performing time synchronization, missing data completion, anomaly removal, timing suppression, and numerical normalization processing on the connection queue monitoring data, and outputting preprocessed connection queue monitoring data; S2, generating a FIFO request sequence and connection constraint interval based on the preprocessed connection queue monitoring data, identifying the pre-order blocking requests corresponding to each request, calculating the number of pre-order blocking requests, the blocking release interval, and the blocking propagation span, and further calculating the weight of each request. S3, calculate the connection contention constraint value corresponding to each request based on the preprocessed connection queue monitoring data, and determine the blocking type corresponding to each request in combination with the preprocessed blocking diffusion value, and output FIFO blocking constraint data; S4, calculate the FIFO order compensation value and dynamic weight allocation value corresponding to each request based on the FIFO blocking constraint data and the preprocessed connection queue monitoring data, construct the FIFO order constraint allocation window for this round and determine the priority processing request set for this round, and then perform connection acquisition qualification allocation and next round priority retention mark generation in combination with the blocking type, and output dynamic weight resource allocation data.

[0009] Further, the specific steps for collecting connection queue monitoring data and performing time synchronization, missing data completion, anomaly removal, timing suppression, and numerical normalization on the connection queue monitoring data are as follows: Real-time collection of connection queue monitoring data, including request arrival timestamp, request enqueue timestamp, connection acquisition start timestamp, connection acquisition completion timestamp, transaction commit timestamp, queue length at enqueue time, total number of connections in the connection pool, number of idle connections in the connection pool, number of connection requests waiting in the connection pool, number of active database transactions, and number of database lock waiting transactions; For the collected connection queue monitoring data, multi-source time base synchronization processing is performed using a precise time protocol synchronization algorithm; missing data completion processing is performed using a Kalman filter interpolation algorithm; anomaly identification and removal processing is performed using a Hample filter anomaly detection algorithm; timing jitter suppression processing is performed using an exponentially weighted moving average filter algorithm; and numerical scale unification processing is performed using a minimum-maximum normalization algorithm, outputting the preprocessed connection queue monitoring data.

[0010] Furthermore, the specific steps for generating the FIFO request sequence and connection constraint interval based on the preprocessed connection queue monitoring data are as follows: Based on the preprocessed connection queue monitoring data, all records are rearranged in ascending order according to the request enqueue timestamp; when the request enqueue timestamps are the same, they are arranged in ascending order according to the request arrival timestamp to generate the FIFO request sequence; then, the connection acquisition start timestamp and transaction commit timestamp corresponding to each request in the FIFO request sequence are read one by one, and the connection acquisition start timestamp is used as the start time of the connection constraint interval, and the transaction commit timestamp is used as the end time of the connection constraint interval to construct the connection constraint interval corresponding to each request.

[0011] Further, the specific steps for identifying the preceding blocking requests corresponding to each request and calculating the number of preceding blocking requests, the blocking release interval, and the blocking propagation span are as follows: Read all connection constraint intervals preceding the current request one by one along the FIFO request sequence. When the transaction commit timestamp of a preceding request is greater than the connection acquisition start timestamp of the current request, the preceding request is identified as a preceding blocking request of the current request. Then, count the number of preceding blocking requests corresponding to the current request and extract the latest transaction commit timestamp and the earliest preceding blocking request's position in the FIFO request sequence from all preceding blocking requests. When the current request has no preceding blocking requests, record the number of preceding blocking requests, the blocking release interval, and the blocking propagation span corresponding to the current request as zero. When the current request has preceding blocking requests, subtract the connection acquisition start timestamp of the current request from the latest transaction commit timestamp to obtain the blocking release interval. The blocking propagation span is obtained by comparing the current request's position in the FIFO request sequence with the earliest preceding blocking request's position in the FIFO request sequence.

[0012] Furthermore, the specific steps for calculating the pre-order blocking diffusion value for each request are as follows: add one to the number of pre-order blocking requests and take the natural logarithm to obtain the blocking quantity diffusion term; add one to the blocking release interval and take the square root to obtain the blocking duration diffusion term; add one to the blocking propagation span and take the natural logarithm to obtain the blocking span diffusion term; multiply the blocking quantity diffusion term, the blocking duration diffusion term, and the blocking span diffusion term to obtain the pre-order blocking diffusion value.

[0013] Further, the specific steps for calculating the connection contention constraint value corresponding to each request based on the preprocessed connection queue monitoring data are as follows: Extract the number of connection requests waiting in the connection pool, the number of idle connections in the connection pool, the number of database lock waiting transactions, and the number of active database transactions for each request; add one to the number of connection requests waiting in the connection pool to obtain the contention demand item; add one to the number of idle connections in the connection pool to obtain the idle supply item; divide the contention demand item by the idle supply item to obtain the basic connection contention item; divide the number of database lock waiting transactions by the number of active database transactions plus one to obtain the lock wait diffusion item; add one to the lock wait diffusion item to obtain the lock wait correction item; multiply the basic connection contention item and the lock wait correction item to obtain the corresponding connection contention constraint value.

[0014] Furthermore, the specific steps for determining the blocking type of each request and outputting FIFO blocking constraint data based on the pre-order blocking diffusion value are as follows: When the pre-order blocking diffusion value is greater than the connection contention constraint value, the corresponding request is marked as a pre-order blocking dominant request; when the pre-order blocking diffusion value is less than or equal to the connection contention constraint value, the database lock waiting transaction count and connection pool idle connection count in the previous K records to the record corresponding to the current request are read; when there are fewer than K records before the current request, all records before the current request and the record corresponding to the current request are used as the judgment record sequence; for the judgment record sequence, when the database lock waiting transaction count in the subsequent record is greater than the database lock waiting transaction count in the previous record, and the connection pool idle connection count in the subsequent record is greater than or equal to the connection pool idle connection count in the previous record, the corresponding request is marked as a lock waiting diffusion request. The process involves several steps: First, if the number of idle connections in the connection pool of a subsequent record is less than the number of idle connections in the connection pool of a preceding record, and the number of database lock waiting transactions in the subsequent record is less than or equal to the number of database lock waiting transactions in the preceding record, the corresponding request is marked as a connection squeezing request. Second, if the number of database lock waiting transactions in the subsequent record is greater than the number of database lock waiting transactions in the preceding record, and the number of idle connections in the connection pool of the subsequent record is less than the number of idle connections in the connection pool of the preceding record, the corresponding request is marked as a composite contention request. Otherwise, the corresponding request is marked as a non-blocking request. A blocking type marker sequence is then generated. Finally, the FIFO blocking constraint data is output by combining the preceding blocking diffusion value, connection contention constraint value, and blocking type marker sequence corresponding to each request according to the FIFO request sequence.

[0015] Furthermore, the specific steps for calculating the FIFO order compensation value and dynamic weight allocation value corresponding to each request based on the FIFO blocking constraint data and the preprocessed connection queue monitoring data are as follows: Add one to the queue length value corresponding to the request when it is enqueued, then divide by the order of the request in the FIFO request sequence plus one to obtain the order compensation ratio; add one to the order compensation ratio and take the natural logarithm to obtain the order compression term; add one to the pre-order blocking diffusion value and take the square root to obtain the blocking diffusion compensation term; multiply the order compression term and the blocking diffusion compensation term to obtain the FIFO order compensation value; add one to the connection contention constraint value and take the natural logarithm to obtain the contention suppression term; divide the FIFO order compensation value by the sum of the contention suppression term and one to obtain the dynamic weight allocation value.

[0016] Further, the specific steps for constructing the FIFO order constraint allocation window and determining the priority request set for this round are as follows: Read the blocking type flags corresponding to each request continuously from the head of the FIFO request sequence; count the number of consecutive non-non-blocking requests starting from the head of the queue to obtain the header blocking segment length; add the header blocking segment length to the current number of idle connections in the connection pool to obtain the FIFO order constraint allocation window length for this round; extract consecutive requests corresponding to the FIFO order constraint allocation window length according to the FIFO request sequence, and arrange them in descending order according to the dynamic weight allocation value; when the dynamic weight allocation values ​​are the same, arrange them in ascending order according to their order in the FIFO request sequence; then select requests sequentially from the sorted results according to the number of idle connections in the current connection pool to determine the priority request set for this round.

[0017] Furthermore, the specific steps for outputting dynamic weighted resource allocation data, combining the allocation of connection acquisition eligibility based on blocking type and the generation of priority retention flags for the next round, are as follows: For the current round of priority processing request set, when the request is a pre-order blocking dominant request, a connection squeezing request, or a non-blocking request, connection acquisition eligibility is directly allocated; when the request is a lock wait diffusion request or a composite contention request, the allocation of connection acquisition eligibility for the current request is suspended, and a priority retention flag for the next round is generated; for requests that generate priority retention flags for the next round, the corresponding consecutive retention rounds are recorded; when the consecutive retention rounds are less than the preset retention limit, and the connection contention constraint value corresponding to the current round is greater than the connection contention constraint value corresponding to the previous round, the next round of priority retention is determined. When competing for constraint values, maintain the priority retention flag for the next round; when the number of consecutive retention rounds reaches the preset retention limit, or when the connection competition constraint value corresponding to the current round is less than or equal to the connection competition constraint value corresponding to the previous round, cancel the priority retention flag for the next round, and use the corresponding request as the normal processing input for the next round FIFO priority constraint allocation window; establish the correspondence between request identifiers and dynamic weight allocation values, blocking type flags, next round priority retention flags, and connection acquisition qualification allocation results, and generate dynamic weight resource allocation data; and at the start of the next round of resource allocation, prioritize reading requests with the next round priority retention flag and participate in the construction of the next round FIFO priority constraint allocation window.

[0018] Beneficial effects The present invention has the following beneficial effects: (1) A dynamic weighted resource allocation method based on FIFO queue, by constructing the correlation between the number of prior blocking requests, the blocking release interval and the blocking propagation span, and further calculating the prior blocking diffusion value, can characterize the blocking propagation process of the prior request to the subsequent request from the inside of the FIFO request sequence, and no longer make a rough judgment based solely on the queue length or waiting time, thereby improving the pertinence and accuracy of shared connection resource blocking identification.

[0019] (2) A dynamic weighted resource allocation method based on FIFO queue. By introducing connection competition constraint values ​​and performing joint constraint analysis on the number of connection pool waiting connection requests, the number of idle connections in the connection pool, the number of database lock waiting transactions, and the number of active database transactions, it can distinguish different blocking types such as pre-order blocking dominance, lock waiting diffusion, connection squeezing, and compound competition, thereby enabling the resource allocation process to have a more granular competition state identification capability.

[0020] (3) A dynamic weighted resource allocation method based on FIFO queue. By constructing a FIFO order constraint allocation window, the dynamic weight competition is limited to the range of continuous requests corresponding to the head blocking segment, avoiding subsequent requests from directly participating in resource preemption by crossing too long order. Dynamic weight allocation is achieved while maintaining FIFO order constraint, thus taking into account both order fairness and resource allocation flexibility.

[0021] (4) A dynamic weighted resource allocation method based on FIFO queue, by setting a priority retention flag for the next round, does not directly push lock waiting diffusion requests and compound contention requests into the current round of connection acquisition qualification allocation, but processes them first in subsequent rounds, which can suppress the continuous amplification of blocking under high contention state, reduce the risk of local congestion accumulation in the connection resource allocation process, and thus improve the stability of overall resource scheduling. Attached Figure Description

[0022] Figure 1 This is a flowchart of a dynamic weighted resource allocation method based on a FIFO queue. Figure 2 This is a schematic diagram of FIFO pre-blocking propagation; Figure 3 This is a schematic diagram of FIFO blocking constraints and dynamic weight resource allocation. Detailed Implementation

[0023] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0024] Please see Figures 1-3This invention provides a technical solution: a dynamic weighted resource allocation method based on a FIFO queue, comprising: S1, collecting connection queue monitoring data, and performing time synchronization, missing data completion, anomaly removal, timing suppression, and numerical normalization processing on the connection queue monitoring data, and outputting preprocessed connection queue monitoring data; S2, generating a FIFO request sequence and connection constraint interval based on the preprocessed connection queue monitoring data, identifying the pre-order blocking requests corresponding to each request, calculating the number of pre-order blocking requests, the blocking release interval, and the blocking propagation span, and further calculating the pre-order blocking diffusion value of each request; S3, calculating the connection contention constraint value corresponding to each request based on the preprocessed connection queue monitoring data, and determining the blocking type corresponding to each request in combination with the pre-order blocking diffusion value, and outputting FIFO blocking constraint data; S4, calculating the FIFO order compensation value and dynamic weight allocation value corresponding to each request based on the FIFO blocking constraint data and the preprocessed connection queue monitoring data, constructing the FIFO order constraint allocation window for this round and determining the priority processing request set for this round, and then performing connection acquisition qualification allocation and next round priority retention mark generation in combination with the blocking type, and outputting dynamic weighted resource allocation data.

[0025] Specifically, the steps for collecting connection queue monitoring data and performing time synchronization, missing data completion, anomaly removal, timing jitter suppression, and numerical scaling on the connection queue monitoring data are as follows: Real-time collection of connection queue monitoring data, including request arrival timestamp, request enqueue timestamp, connection acquisition start timestamp, connection acquisition completion timestamp, transaction commit timestamp, queue length at enqueue time, total number of connections in the connection pool, number of idle connections in the connection pool, number of connection requests waiting for connection requests in the connection pool, number of active database transactions, and number of database lock waiting transactions; The request arrival timestamp is obtained by writing a receive event record to each request entering the processing link at the application access layer, and is used to characterize the time it takes for a request to enter the processing link. The original arrival time provides a time basis for refining the FIFO request sequence according to the order of request arrivals. The request enqueue timestamp is obtained by recording the enqueue event when the FIFO queue is written, and is used to characterize the start time of the queue entry of the request, thus providing a queue timing basis for generating the FIFO request sequence and calculating the pre-order blocking propagation relationship. The connection acquisition start timestamp is obtained by recording the borrow start event before the connection request call is executed in the connection pool, and is used to characterize the moment when the request begins to request connection resources, thus providing a comparison benchmark for identifying whether the preceding request has caused pre-order blocking of the current request. The connection acquisition completion timestamp is recorded by recording the borrow completion event after the connection pool returns an available connection. The following data is collected: the transaction commit timestamp, which is used to characterize the moment when a request successfully occupies connection resources, thus providing the starting boundary for subsequently building connection constraint intervals; the transaction commit timestamp, which is collected by writing the commit completion event record after the transaction manager completes the commit action, and is used to characterize the moment when the transaction ends before the connection resources are released, thus providing the ending boundary for subsequently building connection constraint intervals and calculating blocking release intervals; the queue length value during enqueueing, which is collected by reading the FIFO queue length counter at the moment the request is enqueued, and is used to characterize the queuing pressure level at the moment the request enters the queue, thus providing a basis for subsequently calculating the FIFO order compensation value; and the total number of connections in the connection pool, which is collected by reading the total connection count field in the connection pool operation monitoring interface. The connection pool is collected by reading the idle connection count field from the connection pool operation monitoring interface. This data represents the current available connection resource capacity boundary, providing a capacity benchmark for subsequently characterizing the upper limit of connection resource supply and calculating connection contention constraint values. The number of idle connections in the connection pool is collected by reading the idle connection count field from the connection pool operation monitoring interface. This data represents the remaining amount of connection resources that are not currently occupied, providing a basis for subsequently determining the degree of connection congestion and constructing the FIFO priority constraint allocation window for this round. The number of connection requests waiting in the connection pool is collected by reading the waiting borrow count field from the connection pool operation monitoring interface. This data represents the request pressure that is currently in a connection waiting state, providing a demand-side basis for subsequently characterizing the degree of connection application congestion and calculating connection contention constraint values.The number of active database transactions is collected by reading the number of transaction entries in the execution state from the database running status view. It is used to characterize the transaction load level inside the database at the current moment, thus providing a basis for the running load to characterize the transaction background of lock wait propagation. The number of database lock wait transactions is collected by reading the number of transaction entries in the lock blocking state from the database lock monitoring view. It is used to characterize the degree of blocking caused by lock contention inside the database at the current moment, thus providing a basis for the lock contention to determine lock wait propagation requests and compound contention requests. For the collected connection queue monitoring data, a precise time protocol synchronization algorithm is used to perform multi-source time base synchronization processing. During processing, a precise time protocol synchronization client is first deployed on the application access node, queue node, connection pool node, and database node respectively. Then, the offset of the local clock of each node relative to the master clock is read periodically. The clock offset of the corresponding node is subtracted from the request arrival timestamp, request enqueue timestamp, connection acquisition start timestamp, connection acquisition completion timestamp, and transaction commit timestamp to obtain the corrected timestamp under a unified master clock base. The technical principle of this processing is to eliminate the time misalignment caused by cross-node clock drift by unifying the time reference system of different acquisition sources. Its function is to ensure that there is a directly comparable order among the request arrival timestamp, request enqueue timestamp, connection acquisition start timestamp, connection acquisition completion timestamp, and transaction commit timestamp, thereby avoiding FIFO request sequence distortion, connection constraint interval construction errors, and pre-order blocking identification deviations caused by inconsistent clocks of acquisition nodes. Kalman filter interpolation algorithm is used to perform missing data completion processing. During processing, a state vector is established according to the sampling order: queue length at enqueue time, total number of connections in the connection pool, number of idle connections in the connection pool, number of connection requests waiting in the connection pool, number of active transactions in the database, and number of transactions waiting for database locks. The estimated value at the previous sampling time is used as the predicted value, and the currently available sample value is used as the observation value to perform recursive update calculation. When a sample item is missing, the updated estimated value is used to fill the missing position. For timestamp items, the known timestamp records in adjacent sampling periods are used as the state prediction boundary, and the missing request arrival timestamp, request enqueue timestamp, connection acquisition start timestamp, connection acquisition completion timestamp, and transaction commit timestamp are filled in by combining the position relationship of the current request in the FIFO request sequence.The technical principle of this processing lies in using the recursive correction mechanism between the previous state estimate and the current observation to make a smooth estimate of short-term missing data. Its function is to maintain the continuity of connection queue monitoring data in the time dimension, thereby avoiding interruption of the statistics of the number of pre-order blocking requests, offset of connection contention constraint value calculation, and distortion of FIFO order compensation value due to missing monitoring data. An anomaly detection algorithm using the Hample filter is employed to identify and remove abnormal data. During processing, a sliding window iterates through the queue length at the time of enqueueing, the total number of connections in the connection pool, the number of idle connections in the connection pool, the number of connection requests waiting in the connection pool, the number of active transactions in the database, and the number of transactions waiting for database locks. First, the median of the window is calculated, then the median absolute deviation is calculated. When the deviation of the current sampled value from the median of the window exceeds a preset multiple of the median absolute deviation, the current sampled value is marked as an anomaly and the corresponding record is deleted. For timestamp items, if the request enqueue timestamp after time synchronization is earlier than the request arrival timestamp, if the connection acquisition completion timestamp is earlier than the connection acquisition start timestamp, or if the transaction commit timestamp is earlier than the connection acquisition completion timestamp, the corresponding record is determined to be an anomaly and removed. The technical principle of this processing lies in using the median statistic's insensitivity to extreme values ​​to identify sudden abnormal sampling points. Its function is to remove abnormal records caused by sampling jitter, instantaneous anomalies in the monitoring interface, and record write errors, thereby preventing anomalies from amplifying the calculation results of pre-order blocking diffusion values, connection contention constraint values, and dynamic weight allocation values. An exponentially weighted moving average filtering algorithm is used to perform time-series jitter suppression processing. During processing, the queue length at the time of enqueueing, the total number of connections in the connection pool, the number of idle connections in the connection pool, the number of connection requests waiting in the connection pool, the number of active transactions in the database, and the number of transactions waiting for database locks are used as time-series sequence inputs. The current smoothed output value is calculated recursively according to the sampling order. The current smoothed output value is equal to the current sampled value multiplied by the smoothing coefficient, plus the smoothed output value of the next time step multiplied by the compensation coefficient. The timestamp item retains the correction result after time synchronization, missing data completion, and anomaly removal are completed, and the exponentially weighted moving average processing is not performed again. The technical principle of this processing is to assign higher weights to newer sampled values ​​and lower weights to earlier sampled values ​​to reduce the interference of short-period fluctuations on the judgment of sequence trend. Its effect is to reduce the impact of instantaneous sampling jitter on the determination of connection competition constraint values, the calculation of the length of the FIFO order constraint allocation window in this round, and the generation of dynamic weight allocation values, so as to make subsequent resource allocation judgments more stable. The minimum-maximum normalization algorithm is used to perform numerical scaling uniformity processing. During processing, the minimum and maximum values ​​of the queue length value when enqueued, the total number of connections in the connection pool, the number of idle connections in the connection pool, the number of connection requests waiting in the connection pool, the number of active transactions in the database, and the number of transactions waiting for database locks in the current processing batch are taken respectively. Then, the minimum value is subtracted from the current value and divided by the difference between the maximum value and the minimum value to obtain the normalization result under the uniform scale.For timestamp items, first calculate the enqueue latency between the request arrival timestamp and the request enqueue timestamp; calculate the connection acquisition duration between the connection acquisition start timestamp and the connection acquisition completion timestamp; calculate the connection constraint duration between the connection acquisition completion timestamp and the transaction commit timestamp. Then, perform minimum-maximum normalization processing on the enqueue latency, connection acquisition duration, and connection constraint duration. The technical principle of this processing is to use the upper and lower bounds in the current processing batch to map data of different orders of magnitude and different units to a unified numerical range, so as to eliminate the differences in units and orders of magnitude between queue length, number of connections, number of transactions, and time interval. Its purpose is to avoid a certain type of large-scale data from forming an unreasonable dominance in the subsequent calculation of pre-order blocking diffusion value, connection contention constraint value, FIFO order compensation value, and dynamic weight allocation value. Finally, the preprocessed connection queue monitoring data is output.

[0026] In this implementation scheme, by uniformly collecting connection queue monitoring data from a unified source, correcting the time base, repairing continuity, cleaning up abnormal records, suppressing temporal fluctuations, and unifying numerical scales, the request arrival timestamp, request enqueue timestamp, connection acquisition start timestamp, connection acquisition completion timestamp, transaction commit timestamp, queue length value at enqueue, total number of connections in the connection pool, number of idle connections in the connection pool, number of connection requests waiting in the connection pool, number of active transactions in the database, and number of transactions waiting for database locks can be organized into preprocessed connection queue monitoring data with consistent temporal relationships, stable numerical states, and unified comparison scales. This allows the present invention to provide a reliable data foundation for subsequent FIFO request sequence generation, connection constraint interval construction, pre-order blocking propagation value calculation, connection contention constraint value determination, FIFO order compensation value calculation, and dynamic weight allocation value generation in distributed storage scenarios, thereby improving the accuracy, stability, and feasibility of identifying pre-order blocking propagation, characterizing connection contention states, and allocating connection acquisition qualifications.

[0027] Specifically, the steps for generating the FIFO request sequence and connection constraint interval based on the preprocessed connection queue monitoring data are as follows: Based on the preprocessed connection queue monitoring data, all records are rearranged in ascending order according to the request enqueue timestamp; during rearrangement, the request enqueue timestamp is extracted from each record, and all records are sorted in ascending order using the request enqueue timestamp as the first sorting criterion, so that records that entered the FIFO queue earlier are prioritized at the front, in order to maintain the original order of requests entering the queue; when the request enqueue timestamps are the same, they are sorted in ascending order according to the request arrival timestamp; during the sorting, the request arrival timestamps are extracted again, and records with the same request enqueue timestamps are sorted in ascending order using the request arrival timestamp as the second sorting criterion. This process involves fine-tuning requests that arrive at the processing link earlier than others at the same enqueue time, prioritizing them to the front and avoiding order confusion caused by identical granularity of enqueue record writing, thus generating a FIFO request sequence. The technical principle behind this process is to first restore the FIFO master order based on the direct time of request entry into the queue, and then refine the relative positions of enqueue records at the same moment based on their original arrival time into the processing link. This ensures that the FIFO request sequence maintains both the accuracy of the queuing sequence and the ability to distinguish records at the same moment, providing a stable priority benchmark for identifying subsequent pre-order blocked requests. Then, the connection acquisition start timestamp and transaction commit timestamp corresponding to each request in the FIFO request sequence are read one by one, using the connection acquisition start timestamp as the starting time of the connection constraint interval. The transaction commit timestamp serves as the end time of the connection constraint interval, constructing the connection constraint interval corresponding to each request. During reading, records are expanded sequentially according to their order in the FIFO request sequence. The connection acquisition start timestamp in each record is used as the starting boundary for the corresponding request to enter the connection request constraint state, and the transaction commit timestamp is used as the ending boundary for the corresponding request to end transaction processing and leave the connection constraint state. Then, the connection acquisition start timestamp and transaction commit timestamp are paired end-to-end according to the same request sequence to form a connection constraint interval uniquely corresponding to that request. The technical principle of the connection constraint interval is that the connection acquisition start timestamp marks the beginning of the connection request process, at which point the current request has already been granted access to the preceding connection resources. The direct impact of the state is that the transaction commit timestamp marks the completion of the transaction processing and the end boundary of the connection constraint in the current round. Therefore, the time range from the connection acquisition start timestamp to the transaction commit timestamp can characterize the complete process of a single request being constrained by connection resources from the connection application stage to the transaction end stage. By constructing the connection constraint intervals corresponding to each request, the order relationship in the FIFO request sequence can be mapped to the connection resource constraint process on a unified time axis. This makes the comparison between the transaction commit timestamp of the subsequent preceding request and the connection acquisition start timestamp of the current request have a unified boundary, thus providing a directly applicable interval basis for calculating the number of preceding blocked requests, the blocking release interval, and the blocking propagation span.

[0028] In this implementation scheme, by performing dual-time-baseline order recovery and connection constraint interval mapping on the preprocessed connection queue monitoring data, the request enqueue timestamp, request arrival timestamp, connection acquisition completion timestamp, and transaction commit timestamp can be organized into a FIFO request sequence and connection constraint interval with clear order relationships, clear constraint boundaries, and stable time correspondence. This allows the request queuing order relationship and the actual constraint process of connection resources to establish a definite correspondence within the same temporal framework. This provides a reliable order and interval basis for subsequent identification of prior blocking requests, calculation of blocking release intervals, calculation of blocking propagation spans, and generation of prior blocking diffusion values, thereby improving the accuracy, stability, and feasibility of this invention in characterizing the blocking propagation relationship in the first-in-first-out queue.

[0029] Specifically, the steps for identifying the preceding blocking requests corresponding to each request and calculating the number of preceding blocking requests, the blocking release interval, and the blocking propagation span are as follows: Read all connection constraint intervals preceding the current request one by one along the FIFO request sequence; during reading, use the current request's position in the FIFO request sequence as the current position, and traverse sequentially from the first record before the current position towards the head of the queue, expanding the connection constraint intervals corresponding to all preceding records sequentially onto the same time axis, so that the end boundary of the connection constraints of the preceding records can be compared one by one with the connection acquisition start timestamp of the current request; when the transaction commit timestamp of a preceding request is greater than the connection acquisition start timestamp of the current request... When the transaction commit timestamp is set, the preceding request is identified as a pre-order blocking request of the current request. The determination is made using the transaction commit timestamp as the end boundary of the connection constraint interval of the preceding request and the connection acquisition start timestamp as the start boundary of the current request's connection resource request. If the end boundary is later than the start boundary, it indicates that the preceding request has not yet completed the connection resource release when the current request initiates the connection request. This preceding request creates a pre-existing connection constraint blocking effect on the current request, thus registering the preceding request that satisfies this determination relationship as a pre-order blocking request of the current request. The number of pre-order blocking requests corresponding to the current request is then counted, and the latest transaction commit timestamp and the latest transaction commit timestamp are extracted from all pre-order blocking requests. The sequence of earlier blocking requests within the FIFO request sequence is used to determine their order. During the counting process, each preceding request that meets the pre-order blocking criteria is counted, forming the number of pre-order blocking requests corresponding to the current request. Then, the record with the largest transaction commit timestamp from all pre-order blocking requests is selected as the latest transaction commit timestamp. Finally, the record with the smallest value from the order of all pre-order blocking requests within the FIFO request sequence is selected as the earliest pre-order blocking request's order within the FIFO request sequence. The technical principle behind this process is that the number of pre-order blocking requests represents the number of preceding sources blocking the current request, and the latest transaction commit timestamp represents the latest release of connection resources among all blocking sources. The ending boundary, the order of the earliest prior blocked request in the FIFO request sequence, is used to characterize the starting position of the blocking propagation chain extending towards the head of the queue; when the current request has no prior blocked requests, the number of prior blocked requests, the blocking release interval, and the blocking propagation span corresponding to the current request are all recorded as zero; when recorded as zero, the current request is marked as a request not affected by the propagation of the preceding connection constraint, so that the current request participates in the calculation of the subsequent prior blocking diffusion value with a zero blocking basis, avoiding the introduction of false diffusion amounts into requests that do not have blocking relationships; when the current request has prior blocked requests, the starting timestamp of the current request is obtained by subtracting the connection of the current request from the latest transaction commit timestamp, and the blocking release interval is obtained.The calculation uses the time when the current request initiates the connection request as the starting boundary and the time when the latest connection resource is released among all prior blocked requests as the ending boundary. The time difference between the two is the duration of the blocking propagation effect on the current request during the connection request phase. The technical principle of this process is to use the latest release boundary to characterize the length of the time constraint that has the strongest impact on the current request among all prior blocking sources. The blocking propagation span is obtained by using the difference between the current request's position in the FIFO request sequence and the earliest prior blocked request's position in the FIFO request sequence. During the calculation, the current request's position and the earliest prior blocked request's position are mapped to the same position coordinate system, and the difference between the two positions represents the extension range of the blocking propagation chain in the FIFO request sequence. The technical principle of this process is to quantify the request level depth traversed by the impact of prior blocking through the position distance, so that the number of prior blocked requests, the blocking release interval, and the blocking propagation span can jointly characterize the intensity of the prior blocking propagation on the current request from the dimensions of the number of sources, the duration, and the position propagation, respectively.

[0030] In this implementation scheme, by performing sequential identification, boundary measurement, and span characterization of the preceding connection constraint relationship in the FIFO request sequence, the influence of the preceding connection constraint on the current request can be transformed into three blocking characterization results with clear temporal, sequential, and propagation meanings: the number of preceding blocking requests, the blocking release interval, and the blocking propagation span. This transforms the blocking propagation relationship in the FIFO queue from an implicit state to a computable, comparable, and traceable state, thereby providing a stable input basis for the subsequent generation of preceding blocking diffusion values ​​and improving the accuracy, continuity, and reliability of the connection constraint propagation strength characterization in this invention.

[0031] Specifically, the steps for calculating the pre-order blocking diffusion value for each request are as follows: First, increment the number of pre-order blocking requests by one and then take the natural logarithm to obtain the blocking quantity diffusion term. During calculation, first read the number of pre-order blocking requests corresponding to the current request, then increment it by one to ensure that requests with zero pre-order blocking requests can still participate in subsequent calculations. Then, perform a natural logarithmic transformation on the result after incrementing to obtain the blocking quantity diffusion term. The technical principle of this process is to use the natural logarithmic function to compress the growth rate of the number of pre-order blocking requests, ensuring that the impact of increasing pre-order blocking sources on the diffusion result maintains a monotonically increasing trend, while avoiding excessive amplification of subsequent calculation results by a large number of requests. The congestion duration diffusion term is obtained by adding one to the congestion release interval and taking its square root. During calculation, the congestion release interval corresponding to the current request is first read, then one is added to it, ensuring that requests with a congestion release interval of zero can still participate in subsequent calculations. A square root transformation is then performed on the result to obtain the congestion duration diffusion term. The technical principle of this process is to use the square root function to mitigate the increase in congestion duration, ensuring that the increase in the congestion release interval continuously enhances the representation of the diffusion result, while suppressing the linear amplification of subsequent calculation results by long-term congestion. The congestion span diffusion term is obtained by adding one to the congestion propagation span and taking its natural logarithm. During calculation, the congestion propagation span corresponding to the current request is first read, then... The blocking propagation span is incremented by one to ensure that requests with a blocking propagation span of zero can still participate in subsequent calculations. A natural logarithmic transformation is then applied to the incremented result to obtain the blocking span diffusion term. The technical principle behind this process is to use the natural logarithmic function to compress the growth rate of the sequential propagation depth, maintaining the incremental enhancement capability of the diffusion result even as the FIFO request hierarchy spanned by the blocking propagation increases, while preventing requests with larger spans from unreasonably dominating the overall diffusion result. The blocking quantity diffusion term, blocking duration diffusion term, and blocking span diffusion term are multiplied to obtain the preorder blocking diffusion value. During calculation, the blocking quantity diffusion term is used as a representation of the blocking source scale, and the blocking duration diffusion term is used as a representation of the blocking duration. The quantity is used as the blocking span diffusion term as the representation of the blocking propagation range. Then, the three are multiplied under the same request dimension to form the pre-order blocking diffusion value corresponding to the current request. The technical principle of this processing is to map the source scale information, duration information, and order propagation information corresponding to the number of pre-order blocking requests, blocking release interval, and blocking propagation span to a single diffusion result through product coupling. This allows the pre-order blocking diffusion value to comprehensively reflect the pre-order blocking propagation intensity of the current request in the FIFO request sequence, thereby providing a directly applicable diffusion representation basis for subsequent connection contention constraint value determination, blocking type identification, FIFO order compensation value calculation, and dynamic weight allocation value generation.

[0032] The specific formula for calculating the pre-blocking diffusion value is as follows: ; In the formula, This represents the pre-order blocking diffusion value corresponding to the k-th request. This represents the number of pre-order blocked requests corresponding to the k-th request. This represents the blocking release interval corresponding to the k-th request. This represents the blocking propagation span corresponding to the k-th request.

[0033] In this implementation, by uniformly mapping the number of prior blocking requests, the blocking release interval, and the blocking propagation span to a prior blocking diffusion value, the multidimensional blocking propagation characteristics in the first-in-first-out queue can be converged into a single intensity characterization result. This enables the degree of blocking propagation between different requests to have a unified comparison scale, a unified calculation form, and a unified judgment basis. This provides a stable input basis for subsequent connection competition constraint value calculation, blocking type identification, FIFO order compensation value calculation, and dynamic weight allocation value generation, thereby improving the centrality, comparability, and feasibility of the present invention in characterizing the strength of prior blocking propagation.

[0034] Specifically, the steps for calculating the connection contention constraint value corresponding to each request based on the preprocessed connection queue monitoring data are as follows: Extract the number of connection requests waiting in the connection pool, the number of idle connections in the connection pool, the number of database lock-waiting transactions, and the number of active database transactions for each request; during extraction, read the number of connection requests waiting in the connection pool, the number of idle connections in the connection pool, the number of database lock-waiting transactions, and the number of active database transactions corresponding to the current request one by one according to the order of the current request in the FIFO request sequence, so that the connection resource waiting state, the connection resource remaining state, the database lock contention state, and the database transaction load state are aligned under the same request dimension, which is used to characterize the immediate connection contention environment when the current request initiates a connection request; the number of connection requests waiting in the connection pool... The first item, incremented by one, is the contention demand item. During calculation, the number of waiting connection requests in the connection pool corresponding to the current request is first read, and then one is added to this number to obtain the contention demand item. The technical principle of this process is to preserve the trend of increasing connection request pressure as the number of waiting requests increases, while avoiding zero-value truncation in subsequent fractional operations when the number of waiting connection requests in the connection pool is zero, allowing requests that have not yet formed a waiting backlog to still participate in unified contention calculations. The second item, incremented by one, is the idle supply item. During calculation, the number of idle connections in the connection pool corresponding to the current request is first read, and then one is added to this number to obtain the idle supply item. The technical principle of this process is to preserve the trend of decreasing connection resource availability as the number of idle connections decreases. This process avoids division by zero in subsequent fractional operations when the number of idle connections in the connection pool is zero, ensuring that the fully occupied connection resources can be included in subsequent calculations in a finite numerical form. The demand item is divided by the supply item to obtain the basic connection contention item. During calculation, the demand item is used as the numerator and the supply item as the denominator, and a ratio operation is performed to form the basic connection contention item corresponding to the current request. The technical principle of this process is to quantify the intensity of resource contention faced by the current request at the connection pool level through the direct ratio between demand-side pressure and supply-side surplus, so that the basic connection contention item increases synchronously when the number of waiting connection requests in the connection pool increases and the number of idle connections in the connection pool decreases. The number of database lock waiting transactions divided by the number of active database transactions plus one is used as the lock value. The lock wait diffusion term is calculated by first reading the number of database lock waiting transactions and the number of active database transactions corresponding to the current request, then adding one to the number of active database transactions as the normalized denominator, and using the number of database lock waiting transactions as the numerator to perform a ratio operation to form the lock wait diffusion term. The technical principle of this process is to use the proportion of the number of database lock waiting transactions in the context of active database transactions to characterize the degree of diffusion of lock contention in the current transaction load level. This ensures that the lock wait diffusion term increases when the number of database lock waiting transactions increases, and that the lock wait diffusion term is relatively suppressed when the number of active database transactions increases, under the same lock wait scale. Adding one to the lock wait diffusion term yields the lock wait correction term, which is calculated by adding one to the lock wait diffusion term.The technical principle of this processing is to ensure that requests without lock wait propagation still participate in subsequent calculations in a baseline corrected state, so that the connection contention base term is not weakened to zero when the lock wait propagation term is zero, and requests with lock wait propagation show a gain amplification effect in subsequent results. The connection contention base term and the lock wait correction term are multiplied to obtain the corresponding connection contention constraint value. During calculation, the connection contention base term is used as a representation of contention intensity at the connection pool level, and the lock wait correction term is used as a correction representation under the background of database lock contention. The two are then multiplied in the current request dimension to form the connection contention constraint value corresponding to the current request. The technical principle of this processing is to uniformly map the number of connection pool waiting connection requests, the number of idle connections in the connection pool, the number of database lock waiting transactions, and the number of active database transactions to a single contention constraint result through product coupling. This allows the connection contention constraint value to comprehensively reflect the connection pool contention pressure and database lock contention pressure experienced by the current request during the connection resource allocation stage, thus providing a directly applicable contention constraint basis for subsequent blocking type determination, FIFO order compensation value calculation, and dynamic weight allocation value generation.

[0035] The specific formula for calculating the connection competition constraint value is as follows: ; In the formula, This represents the connection contention constraint value corresponding to the k-th request. This represents the number of connection requests waiting in the connection pool for the k-th request. This represents the number of idle connections in the connection pool corresponding to the k-th request. This indicates the number of database lock waiting transactions corresponding to the k-th request. This represents the number of active database transactions corresponding to the k-th request.

[0036] In this implementation, by uniformly mapping the number of connection requests waiting in the connection pool, the number of idle connections in the connection pool, the number of transactions waiting for database locks, and the number of active database transactions to connection contention constraint values, the competition pressure on the connection pool side and the database lock side faced by the current request during the connection resource application stage can be converged into a single constraint result. This gives the strength of competition between different requests a unified representation scale, a unified comparison basis, and a unified input format, thereby providing a stable competitive basis for subsequent blocking type determination, FIFO order compensation value calculation, and dynamic weight allocation value generation. This improves the centrality, comparability, and feasibility of the connection contention state characterization of this invention.

[0037] In this embodiment, Table 1 is an example data table of first-in-first-out (FIFO) blocking propagation, listing the calculated data of pre-order blocking diffusion values ​​and connection contention constraint values ​​for five requests. Specifically: In request 1, the number of pre-order blocking requests is 0, the blocking release interval is 0, the blocking propagation span is 0, the number of connection requests waiting in the connection pool is 1, the number of idle connections in the connection pool is 5, the number of database lock waiting transactions is 0, the number of active database transactions is 8, the pre-order blocking diffusion value is 0, and the connection contention constraint value is 0.3333. In request 2, the number of pre-order blocking requests is 1, the blocking release interval is 12, the blocking propagation span is 1, the number of connection requests waiting in the connection pool is 2, the number of idle connections in the connection pool is 4, the number of database lock waiting transactions is 1, the number of active database transactions is 9, the pre-order blocking diffusion value is 1.7323, and the connection contention constraint value is 0.6600. In request 3, the number of preorder blocked requests is 2, the blocking release interval is 35, the blocking propagation span is 2, the number of connection requests waiting in the connection pool is 4, the number of idle connections in the connection pool is 3, the number of database lock waiting transactions is 2, the number of active database transactions is 10, the preorder blocking diffusion value is 7.2417, and the connection contention constraint value is 1.4773. In request 4, the number of preorder blocked requests is 3, the blocking release interval is 80, the blocking propagation span is 3, the number of connection requests waiting in the connection pool is 6, the number of idle connections in the connection pool is 2, the number of database lock waiting transactions is 4, the number of active database transactions is 12, the preorder blocking diffusion value is 17.2963, and the connection contention constraint value is 3.0513. In request 5, the number of pre-order blocked requests is 4, the blocking release interval is 150, the blocking propagation span is 4, the number of connection pool waiting requests is 8, the number of idle connections in the connection pool is 1, the number of database lock waiting transactions is 5, the number of active database transactions is 11, the pre-order blocking propagation value is 31.8300, and the connection contention constraint value is 6.3750. As shown in Table 1, as the request moves further down the FIFO request sequence, the number of pre-order blocked requests, the blocking release interval, and the blocking propagation span gradually increase, and the pre-order blocking propagation value and the connection contention constraint value also increase accordingly. This indicates that subsequent requests are simultaneously affected by both the enhanced pre-order blocking propagation and the intensified connection contention.

[0038] Table 1. Example Data Table of FIFO Pre-blocking Propagation

[0039] like Figure 2As shown in the figure, the process of pre-order blocking formation of five requests in a FIFO request sequence is illustrated by combining time constraint intervals and blocking propagation relationships. The vertical axis represents the order of requests 1 to 5 in the FIFO request sequence, and the horizontal axis represents the time axis. The thick horizontal line corresponding to each request represents the connection constraint interval, which is used to characterize the duration of connection resource constraints imposed on the corresponding request from the connection acquisition start timestamp to the transaction commit timestamp. The circle to the left of each request represents the connection acquisition start timestamp, which is used to characterize the moment when the corresponding request begins to request connection resources. The curved arrow in the figure represents the pre-order blocking propagation relationship, which is used to characterize the pre-order blocking effect formed when the transaction commit timestamp of the preceding request is later than the connection acquisition start timestamp of the subsequent request. The shaded area represents the blocking release interval, which is used to characterize the blocking duration interval from the connection acquisition start timestamp of the current request to the transaction commit timestamp of the latest preceding blocked request. In the diagram, request 1 is not blocked by its preceding request, request 2 is blocked by the preceding request of request 1, request 3 is blocked by the preceding request of request 2, request 4 is blocked by the preceding requests of both request 2 and request 3, and request 5 is blocked by the preceding requests of both request 3 and request 4. This reflects that as the order of requests in the FIFO request sequence moves to the end, the number of preceding blocked requests, the blocking release interval, and the blocking propagation span gradually increase. Figure 2 This invention intuitively demonstrates the formation mechanism of the number of pre-order blocking requests, the blocking release interval, and the blocking propagation span. It can reflect the differences in blocking propagation of different requests in the FIFO queue and provide a basis for further calculation of pre-order blocking diffusion value, subsequent execution connection contention constraint determination, and dynamic weight resource allocation.

[0040] Specifically, the steps for determining the blocking type of each request and outputting FIFO blocking constraint data based on the pre-order blocking diffusion value are as follows: When the pre-order blocking diffusion value is greater than the connection contention constraint value, the corresponding request is marked as a pre-order blocking dominant request; during the determination, the pre-order blocking diffusion value corresponding to the current request is used as a measure of the pre-order blocking propagation strength, and the connection contention constraint value corresponding to the current request is used as a measure of the connection resource contention strength. When the pre-order blocking diffusion value is greater than the connection contention constraint value, it indicates that the pre-order connection constraint propagation influence on the current request has exceeded the constraint strength of the connection contention environment in which the current request is located. At this time, the main source of constraint for the current request is the pre-order blocking propagation within the FIFO request sequence. Therefore, the current request is marked as a pre-order blocking dominant request. The process involves classifying requests into the pre-order blocking dominant request category. When the pre-order blocking diffusion value is less than or equal to the connection contention constraint value, the process reads the database lock waiting transaction count and connection pool idle connection count from the preceding K records to the record corresponding to the current request. Here, K is set to 3. During reading, the current request's position in the FIFO request sequence is used as the current position. Three preceding records are backtracked from the current position towards the head of the queue. These three preceding records are then arranged sequentially with the record corresponding to the current request in terms of order, forming a decision record sequence. This ensures that the database lock waiting transaction count and connection pool idle connection count form a continuous comparison basis within the order range near the current request. The technical principle behind this process is that when the pre-order blocking diffusion value does not exceed the connection contention constraint value, the main constraint on the current request is... The source is no longer determined solely by the propagation of preceding blocking events, but requires further analysis of the lock contention evolution trend in the nearest neighbor sequence and the trend of connection resource availability changes to identify the source of contention. When there are fewer than K records before the current request, all records before the current request and the record corresponding to the current request are used as the decision record sequence. During processing, all existing preceding records before the current request, along with the record corresponding to the current request, are arranged sequentially to form the decision record sequence. This ensures that requests near the head of the queue still have a viable nearest neighbor determination basis even when the number of preceding records is insufficient, avoiding interruption of blocking type identification due to insufficient preceding records. For the decision record sequence, when the number of database lock waiting transactions in the subsequent records between any two adjacent records in the decision record sequence is equal to the number of records between adjacent records, the decision record sequence is determined by the following condition: If the number of database lock waiting transactions in the preceding record is greater than the number of idle connections in the connection pool in the following record, and the number of idle connections in the connection pool in the following record is greater than or equal to the number of idle connections in the connection pool in the preceding record, the corresponding request is marked as a lock wait propagation request. During the determination, the number of database lock waiting transactions in adjacent records in the determination record sequence is compared one by one. If the number of database lock waiting transactions in the following record continues to increase, it indicates that the lock waiting pressure is propagating along the FIFO request sequence. Then, the number of idle connections in the connection pool in adjacent records in the determination record sequence is compared one by one. If the number of idle connections in the connection pool does not show a continuous decrease, it indicates that the connection resource reserve has not formed a synchronous contraction. Therefore, the main source of contention for the current request is the propagation of database lock wait, and thus the current request is classified as a lock wait propagation request.When any two adjacent records in the determination record sequence have a lower number of idle connections in the connection pool in the subsequent record than in the preceding record, and the number of database lock waiting transactions in the subsequent record is less than or equal to the number of database lock waiting transactions in the preceding record, the corresponding request is marked as a connection squeezing request. During the determination process, the number of idle connections in the connection pool of adjacent records in the determination record sequence is compared pairwise. If the number of idle connections in the connection pool of subsequent records continues to decrease, it indicates that the connection resource reserve is continuously compressed along the FIFO request sequence. Then, the number of database lock waiting transactions of adjacent records in the determination record sequence is compared pairwise again. If the number of database lock waiting transactions does not show a continuous increase... If the current request is primarily driven by resource squeezing at the connection pool level rather than lock wait propagation, it is classified as a connection squeezing request. If, between any two adjacent records in the decision record sequence, the number of database lock waiting transactions in the subsequent record is greater than the number of database lock waiting transactions in the preceding record, and the number of idle connections in the connection pool in the subsequent record is less than the number of idle connections in the connection pool in the preceding record, the corresponding request is marked as a composite contention request. If, during the decision process, the number of database lock waiting transactions continues to increase along the decision record sequence, while the number of idle connections in the connection pool continues to decrease along the decision record sequence, it indicates that the current request is simultaneously subject to resource squeezing at the connection pool level within the nearest neighbor order. Based on the combined effects of intensified database lock contention and shrinking connection resource availability, the current request's contention originates from a coupled superposition of lock contention constraints and connection squeeze constraints, thus classifying the current request as a composite contention request. Otherwise, the corresponding request is marked as a non-blocking request. This determination method characterizes the current request as neither exhibiting a transcendence relationship between the prior blocking propagation value and the connection contention constraint value, nor reflecting a continuously increasing trend in the number of database lock-waiting transactions, nor a continuously decreasing trend in the number of idle connections in the connection pool. Therefore, the current request does not possess significant blocking propagation characteristics or significant contention amplification characteristics; and generates a blocking type label sequence; the generation follows the order in the FIFO request sequence. First, the blocking type flag for each request is written to the flag position corresponding to the request order, forming a blocking type flag sequence covering all requests. Then, the prior blocking propagation value, connection contention constraint value, and blocking type flag sequence corresponding to each request are combined one by one according to the FIFO request sequence to output FIFO blocking constraint data. When combining, each request record in the FIFO request sequence is used as an index to write the prior blocking propagation value, connection contention constraint value, and blocking type flag corresponding to the current request into the same constraint record, so that the FIFO blocking constraint data simultaneously retains the order information, prior blocking propagation information, connection contention constraint information, and blocking type information.The technical principle of this process lies in first distinguishing the dominant situation of prior blocking propagation by utilizing the relationship between the magnitude of the pre-order blocking propagation value and the connection contention constraint value. Then, it utilizes the continuous change relationship between the number of database lock-waiting transactions and the number of idle connections in the connection pool within the decision record sequence to distinguish between lock-waiting propagation, connection squeezing, and combined contention situations. This allows the current request's blocking state to be mapped into FIFO blocking constraint data that can directly participate in FIFO priority compensation value calculation, dynamic weight allocation value calculation, current round FIFO priority constraint allocation window construction, connection acquisition eligibility allocation, and the generation of the next round's priority retention flag.

[0041] In this implementation, by incorporating the pre-order blocking diffusion value, connection contention constraint value, database lock waiting transaction count, and connection pool idle connection count into the blocking type determination process, the blocking status of the current request in the FIFO request sequence can be refined into five categories with clear constraint meanings: pre-order blocking dominant request, lock waiting diffusion request, connection squeezing request, composite contention request, and non-blocking request. This enables the FIFO blocking constraint data to simultaneously possess the ability to distinguish propagation intensity, contention source, and nearest neighbor trend. Thus, this invention provides a unified determination basis for subsequent FIFO order compensation value calculation, dynamic weight allocation value generation, current round FIFO order constraint allocation window construction, connection acquisition qualification allocation, and next round priority retention mark generation in distributed storage scenarios, improving the hierarchy, comparability, and feasibility of blocking status identification.

[0042] Specifically, the steps for calculating the FIFO order compensation value and dynamic weight allocation value for each request based on FIFO blocking constraint data and preprocessed connection queue monitoring data are as follows: First, increment the queue length value at enqueue time corresponding to the request by one, then divide by the increment of the request's order in the FIFO request sequence to obtain the order compensation ratio. During calculation, first read the queue length value at enqueue time corresponding to the current request, then read the current request's order in the FIFO request sequence. The queue length value at enqueue time has undergone preprocessing to achieve numerical scale unification, and the order in the FIFO request sequence is a dimensionless sequence identifier. Therefore, the queue length value at enqueue time used for calculation and the order in the FIFO request sequence are both dimensionless. In a directly comparable dimensionless state; then, add one to the queue length value at the time of enqueueing, add one to the order of the FIFO request sequence, and then divide the queue length value at the time of enqueueing with the added one by the order of the FIFO request sequence to obtain the order compensation ratio; the technical principle of this processing is to use the ratio of the queuing pressure at the moment the current request enters the queue to the current request's order position to characterize the order compensation intensity that the current request should obtain under the first-in-first-out order constraint, so that requests with larger queue length values ​​at the time of enqueueing and higher order positions in the FIFO request sequence will have a higher order compensation basis in subsequent calculations; add one to the order compensation ratio and take the natural logarithm to obtain the order compression term; calculate The order compensation ratio term is incremented by one, and then the result is transformed by the natural logarithm to obtain the order compression term. The technical principle of this process is to use the natural logarithm function to compress the growth rate of the order compensation ratio term, so that the order compensation effect maintains the trend of increasing with queuing pressure, while avoiding excessive amplification of subsequent compensation results by high queuing pressure requests. The square root of the pre-order blocking diffusion value is then taken after incrementing by one to obtain the blocking diffusion compensation term. During calculation, the pre-order blocking diffusion value corresponding to the current request is read. The pre-order blocking diffusion value is calculated from the number of pre-order blocking requests, the blocking release interval, and the blocking propagation span. This value has already been written into the FIFO blocking as a dimensionless diffusion characterization result before entering this step. The data is constrained, and then one is added to the prior blocking diffusion value. A square root transformation is performed on the result to obtain the blocking diffusion compensation term. The technical principle of this process is to use the square root function to slow down the growth rate of the diffusion value, so that the compensation result can continue to improve even when the intensity of prior blocking propagation increases, while suppressing the single dominance of the ultra-large diffusion value on the subsequent dynamic weight allocation value. The order compression term is multiplied with the blocking diffusion compensation term to obtain the FIFO order compensation value. During the calculation, the order compression term is used as the first-in-first-out order compensation representation quantity, and the blocking diffusion compensation term is used as the prior blocking propagation compensation representation quantity. Then, the product operation is performed under the current request dimension to form the FIFO order compensation value corresponding to the current request.The technical principle of this process lies in mapping queuing order factors and congestion propagation factors into a single compensation result through product coupling. This allows the FIFO order compensation value to simultaneously represent the order compensation requirement of the current request in the FIFO request sequence and the intensity of the impact of preceding congestion propagation. The connection contention constraint value is incremented by one and its natural logarithm is taken to obtain the contention suppression term. During calculation, the connection contention constraint value corresponding to the current request is read. This value is calculated from the number of connection requests waiting in the connection pool, the number of idle connections in the connection pool, the number of database lock-waiting transactions, and the number of active database transactions. This value has already been written into the FIFO congestion constraint data as a dimensionless contention constraint result before entering this step. The connection contention constraint value is then incremented by one, and a natural logarithmic transformation is performed on the result to obtain the contention suppression term. The technical principle of this process is to compress the growth rate of the connection contention constraint value using the natural logarithmic function, ensuring that the suppression strength continuously improves as the connection contention environment intensifies, while avoiding unreasonable dynamic weight allocation values ​​caused by extreme contention states. The dynamic weight allocation value is obtained by dividing the FIFO order compensation value by the sum of the competition suppression term and one. During calculation, the FIFO order compensation value is used as the numerator, and the sum of the competition suppression term and one is used as the denominator. A ratio operation is performed under the current request dimension to form the dynamic weight allocation value corresponding to the current request. The technical principle of this process is to use the FIFO order compensation value to represent the order compensation intensity that the current request should obtain, and then use the competition suppression term to represent the degree of constraint on the compensation result by the connection competition environment in which the current request is located. This ensures that the dynamic weight allocation value is suppressed and corrected by the connection competition state while maintaining the FIFO order compensation capability. The queue length value, pre-order blocking diffusion value, and connection competition constraint value involved in the calculation are all preprocessed dimensionless data, and the order in the FIFO request sequence is a dimensionless sequence identifier. This ensures that the calculation process of the FIFO order compensation value and the dynamic weight allocation value is based on a unified numerical scale, thereby avoiding unreasonable deviations in the dynamic weight allocation result caused by differences in dimensions and orders of magnitude.

[0043] The specific formula for calculating the FIFO order compensation value is as follows: ; In the formula, This represents the FIFO order compensation value corresponding to the k-th request. This represents the queue length value when the k-th request is enqueued. This indicates the order of the k-th request in the FIFO request sequence. This represents the pre-order blocking diffusion value corresponding to the k-th request.

[0044] The specific formula for calculating the dynamic weight allocation value is as follows: ; In the formula, This represents the dynamic weight allocation value corresponding to the k-th request. This represents the FIFO order compensation value corresponding to the k-th request. This represents the connection contention constraint value corresponding to the k-th request.

[0045] In this implementation, by uniformly incorporating the queue length value at enqueue time, the order in the FIFO request sequence, the pre-order blocking propagation value, and the connection contention constraint value into the calculation process of the FIFO order compensation value and the dynamic weight allocation value, the first-in-first-out order constraint, the impact of pre-order blocking propagation, and the connection contention suppression relationship can be converged into a unified weight representation result. This enables the resource allocation priority among different requests to have a unified calculation scale, a unified comparison basis, and a unified output format. This provides a stable weight basis for the subsequent construction of the current round FIFO order constraint allocation window, the determination of the current round priority processing request set, the allocation of connection acquisition eligibility, and the generation of the next round priority retention mark. This improves the centrality, comparability, and feasibility of the dynamic weight resource allocation process characterization of this invention.

[0046] Specifically, the steps for constructing the FIFO priority constraint allocation window and determining the priority request set for this round are as follows: Read the blocking type flags corresponding to each request continuously from the head of the FIFO request sequence; when reading, take the first request in the FIFO request sequence as the starting position, and expand the blocking type flags sequentially towards the tail of the queue, arranging the pre-order blocking dominant request, lock wait diffusion request, connection squeezing request, composite contention request, and non-blocking request in sequence under the same priority reference to identify the blocking distribution state near the head of the queue in the current round; count the number of consecutive non-non-blocking requests starting from the head of the queue to obtain the length of the head blocking segment; when counting, check the blocking type flags one by one from the head of the FIFO request sequence, and when the blocking type... The type marker indicates the number of requests that are not part of the non-blocking request accumulation. Accumulation stops when a non-blocking request first appears, and the number of requests accumulated before the stop position is recorded as the header blocking segment length. The technical principle behind this process is that consecutive non-blocking requests at the head of the queue indicate that the blocking pressure in the current connection resource allocation process has already accumulated at the beginning of the FIFO request sequence. Therefore, the header blocking segment length can quantify the range of blocked requests that require the most priority in the current round. The header blocking segment length is added to the current number of idle connections in the connection pool to obtain the FIFO order constraint allocation window length for this round. During calculation, the number of idle connections in the connection pool corresponding to the current round is read, and the header blocking segment length is used as a representation of the blocking pressure coverage range. The number of connections is used as a representation of the number of connection resources that can be immediately allocated in the current round. The two values ​​are then added together within the same round to form the FIFO priority constraint allocation window length for this round. The technical principle of this process is to limit the range of blocked requests that need to be prioritized in the current round by using the length of the header blocking segment, and to limit the actual processing capacity that can be released in the current round by using the number of idle connections in the connection pool. This ensures that the FIFO priority constraint allocation window length reflects both the blocking constraint demand and the connection resource supply capacity, thereby avoiding the omission of header blocking requests due to an excessively short priority window, and avoiding the premature entry of later requests into contention due to an excessively long priority window. Continuous requests corresponding to the FIFO priority constraint allocation window length are extracted according to the FIFO request sequence and then processed accordingly. The dynamic weight allocation values ​​are sorted in descending order. When the dynamic weight allocation values ​​are the same, they are sorted in ascending order according to their position in the FIFO request sequence. During the truncation, the head of the FIFO request sequence is used as the starting boundary, and requests are continuously selected towards the tail of the sequence, with the number of requests matching the length of the FIFO order constraint allocation window in this round, forming the range of requests participating in priority competition in the current round. During the sorting, the dynamic weight allocation value corresponding to each request in this range is read first, and then the dynamic weight allocation value is used as the first sorting criterion to perform descending rearrangement, so that requests with larger dynamic weight allocation values ​​are placed at the front. When the dynamic weight allocation values ​​are the same, the order in the FIFO request sequence is used as the second sorting criterion to perform ascending subdivision, so that requests with earlier original positions are prioritized at the front.The technical principle behind this process is that the dynamic weight allocation value is used to characterize the comprehensive priority of the current request under the combined effects of priority compensation pressure, congestion propagation pressure, and connection contention suppression. The order in the FIFO request sequence is used to maintain the first-in-first-out constraint under the same priority. Therefore, by first sorting by the dynamic weight allocation value and then by the order in the FIFO request sequence, restricted contention can be achieved without violating the priority constraint. Then, requests are selected sequentially from the sorted results according to the number of idle connections in the current connection pool to determine the priority request set for this round. During selection, the number of idle connections in the current connection pool is used as the priority value. The available processing slots from the previous round are retrieved sequentially from the top of the sorted results until the total number of requests matches the current number of idle connections in the connection pool. This retrieved set of requests is designated as the priority processing request set for this round. The technical principle behind this process is that the number of available connection resources in the current round directly constrains the output size of the priority processing requests. This ensures that the number of priority processing requests matches the available connection resource capacity, the order is constrained by a limited window, and the priority is driven by dynamic weights. This provides directly applicable processing input for subsequent connection acquisition allocation and the generation of priority retention tags for the next round.

[0047] In this implementation, by incorporating the blocking type flag, the length of the header blocking segment, the number of idle connections in the connection pool, the dynamic weight allocation value, and the order in the FIFO request sequence into the FIFO order constraint allocation window construction process, the blocking aggregation state at the head of the queue, the current connection resource allocation capacity, and the overall priority of requests can be converged into a unified order-constrained processing range. This ensures that the request set prioritized in this round simultaneously possesses the foundations of order constraints, blocking constraints, resource capacity constraints, and dynamic weight constraints, thereby providing stable processing inputs for subsequent connection acquisition qualification allocation and the generation of priority retention flags in the next round. This enhances the centrality, controllability, and implementability of the invention's characterization of the resource allocation boundary in the current round.

[0048] Specifically, the steps for connection acquisition qualification allocation, next-round priority retention mark generation, and dynamic weight resource allocation data output, combined with blocking type, are as follows: For the priority processing request set in this round, firstly, read the request identifier, blocking type mark, dynamic weight allocation value, and connection contention constraint value one by one according to the order in the FIFO request sequence, and then map each request to the connection resource allocation process of the current round; when the request is a pre-order blocking dominant request, a connection squeezing request, or a non-blocking request, directly allocate connection acquisition qualification; during allocation, take an available connection qualification from the available connection resource pool of the current round and write it into the current request. The connection acquisition qualification allocation result in the corresponding record enables the current request to enter the immediate processing state of the current round. The technical principle of this processing is that pre-order blocking dominant requests are mainly affected by the propagation of preceding blocking, connection squeezing requests are mainly affected by the compression of connection resource reserves, and non-blocking requests do not show significant blocking amplification characteristics. Therefore, these three types of requests have the condition to immediately occupy the currently available connection resources after entering the priority processing request set of this round. When the request is a lock waiting propagation request or a composite contention request, the allocation of connection acquisition qualification for the current request is temporarily suspended, and a priority reservation mark for the next round is generated. During the suspension, no connection acquisition qualification is written to the current request. The allocation result is only written to the record corresponding to the current request, creating a priority reservation flag for the next round. This causes the current request to exit the immediate processing path of the current round and enter the priority input path of subsequent rounds. The technical principle behind this process is that lock wait propagation requests reflect the state of database lock contention spreading backward along the FIFO request sequence, while composite contention requests reflect the state of simultaneously increasing pressure from shrinking connection resource reserves and database lock contention. If connection acquisition eligibility is directly allocated in the current round, it will further amplify the database lock wait pressure. Therefore, by temporarily suspending allocation in the current round and reserving priority eligibility for subsequent rounds, the continued propagation of lock contention can be suppressed. For requests that generate the next round of priority retention flags, record the corresponding consecutive retention rounds. When recording, create a consecutive retention round counter in the record corresponding to the current request. When the next round of priority retention flags is generated for the first time in the current round, the consecutive retention rounds are recorded as 1. In subsequent rounds, when the next round of priority retention flags is maintained, the consecutive retention rounds are incremented by 1 based on the previous round of consecutive retention rounds. At the same time, before the end of the current round, write the connection contention constraint value corresponding to the current request into the historical round record corresponding to the request, and use the request identifier as the cross-round corresponding index, so that the connection contention constraint value corresponding to the previous round can be accurately read back in subsequent rounds.At the start of the next round of resource allocation, for requests marked with priority retention for the next round, the number of waiting connection requests in the connection pool, the number of idle connections in the connection pool, the number of database lock waiting transactions, and the number of active database transactions are re-extracted based on the pre-processed connection queue monitoring data corresponding to the next round. Then, the connection contention constraint value for the current round is recalculated according to the connection contention constraint value calculation process. Furthermore, the connection contention constraint value for the same request in the historical round records of the previous round is read according to the request identifier to compare the connection contention constraint value for the current round with that for the previous round. If the number of consecutive retention rounds is less than the preset retention limit, and the connection contention constraint value for the current round is greater than that for the previous round, then... The priority retention flag for the next round is maintained; the preset retention limit is set to 2 to 5 rounds. The technical principle behind this process is that when the consecutive retention rounds are still within a controlled range, and the connection contention constraint value recalculated for the same request in the new round continues to increase, it indicates that the connection contention environment for the current request is still deteriorating. Maintaining the priority retention flag for the next round can prevent premature consumption of connection resources during the stage of continuously worsening contention. When the consecutive retention rounds reach the preset retention limit, or the connection contention constraint value corresponding to the current round is less than or equal to the connection contention constraint value corresponding to the previous round, the priority retention flag for the next round is canceled, and the corresponding request is used as the normal processing input for the next round's FIFO priority constraint allocation window. The current request is deleted during processing. The corresponding record shows the next-round priority retention flag. The current request is then rewritten into the next-round FIFO order constraint allocation window input sequence, allowing it to re-participate in the current round's FIFO order constraint allocation window length truncation, dynamic weight allocation value sorting, and the determination of the current round's priority processing request set, following the normal competition path of the previous round. The technical principle behind this process is that when the consecutive retention rounds reach their limit, continued retention weakens request fairness; when the connection competition constraint value recalculated for the same request in a new round no longer increases, continued retention loses its competition suppression significance. Therefore, the current request needs to be restored to normal processing input. This involves establishing request identifiers, dynamic weight allocation values, blocking type flags, next-round priority retention flags, and connection acquisition qualification allocation results. The system establishes a correspondence between results to generate dynamic weighted resource allocation data. During setup, the request identifier is used as an index to write the dynamic weight allocation value, blocking type flag, next-round priority retention flag status, and connection acquisition qualification allocation result corresponding to the same request into the same allocation record. Then, the dynamic weighted resource allocation data is output according to the order in the FIFO request sequence. The technical principle of this process is that by unifying the weight results, blocking judgment results, retention status, and allocation results into the same record, the resource allocation status of the current round becomes traceable, retrievable, and comparable. Furthermore, at the start of the next round of resource allocation, requests with the next-round priority retention flag are read first and participate in the construction of the next round's FIFO order constraint allocation window.During the reading process, all requests with the priority retention flag for the next round are first extracted from the dynamic weighted resource allocation data. These requests are then placed at the beginning of the input sequence of the next round's FIFO priority constraint allocation window, ensuring they enter the candidate range first during the next round's priority window truncation phase. The technical principle behind this process is that by introducing the previous round's reserved requests at the beginning of the next round, deferred lock-waiting requests and composite contention requests can re-participate in connection acquisition qualification allocation with priority after the contention environment eases, thus forming a cross-round closed-loop dynamic weighted resource allocation process.

[0049] In this implementation, by unifying the blocking type flag, connection acquisition qualification allocation result, next round priority retention flag, consecutive retention rounds, and connection contention constraint value into the same round of resource allocation process, the current round's immediate allocation behavior, cross-round retention behavior, and subsequent round re-entry behavior can be converged into a continuously connected dynamic weighted resource allocation result. This ensures that the processing status of different requests in the FIFO request sequence has a unified allocation basis, unified round constraints, and unified tracking form. Thus, in a distributed storage scenario, this invention can achieve continuous adjustment of the connection acquisition qualification allocation process, release of contention pressure, and compensation for subsequent rounds while maintaining FIFO order constraints, thereby improving the completeness, stability, and feasibility of the dynamic weighted resource allocation process.

[0050] like Figure 3As shown in the figure, the blocking constraint determination and dynamic weight resource allocation process of five requests under the FIFO request sequence is displayed in a progressive column format. The leftmost column represents the FIFO request sequence, which represents the original order of requests 1 to 5 in the first-in-first-out queue. The middle left column represents the FIFO blocking constraint data, which represents the connection contention constraint value, pre-order blocking diffusion value, and blocking type determination result for each request. The middle dashed box area represents the FIFO order constraint allocation window for this round, which represents the range of consecutive requests participating in the dynamic weight competition for this round, and marks the dynamic weight allocation value for each request within the box. The middle right column represents the priority processing requests for this round, which represents the requests selected from the FIFO order constraint allocation window after being sorted by the dynamic weight allocation value. The rightmost column represents the resource allocation result, which represents whether the corresponding request is allocated a connection or whether a priority retention mark is generated for the next round. The lower right column has a separate priority retention mark area for the next round, which represents requests that are not directly allocated a connection in the current round but are retained for priority processing in the next round. In the diagram, Request 1 has relatively small connection contention constraint values ​​and pre-order blocking diffusion values, so it is marked as a non-blocking request and does not enter the priority processing range of this round. Requests 2 and 3 are marked as pre-order blocking dominant requests. After entering the FIFO order constraint allocation window of this round, they obtain higher dynamic weight allocation values ​​and are allocated connection acquisition qualifications in the priority processing stage of this round. Request 4 is marked as a composite contention request. Although it enters the FIFO order constraint allocation window of this round and has a high dynamic weight allocation value, it is not directly allocated connection acquisition qualifications in the resource allocation results, but instead generates a priority retention mark for the next round. Request 5 is also a composite contention request, but it does not enter the priority processing range of this round. Figure 3 This invention visually demonstrates the transmission relationship between FIFO blocking constraint data and dynamic weight resource allocation data. It reflects the correlation between blocking type determination, construction of the current round of FIFO order constraint allocation window, determination of the current round of priority processing request, and generation of the next round of priority retention mark. It also verifies the feasibility of implementing dynamic weight resource allocation while maintaining FIFO order constraints.

[0051] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0052] The preferred embodiments of the present invention disclosed above are merely illustrative of the invention. These preferred embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the content of this specification. This specification selects and specifically describes these embodiments to better explain the principles and practical applications of the invention, thereby enabling those skilled in the art to better understand and utilize the invention. The invention is limited only by the claims and their full scope and equivalents.

Claims

1. A dynamic weighted resource allocation method based on a FIFO queue, characterized in that, Includes the following steps: S1 collects connection queue monitoring data and performs time synchronization, missing data completion, anomaly removal, time series suppression and numerical normalization processing on the connection queue monitoring data, and outputs the preprocessed connection queue monitoring data. S2, based on the preprocessed connection queue monitoring data, generate a FIFO request sequence and connection constraint interval, identify the pre-order blocking request corresponding to each request, calculate the number of pre-order blocking requests, blocking release interval and blocking propagation span, and further calculate the pre-order blocking diffusion value of each request; S3, calculate the connection contention constraint value corresponding to each request based on the preprocessed connection queue monitoring data, and determine the blocking type corresponding to each request by combining the pre-order blocking diffusion value, and output FIFO blocking constraint data; S4 calculates the FIFO order compensation value and dynamic weight allocation value for each request based on the FIFO blocking constraint data and the preprocessed connection queue monitoring data, constructs the FIFO order constraint allocation window for this round and determines the priority processing request set for this round, and then combines the blocking type to perform connection acquisition qualification allocation and next round priority retention mark generation, outputting dynamic weight resource allocation data.

2. The dynamic weighted resource allocation method based on a FIFO queue according to claim 1, characterized in that: The specific steps for collecting connection queue monitoring data and performing time synchronization, missing data completion, anomaly removal, time-series suppression, and numerical normalization on the connection queue monitoring data are as follows: Real-time collection of connection queue monitoring data, including request arrival timestamp, request enqueue timestamp, connection acquisition start timestamp, connection acquisition completion timestamp, transaction commit timestamp, queue length value at enqueue, total number of connections in the connection pool, number of idle connections in the connection pool, number of connection requests waiting in the connection pool, number of active database transactions, and number of database lock waiting transactions. For the collected connection queue monitoring data, the precise time protocol time synchronization algorithm is used to perform multi-source time reference synchronization processing; the Kalman filter interpolation algorithm is used to perform missing data completion processing; the Hanpu filter anomaly detection algorithm is used to perform anomaly identification and removal processing; the exponential weighted moving average filter algorithm is used to perform timing jitter suppression processing; and the minimum-maximum normalization algorithm is used to perform numerical scale unification processing, outputting the preprocessed connection queue monitoring data.

3. The dynamic weighted resource allocation method based on a FIFO queue according to claim 2, characterized in that: The specific steps for generating the FIFO request sequence and connection constraint interval based on the preprocessed connection queue monitoring data are as follows: Based on the preprocessed connection queue monitoring data, all records are rearranged in ascending order according to the request enqueue timestamp; when the request enqueue timestamps are the same, they are arranged in ascending order according to the request arrival timestamp to generate a FIFO request sequence. Then, read the connection acquisition start timestamp and transaction commit timestamp corresponding to each request in the FIFO request sequence one by one. Use the connection acquisition start timestamp as the start time of the connection constraint interval and the transaction commit timestamp as the end time of the connection constraint interval to construct the connection constraint interval corresponding to each request.

4. The dynamic weighted resource allocation method based on a FIFO queue according to claim 3, characterized in that: The specific steps for identifying the preceding blocked requests corresponding to each request and calculating the number of preceding blocked requests, the blocking release interval, and the blocking propagation span are as follows: Read all connection constraint intervals preceding the current request one by one along the FIFO request sequence. When the transaction commit timestamp of a preceding request is greater than the connection acquisition start timestamp of the current request, the preceding request is identified as a pre-blocking request of the current request. Then, count the number of pre-blocking requests corresponding to the current request, and extract the latest transaction commit timestamp and the order of the earliest pre-blocking request in the FIFO request sequence from all pre-blocking requests. When there are no pre-blocking requests for the current request, record the number of pre-blocking requests, the blocking release interval, and the blocking propagation span corresponding to the current request as zero. When there are pre-blocking requests for the current request, subtract the connection acquisition start timestamp of the current request from the latest transaction commit timestamp to obtain the blocking release interval. The difference between the order of the current request in the FIFO request sequence and the order of the earliest pre-blocking request in the FIFO request sequence is used to obtain the blocking propagation span.

5. The dynamic weighted resource allocation method based on a FIFO queue according to claim 4, characterized in that: The specific steps for further calculating the pre-order blocking diffusion value for each request are as follows: Add one to the number of prior blocked requests and take the natural logarithm to obtain the blocking quantity diffusion term; add one to the blocking release interval and take the square root to obtain the blocking duration diffusion term; add one to the blocking propagation span and take the natural logarithm to obtain the blocking span diffusion term; multiply the blocking quantity diffusion term, the blocking duration diffusion term, and the blocking span diffusion term to obtain the prior blocking diffusion value.

6. The dynamic weighted resource allocation method based on a FIFO queue according to claim 2, characterized in that: The specific steps for calculating the connection contention constraint value corresponding to each request based on the preprocessed connection queue monitoring data are as follows: Extract the number of connection requests waiting in the connection pool, the number of idle connections in the connection pool, the number of database lock-waiting transactions, and the number of active database transactions for each request. Add one to the number of connection requests waiting in the connection pool to get the contention demand item; add one to the number of idle connections in the connection pool to get the idle supply item. Divide the demand term by the supply term to obtain the basic connection contention term; divide the number of database lock-waiting transactions by the number of active database transactions plus one to obtain the lock-waiting diffusion term; add one to the lock-waiting diffusion term to obtain the lock-waiting correction term; multiply the basic connection contention term and the lock-waiting correction term to obtain the corresponding connection contention constraint value.

7. The dynamic weighted resource allocation method based on a FIFO queue according to claim 6, characterized in that: The specific steps for determining the blocking type of each request by combining the prior blocking diffusion value and outputting FIFO blocking constraint data are as follows: When the pre-order blocking diffusion value is greater than the connection contention constraint value, the corresponding request is marked as a pre-order blocking dominant request; When the preceding blocking diffusion value is less than or equal to the connection contention constraint value, read the number of database lock waiting transactions and the number of idle connections in the connection pool from the preceding K records to the record corresponding to the current request; when there are less than K records before the current request, use all records before the current request and the record corresponding to the current request as the judgment record sequence; For a decision record sequence, when the number of database lock waiting transactions in the subsequent record is greater than the number of database lock waiting transactions in the preceding record between any two adjacent records in the decision record sequence, and the number of idle connections in the connection pool in the subsequent record is greater than or equal to the number of idle connections in the connection pool in the preceding record, the corresponding request will be marked as a lock waiting propagation request. When it is determined that between any two adjacent records in the record sequence, the number of idle connections in the connection pool of the subsequent record is less than the number of idle connections in the connection pool of the preceding record, and the number of database lock waiting transactions in the subsequent record is less than or equal to the number of database lock waiting transactions in the preceding record, the corresponding request is marked as a connection squeezing request. When it is determined that between any two adjacent records in the record sequence, the number of database lock waiting transactions in the subsequent record is greater than the number of database lock waiting transactions in the preceding record, and the number of idle connections in the connection pool in the subsequent record is less than the number of idle connections in the connection pool in the preceding record, the corresponding request is marked as a composite contention request. Otherwise, mark the corresponding request as a non-blocking request; And generate a sequence of blocking type markers; The FIFO blocking constraint data is output by combining the preceding blocking diffusion value, connection contention constraint value, and blocking type label sequence corresponding to each request according to the FIFO request sequence.

8. The dynamic weighted resource allocation method based on a FIFO queue according to claim 7, characterized in that: The specific steps for calculating the FIFO order compensation value and dynamic weight allocation value for each request based on FIFO blocking constraint data and preprocessed connection queue monitoring data are as follows: Add one to the queue length value corresponding to the request when it is enqueued, and divide by the order of the request in the FIFO request sequence plus one to obtain the order compensation ratio; add one to the order compensation ratio and take the natural logarithm to obtain the order compression; add one to the preorder blocking diffusion value and take the square root to obtain the blocking diffusion compensation; multiply the order compression and blocking diffusion compensation to obtain the FIFO order compensation value. Add one to the connection competition constraint value and take the natural logarithm to obtain the competition suppression term; divide the FIFO order compensation value by the sum of the competition suppression term and one to obtain the dynamic weight allocation value.

9. A dynamic weighted resource allocation method based on a FIFO queue according to claim 8, characterized in that: The specific steps for constructing the FIFO priority constraint allocation window for this round and determining the priority request set for this round are as follows: Read the blocking type flags corresponding to each request continuously from the head of the FIFO request sequence; count the number of consecutive non-non-blocking requests starting from the head of the queue to obtain the header blocking segment length; add the header blocking segment length to the current number of idle connections in the connection pool to obtain the FIFO order constraint allocation window length for this round; extract consecutive requests corresponding to the current FIFO order constraint allocation window length according to the FIFO request sequence, and sort them in descending order according to the dynamic weight allocation value. If the dynamic weight allocation values ​​are the same, sort them in ascending order according to their order in the FIFO request sequence; then select requests from the sorted results according to the number of idle connections in the current connection pool to determine the priority request set for this round.

10. A dynamic weighted resource allocation method based on a FIFO queue according to claim 9, characterized in that: The specific steps for combining the blocking type to perform connection acquisition qualification allocation and next-round priority retention mark generation, and outputting dynamic weighted resource allocation data are as follows: For the current priority request set, when the request is a pre-blocking dominant request, a connection squeezing request, or a non-blocking request, connection acquisition qualification is directly allocated; when the request is a lock wait diffusion request or a compound contention request, the current request's connection acquisition qualification is suspended, and a priority reserve flag for the next round is generated. For each request to generate a priority retention flag for the next round, record the corresponding consecutive retention rounds; when the consecutive retention rounds are less than the preset retention limit, and the connection contention constraint value corresponding to the current round is greater than the connection contention constraint value corresponding to the previous round, retain the priority retention flag for the next round. When the number of consecutive retention rounds reaches the preset retention limit, or when the connection contention constraint value corresponding to the current round is less than or equal to the connection contention constraint value corresponding to the previous round, the priority retention flag for the next round is canceled, and the corresponding request is used as the normal processing input for the FIFO order constraint allocation window in the next round. Establish a correspondence between request identifiers and dynamic weight allocation values, blocking type flags, next-round priority retention flags, and connection acquisition qualification allocation results to generate dynamic weight resource allocation data; At the start of the next round of resource allocation, requests with the next round priority retention flag are read first and participate in the construction of the next round of FIFO order constraint allocation window.

Images