Methods, devices, equipment, media, and products for lock preemption in distributed systems

Abstract

This application provides a method, apparatus, device, medium, and product for lock acquisition in a distributed system. The method includes: recording the lock acquisition transaction time of a successfully acquired master node; and adjusting the lease duration and renewal interval of the master node based on the lock acquisition transaction time. This method aims to improve the stability of the distributed system.

Description

Technical Field

[0001] This application relates to the field of distributed systems, and in particular to a method, apparatus, device, medium, and product for lock-grabbing in a distributed system. Background Technology

[0002] With the widespread application of distributed systems in financial transactions, e-commerce, and other business areas, system reliability and data consistency have become core requirements. In scenarios such as preventing duplicate charges in financial transaction systems and preventing data conflicts in e-commerce order processing, leader election mechanisms are a technical means to achieve unified task scheduling, resource coordination, and state management. Currently, existing distributed systems use a fixed lease strategy for the term of master nodes, which suffers from poor stability.

[0003] Therefore, improving the stability of distributed systems is an urgent problem to be solved. Summary of the Invention

[0004] The lock-grabbing method, apparatus, device, medium, and product for distributed systems provided in this application are intended to improve the stability of distributed systems.

[0005] In a first aspect, embodiments of this application provide a method for preempting locks in a distributed system, including:

[0006] Record the lock acquisition transaction time of the master node that successfully acquired the lock;

[0007] Based on the time taken for the lock-grabbing transaction, adjust the lease duration and renewal interval of the master node.

[0008] Optionally, adjusting the lease duration and renewal interval of the master node based on the time consumed by the preemption transaction includes:

[0009] Based on the lock acquisition transaction time and the estimated round-trip time between the master node and the lock management server, the updated round-trip time estimate is obtained.

[0010] Based on the updated round-trip delay estimate, the lease duration and renewal interval of the master node are adjusted.

[0011] Optionally, obtaining the updated round-trip time estimate based on the lock acquisition transaction time and the round-trip time estimate between the master node and the lock management server includes:

[0012] Obtain historical round-trip delay estimates and preset smoothing factors;

[0013] The updated round-trip time estimate is obtained based on the lock acquisition transaction time, the historical round-trip time estimate, and the preset smoothing factor.

[0014] Optionally, adjusting the lease duration and renewal interval of the master node based on the updated round-trip delay estimate includes:

[0015] Based on the preset round-trip delay tolerance window parameters and the updated round-trip delay estimate, the lease duration of the master node is adjusted to obtain the adjusted lease duration.

[0016] Based on the adjusted lease duration and the preset renewal frequency guarantee parameters, the renewal interval of the master node is adjusted to obtain the adjusted renewal interval.

[0017] Optionally, adjusting the lease duration of the master node based on a preset round-trip delay tolerance window parameter and the updated round-trip delay estimate to obtain the adjusted lease duration includes:

[0018] The candidate lease duration is obtained based on the round-trip delay tolerance window parameter and the updated round-trip delay estimate.

[0019] When the candidate lease duration is greater than or equal to the lower limit lease duration, the candidate lease duration shall be used as the candidate lease duration;

[0020] When the candidate lease duration is less than the lower limit lease duration, the lower limit lease duration shall be used as the candidate lease duration.

[0021] Optional, also includes:

[0022] If the updated round-trip time estimate is greater than or equal to a preset time delay threshold, an error message is output to indicate that there is a network anomaly.

[0023] Secondly, embodiments of this application provide a lock-grabbing device for a distributed system, comprising:

[0024] The processing module is used to record the lock acquisition transaction time of the master node that successfully acquires the lock;

[0025] The control module is used to adjust the lease duration and renewal interval of the master node based on the time taken for the lock acquisition transaction.

[0026] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0027] The memory stores computer-executed instructions;

[0028] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0029] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0030] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0031] The distributed system lock-acquiring method, apparatus, device, medium, and product provided in this application embodiment record the lock-acquiring transaction time of the master node that successfully acquires the lock, and adjust the lease duration and renewal interval of the master node according to the lock-acquiring transaction time. Compared with the prior art, it breaks through the limitations of traditional fixed leases and heartbeat measurement. By linking lease adjustment with end-to-end transaction delay, it solves the problem of the disconnect between lease configuration and actual operation, thereby achieving the effect of improving the stability of the distributed system. Attached Figure Description

