Resource processing method and device, distributed storage system and storage medium

Abstract

The invention discloses a resource processing method and device, a distributed storage system and a storage medium. The method comprises the following steps: in the case that a target resource is locked by a lease lock, in response to a received lock request of a target client, determining whether the lock request meets a target condition based on the difference between the current lock attribute information of the lease lock and the lock attribute information in the lock request; if the lock request meets the target condition, updating the lease lock based on lock attribute information in the lock request; and locking the target resource through the updated lease lock. According to the method provided by the invention, the target client side can quickly preempt the lease lock, so that the target resource can be quickly accessed, and the efficiency of realizing the service through the target resource is improved.

Description

Technical Field

[0001] This application relates to the field of electronic information technology, and more specifically, to a resource processing method, apparatus, distributed storage system, and storage medium. Background Technology

[0002] A distributed lock is a mechanism used in distributed systems or cluster environments to coordinate mutual exclusion access to shared resources (in the case of a distributed storage system, the shared resource is a shared storage resource) by multiple clients.

[0003] Specifically, when a client wants to use a shared resource to perform a business function, it locks the shared resource using a lease lock and identifies the client as the holder of the lease lock. When the shared resource is locked by the lease lock, the client can access the shared resource. Other clients that are not the holder of the lease lock do not have the right to access the shared resource. Alternatively, other clients that are not the holder of the lease lock can only read the shared resource, but they do not have the right to write information to the shared resource or modify the information within the shared resource.

[0004] In related technologies, there is a problem of low efficiency in business implementation. Summary of the Invention

[0005] In view of this, embodiments of this application propose a resource processing method, apparatus, distributed storage system, and storage medium.

[0006] In a first aspect, embodiments of this application provide a resource processing method, the method comprising: when a target resource is locked by a lease lock, in response to receiving a lock request from a target client, determining whether the lock request meets a target condition based on the difference between the current lock attribute information of the lease lock and the lock attribute information in the lock request; if the lock request meets the target condition, updating the lease lock based on the lock attribute information in the lock request; wherein, after the lease lock is updated, the target client becomes the holding client of the updated lease lock; the holding client of the lease lock is a client with access rights to the target resource; and locking the target resource using the updated lease lock.

[0007] Secondly, embodiments of this application provide a resource processing apparatus, comprising: a response module, configured to, when a target resource is locked by a lease lock, respond to a lock request received from a target client and determine whether the lock request meets a target condition based on the difference between the current lock attribute information of the lease lock and the lock attribute information in the lock request; an update module, configured to, if the lock request meets the target condition, update the lease lock based on the lock attribute information in the lock request; wherein, after the lease lock is updated, the target client becomes the holding client of the updated lease lock; the holding client of the lease lock is a client with access rights to the target resource; and a locking module, configured to lock the target resource using the updated lease lock.

[0008] Optionally, the response module is further configured to, in the case where the target resource is locked by a lease lock, respond to a lock request received from the target client by determining whether the current holder of the lease lock is the target client; if the current holder of the lease lock is the target client, determine whether the lock request meets the reentrancy condition based on the difference between the current lock attribute information of the lease lock and the lock attribute information in the lock request; if the current holder of the lease lock is the target client and the lock request meets the reentrancy condition, the lock request meets the target condition; if the current holder of the lease lock is not the target client, determine whether the lock request meets the preemption condition based on the difference between the current lock attribute information of the lease lock and the lock attribute information in the lock request; if the current holder of the lease lock is not the target client and the lock request meets the preemption condition, the lock request meets the target condition.

[0009] Optionally, the lock attribute information includes the version information of the lease lock and the term information of the lease period; when the holding client of the lease lock changes, the version information of the lease lock changes; when the holding client of the lease lock remains unchanged but the holding client of the lease lock sends a new lock request, the term information of the lease lock changes; the response module is further configured to determine whether the lock request meets the reentrancy condition if the current holding client of the lease lock is the target client, based on the difference between the current version information of the lease lock and the version information in the lock request, and / or the difference between the current term information of the lease lock and the term information in the lock request.

[0010] Optionally, the version information includes the version number of the lease lock, which changes monotonically over time; the term information includes the term version number of the lease term of the lease lock, which changes monotonically over time when the holding client of the lease lock remains unchanged; the response module is further configured to determine that the lock request satisfies the reentrancy condition if the current holding client of the lease lock is the target client and the difference between the current version number of the lease lock and the version number in the lock request conforms to the monotonic change law corresponding to the version number; and to determine that the lock request satisfies the reentrancy condition if it is determined that the current holding client of the lease lock is the target client, the version number of the lease lock is the same as the version number in the lock request, and the difference between the term version number of the lease lock and the term version number in the lock request conforms to the monotonic change law corresponding to the term version number.

[0011] Optionally, the lock attribute information includes the version information of the lease lock; when the holding client of the lease lock changes, the version information of the lease lock changes; the response module is also used to determine whether the lock request meets the preemption condition if the current holding client of the lease lock is not the target client, based on the difference between the current version information of the lease lock and the version information in the lock request.

[0012] Optionally, the version information includes the version number of the lease lock, which changes monotonically over time; the response module is also used to determine that the lock request meets the preemption condition if the current holding client of the lease lock is not the target client, and the difference between the current version number of the lease lock and the version number in the lock request conforms to the monotonically changing pattern of the version number.

[0013] Optionally, the current lock attribute information of the lease lock includes the identifier of the current holding client of the lease lock; the lock attribute information in the lock request also includes the identifier of the target client; the response module is further configured to, in the case where the target resource is locked by the lease lock, respond to the receipt of the lock request from the target client and determine whether the current holding client of the lease lock is the target client based on the difference between the identifier of the current holding client of the lease lock and the identifier of the target client.

[0014] Optionally, the update module is further configured to update the current lock attribute information of the lease lock based on the lock attribute information in the lock request if the lock request meets the target conditions and the current holding client of the lease lock is not the target client; control the lease lock to enter the preemption state; when the lease lock is in the preemption state, the holding client of the lease lock is still the current holding client of the lease lock and the lease lock can only be preempted by the target client; when the lease lock is in the preemption state, unlock the target resource and update the holding client of the lease lock to the target client to complete the update of the lease lock; correspondingly, the locking module is further configured to control the lease lock to exit the preemption state and lock the target resource with the updated lease lock.

[0015] Thirdly, embodiments of this application provide a distributed storage system, which includes multiple nodes, each node including at least two controllers and a shared storage disk; wherein each controller corresponds to at least one client, and at least one controller in each node corresponds to a server; for each node, the server of the node is communicatively connected to each client in the node and the shared storage disk; for each server, the server is used to execute the above-described method.

[0016] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-readable instructions that, when executed by a processor, implement the above-described method.

