Implementation system of elastic lock of distributed system

Abstract

The invention provides an implementation system of a distributed system elastic lock. The implementation system comprises a resource manager and a distributed lock controller, the resource manager comprises a resource management unit and a distributed lock agent; the distributed lock controller comprises a data acquisition unit, a data analysis unit and a control unit; the distributed lock controller collects load data bearing Pod corresponding to the service instance and determines the occupied time of a lock allocated to the service instance in the current state so as to generate lock type switching logic and lock number scaling logic, and the resource manager receives instructions output by executing the lock type switching logic and the lock number scaling logic respectively and sends the instructions to the service instance. Therefore, an application or lock release request is initiated to the control unit. According to the method and the system, the lock distributed by the service instance running in the distributed system is elastically expanded and contracted based on the lock type switching logic and the lock quantity expansion and contraction logic according to the load data of the Pod in the cloud native architecture, and meanwhile, the dynamic switching of the lock types and the dynamic change of the lock quantity are realized.

Description

Technical Field

[0001] This invention relates to the field of distributed system technology, and in particular to an implementation system for a resilient lock in a distributed system. Background Technology

[0002] For distributed systems and cloud platforms built upon them, resources such as CPU, cloud disks, and bandwidth all fall under the category of resources. Most events throughout the cloud platform's lifecycle are resource scheduling events. Distributed locks are typically used in distributed systems to ensure that only one thread can execute the same distributed lock at any given time. Distributed locks aim to prevent interference between multiple processes within a distributed system. From the perspective of timely request-response, distributed locks are divided into blocking locks and non-blocking locks. With blocking locks, when multiple threads simultaneously call a locked method, all threads are queued for processing. With non-blocking locks, when multiple threads simultaneously call a locked method, if one thread acquires the lock first while other threads have not, the other threads returning immediately will not receive a response until the first thread to acquire the lock releases it.

[0003] Cloud platforms have a vast number of distributed lock application scenarios. In cloud platforms, instances responding to the creation, deregistration, and migration of cloud hosts and disks typically use the same type of lock with a fixed number of locks. This makes it impossible to adjust the lock type according to different business needs during the response process, and also prevents the use of too many or too few locks due to varying node loads, thus failing to meet business requirements. Although existing technologies allow operations personnel to manually switch lock types and adjust the number of locks in the Cloud Management Platform (CMP), this still cannot effectively and accurately schedule resources in the distributed system, and the manual switching of lock types and adjustments can cause business interruptions, thus negatively impacting the user experience.

[0004] In view of this, it is necessary to improve the locking technology of existing distributed systems to solve the above problems. It should be noted that the above introduction to the background technology is only for the purpose of clearly and completely explaining the technical solutions of this application and facilitating understanding by those skilled in the art. It should not be assumed that these technical solutions are known to those skilled in the art simply because they have been described in the background technology section of this application. Summary of the Invention

[0005] The purpose of this invention is to disclose an implementation system for elastic locks in distributed systems, in order to solve the aforementioned technical defects existing in distributed systems in the prior art, and especially to solve the technical problems in the prior art of distributed systems and cloud platforms based on distributed systems that cannot dynamically switch lock types and cannot dynamically scale the number of locks during the lock type determination process, and to avoid the technical problems of excessively long application response time and application response failure in disaster recovery and backup scenarios of distributed systems.

[0006] To achieve the above objectives, the present invention provides an implementation system for a distributed system elastic lock, the implementation system comprising: a resource manager and a distributed lock controller;

[0007] The resource manager includes a resource management unit and a distributed lock agent;

[0008] The distributed lock controller includes a data acquisition unit, a data analysis unit, and a control unit;

[0009] The distributed lock controller collects the load data of the Pod corresponding to the service instance and determines the time that the lock allocated to the service instance is occupied in the current state, so as to generate lock type switching logic and lock quantity scaling logic. The resource manager receives the instructions output by executing the lock type switching logic and lock quantity scaling logic respectively, so as to initiate a lock request or release request to the control unit.