[0032] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0033] Figure 1 A flowchart illustrating a lock-preemption method for a distributed system provided in an embodiment of this application;

[0034] Figure 2 A flowchart illustrating another method for preempting locks in a distributed system provided in this application embodiment;

[0035] Figure 3 A flowchart illustrating another method for preempting locks in a distributed system provided in this application embodiment;

[0036] Figure 4 A schematic diagram of the structure of a lock-grabbing device for a distributed system provided in an embodiment of this application;

[0037] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0038] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0039] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0040] In cloud computing and hybrid cloud environments, distributed systems typically consist of multiple nodes. These nodes need to elect a leader through an election mechanism to coordinate core operations such as task scheduling and resource allocation. For example, in cloud-native architectures, scenarios such as load balancing in microservice clusters, node scheduling in container orchestration systems (such as Kubernetes and K8s), and master-slave switching in distributed databases all rely on leader election mechanisms.

[0041] However, existing distributed systems face many serious challenges in leader election mechanisms when running in complex network environments.

[0042] First, with the increasing demand for cross-regional deployment of distributed systems, and the growing prevalence of deployment models such as intra-city active-active and cross-city hybrid cloud, the network latency (Round-Trip Time, RTT) between nodes exhibits significant differences, ranging from 2ms to 100ms. Furthermore, the network environment is not static; factors such as virtual machine migration, network congestion, and fiber optic cable cutovers can all cause dynamic fluctuations in RTT. This unstable network latency presents significant challenges to the Leader election mechanism, making it difficult to guarantee the timeliness and accuracy of inter-node communication, thereby affecting the accuracy and timeliness of the election results.

[0043] Secondly, traditional leader election mechanisms often employ fixed-lease strategies, such as setting the lease duration to 30 seconds. Under stable network conditions, this fixed-lease strategy can ensure system security to a certain extent, guaranteeing the legitimacy and validity of the master node. However, when network fluctuations occur, the fixed-lease strategy is prone to misjudgment, incorrectly identifying a normal master node as down, thus triggering frequent master node switching operations. This misjudgment not only increases system overhead but can also lead to serious problems such as data inconsistency. Conversely, setting the lease duration too short, such as 5 seconds, while improving adaptability to network fluctuations to some extent, may cause scheduling oscillations due to momentary delays (such as garbage collection (GC) pauses or brief network fluctuations). Scheduling oscillations lead to frequent system state switching and resource reallocation, severely impacting system stability and performance.

[0044] Furthermore, in the actual deployment and operation of distributed systems, operations and maintenance personnel need to manually configure lease parameters based on the system's deployment topology. However, network conditions are dynamic; for example, network traffic varies significantly during peak hours. This static lease parameter configuration method makes it difficult to adjust parameters in a timely manner according to changes in actual network conditions, failing to balance switching speed and system stability. Inappropriate lease parameter configuration may lead to slow or overly sensitive system responses to network changes, thereby affecting the overall operational efficiency and reliability of the distributed system.

[0045] In summary, existing leader election mechanisms in distributed systems have many problems in terms of network dynamism, lease configuration, and operational complexity. An innovative solution is urgently needed to address these challenges and improve the stability and reliability of distributed systems in complex network environments.

[0046] In view of this, embodiments of this application provide a method for preempting locks in a distributed system. By transforming leases from static configuration items into dynamic functions, network latency is measured based on the actual time taken for preempting lock transactions rather than heartbeat packets. The lease duration and renewal interval are adjusted according to the actual time taken for preempting lock transactions, achieving real-time lease optimization in a dynamic network environment. Compared to existing technologies, this method overcomes the limitations of traditional fixed leases and heartbeat measurements. By correlating lease adjustments with end-to-end transaction latency, it solves the problem of the disconnect between lease configuration and actual operation, thereby improving the stability of the distributed system.

[0047] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0048] Figure 1 This is a flowchart illustrating a lock-preemption method for a distributed system provided in an embodiment of this application. Figure 1 As shown, the method includes:

[0049] S101. Record the lock acquisition transaction time of the master node that successfully acquired the lock.

[0050] A master node that successfully acquires the lock refers to the business execution node that successfully acquires the distributed lock in a distributed environment. This may include business nodes responsible for writing data, scheduling nodes responsible for task scheduling, and management nodes responsible for resource allocation.