[0017] Fifthly, embodiments of this application provide a computer program product including computer-readable instructions that, when executed by a processor, implement the method described above.

[0018] This application provides a resource processing method, apparatus, distributed storage system, and storage medium. In this application, a target client can apply to become the holder of a lease lock through a lock request. When the lock request meets the target conditions, the lease lock is updated to achieve the goal of the target client becoming the holder of the lease lock. Then, the target resource is locked through the updated lease lock, so that the target client can realize business through the target resource. The target client no longer needs to wait for the target group lock to release the holding right of the lease lock before holding the lease lock, which makes it easier for the target client to quickly "preempt" the lease lock, thereby quickly accessing the target resource and improving the efficiency of realizing business through the target resource. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 A schematic diagram illustrating an application scenario applicable to the embodiments of this application is shown; Figure 2 A schematic diagram illustrating yet another application scenario applicable to the embodiments of this application is shown; Figure 3 A flowchart of a resource processing method according to an embodiment of this application is shown; Figure 4 It shows Figure 3 A flowchart of step S110 in one embodiment is shown in the corresponding example; Figure 5 A flowchart of a resource processing method according to yet another embodiment of this application is shown; Figure 6 A schematic diagram illustrating the lock state transition process of a lease lock according to an embodiment of this application is shown; Figure 7 A schematic diagram illustrating the preemption process of a lease lock according to an embodiment of this application is shown; Figure 8 A block diagram of a resource processing apparatus according to one embodiment of this application is shown; Figure 9 A structural block diagram of an electronic device for performing a resource processing method according to an embodiment of this application is shown. Detailed Implementation

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

[0022] In the following description, the terms "first" and "second" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first" and "second" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0023] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit the application. It should be noted that "multiple" as used herein refers to two or more. "And / or" describes the association relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship.

[0024] The following is an explanation of the technical terms used in this application: PLock (Persistence Lock): The name given to the lease lock (also known as distributed lease lock) implementation in this application. It is a distributed, persistent, preemptible, monotonic clock-based lock that serves as infrastructure for use by upper-layer product business modules.

[0025] Lock Lease: A record structure that indicates a client's ownership of a lock. A client will obtain a lock lease after successfully locking the lock.

[0026] TTL (Time To Live): The lease life of a lease lock, representing the length of a time period used to time the lease period of a lock round, typically 30s or 60s, etc.

[0027] Lock preemption: When client A holds a lease lock and has successfully locked it, client B can preemptively acquire the right to hold the lease lock under certain conditions, after which client A's holding right becomes invalid.

[0028] Placement Group (PG): A distributed facility, typically in multi-replica or erasure coding mode, where data stored in a placement group is stored on multiple distributed nodes and maintains consistency.

[0029] Lock server: The process that runs the lease lock state transition process and stores the lease lock state in the reset group. It communicates with the lock client below through a designed message format.

[0030] Lock client: The client state transition process that runs the lease lock and is connected to the module process of the actual business. It communicates with the lock server mentioned above using the designed message format.

[0031] PLogFS: A business service module and one of the users of lease locks.

[0032] Please refer to Figure 1 The diagram illustrates an application scenario applicable to the embodiments of this application. This application scenario includes a terminal 110 and a distributed storage system 120.

[0033] Terminal 110 can be, for example, a smartphone, tablet, e-book reader, music player, wearable device, smart home device, in-vehicle terminal, etc. Terminal 110 may include a data request client capable of sending requests to apply for lease lock holding rights from a node in the distributed storage system 120, and accessing the shared resources of the corresponding node using the obtained lease lock.

[0034] The distributed storage system 120 includes multiple nodes, for example, Figure 1In this example, the distributed storage system comprises three nodes: node 121, node 122, and node 123. Nodes in the distributed storage system 120 can be independent physical servers, server clusters or distributed systems composed of multiple physical servers, or cloud servers providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms.

[0035] Each node in the distributed storage system 120 may include at least two controllers and a shared storage disk. Each controller corresponds to at least one client (the client mentioned above is the lock client), and each node has at least one controller corresponding to a server (the server mentioned above is the lock server). Specifically, for each node, the server communicates with each client and the shared storage disk within the node. In other words, the lock client, lock server, and shared storage disk are all deployed within the node.

[0036] For example, when terminal 110 requests access to data in node 121 of distributed storage system 120 (that is, the target resource in the shared storage disk), terminal 110 requests access to the lock client in node 121. The lock client initiates a lock request, and the lock server in node 121 responds to the lock request by updating the lease lock and locking the target resource in the shared storage disk of node 121 according to the updated lease lock, so that terminal 110 can access the target resource through the lock client in node 121.

[0037] In some exemplary scenarios, a node in a distributed storage system may include two controllers: controller A and controller B, and the shared resource is a shared storage disk. Correspondingly, the application scenarios applicable to the embodiments of this application are as follows: Figure 2 As shown.

[0038] For controller A: It provides business services to users through upper-layer business services. When the upper-layer business service receives a user's business request, it sends a lock request through lock client 1 in the business service module. The lock request is used to request access to the hard disk corresponding to the main resource. Based on the lock request, the main resource is locked for lock client 1 to use, so that lock client 1 can access the corresponding hard disk through the OSD (Object Storage Device) process of the main resource.

[0039] Similarly, for controller B: it provides business services to users through upper-layer business services. When the upper-layer business service receives a user's business request, it sends a lock request through lock client 2 in the business service module. The lock request is used to apply for access to the hard drive corresponding to the main resource. Based on the lock request, the main resource is locked for lock client 2 to use, so that lock client 2 can access the corresponding hard drive through the OSD (Object Storage Device) process of the main resource.

[0040] Figure 2 In this process, a dual-controller arbitration is used to determine whether controller A or controller B has a higher priority, so that the lock client in the controller with the higher priority can preempt the lease lock held by the other.

[0041] Please see Figure 3 , Figure 3 This application illustrates a flowchart of a resource processing method according to an embodiment of the present application. The method is applied to a server in any node of a distributed storage system 120 and may include: S110. When the target resource is locked by a lease lock, in response to receiving a lock request from the target client, determine whether the lock request meets the target conditions based on the difference between the current lock attribute information of the lease lock and the lock attribute information in the lock request.

[0042] The target resource is a resource that can be shared by multiple clients (i.e., the aforementioned lock clients). The target resource can be shared memory, shared services, and shared databases, etc. The server is used to connect the client to the target resource and provide the target resource to the client.

[0043] Typically, there is a one-to-one correspondence between a target resource and a lease lock. Each target resource is locked using a corresponding lease lock, and each client can act as the holder of the lease lock. In this embodiment, for ease of understanding, a target resource is used as the basis for explanation.