[0010] As a further improvement of the present invention, the load data is defined by one or any combination of CPU utilization, memory utilization, and API response efficiency.

[0011] As a further improvement of the present invention, the data acquisition unit acquires the load data of the Pod corresponding to the service instance and the historical occupancy time data of the lock; the data analysis unit acquires the load data of the Pod corresponding to the service instance and the historical occupancy time data of the lock to determine the lock type and number of locks adapted to the service instance in the current state.

[0012] The control unit obtains the lock type and number of locks that the service instance is adapted to in the current state from the data analysis unit, and notifies the distributed lock agent.

[0013] As a further improvement of the present invention, the resource management unit manages the resources on which the service instance depends, and initiates lock request or lock release request to the distributed lock agent at a set period, so as to synchronize the lock request or lock release request to the control unit through the distributed lock agent.

[0014] As a further improvement of the present invention, the distributed lock controller further includes a data recording unit;

[0015] The data acquisition unit accesses the data recording unit at a set period to query the number of times the locks assigned to the service instance are used and the duration of each use. Records of lock requests initiated or released by the control unit are saved to the data recording unit.

[0016] As a further improvement of the present invention, the distributed lock agent runs lock quantity scaling logic, the lock quantity scaling logic including:

[0017] A default number of locks are created for the service instance, and upper and lower threshold values ​​for load data are set. After obtaining the load data of the Pod corresponding to the service instance from the distributed lock controller, the relationship between the load data and the upper threshold values ​​is determined.

[0018] When the load data is higher than or equal to the upper limit threshold, it is further determined whether the locks allocated to the service instance in the current state have been exhausted. If so, the number of locks allocated to the service instance is increased; otherwise, the default number of locks created for the service instance is maintained.

[0019] When the load data is less than the upper limit threshold, maintain the default number of locks created for the service instance.

[0020] As a further improvement of the present invention, the lock quantity scaling logic further includes: determining whether the load data is less than the lower threshold.

[0021] When the load data is less than the lower threshold, it is further determined whether the locks allocated to the service instance in the current state have been exhausted. If so, the number of locks created for the service instance is maintained at the default number. If not, the number of locks created for the service instance is reduced.

[0022] When the load data is greater than or equal to the lower threshold, maintain the default number of locks created for the service instance.

[0023] As a further improvement of the present invention, the data recording unit operates lock type switching logic, the lock type switching logic including:

[0024] Record the duration for which locks allocated to the service instance are held in the current state.

[0025] Set the average usage time of the assigned lock during the operation of the service instance.

[0026] Calculate the blocking time and compare the blocking time with the average usage time. When the blocking time is less than or equal to a preset ratio of the average usage time, switch the non-blocking lock to a blocking lock; when the blocking time is greater than the preset ratio of the average usage time, switch the blocking lock to a non-blocking lock.

[0027] As a further improvement of the present invention, the data recording unit is configured as a database, and the implementation system is integrally deployed on a cloud management platform.

[0028] As a further improvement of the present invention, the preset ratio is 5-10%.

[0029] Compared with the prior art, the beneficial effects of the present invention are:

[0030] The implementation system of the distributed system elastic lock disclosed in this application realizes the elastic scaling of the locks allocated to the service instances running in the distributed system according to the load data of the Pods in the cloud native architecture based on the lock type switching logic and the lock quantity scaling logic. At the same time, it realizes the dynamic switching of the lock type and the dynamic change of the lock quantity, so as to more accurately conform to the load data of the Pods, and thus avoid various adverse situations such as access delay, resource waste, or resources being unable to support the service instances during the various access requests initiated by the user and various running stages of the service instances. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Figure 1 It is the overall topology diagram of the implementation system of the distributed system elastic lock of the present invention;