[0051] A lock-acquiring transaction refers to the complete business process from initiating a lock-acquiring request to receiving a successful lock-acquiring response, which may include request encapsulation, network transmission, lock server verification, and response return. The lock-acquiring transaction time refers to the length of time from the start to the end of the lock-acquiring transaction, which can be obtained, for example, by collecting the difference between the timestamps of the transaction's start and end.

[0052] In this step, the first timestamp can be collected when the lock acquisition request is initiated on the master node, and the second timestamp can be collected when the lock acquisition success response is received. The lock acquisition transaction time can be obtained by calculating the difference between the two timestamps. This does not require additional network probing tools and can be directly recorded based on the end-to-end delay of the actual lock acquisition process.

[0053] One possible implementation is to use the clock module built into the master node to collect the timestamp of the time when the lock acquisition request is initiated and the timestamp of the time when the lock acquisition success response is received. The lock acquisition transaction time of the master node that successfully acquired the lock is calculated based on the collected timestamps, and the calculated lock acquisition transaction time of the master node that successfully acquired the lock is recorded.

[0054] Another possible implementation is to obtain the server-side processing timestamp carried in the lock acquisition response and combine it with the master node's request initiation timestamp to calculate the lock acquisition transaction time. This approach eliminates the influence of the master node's local clock error, improving the reliability of the time recording. The server-side processing timestamp is generated by the lock server after completing the lock acquisition verification and returned along with the response message. After receiving the response, the master node first parses the server-side timestamp and then calculates the difference with the local request timestamp to ensure that the difference reflects the true end-to-end latency.

[0055] S102. Adjust the lease duration and renewal interval of the master node based on the time taken for the lock acquisition transaction.

[0056] The lease duration refers to the effective length of time that the master node holds the distributed lock. During this duration, the lock server will not allocate the lock to other nodes. It can be in different quantities such as milliseconds, seconds, and minutes.

[0057] The renewal interval refers to the time interval at which the master node sends a renewal request to the lock server. The master node needs to complete the renewal before the lease expires in order to continue holding the lock. The unit of the renewal interval is the same as the lease duration.

[0058] Specifically, based on the network and service status reflected by the time taken to acquire the lock, the values ​​of lease duration and renewal interval can be dynamically modified to ensure that the lease duration is sufficient to cover business operation needs and that the renewal interval can guarantee the reliability of renewal.

[0059] In this step, the core input can be the time taken to acquire the lock. By analyzing information such as network round-trip latency and server processing latency included in the time, the corresponding lease duration and renewal interval can be matched to avoid the problem of fixed configuration being out of touch with the actual state.

[0060] One possible implementation is to use a fixed percentage of the time spent on the lock acquisition transaction as the basis for adjusting the lease duration. For example, the lease duration can be adjusted linearly based on the fluctuation range of the time spent. If the time spent increases, the lease should be extended; if the time spent decreases, the lease should be shortened. The adjustment percentage can be set according to the average time spent on the business operation to ensure that the lease duration is always greater than the time spent on the business operation.

[0061] Another possible implementation is to iteratively update the network latency estimate by updating the latency of the preemption transaction. Based on the updated latency estimate, lease and renewal adjustments can be made. This method can smooth out the impact of single latency fluctuations, resulting in more stable configuration parameters, and is suitable for scenarios with large network fluctuations. Optionally, the network latency estimate update can employ a sliding window mechanism, retaining only the latency data of preemption transactions within the most recent period to avoid interference from outdated historical data.

[0062] The method provided in this application, by recording the lock acquisition transaction time of the master node that successfully acquires the lock, adjusts the lease duration and renewal interval of the master node based on the lock acquisition transaction time. Compared with existing technologies, it overcomes the limitations of traditional fixed leases and heartbeat measurement. By linking lease adjustment with end-to-end transaction delay, it solves the problem of lease configuration being out of sync with actual operation, thereby improving the stability of the distributed system. Traditional fixed lease configuration cannot adapt to dynamic network changes, easily leading to resource waste due to excessively long leases or premature lock release due to excessively short leases. However, the dynamic adjustment method based on lock acquisition transaction time can keep up with network and service status changes in real time, matching the optimal lease configuration for different scenarios. At the same time, it eliminates the need for additional heartbeat detection processes, reducing system resource consumption and improving the overall performance of the distributed lock.