[0044] In this context, the client holding the lease lock is the client with access rights to the target resource. This means that other clients besides the lease lock holder do not have access rights to the target resource. In other words, when a client acts as the lease lock holder, after the target resource is locked through the lease lock, that client has exclusive access rights to the target resource, and other clients do not have access rights to that target resource.

[0045] When the target resource is locked by a lease lock, it means that the target resource is accessed by the client currently holding the lease lock. The client currently holding the lease lock can be the target client or a different client than the target client.

[0046] If the current holder of the lease lock is the target client, this means that during the period when the target client holds the lease lock, the target client may experience a failure that prevents or prevents timely communication with the server. In this case, the target client can re-initiate the lock request, and this re-initiated lock request will be regarded as the lock request initiated by the target client in S110.

[0047] If the current holder of the lease lock is not the target client, this means that while other clients are holding the lease lock, if the target client wants to use the target resource, the target client will initiate a lock request to apply for the right to hold the lease lock.

[0048] However, to prevent malicious "preemption" of the current holder's rights to the lease lock, when the target client wants to use the target resource, the server (i.e., the lock server in the aforementioned example) can arbitrate whether the target client has the right to preempt the current holder's rights to the lease lock, or whether the target client's priority is higher than the current holder's priority. If so, the server agrees to the target client's "preemption," and the target client can send a request to the server to apply for the lease lock's holding rights. The server will then release the holding rights to the target client in accordance with the method described in this application. If not, the server does not agree to the target client's "preemption," and the target client will not send a lock request to apply for the lease lock's holding rights. Alternatively, even if the target client sends a lock request to the server to apply for the lease lock's holding rights, the server will not release the holding rights to the target client.

[0049] The lock request sent by the target client may include the lock attribute information of the lease lock. The lock attribute information may include the lock identifier of the lease lock, the resource identifier of the target resource (since there is a one-to-one correspondence between the target resource and the lease lock, either the lock identifier or the resource identifier of the target resource can be used to indicate the lease lock), the identifier of the holding client, the version information, the lease term information, and the lock status.

[0050] Among them, the lock identifier can be the number, name, or ID of the lease lock; the resource identifier of the target resource can be the number, name, or ID of the target resource; the identifier of the holding client can be the number, name, or ID of the holding client; the lease lock version information is used to indicate the version of the lease lock; if the lease lock version changes, the lease lock version information changes; the lease term information of the lease lock is used to indicate the lease of the lease lock; if the lease of the lease changes, the lease term information changes; the lock state can include locked state, unlocked state, and preempted state, etc.

[0051] The preemptive state is a non-persistent locked state. In contrast, the locked state is actually a persistent locked state to continuously lock the target resource. The unlock state is also a persistent unlock state to continuously unlock the target resource.

[0052] The lease refers to the lock lease mentioned earlier. When the client holding the leased lock remains unchanged, if the client holding the leased lock sends a new lock request, the lease term information changes, and thus the lease term information changes. Similarly, when the client holding the leased lock remains unchanged, if the client holding the leased lock does not trigger a new lock request, the lease of the leased lock remains unchanged, and correspondingly, the lease term information also remains unchanged.

[0053] Typically, when the client holding a leased lock changes, the leased lock's version information changes. This allows for efficient and quick differentiation of whether the client holding the leased lock has changed based on the differences in the leased lock's version information. When the same client holds a leased lock at different time periods (e.g., at intervals), the leased lock's version information will also be different, making it easier to quickly and efficiently differentiate whether the holding period of the leased lock has changed. However, when the same client holds a leased lock within the same time period (which can refer to a single time period or multiple consecutive time periods), the leased lock's version information can be the same to avoid changing the leased lock's version information during a single consecutive holding, which could lead to a large amount of data processing.

[0054] For example, during the period when a client holds a lease lock, the client may malfunction and be unable to communicate with the server in a timely manner. At this time, the client can re-initiate a lock request and apply for a new "lock lease". As a result, the term information of the lease lock held by the client will also change. However, the client actually holds the lease lock continuously, so the version information of the target lock can remain unchanged.

[0055] It is worth mentioning that the lock attribute information in the lock request can include all the attribute information of the lease lock, or it can include a part of all the attribute information of the lease lock. For example, the lock attribute information of the lease lock can include the lock identifier of the lease lock, the resource identifier of the target resource, the identifier of the holding client, the version information, the lease term information, and the lock status. Correspondingly, the lock attribute information in the lock request includes the identifier of the holding client, the version information, and the lease term information.

[0056] In some implementations, the lease lock has a renewal period. During the renewal period, if the current holder of the lease lock sends a renewal request, the renewal period is reset, thus enabling the current holder to hold the lease lock "indefinitely." Similarly, when the renewal period expires and no renewal request is received from the current holder, it is determined that the current holder no longer wishes to hold the lease lock, and the current holder's holding rights are released to allow other clients to apply for holding rights.

[0057] However, during the renewal period of the current holding client of the lease lock, the lease lock term information usually remains unchanged because the current holding client of the lease lock actually uses the original "lock lease" to renew the lease lock, without triggering a new "lock lease".

[0058] In some other implementations, the lease lock may not be configured with a renewal period. If the client holding the lease lock does not send a termination or unlocking request, it means that the client holding the lease lock wants to continue holding the lease lock. In this case, the client holding the lease lock is allowed to continue holding the lease lock until a termination or unlocking request is received from the client holding the lease lock. If it is determined that the current client holding the lease lock no longer wants to hold the lease lock, the holding rights of the current client holding the lease lock are released so that other clients can apply for holding rights of the lease lock.

[0059] The current lock attribute information of the lease lock refers to the attribute information of the lease lock itself, while the lock attribute information in the lock request of the target client refers to the lock attribute information that the lease lock has when the target client holds the lease lock.

[0060] It is worth mentioning that in this embodiment, the current lock attribute information of the lease lock is obtained after updating the lock attribute information in the historical lock request; the historical lock request is sent by the current holding client of the lease lock, and the receiving time of the historical lock request is before the receiving time of the lock request.

[0061] In other words, at a historical point in time (before the time the lock request was received), the current holder of the lease lock sent a historical lock request. The server then responds to this historical lock request, updates the lease lock based on the lock attribute information in the historical lock request, and determines that the current holder client holds the lease lock. The server then uses the lease lock to lock the target resource, granting the current holder client access to the target resource. This achieves the locking of the target resource, and the ownership of the target resource belongs to the current holder client. Of course, the method by which the current holder client acquires the lease lock ownership is the same as the method by which the target client acquires the lease lock ownership, and will not be elaborated here.

[0062] As mentioned above, the lock request from the target client includes lock attribute information. Therefore, it is possible to determine whether the lock request meets the target conditions based on the difference between the current lock attribute information of the lease lock and the lock attribute information in the lock request.