[0032] Figure 2 is Figure 1 the topology diagram of the distributed lock proxy shown;

[0033] Figure 3 It is the detailed flowchart of the lock quantity scaling logic;

[0034] Figure 4 It is the detailed flowchart of the lock type switching logic. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0035] The present invention will be described in detail below with reference to the embodiments shown in the drawings. However, it should be noted that these embodiments are not limitations of the present invention, and any equivalent transformation or substitution in terms of function, method, or structure made by those of ordinary skill in the art based on these embodiments shall fall within the protection scope of the present invention.

[0036] Refer Figures 1 to 4As shown in the figure, this embodiment discloses a specific implementation of the implementation system 100 of the distributed system elastic lock (hereinafter referred to as "implementation system 100" for short). The implementation system of the distributed system elastic lock is deployed on the cloud management platform (CMP) 200. Briefly speaking, the implementation system 100 in this application realizes the dynamic change of the number of locks and the dynamic switching of lock types, so as to form the elastic scaling of the locks in this application, and can reasonably schedule and use the resources contained in the cloud platform. Elastic scaling includes elastic expansion and elastic contraction. Elastic expansion is when the cloud platform responds to an increase in the traffic volume of a service, by elastically increasing the resources for the responding service to effectively respond to the service; elastic contraction is when the cloud platform responds to a decrease in the traffic volume of a service, automatically recycling the resources for the responding service to avoid resource waste, so that elastic scaling realizes the expansion and contraction processing of resources. The implementation system 100 in this embodiment can perform elastic scaling based on the lock type switching logic and the lock number scaling logic, and at the same time realizes the dynamic switching of lock types and the dynamic change of lock numbers, so as to more accurately conform to the load data of the Pod. The service instance carries its corresponding business logic through one or more Pods.

[0037] As shown Figure 1 As shown, the implementation system 100 in this embodiment includes: a resource manager 10 and a distributed lock controller 20. The resource manager 10 is connected to the resource pool 30, and the distributed lock controller 20 is connected to multiple working nodes 41 to 4i, where the parameter i takes a positive integer greater than or equal to 1. The resource manager 10 includes a resource management unit 11 and a distributed lock proxy 12. The distributed lock controller 20 includes a data collection unit 21, a data analysis unit 22 and a control unit 24. The distributed lock controller 20 collects the load data of the Pod corresponding to the service instance (that is, Service Instance), and determines the time when the lock allocated to the service instance in the current state is occupied, so as to generate the lock type switching logic and the lock number scaling logic. The resource manager 10 receives the instructions respectively output by executing the lock type switching logic and the lock number scaling logic, so as to initiate a lock application or release request to the control unit 24, where the load data is defined by one or any combination of CPU usage rate, memory usage rate, and API response efficiency. Events such as event one 111 and event two 112 run in the resource management unit 11. An event can be understood as a service (or application) defined by various resources configured for the service instance, and includes the type of lock and the number of locks.

[0038] The aforementioned services (or applications), such as creating cloud hosts or managing cloud disks, require specific lock types. When a blocking lock is invoked, the current thread is suspended until the result is returned. When a non-blocking lock is invoked, the current thread is not blocked if the result cannot be obtained immediately; in this case, the caller needs to query the processing status through a periodic polling mechanism. Therefore, events such as creating cloud hosts or managing cloud disks require a specific number of locks of a specific type. Users who allocate locks first will have priority over users who allocate locks later in executing the service instance they expect. More specifically, creating cloud disks takes longer, so blocking locks are preferred, but the time will increase dramatically when the system load is too high. If a large number of blocking locks are configured for users at this time, it will further increase the system load, leading to a vicious cycle. Conversely, in disaster recovery scenarios, cloud disk management (e.g., creating cloud disks) takes less time. If the lock type is kept as either a blocking lock or a non-blocking lock, a mismatch will occur, resulting in a long lock acquisition time for creating small amounts of cloud disks, which may lead to cloud disk creation failure. The implementation system 100 disclosed in this embodiment is intended to solve the aforementioned problems, but is not limited to the two typical scenarios listed above.