[0063] The following section provides a detailed explanation of how the lease duration and renewal interval of the master node are adjusted based on the time taken for the lock-grabbing transaction in step S102. Figure 2 This is a flowchart illustrating another lock-preemption method for a distributed system provided in an embodiment of this application. Figure 2 As shown, the aforementioned step S102 may specifically include:

[0064] S201. Based on the lock acquisition transaction time and the estimated round-trip time between the master node and the lock management server, obtain the updated estimated round-trip time.

[0065] The estimated round-trip time between the master node and the lock management server refers to the estimated time from when the master node sends a request to when it receives a response from the lock server. This value includes network transmission latency between the master node and the server, server processing latency, etc. The update refers to iteratively updating the historical estimates based on the time taken for the current lock acquisition transaction to obtain a latency estimate that better reflects the current state.

[0066] One possible implementation is to subtract a preset server processing latency estimate from the lock acquisition transaction time and use the result as the updated round-trip latency estimate. This approach assumes that the lock acquisition transaction time is mainly composed of network round-trip latency, and the server processing latency can be estimated using a fixed ratio. For example, if historical data shows that the server processing latency is about one-fifth of the lock acquisition transaction time, then four-fifths of the lock acquisition transaction time is used as the round-trip latency estimate to ensure that the estimate is closer to the actual network conditions. The preset server processing latency ratio can be dynamically adjusted through a distributed configuration center. When the server hardware is upgraded or the business logic is optimized, the ratio value can be updated in a timely manner to ensure the estimation accuracy.

[0067] Another possible implementation is to perform a weighted update based on the preemption transaction time, historical round-trip latency estimates, and a preset smoothing factor. This method balances the weights of historical and current data, reducing the impact of single-transaction time fluctuations on the estimate. Specifically, this implementation can be achieved through the following sub-steps:

[0068] S2011, Obtain historical round-trip delay estimates and preset smoothing factors.

[0069] Among them, the historical round-trip time estimate refers to the round-trip time estimate obtained from the last iteration update. It can be stored in the local cache or distributed configuration nodes, and the original value is overwritten after each update.

[0070] The preset smoothing factor is a parameter used to balance the weight of historical estimates and the current transaction latency. Its value ranges from 0 to 1; a larger value indicates a higher weight for the current latency and a lower weight for the historical estimate. It can be dynamically configured based on network fluctuations. For example, in scenarios with low network fluctuations, a smaller smoothing factor is set to reduce the impact of sudden fluctuations on the estimate; in scenarios with high network fluctuations, a larger smoothing factor is set to quickly adapt to changes in network status. The smoothing factor can be configured through a distributed configuration center, supporting hot updates and taking effect without restarting nodes.

[0071] For example, the preset smoothing factor may be the smoothing factor of the Exponentially Weighted Moving Average (EWMA) algorithm, or it may be the smoothing factor of algorithms such as Simple Moving Average (SMA) or Kalman Filter.

[0072] S2012. Based on the time consumed by the preemption transaction, the estimated historical round-trip time, and the preset smoothing factor, the updated estimated round-trip time is obtained.

[0073] In this step, taking the EWMA method to update the round-trip delay estimate as an example, the time taken for the lock-grabbing transaction can be used as the current delay observation value. This value is then weighted and averaged with the historical round-trip delay estimates. The weights are controlled by a preset smoothing factor, and the result is the updated round-trip delay estimate.

[0074] For example, the updated round-trip delay estimate can be calculated using the following formula (1):

[0075] (1)

[0076] in, This is the updated round-trip time estimate. As a preset smoothing factor, The time spent on lock acquisition This is the estimated historical round-trip time delay.

[0077] Optionally, if it is necessary to exclude the impact of server processing latency, the preset server processing latency estimate can be subtracted from the lock acquisition transaction time, and then substituted into the above logic calculation. That is, the updated round-trip latency estimate = preset smoothing factor × (lock acquisition transaction time - server processing latency estimate) + (1 - preset smoothing factor) × historical round-trip latency estimate.

[0078] The estimated server-side processing latency can be obtained by statistically analyzing the server-side processing time of historical lock-grabbing transactions, or by calculating the processing time returned by the lock server in the response. After completing the lock-grabbing verification, the lock server records its own processing start time and end time, calculates the processing time, and returns it to the master node with the response message. The master node directly uses the processing time for calculation, further improving the accuracy of the estimated value and reducing the error caused by the preset ratio.