[0063] If the target condition is met, it means that the holding rights of the lease lock can be transferred to the target client. Then, the subsequent process of making the target client the holder of the lease lock and locking the target resource for the target client to access will be executed. If the target condition is not met, it means that the holding rights of the lease lock cannot be transferred to the target client. In this case, the current holder of the lease lock will continue to have the holding rights of the lease lock, and the subsequent process of making the target client the holder of the lease lock and locking the target resource for the target client to access will not be executed.

[0064] S120. If the lock request meets the target conditions, update the lease lock based on the lock attribute information in the lock request.

[0065] When the target conditions are met, it means that the holding rights of the lease lock can be transferred to the target client. At this time, based on the lock attribute information in the lock request, the lease lock is updated so that after the lease lock is updated, the target client becomes the holding client of the updated lease lock, and the lock attribute information of the updated lease lock matches the updated lease lock, thus realizing the transfer of the holding rights of the lease lock to the target client.

[0066] For example, when the lock attribute information of a lease lock includes the lock identifier of the lease lock, the resource identifier of the target resource, the identifier of the holding client, the version information, and the term information of the lease period, the updated lock attribute information of the lease lock may include the lock identifier of the lease lock (actually unchanged), the resource identifier of the target resource (actually unchanged), the identifier of the holding client (changed to the identifier of the target client), the version information (changed), and the term information of the lease period (changed).

[0067] S130. Lock the target resource using the updated lease lock.

[0068] After the lease lock is updated, the client holding the lease lock becomes the target client. At this point, the target resource is locked using the updated lease lock, so that the target client has exclusive access to the target resource.

[0069] In this embodiment, the target client can apply to become the holder of the lease lock through a lock request, and update the lease lock when the lock request meets the target conditions, thereby achieving the goal of the target client becoming the holder of the lease lock. Then, the target resource is locked through the updated lease lock, so that the target client can realize business through the target resource. The target client no longer needs to wait for the target group lock to release the holding right of the lease lock before holding the lease lock, which makes it easier for the target client to quickly "preempt" the lease lock, thereby quickly accessing the target resource and improving the efficiency of realizing business through the target resource.

[0070] In some embodiments, such as Figure 4 As shown, S110 includes: S111. When the target resource is locked by a lease lock, in response to receiving a lock request from the target client, determine whether the current holder of the lease lock is the target client.

[0071] The server can store the identifier of the current holding client of the lease lock. The lock request can include the identifier of the target client. At this time, the identifier of the current holding client of the lease lock is compared with the identifier of the target client. If they match, the current holding client of the lease lock is determined to be the target client. If they do not match, the current holding client of the lease lock is determined not to be the target client.

[0072] In some implementations, as described above, the current lock attribute information of the lease lock is obtained by updating the lock attribute information in the historical lock request; the historical lock request is sent by the current holding client of the lease lock, and the time point of receipt of the historical lock request is before the time point of receipt of the lock request; since the lock attribute information in the historical lock request also includes the identifier of the current holding client of the lease lock, the current lock attribute information of the lease lock can include the identifier of the current holding client of the lease lock; the lock attribute information in the lock request also includes the identifier of the target client; thus, S111 includes: when the target resource is locked by the lease lock, in response to receiving the lock request from the target client, determining whether the current holding client of the lease lock is the target client based on the difference between the identifier of the current holding client of the lease lock and the identifier of the target client.

[0073] S112. If the current holding client of the lease lock is the target client, determine whether the lock request meets the reentrancy condition based on the difference between the current lock attribute information of the lease lock and the lock attribute information in the lock request.

[0074] Specifically, the lock request satisfies the target condition when the current holding client of the lease lock is the target client and the lock request meets the reentrancy condition.

[0075] In other words, the current holder of the lease lock is the target client. The target client was originally the current holder of the lease lock, but due to reasons such as a malfunction of the target client, the target client re-triggered a new lock request (before S111, the target client had already obtained the right to hold the lease lock through the lock request, so the lock request obtained in S111 is actually a new lock request triggered by the target client). At this time, based on the difference between the current lock attribute information of the lease lock and the lock attribute information in the lock request, it is determined whether the lock request meets the reentrancy condition.

[0076] If the reentrancy condition is met, it means that the target client still has the right to hold the lease lock. If it is allowed to continue holding the lease lock, the subsequent processing flow after the target condition is met will continue to achieve the lease lock for the target client to continue using. If the reentry condition is not met, it means that the target client no longer has the right to hold the lease lock and is not allowed to continue holding the lease lock. Therefore, the subsequent processing flow after the target condition is met will not continue, so that other clients can apply for the right to hold the lease lock.

[0077] The reentrancy condition can be determined by comparing the differences between the current lock attribute information of the lease lock and the lock attribute information in the lock request.

[0078] Optionally, the lock attribute information includes the version information of the lease lock and the term information of the lease period; when the holding client of the lease lock changes, the version information of the lease lock changes; when the holding client of the lease lock remains unchanged but the holding client of the lease lock sends a new lock request, the term information of the lease lock changes; S112 may include: if the current holding client of the lease lock is the target client, based on the difference between the current version information of the lease lock and the version information in the lock request, and / or the difference between the current term information of the lease lock and the term information in the lock request, determining whether the lock request meets the reentrancy condition.

[0079] In other words, in response to receiving a lock request from the target client, if it is determined that the current holder of the lease lock is the target client, it can be determined whether the lock request meets the reentrancy condition based on at least one of two differences. Specifically, these two differences are based on the difference between the current version information of the lease lock and the version information in the lock request, and the difference between the current term information of the lease lock and the term information in the lock request.

[0080] Changes in the lease lock's version information indicate changes in the lease lock's version. Typically, over time, the lease lock's version will become higher and higher. Therefore, if the difference between the current lease lock's version information and the version information in the lock request is that the version of the lease lock indicated by the version information in the lock request is higher, it means that the lease lock requested by the lock request is a "newer" version. If the lease lock held by the target client is a newer lease lock, then it is determined that the target client's lock request was triggered to achieve re-access to the target resource. The target client's lock request meets the reentrancy condition, and it is allowed to hold the lease lock.

[0081] Changes in the lease term information indicate changes in the lease term. Typically, as time progresses, when a new lease is created for the same version of the lease, the lease term information will also indicate the new lease. Thus, if the difference between the current version information of the lease and the version information in the lock request is consistent, and the difference between the current term information of the lease and the term information in the lock request is an update to the lease of the lease requested by the lock request, it means that the lease of the lease requested by the lock request is "newer," and the lease of the lease held by the target client is a new lease. Therefore, it is determined that the lock request of the target client was triggered to enable re-access to the target resource, and the lock request of the target client meets the reentrancy condition, allowing it to hold the lease.