[0039] Data acquisition unit 21 collects load data and historical lock occupancy time data of the Pod corresponding to the service instance; data analysis unit 22 obtains the load data and historical lock occupancy time data of the Pod corresponding to the service instance to determine the lock type and number of locks suitable for the service instance in the current state. Control unit 24 obtains the lock type and number of locks suitable for the service instance in the current state from data analysis unit 22 and notifies distributed lock agent 12. Control unit 24 initiates a query request to data analysis unit 22 to query the lock type, and data analysis unit 22 returns a response to control unit 24 indicating the lock type. Control unit 24 records the data generated each time the lock is used (i.e., lock acquisition / release data) and sends it to data recording unit 23 for storage.

[0040] Resource management unit 11 manages the resources on which service instances depend and periodically sends lock requests to distributed lock agent 12 to synchronize these requests to control unit 24. Distributed lock agent 12 provides agent functionality for resource controller 10 to acquire locks and provides lock request and release functionality to control unit 24.

[0041] The distributed lock controller 20 further includes a data recording unit 23. The data acquisition unit 21 accesses the data recording unit 23 at a set period to query the usage times and the duration of each use of the locks assigned to the service instances. The records of the control unit 24 initiating lock application or release requests are saved to the data recording unit 24. Specifically, the data recording unit 23 in this embodiment is configured as a database (Date Base). Optionally, the data recording unit 23 can be configured as a Redis database to facilitate the establishment of an indirect session process with the distributed lock agent 12 through the control unit 24. Further, Figure 2 As shown, the distributed lock agent 12 includes a Queue 121 and a Filter 122. When the Queue 121 receives multiple lock application / release requests, it can ensure that the messages corresponding to the lock application / release requests are processed in FIFO order and only once, and the Queue 121 uniformly manages multiple lock application / release requests. As described below, when the type and quantity of the locks do not need to change, the received lock application / release requests will be filtered by the Filter 122 and the control unit 24 will not be notified. In particular, when the number of service instances running in the cloud platform is small and the load data corresponding to the Pods is not high, by configuring the introduction of the distributed lock agent 12 with the Queue 121, the disordered state existing in the process of lock application and release is solved, and the resource waste caused by the aforementioned disordered state is avoided.

[0042] Therefore, at this time, the distributed lock agent 12 will not initiate an event of lock application / release request to the control unit 24. At the same time, when the type and quantity of the locks need to change, the distributed lock agent 12 will initiate an event of lock application / release request to the control unit 24. Therefore, through the aforementioned distributed lock agent 12, it is realized to avoid invalid and overly frequent lock application / release requests to the control unit 24. Figure 2 The Filter 122 in it is just a logical expression. In actual software engineering, the Filter 122 is regarded as an internal logic unit built inside the Queue 121.

[0043] Refer to Figure 3 As shown, the distributed lock agent 12 runs a lock quantity scaling logic, and the lock quantity scaling logic includes steps S300 to step S311.

[0044] Step S300: Start.

[0045] Step S301: Create a default quantity of locks for the service instance.

[0046] Step S303: Obtain the load data of the resources associated with the service instance in the cloud platform.

[0047] Step S304: Periodically test the load data of the foregoing resources based on a timing policy. Thus, determine whether the load data can meet the actual requirements of the service instance. Then, set the upper threshold and lower threshold of the load data. After obtaining the load data of the Pod corresponding to the service instance from the distributed lock controller 20, execute Step S304: Judge the size relationship between the load data and the upper threshold.