[0079] S202. Based on the updated round-trip delay estimate, adjust the lease duration and renewal interval of the master node.

[0080] Adjusting the lease duration ensures that the lease duration is sufficient to cover the time required for the master node to complete its business operations, while avoiding excessive lock resource consumption. Adjusting the renewal interval ensures that the master node has enough time to complete the renewal before the lease expires, while avoiding excessively short intervals that would lead to frequent renewals consuming system resources. The input to both adjustment processes is the updated round-trip latency estimate, and the output lease duration and renewal interval are both measured in time units.

[0081] One possible implementation is to set the lease duration to a fixed multiple of the updated round-trip latency estimate, and the renewal interval to a fixed proportion of the lease duration. For example, the lease duration could be set to ten times the round-trip latency estimate, and the renewal interval to one-fifth of the lease duration. This approach is simple to implement, can quickly adapt to latency changes, and is suitable for scenarios with low configuration complexity requirements. The fixed multiple and proportion can be configured according to the business scenario. For example, for latency-sensitive businesses, a larger lease multiple can be set to ensure that business operations have enough time to complete, while for businesses with high resource utilization requirements, a smaller lease multiple can be set to reduce the time that locks resources are occupied.

[0082] Another possible implementation is to adjust the lease duration and renewal interval separately using preset tolerance parameters. This method can more accurately adapt to business needs and reliability requirements. Specifically, this implementation can be achieved through the following sub-steps:

[0083] S2021. Based on the preset round-trip delay tolerance window parameters and the updated round-trip delay estimate, adjust the lease duration of the master node to obtain the adjusted lease duration.

[0084] The round-trip delay tolerance window refers to the time margin allowed for the master node to complete business operations within the time it holds the lock, and can be set according to the complexity of the business operations.

[0085] For example, for complex business operations involving multi-step calculations and cross-node data synchronization, a larger tolerance window can be set to ensure that the business operation has enough time to complete; for business operations involving only simple data writing and local verification, a smaller tolerance window can be set to reduce the time lock resources are occupied.

[0086] The preset round-trip delay tolerance window parameter is an adjustment parameter used to adjust the round-trip delay tolerance window. The preset round-trip delay tolerance window can be dynamically adjusted by adjusting this parameter.

[0087] For example, the round-trip delay tolerance window can be set according to a multiple of the round-trip delay estimate. For instance, the round-trip delay tolerance window can be set to 3 times the round-trip delay estimate, then the round-trip delay tolerance window parameter is 3, which represents adjusting the round-trip delay tolerance window to 3 times the round-trip delay estimate.

[0088] For example, a specific value can be set as the round-trip delay tolerance window. Different round-trip delay tolerance window values ​​can be set based on different estimated round-trip delay values. For instance, when the estimated round-trip delay is 0.5 seconds, the tolerance window is 1 second; when the estimated round-trip delay is 0.3 seconds, the tolerance window is 0.7 seconds, and so on. There can be a preset mapping relationship between the two. In this case, the round-trip delay tolerance window parameters are 1, 0.7, etc.

[0089] When the round-trip delay tolerance window is set based on a multiple of the round-trip delay estimate, the lease duration of the master node can be adjusted by multiplying the preset round-trip delay tolerance window parameter and the updated round-trip delay estimate to obtain the adjusted lease duration.

[0090] When a specific value is set as the round-trip delay tolerance window, the sum of the updated round-trip delay estimate and the tolerance window can be used as the lease duration to ensure that the lease duration is sufficient to cover the round-trip delay and business operation time.

[0091] Optionally, the round-trip delay tolerance window parameter mentioned above can also be set independently based on the average time of historical business operations. For example, if the average time of business operations in a recent period is found to be a certain fixed length, this length can be directly used as the tolerance window to ensure that the lease duration can cover the basic needs of business operations.

[0092] S2022. Based on the adjusted lease duration and the preset renewal frequency guarantee parameters, adjust the renewal interval of the master node to obtain the adjusted renewal interval.

[0093] The preset renewal count guarantee parameter refers to the minimum number of renewals that the master node needs to complete before the lease expires, which can be set according to the system's reliability requirements.