[0082] Optionally, the version information includes the version number of the lease lock, which changes monotonically over time (e.g., monotonically increasing: the version number increases over time; or monotonically decreasing: the version number decreases over time); the term information includes the term version number of the lease term of the lease lock, which changes monotonically over time when the holding client of the lease lock remains unchanged (e.g., monotonically increasing: the term version number increases over time; or monotonically decreasing: the term version number decreases over time). Accordingly, S112 may include: if the current holding client of the lease lock is the target client, and the difference between the current version number of the lease lock and the version number in the lock request conforms to the monotonically changing rule corresponding to the version number, determining that the lock request meets the reentrancy condition; or, if it is determined that the current holding client of the lease lock is the target client, the version number of the lease lock is the same as the version number in the lock request, and the difference between the term version number of the lease lock and the term version number in the lock request conforms to the monotonically changing rule corresponding to the term version number, determining that the lock request meets the reentrancy condition.

[0083] Generally, when each client triggers a lock request, the lease lock version number is configured for the client's lock request in the global scope of all clients. The lease lock version number changes monotonically in the global scope. For example, if the lease lock version number increases over time, the lease lock version number in a previous lock request will not be higher than the lease lock version number in the current lock request (regardless of the client that sent the lock request).

[0084] However, version information can distinguish different clients. Therefore, the term version number is used to differentiate changes in the lease status of a lease lock when the same client holds it. Thus, for each client, the term version number can be configured according to the client's own monotonic clock, ensuring that the term version number changes monotonically only within the same client. For example, if the lease lock's term version number increments over time, then the term version number in a client's earlier lock request for the lease lock will not be higher than the term version number in a later lock request from the same client.