[0048] If so, that is, when the load data is higher than or equal to the upper threshold, jump to execute Step S306; if not, jump to execute Step S305. Step 306: Judge whether the locks allocated to the service instance in the current state are consumed. If so, jump to execute Step S307: Expand the number of locks allocated to the service instance. If not, jump to execute Step S305: Keep the number of locks created by default for the service instance, and thus do not perform expansion on the number of locks. However, at this time, it is necessary to consider whether to perform reduction on the number of locks. Therefore, after Steps S307 and S305 are executed, both need to jump to execute Step S308 to judge whether the load data is less than the lower threshold. Step S305 jumps along arrow 315 to Step S308.

[0049] If so, that is, when the load data is less than the upper threshold, keep the number of locks created by default for the service instance and jump to execute Step S310; if not, that is, when the load data is greater than or equal to the upper threshold, jump to execute Step S309: Do not perform reduction on the number of locks, and then jump to Step 312: End.

[0050] The lock number scaling logic further includes: Step 308: Judge whether the load data is less than the lower threshold.

[0051] If so, when the load data is less than the lower threshold, further judge whether the locks allocated to the service instance in the current state are consumed, and jump to execute Step S310. If so (that is, the locks allocated to the service instance in the current state have been consumed), jump to execute Step 309: Keep the number of locks created by default for the service instance (that is, do not perform reduction on the number of locks). If not (that is, the locks allocated to the service instance in the current state have not been consumed), jump to execute Step S311: Reduce the number of locks created by default for the service instance; when the load data is greater than or equal to the lower threshold, jump to execute Step S309 to keep the number of locks created by default for the service instance.

[0052] Step S312: End. Thus, the lock number scaling logic is executed.

[0053] See Figure 4As shown, the data recording unit 23 runs the lock type switching logic, which includes steps S400 to S406.

[0054] Step S400: Begin.

[0055] Step S401: Record the time that the lock allocated to the service instance in the current state is occupied, and denot it as AUT (Average Used Time).

[0056] Step S402: Set the average usage time of the assigned lock during the operation of the service instance.

[0057] Step S403: Calculate the blocking time, which is the fastest time to acquire a lock from the existing locks. It can be considered as the waiting time required for the most recent lock to release, and is denoted as BT (Block Time). BT = AUT - (Current Time - Start Time of Occupancy). Specifically, the aforementioned preset ratio is 5-10%, and can be arbitrarily adjusted by the user, with 5% selected as an example. Compare the blocking time with the average usage time. When the blocking time is less than or equal to the preset ratio of the average usage time, proceed to step S404: switch the non-blocking lock to a blocking lock; when the blocking time is greater than the preset ratio of the average usage time, proceed to step S405: switch the blocking lock to a non-blocking lock. Step S406: End.

[0058] The main program code for implementing the aforementioned lock type switching logic is shown below.

[0059]

[0060] Therefore, the implementation system 100 disclosed in this application realizes dynamic and fine-grained configuration of distributed locks (including blocking locks and non-blocking locks) in cloud-native architecture, which can meet the needs of using different types and numbers of locks in different scenarios. Thus, it can effectively support the dynamic scaling characteristics of cloud-native architecture, and can configure locks of fixed types and numbers without fixing them, so as to better adapt to the creation, deployment, operation and resource reclamation of one or more service instances.

[0061] In particular, the implementation system 100 in this embodiment reliably responds to one or more parallel tasks corresponding to access requests or operations initiated by users in the virtual machine (VM) on the cloud platform client. This is especially important in scenarios with stringent real-time and security requirements, such as online payment systems for shopping websites, settlement systems for financial institutions, and electronic ticketing systems. The aforementioned tasks correspond to service instances, and service instances are treated as one or more program / computer events running on the cloud platform.

[0062] The detailed descriptions listed above are merely specific descriptions of feasible embodiments of the present invention, and are not intended to limit the scope of protection of the present invention. All equivalent embodiments or modifications made without departing from the spirit of the present invention should be included within the scope of protection of the present invention.

[0063] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered in all respects as exemplary and non-limiting, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims.