[0094] For example, in scenarios like financial transactions where high reliability is required, a higher number of renewal attempts can be set to ensure sufficient retry opportunities in case of a renewal failure, preventing premature lock release. Conversely, in ordinary data synchronization scenarios with lower reliability requirements, a lower number of renewal attempts can be set to reduce the consumption of system resources by renewal requests.

[0095] Specifically, the adjusted lease duration can be divided by the renewal frequency guarantee parameter to obtain the renewal interval, ensuring sufficient time to complete the specified number of renewals within the lease period. For example, the adjusted renewal interval can be calculated using the following formula (2):

[0096] (2)

[0097] in, For the adjusted extension interval, For the adjusted lease duration, Parameters to ensure the number of renewals.

[0098] Optionally, to reduce frequent requests caused by excessively short renewal intervals, a lower limit for the renewal interval can be set. If the calculated result is less than the lower limit, the lower limit will be used as the final renewal interval. The lower limit can be set according to the minimum interval requirement of network requests to avoid network congestion caused by excessively frequent requests.

[0099] The method provided in this application dynamically updates the estimated round-trip latency between the master node and the lock management server by adjusting the lease duration and renewal interval based on the updated estimate, thus achieving dynamic matching of lease configuration with network environment and service status. This approach avoids the problem of fixed lease configurations failing to adapt to network fluctuations. Simultaneously, it reduces the impact of single-transaction latency fluctuations on the estimated value through a smoothing factor, improving the stability of lease adjustments and reducing the probability of premature release or resource waste of distributed locks. Furthermore, it eliminates the need for additional heartbeat detection processes, reducing system resource consumption and improving the overall performance of the distributed system. It is applicable to various distributed lock scenarios, including but not limited to distributed databases, distributed caches, and distributed task scheduling.

[0100] The following section details how, in step S2021, the lease duration of the master node is adjusted based on the preset round-trip delay tolerance window parameters and the updated round-trip delay estimate to obtain the adjusted lease duration. Figure 3 This is a flowchart illustrating another lock-preemption method for a distributed system provided in an embodiment of this application. Figure 3 As shown, the aforementioned step S2021 may specifically include:

[0101] S301. Based on the round-trip delay tolerance window parameters and the updated round-trip delay estimate, obtain the candidate lease duration.

[0102] The candidate lease duration refers to the initially calculated lease duration, which can be, for example, the product of the updated round-trip delay estimate and the round-trip delay tolerance window parameter, or the sum of the updated round-trip delay estimate and the round-trip delay tolerance window. The following example illustrates this with the candidate lease duration being the product of the updated round-trip delay estimate and the round-trip delay tolerance window parameter.

[0103] The candidate lease duration is obtained by multiplying the round-trip delay tolerance window parameter by the updated round-trip delay estimate. For example, the candidate lease duration can be calculated using the following formula (3):

[0104] (3)

[0105] in, For the candidate lease duration, For round-trip delay tolerance window parameters, such as The value of is 3.

[0106] S302. When the candidate lease duration is greater than or equal to the lower lease duration, the candidate lease duration shall be used as the adjusted lease duration.

[0107] The minimum lease duration refers to the minimum valid time the master node holds the lock. It can be set according to the shortest possible time for business operations, ensuring that the master node has sufficient time to complete the minimum number of business operations. This minimum lease duration can be configured through a distributed configuration center, supporting hot updates. When business operation processes change, the minimum duration can be updated promptly to ensure the accuracy of the configuration.

[0108] For example, if the business only involves simple data verification and local status updates, a shorter lower limit duration can be set; if the business involves multi-node data synchronization and complex business logic judgment, a longer lower limit duration can be set.

[0109] In this step, the candidate lease duration can be compared with the lower limit lease duration. If the candidate lease duration is longer than the lower limit lease duration, it means that the candidate lease duration meets the minimum value of the lease, and the candidate lease duration can be used as the final lease duration.

[0110] S303. When the candidate lease duration is less than the minimum lease duration, the minimum lease duration shall be used as the adjusted lease duration.

[0111] In this step, the candidate lease duration can be compared with the lower limit lease duration. If the candidate lease duration is less than the lower limit lease duration, it means that the candidate lease duration does not meet the minimum lease value. The lower limit lease duration can be used as the final lease duration to avoid the problem that the lease duration is too short due to low network latency, which cannot cover basic business operations and improve system stability.