[0085] For example, if both the lease lock version number and the term version number increment over time, then the aforementioned reentrancy conditions include: a larger version number, or the same version number and the same or larger term version number. In this case, the target condition is as follows: (The identifier of the target client in the lock request is the same as the identifier of the client currently holding the lease lock) and ((The version number of the lock request is greater than the version number of the current lock), or ((The version number in the lock request is equal to the version number of the current lock) and (The version number of the lock request is greater than or equal to the version number of the current lock)).

[0086] Alternatively, if both the lease lock's version number and term version number decrease over time, then the aforementioned reentrancy conditions include: a smaller version number, or the same version number and the same or smaller term version number. In this case, the target condition is as follows: (The identifier of the target client in the lock request is the same as the identifier of the client currently holding the lease lock) and ((the version number of the lock request is less than the version number of the current lock), or, ((the version number in the lock request is equal to the version number of the current lock) and (the version number of the lock request's expiration date is less than or equal to the version number of the current lock's expiration date)).

[0087] S113. If the current holder of the lease lock is not the target client, determine whether the lock request meets the preemption condition based on the difference between the current lock attribute information of the lease lock and the lock attribute information in the lock request.

[0088] Specifically, if the current holding client of the lease lock is not the target client and the lock request meets the preemption condition, the lock request meets the target condition.

[0089] In other words, the current holder of the lease lock is not the target client, but the target client has the right to preempt. The target client is allowed to preempt the current holder of the lease lock from holding the lease lock. In this case, the difference between the current lock attribute information of the lease lock and the lock attribute information in the lock request is used to determine whether the lock request meets the preemption condition.

[0090] If the preemption condition is met, it means that the current client holding the lease lock no longer has the right to continue holding the lease lock, while the target client has the right to hold the lease lock. If the target client is allowed to preempt the lease lock, the subsequent processing flow after the target condition is met will continue, so that the lease lock can be transferred to the target client for continued use. If the preemption condition is not met, it means that the current holder of the lease lock has the right to continue holding the lease lock, while the target client does not have the right to hold the lease lock. If the target client is not allowed to preempt the lease lock, the subsequent processing flow after the target condition is met will not continue, and the current holder of the lease lock will continue to hold the lease lock.

[0091] The preemption condition can be determined by comparing the differences between the current lock attribute information of the lease lock and the lock attribute information in the lock request.

[0092] Optional lock attribute information includes lease lock version information; when the lease lock holder client changes, the lease lock version information changes; S113 may include: if the current lease lock holder client is not the target client, determine whether the lock request meets the preemption condition based on the difference between the current lease lock version information and the version information in the lock request.

[0093] In other words, in response to receiving a lock request from the target client, if it is determined that the current holder of the lease lock is not the target client, the difference between the current version information of the lease lock and the version information in the lock request can be used to directly determine whether the lock request meets the preemption condition.

[0094] Changes in the lease lock's version information indicate changes in the lease lock's version. Typically, over time, the lease lock's version will become higher and higher. Therefore, if the difference between the current lease lock's version information and the version information in the lock request is that the version of the lease lock indicated by the version information in the lock request is higher, it means that the lease lock requested in the lock request is a "newer" version. If the lease lock held by the target client is a newer lease lock, then it is determined that the target client's lock request was triggered to preempt the lease lock. The target client's lock request meets the preemption condition, and the target client is allowed to preempt the lease lock.

[0095] Furthermore, the version information includes the version number of the lease lock, which changes monotonically over time (e.g., monotonically increasing: the version number increases over time, or monotonically decreasing: the version number decreases over time). Accordingly, S113 may include: if the current holding client of the lease lock is not the target client, and the difference between the current version number of the lease lock and the version number in the lock request conforms to the monotonically changing pattern of the version number, then the lock request is determined to meet the preemption condition.

[0096] For example, if both the lease lock version number and the term version number increment over time, then the aforementioned preemption condition includes: a larger version number. In this case, the target condition is as follows: (The identifier of the target client in the lock request is different from the identifier of the current holding client of the lease lock) and (the version number of the lock request is greater than the version number of the current lock).

[0097] For example, if both the version number and the term version number of the lease lock decrease over time, then the aforementioned preemption condition includes: a smaller version number. In this case, the target condition is as follows: (The identifier of the target client in the lock request is different from the identifier of the current holding client of the lease lock) and (the version number of the lock request is less than the version number of the current lock).

[0098] In this embodiment, specific target conditions are defined, and two scenarios are distinguished: the current holder of the lease lock is the target client and the current holder of the lease lock is not the target client. This makes the target conditions more accurate and improves the accuracy of determining the preemption and reentry timing. This enables accurate preemption and reentry, avoiding preemption or reentry at inappropriate times, which could lead to confusion in lease lock holding permissions and business failures. This further improves the stability of business operations through lease locks.

[0099] In some embodiments, such as Figure 5 As shown, S120 includes: S121. If the lock request meets the target condition and the current holder of the lease lock is not the target client, update the current lock attribute information of the lease lock based on the lock attribute information in the lock request.

[0100] If the lock request meets the target conditions and the current holder of the lease lock is not the target client, then the current lock attribute information of the lease lock is updated using the lock attribute information in the lock request, so that the lock attribute information of the lease lock indicates that the holder of the lease lock is the target client.

[0101] For example, when the lock attribute information of a lease lock includes the lock identifier of the lease lock, the resource identifier of the target resource, the identifier of the holding client, the version information, and the term information of the lease period, the updated lock attribute information of the lease lock may include the lock identifier of the lease lock (actually unchanged), the resource identifier of the target resource (actually unchanged), the identifier of the holding client (changed to the identifier of the target client), the version information (changed to the version information in the lock request of the target client), and the term information of the lease period (changed to the term information in the lock request of the target client).

[0102] S122, Control the lease lock to enter the preemption state.

[0103] In this case, the lease lock is in a preemptive state. The client holding the lease lock remains the current holder of the lease lock, and the lease lock can only be preempted by the target client.

[0104] As mentioned above, the preemption state is a non-persistent locked state used during the preemption process to wait for the current holding client to release its holding rights, in order to prevent double-write situations caused by other clients or target clients holding the lease lock while the current holding client has not released its rights.

[0105] It is worth mentioning that the lock attribute information of the lease lock can also include the lock state. When the process of S131 updates the lock attribute information of the lease lock, the lock state of the lease lock is updated to the preemptive state. Thus, in response to the lock state changing to the preemptive state, the lease lock is controlled to enter the preemptive state.

[0106] S123. When the lease lock is in a preemptive state, unlock the target resource and update the lease lock holder client to the target client to complete the lease lock update.

[0107] When the lease lock is in a preemptive state, the target resource is unlocked, and the lease lock holder client is updated to the target client. In this way, the lease lock holder client is updated, and the lease lock update is completed.

[0108] Accordingly, S130 includes: S131, controlling the lease lock to exit the preemption state, and locking the target resource through the updated lease lock.

[0109] After updating the lease lock holder client, the updated lease lock holder rights belong to the target client. At this time, the lease lock is controlled to exit the preemption state, and the target resource is locked through the updated lease lock. Correspondingly, if the lease lock's lock attribute information also includes the lock state, the lock state in the lease lock's lock attribute information can also be updated to the locked state.

[0110] In this embodiment, the changes in the lock state of the lease lock are as follows: Figure 6 As shown, Figure 6 Explanation of terms related to states and events: Initial: Lock initial state Unlocked: The lock has been released (unlocked). The lock can be acquired when the space is currently available. Locked: The lock is currently held by a client. Unlocking: The unlocking process is in progress. Locking: Currently in a locking state; the lock request is still being processed. Preempted: The lock has been preempted by a new client, and the preemption process is still in progress. ResetUnlocked: Resets the lock state to Unlocked. ResetLocked: Resets the lock state to Locked. EUnlock: Unlock operation request event ELock: Locking operation request event ETTLRefresh: Locked Lease Renewal Request Event ESaveCommited: Lock information has been successfully stored. like Figure 6 As shown, in the unlocked state, if the target condition is met, the lock is directly acquired to enter the locking state. After the locking state is completed, the lock information is stored. After the lock information has been stored, the lock state is determined to enter the locked state.

[0111] When the lock is in a locked state, if an unlock request is received, the lock will be unlocked directly to enter the unlocking state. After the unlocking state is completed, the lock information will be stored. Once the lock information has been stored, the lock state will be determined to enter the unlocked state.

[0112] In the locked state, upon receiving a lock request, it is determined whether the lock request meets the target conditions. If the preemption conditions under the target conditions are met, it enters the non-persistent preemption state, then responds to the original client to unlock, directly locks to enter the locking state, and after the locking state is completed, the lock information is stored. After the lock information has been stored, the lock state is determined to enter the locked state.

[0113] If the reentrancy condition under the target condition is met, the lock is directly re-acquired to enter the locking state. After the locking state is completed, the lock information is stored. After the lock information has been stored, the lock state is determined to enter the locked state.

[0114] In this embodiment, the preemption process of the lease lock is as follows: Figure 7 As shown.

[0115] 1. Lock client 1 sends a lock request to the server (i.e., the lock server in the previous example). The version number of the lock request is epoch1, and the expiration version number is interval1.

[0116] 2. The server responds to the lock request from lock client 1 and agrees to acquire the lock.

[0117] 3. The lease lock's lock state is changed to locked state. The lease lock version information includes: version number epoch1 and term version number interval1.

[0118] 4. Lock client 1 continues to renew the lease lock in order to continue holding the lease lock.

[0119] 5. Agreed to renew the contract.

[0120] 6. Lock client 2 has a higher priority and needs to be locked.

[0121] 7. Lock client 2 sends a lock request to the server. The version number of the lock request is epoch2, and the expiration version number is interval2.

[0122] 8. Determine that the target conditions are met.

[0123] 9. The lock state transitions to a preemptive state. Lock client 2 (from (epoch2, interval2)) is allowed to preempt, and the lock is held by lock client 1 (from (epoch1, interval1)).

[0124] 10. Return to retry, allowing lock client 1 to retry acquiring the lock.

[0125] 11. Periodic renewal. Lock client 1 continuously renews the lease lock.

[0126] 12. Lock has been preempted, returning a STALE error. The server informs lock client 1 that the lease lock has been preempted by lock client 2, and the lease has expired.

[0127] 13. Retry locking. The locking client retryes locking.

[0128] 14. The lock has not expired. Return AGAN to allow lock client 2 to retry acquiring the lock. However, at this time, lock client 1 still holds the lease lock and has not yet released the holding permission, so the lock has not expired.

[0129] 15. Received STALE proactive unlock (epoch1, interval1). Lock client 1 determines that the lock has expired based on the information in step 12 and proactively unlocks it.

[0130] 16. Set the remaining lock time to 0. Set the lease term of the lease lock to client 1 to 0.

[0131] 17. Agree to unlock.

[0132] 18. Stop Service. Stop the service implemented by client 1 through the target resource.

[0133] 19. Retry locking (epoch2, interval2). Client 2 retryes locking.

[0134] 20. The person who locked the lock was the one who seized it, and the lock was legal and had expired.

[0135] 21. Asynchronously update the lock state to the locked state. Furthermore, the lock is currently held by lock client 2.

[0136] 22. Agreed to lock.

[0137] 23. Lock acquisition successful, takeover of services begins. Services implemented by lock client 2 through the target resource.

[0138] exist Figure 7 In the example, to reduce the overhead of negotiation between lock client 1 and lock client 2, the server acts as a bridge, indicating changes to the lease lock through the lock attribute information of the lease lock.

[0139] Meanwhile, in order to reduce deployment costs, the server-side control logic (such as controlling lock client 1 to unlock) is omitted, and only the logic of the server-side return information is retained, with the lock client actively requesting to lock and unlock.

[0140] In this embodiment, a preemption state is introduced. The preemption state is a non-persistent state. This is so that if a cluster-wide failure and restart occurs during the preemption process, the lock state will be restored to the locked state before the preemption occurred, as if the preemption had never happened. This can prevent the lock state from getting stuck in an intermediate state and can also avoid double write failures caused by premature preemption.

[0141] Please see Figure 8 , Figure 8 This illustration shows a block diagram of a resource processing apparatus according to an embodiment of the present application. The resource processing apparatus 800 includes: The response module 810 is used to respond to a lock request received from the target client when the target resource is locked by a lease lock, and determine whether the lock request meets the target conditions based on the difference between the current lock attribute information of the lease lock and the lock attribute information in the lock request. The update module 820 is used to update the lease lock based on the lock attribute information in the lock request if the lock request meets the target conditions; wherein, the client holding the updated lease lock is the target client; the client holding the lease lock is a client with access rights to the target resource; Locking module 830 is used to lock the target resource using an updated lease lock.

[0142] Optionally, the response module 810 is further configured to, in the case where the target resource is locked by a lease lock, respond to receiving a lock request from the target client, determine whether the current holder of the lease lock is the target client; if the current holder of the lease lock is the target client, determine whether the lock request meets the reentrancy condition based on the difference between the current lock attribute information of the lease lock and the lock attribute information in the lock request; if the current holder of the lease lock is the target client and the lock request meets the reentrancy condition, the lock request meets the target condition; if the current holder of the lease lock is not the target client, determine whether the lock request meets the preemption condition based on the difference between the current lock attribute information of the lease lock and the lock attribute information in the lock request; if the current holder of the lease lock is not the target client and the lock request meets the preemption condition, the lock request meets the target condition.

[0143] Optionally, the lock attribute information includes the version information of the lease lock and the term information of the lease period; when the holding client of the lease lock changes, the version information of the lease lock changes; when the holding client of the lease lock remains unchanged but the holding client of the lease lock sends a new lock request, the term information of the lease lock changes; the response module 810 is further configured to determine whether the lock request meets the reentrancy condition if the current holding client of the lease lock is the target client, based on the difference between the current version information of the lease lock and the version information in the lock request, and / or the difference between the current term information of the lease lock and the term information in the lock request.

[0144] Optionally, the version information includes the version number of the lease lock, which changes monotonically over time; the term information includes the term version number of the lease term of the lease lock, which changes monotonically over time when the holding client of the lease lock remains unchanged; the response module 810 is further configured to determine that the lock request satisfies the reentrancy condition if the current holding client of the lease lock is the target client and the difference between the current version number of the lease lock and the version number in the lock request conforms to the monotonic change law corresponding to the version number; and to determine that the lock request satisfies the reentrancy condition if it is determined that the current holding client of the lease lock is the target client, the version number of the lease lock is the same as the version number in the lock request, and the difference between the term version number of the lease lock and the term version number in the lock request conforms to the monotonic change law corresponding to the term version number.

[0145] Optionally, the lock attribute information includes the version information of the lease lock; when the holding client of the lease lock changes, the version information of the lease lock changes; the response module 810 is also used to determine whether the lock request meets the preemption condition based on the difference between the current version information of the lease lock and the version information in the lock request if the current holding client of the lease lock is not the target client.

[0146] Optionally, the version information includes the version number of the lease lock, which changes monotonically over time; the response module 810 is also used to determine that the lock request meets the preemption condition if the current holding client of the lease lock is not the target client and the difference between the current version number of the lease lock and the version number in the lock request conforms to the monotonic change law corresponding to the version number.

[0147] Optionally, the current lock attribute information of the lease lock includes the identifier of the current holding client of the lease lock; the lock attribute information in the lock request also includes the identifier of the target client; the response module 810 is further configured to, in the case that the target resource is locked by the lease lock, in response to receiving the lock request from the target client, determine whether the current holding client of the lease lock is the target client based on the difference between the identifier of the current holding client of the lease lock and the identifier of the target client.

[0148] Optionally, the update module 820 is further configured to update the current lock attribute information of the lease lock based on the lock attribute information in the lock request if the lock request meets the target condition and the current holding client of the lease lock is not the target client; control the lease lock to enter the preemption state; when the lease lock is in the preemption state, the holding client of the lease lock is still the current holding client of the lease lock and the lease lock can only be preempted by the target client; when the lease lock is in the preemption state, unlock the target resource and update the holding client of the lease lock to the target client to complete the update of the lease lock; correspondingly, the locking module 830 is further configured to control the lease lock to exit the preemption state and lock the target resource with the updated lease lock.

[0149] It should be noted that the device embodiments in this application correspond to the aforementioned method embodiments. The specific principles in the device embodiments can be found in the content of the aforementioned method embodiments, and will not be repeated here.

[0150] Figure 9 A structural block diagram of an electronic device for performing a resource processing method according to an embodiment of this application is shown. The electronic device may be... Figure 1 Any node in the distributed storage system 120, etc., should be noted. Figure 9 The computer system 1200 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0151] like Figure 9 As shown, the computer system 1200 includes a Central Processing Unit (CPU) 1201, which can perform various appropriate actions and processes, such as executing the methods described in the above embodiments, based on programs stored in Read-Only Memory (ROM) 1202 or programs loaded from storage portion 1208 into Random Access Memory (RAM) 1203. The RAM 1203 also stores various programs and data required for system operation. The CPU 1201, ROM 1202, and RAM 1203 are interconnected via a bus 1204. An Input / Output (I / O) interface 1205 is also connected to the bus 1204.