[0064] Furthermore, it should be understood that although this specification describes embodiments, not every embodiment contains only one independent technical solution. This narrative style is merely for clarity. Those skilled in the art should consider the specification as a whole, and the technical solutions in each embodiment can also be appropriately combined to form other embodiments that can be understood by those skilled in the art.

Claims

1. A system for implementing a resilient lock in a distributed system, characterized in that, The implementation system includes: a resource manager and a distributed lock controller; The resource manager includes a resource management unit and a distributed lock agent; The distributed lock controller includes a data acquisition unit, a data analysis unit, and a control unit; The distributed lock controller collects the load data of the Pod corresponding to the service instance and determines the time that the lock allocated to the service instance is occupied in the current state, so as to generate lock type switching logic and lock quantity scaling logic. The resource manager receives the instructions output by executing the lock type switching logic and lock quantity scaling logic respectively, so as to initiate a lock request or release request to the control unit.

2. The implementation system according to claim 1, characterized in that, The load data is defined by one or more of the following: CPU utilization, memory utilization, and API response efficiency.

3. The implementation system according to claim 1, characterized in that, The data acquisition unit collects the load data of the Pod corresponding to the service instance and the historical occupancy time data of the lock; the data analysis unit obtains the load data of the Pod corresponding to the service instance and the historical occupancy time data of the lock to determine the lock type and number of locks that the service instance is adapted to in the current state. The control unit obtains the lock type and number of locks that the service instance is adapted to in the current state from the data analysis unit, and notifies the distributed lock agent.

4. The implementation system according to claim 1, characterized in that, The resource management unit manages the resources that the service instance depends on, and initiates lock request or lock release request to the distributed lock agent at a set period, so as to synchronize the lock request or lock release request to the control unit through the distributed lock agent.

5. The implementation system according to any one of claims 1 to 4, characterized in that, The distributed lock controller also includes a data recording unit; The data acquisition unit accesses the data recording unit at a set period to query the number of times the locks assigned to the service instance are used and the duration of each use. Records of lock requests initiated or released by the control unit are saved to the data recording unit.

6. The implementation system according to claim 5, characterized in that, The distributed lock agent runs lock quantity scaling logic, which includes: A default number of locks are created for the service instance, and upper and lower threshold values ​​for load data are set. After obtaining the load data of the Pod corresponding to the service instance from the distributed lock controller, the relationship between the load data and the upper threshold values ​​is determined. When the load data is higher than or equal to the upper limit threshold, it is further determined whether the locks allocated to the service instance in the current state have been exhausted. If so, the number of locks allocated to the service instance is increased; otherwise, the default number of locks created for the service instance is maintained. When the load data is less than the upper limit threshold, maintain the default number of locks created for the service instance.

7. The implementation system according to claim 6, characterized in that, The lock quantity scaling logic further includes: determining whether the load data is less than the lower threshold. When the load data is less than the lower threshold, it is further determined whether the locks allocated to the service instance in the current state have been exhausted. If so, the number of locks created for the service instance is maintained at the default number. If not, the number of locks created for the service instance is reduced. When the load data is greater than or equal to the lower threshold, maintain the default number of locks created for the service instance.

8. The implementation system according to claim 5, characterized in that, The data recording unit operates lock type switching logic, which includes: Record the duration for which locks allocated to the service instance are held in the current state. Set the average usage time of the assigned lock during the operation of the service instance. Calculate the blocking time and compare it with the average usage time. When the blocking time is less than or equal to a preset percentage of the average usage time, switch the non-blocking lock to a blocking lock; when the blocking time is greater than a preset percentage of the average usage time, switch the blocking lock back to a non-blocking lock.

9. The implementation system according to claim 5, characterized in that, The data recording unit is configured as a database, and the implementation system is deployed as a whole on a cloud management platform.

10. The implementation system according to claim 8, characterized in that, The preset ratio is 5-10%.

Images