[0112] Optionally, when business operation processes are simplified or optimized, the lower limit duration can be lowered in a timely manner to reduce the time locked resources are occupied; when the complexity of business operation processes increases, the lower limit duration can be raised in a timely manner to ensure that business operations have sufficient time to complete. The adjustment of the lease lower limit duration can be completed automatically based on business monitoring data. For example, when the shortest execution time of a business operation is detected to have increased recently, the lease lower limit duration can be automatically raised.

[0113] The method provided in this application ensures the minimum lease duration by setting a minimum lease duration, thus avoiding the risk of service interruption caused by excessively short leases in extreme scenarios. At the same time, it combines round-trip delay estimates and tolerance windows to calculate candidate lease durations, ensuring that the lease duration can fit the actual network and service status. This achieves a balance between flexibility and reliability, is applicable to various complex distributed scenarios, and can match the optimal lease configuration for different services, thereby improving the stability and reliability of distributed systems.

[0114] In one possible implementation, the method may further include: outputting an error message if the updated round-trip delay estimate is greater than or equal to a preset delay threshold.

[0115] The error message is used to indicate that there is a network error.

[0116] If the updated round-trip latency estimate is greater than or equal to the preset latency threshold, it indicates that the network or service status between the current master node and the lock server is abnormal. This could be due to network link congestion, lock server performance bottlenecks, network equipment failures, or other issues that could lead to lease adjustment failures or business operation timeouts.

[0117] In this step, the round-trip time (RTT) estimate can be continuously monitored. After each RTT estimate is updated, the updated RTT estimate is compared with a preset latency threshold to determine if there is a network anomaly.

[0118] When it is necessary to output an error message, the error status information can be encapsulated into a standardized message format and sent to the monitoring system, alarm module, or business logs. The message content may include, for example, the updated round-trip latency estimate, the preset latency threshold, the current lock acquisition transaction time, the master node identifier, and the lock server identifier, facilitating quick problem location by operations and maintenance personnel.

[0119] Optionally, the preset latency threshold can be set based on the maximum value of historical normal latency, or it can be dynamically adjusted through the real-time statistical latency dynamic range. For example, a sliding window can be used to count the maximum latency in a recent period, and a fixed multiple of this maximum value can be used as the threshold to ensure the accuracy of anomaly detection.

[0120] The preset latency threshold can be configured through a distributed configuration center, which supports setting different thresholds according to different business types, enabling fine-grained anomaly monitoring.

[0121] Optionally, exception notifications can be sent asynchronously to avoid affecting the normal execution of the lease adjustment process. Furthermore, a retry mechanism can be configured to automatically retry if transmission fails, ensuring that exception information is received promptly. The receiving end of the exception notification can be configured with alarm rules to automatically trigger alarm actions upon receiving an exception notification, such as sending emails, SMS messages, or instant messages, to notify operations and maintenance personnel to handle the issue promptly and prevent the spread of the exception status leading to business failures.

[0122] Figure 4 A schematic diagram of the structure of a lock-grabbing device for a distributed system provided in this application is shown in the embodiments. Figure 4 As shown, the lock-grabbing device for the distributed system provided in this embodiment includes: a processing module 11 and a control module 12. In one possible implementation, it may also include: an output module 13.

[0123] Processing module 11 is used to record the lock acquisition transaction time of the master node that successfully acquires the lock.

[0124] Control module 12 is used to adjust the lease duration and renewal interval of the master node based on the time taken for the lock acquisition transaction.

[0125] Optionally, control module 12 is specifically used to obtain an updated round-trip time estimate based on the lock acquisition transaction time and the estimated round-trip time between the master node and the lock management server. Based on the updated round-trip time estimate, the lease duration and renewal interval of the master node are adjusted.

[0126] Optionally, the control module 12 is specifically used to obtain historical round-trip time estimates and preset smoothing factors. Based on the lock-grabbing transaction time, historical round-trip time estimates, and preset smoothing factors, an updated round-trip time estimate is obtained.

[0127] Optionally, the control module 12 is specifically used to adjust the lease duration of the master node according to the preset round-trip delay tolerance window parameters and the updated round-trip delay estimate, to obtain the adjusted lease duration. Based on the adjusted lease duration and the preset renewal frequency guarantee parameters, the renewal interval of the master node is adjusted to obtain the adjusted renewal interval.