[0152] The following components are connected to I / O interface 1205: an input section 1206 including a keyboard, mouse, etc.; an output section 1207 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1208 including a hard disk, etc.; and a communication section 1209 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 1209 performs communication processing via a network such as the Internet. A drive 1210 is also connected to I / O interface 1205 as needed. Removable media 1211, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 1210 as needed so that computer programs read from them can be installed into storage section 1208 as needed.

[0153] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1209, and / or installed from removable medium 1211. When the computer program is executed by central processing unit (CPU) 1201, it performs various functions defined in the system of this application.

[0154] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium, a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such transmitted data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0155] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer-readable instructions.

[0156] The units described in the embodiments of this application can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the specific unit itself.

[0157] In another aspect, this application also provides a computer-readable storage medium, which may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into the electronic device. The aforementioned computer-readable storage medium carries computer-readable instructions that, when executed by a processor, implement the methods in any of the above embodiments.

[0158] According to one aspect of the embodiments of this application, a computer program product is provided, the computer program product including computer-readable instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer-readable instructions from the computer-readable storage medium, and the processor executes the computer-readable instructions, causing the electronic device to perform the methods of any of the above embodiments.

[0159] In the embodiments of this application, the terms "module" or "unit" refer to a part of a computer program with a predetermined function, which works together with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (e.g., processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that functions as a whole.

[0160] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0161] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause an electronic device (such as a personal computer, server, touch terminal, or network device, etc.) to execute the methods according to the embodiments of this application.