[0128] Optionally, the control module 12 is specifically used to obtain the candidate lease duration based on the round-trip delay tolerance window parameter and the updated round-trip delay estimate. When the candidate lease duration is greater than or equal to the lower lease duration, the candidate lease duration is used as the candidate lease duration. When the candidate lease duration is less than the lower lease duration, the lower lease duration is used as the candidate lease duration.

[0129] Optionally, the output module 13 is used to output an error message when the updated round-trip delay estimate is greater than or equal to a preset delay threshold. The error message is used to indicate that there is a network error.

[0130] The lock-grabbing device for the distributed system provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0131] Figure 5 This is a schematic diagram of an electronic device provided in an embodiment of this application. The electronic device is used to execute the aforementioned lock-preemption method in a distributed system. Figure 5 As shown, the electronic device 500 may include at least one processor 501, a memory 502, and a communication interface 503.

[0132] The memory 502 is used to store programs. Specifically, the program may include program code, which includes computer operation instructions.

[0133] Memory 502 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0134] The processor 501 is used to execute computer execution instructions stored in the memory 502 to implement the method described in the foregoing method embodiments. The processor 501 may be a CPU, an Application Specific Integrated Circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.

[0135] Processor 501 can communicate and interact with external devices through communication interface 503. In specific implementations, if communication interface 503, memory 502, and processor 501 are implemented independently, they can be interconnected via a bus to complete communication. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc., but this does not imply that there is only one bus or one type of bus.

[0136] Optionally, in a specific implementation, if the communication interface 503, memory 502, and processor 501 are integrated on a single chip, then the communication interface 503, memory 502, and processor 501 can communicate through an internal interface.

[0137] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0138] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0139] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0140] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0141] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0142] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0143] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0144] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0145] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0146] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A method for preempting locks in a distributed system, characterized in that, include: Record the lock acquisition transaction time of the master node that successfully acquired the lock; Based on the time taken for the lock-grabbing transaction, adjust the lease duration and renewal interval of the master node.

2. The method according to claim 1, characterized in that, The step of adjusting the lease duration and renewal interval of the master node based on the time consumed by the preemption transaction includes: Based on the lock acquisition transaction time and the estimated round-trip time between the master node and the lock management server, the updated round-trip time estimate is obtained. Based on the updated round-trip delay estimate, the lease duration and renewal interval of the master node are adjusted.

3. The method according to claim 2, characterized in that, The step of obtaining the updated round-trip time estimate based on the lock acquisition transaction time and the round-trip time estimate between the master node and the lock management server includes: Obtain historical round-trip delay estimates and preset smoothing factors; The updated round-trip time estimate is obtained based on the lock acquisition transaction time, the historical round-trip time estimate, and the preset smoothing factor.

4. The method according to claim 2, characterized in that, The step of adjusting the lease duration and renewal interval of the master node based on the updated round-trip delay estimate includes: Based on the preset round-trip delay tolerance window parameters and the updated round-trip delay estimate, the lease duration of the master node is adjusted to obtain the adjusted lease duration. Based on the adjusted lease duration and the preset renewal frequency guarantee parameters, the renewal interval of the master node is adjusted to obtain the adjusted renewal interval.

5. The method according to claim 4, characterized in that, The step of adjusting the lease duration of the master node according to the preset round-trip delay tolerance window parameter and the updated round-trip delay estimate to obtain the adjusted lease duration includes: The candidate lease duration is obtained based on the round-trip delay tolerance window parameter and the updated round-trip delay estimate. When the candidate lease duration is greater than or equal to the lower limit lease duration, the candidate lease duration shall be used as the candidate lease duration; When the candidate lease duration is less than the lower limit lease duration, the lower limit lease duration shall be used as the candidate lease duration.

6. The method according to any one of claims 1-5, characterized in that, Also includes: If the updated round-trip time estimate is greater than or equal to a preset time delay threshold, an error message is output to indicate that there is a network anomaly.

7. A lock-grabbing device for a distributed system, characterized in that, include: The processing module is used to record the lock acquisition transaction time of the master node that successfully acquires the lock; The control module is used to adjust the lease duration and renewal interval of the master node based on the time taken for the lock acquisition transaction.

8. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-6.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method described in any one of claims 1-6.

Images