[0162] Other embodiments of this application will readily conceive of by those skilled in the art upon consideration of the specification and practice of the embodiments disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. It should be understood that this application 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 this application is limited only by the appended claims.

[0163] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A resource processing method, characterized in that, The method includes: When the target resource is locked by a lease lock, in response to receiving a lock request from the target client, based on the difference between the current lock attribute information of the lease lock and the lock attribute information in the lock request, it is determined whether the lock request meets the target conditions; If the lock request meets the target condition, the lease lock is updated based on the lock attribute information in the lock request; wherein, after the lease lock is updated, the target client becomes the holding client of the updated lease lock; the holding client of the lease lock is a client with access rights to the target resource; The target resource is locked using the updated lease lock.

2. The method according to claim 1, characterized in that, When the target resource is locked by a lease lock, in response to receiving a lock request from the target client, the method determines whether the lock request meets the target condition based on the difference between the current lock attribute information of the lease lock and the lock attribute information in the lock request, including: If the target resource is locked by a lease lock, in response to receiving a lock request from the target client, it is determined whether the client currently holding the lease lock is the target client; If the current holding client of the lease lock is the target client, based on the difference between the current lock attribute information of the lease lock and the lock attribute information in the lock request, it is determined whether the lock request meets the reentrancy condition; if the current holding client of the lease lock is the target client and the lock request meets the reentrancy condition, the lock request meets the target condition. If the current holding client of the lease lock is not the target client, the lock request is determined to meet the preemption condition based on the difference between the current lock attribute information of the lease lock and the lock attribute information in the lock request; if the current holding client of the lease lock is not the target client and the lock request meets the preemption condition, the lock request meets the target condition.

3. The method according to claim 2, characterized in that, The lock attribute information includes the version information of the lease lock and the term information of the lease period; when the holding client of the lease lock changes, the version information of the lease lock changes; when the holding client of the lease lock remains unchanged but the holding client of the lease lock sends a new lock request, the term information of the lease lock changes. If the current holding client of the lease lock is the target client, determining whether the lock request meets the reentrancy condition based on the difference between the current lock attribute information of the lease lock and the lock attribute information in the lock request includes: If the current holding client of the lease lock is the target client, based on the difference between the current version information of the lease lock and the version information in the lock request, and / or the difference between the current term information of the lease lock and the term information in the lock request, it is determined whether the lock request meets the reentrancy condition.

4. The method according to claim 3, characterized in that, The version information includes the version number of the lease lock, which changes monotonically over time; the term information includes the term version number of the lease term of the lease lock, which changes monotonically over time when the holding client of the lease lock remains unchanged. If the current holding client of the lease lock is the target client, the determination of whether the lock request meets the reentrancy condition based on the difference between the current version information of the lease lock and the version information in the lock request, and / or the difference between the current term information of the lease lock and the term information in the lock request includes: If the current holding client of the lease lock is the target client, and the difference between the current version number of the lease lock and the version number in the lock request conforms to the monotonic change pattern corresponding to the version number, then the lock request is determined to satisfy the reentrancy condition; or... If it is determined that the current holding client of the lease lock is the target client, the version number of the lease lock is the same as the version number in the lock request, and the difference between the term version number of the lease lock and the term version number in the lock request conforms to the tone change rule corresponding to the term version number, then the lock request satisfies the reentrancy condition.

5. The method according to claim 2, characterized in that, The lock attribute information includes the version information of the lease lock; when the client holding the lease lock changes, the version information of the lease lock changes; If the current holding client of the lease lock is not the target client, determining whether the lock request meets the preemption condition based on the difference between the current lock attribute information of the lease lock and the lock attribute information in the lock request includes: If the current holding client of the lease lock is not the target client, the system determines whether the lock request meets the preemption condition based on the difference between the current version information of the lease lock and the version information in the lock request.

6. The method according to claim 5, characterized in that, The version information includes the version number of the lease lock, which changes monotonically over time; If the current holding client of the lease lock is not the target client, determining whether the lock request meets the preemption condition based on the difference between the current version information of the lease lock and the version information in the lock request includes: If the current holding client of the lease lock is not the target client, and the difference between the current version number of the lease lock and the version number in the lock request conforms to the monotonic change pattern corresponding to the version number, then the lock request is determined to meet the preemption condition.

7. The method according to any one of claims 2-6, characterized in that, The current lock attribute information of the lease lock includes the identifier of the current holding client of the lease lock; the lock attribute information in the lock request also includes the identifier of the target client; When the target resource is locked by a lease lock, in response to receiving a lock request from the target client, determining whether the client currently holding the lease lock is the target client includes: When the target resource is locked by a lease lock, in response to receiving a lock request from the target client, the system determines whether the current holder of the lease lock is the target client based on the difference between the identifier of the current holder of the lease lock and the identifier of the target client.

8. The method according to claim 1, characterized in that, If the lock request satisfies the target condition, the lease lock is updated based on the lock attribute information in the lock request, including: If the lock request meets the target condition and the current holding client of the lease lock is not the target client, the current lock attribute information of the lease lock is updated based on the lock attribute information in the lock request; Control the lease lock to enter the preemption state; when the lease lock is in the preemption state, the client holding the lease lock is still the current client holding the lease lock, and the lease lock can only be preempted by the target client; When the lease lock is in a preemptive state, unlock the target resource and update the lease lock holder client to the target client to complete the lease lock update; The step of locking the target resource using the updated lease lock includes: Control the lease lock to exit the preemption state, and lock the target resource with the updated lease lock.

9. A resource processing device, characterized in that, The device includes: The response module is used to, when the target resource is locked by a lease lock, respond to a lock request received from the target client and determine whether the lock request meets the target conditions based on the difference between the current lock attribute information of the lease lock and the lock attribute information in the lock request; An update module is used to update the lease lock based on the lock attribute information in the lock request if the lock request meets the target condition; wherein, after the lease lock is updated, the target client becomes the holding client of the updated lease lock; the holding client of the lease lock is a client with access rights to the target resource; A locking module is used to lock the target resource using an updated lease lock.

10. A distributed storage system, characterized in that, The distributed storage system includes multiple nodes, and each node includes at least two controllers and a shared storage disk; Each controller corresponds to at least one client, and at least one controller in each node corresponds to a server. For each node, the server of the node communicates with each client in the node and the shared storage disk respectively; For each of the servers, the server is used to perform the method of any one of claims 1-8.

11. A computer-readable storage medium, characterized in that, It stores computer-readable instructions that, when executed by a processor, implement the method as described in any one of claims 1-8.

12. A computer program product, characterized in that, It includes computer-readable instructions that, when executed by a processor, implement the method of any one of claims 1-8.

Images