JP2018110031A - Method of managing lock in cluster, lock server and client - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a method of managing lock in a cluster, a lock server and client.SOLUTION: A cluster includes a client and a lock server. The lock server includes an interface card and a memory. The memory is brought in its standby state to look for a read lock or stores a lock request queue. The memory further includes a read lock allocating count and a write lock allocating identifier. The read lock allocating count is used for recording an allocated read lock. The write lock allocating identifier is used for indicating whether or not a write lock is allocated. The client communicates with the interface card of the lock server by using an RDMA protocol to carry out a lock operation.SELECTED DRAWING: Figure 2

Description

  The present invention relates to the field of information technology, and more particularly to a lock management method, a lock server, and a client in a cluster.

  The cluster includes a plurality of clients, and in order to obtain a processing permission such as a write permission or a read permission for a shared resource in the cluster, the client needs to apply for a processing permission from a lock server in the cluster. . This is commonly referred to as a lock application. In general, write permission is also called write lock or exclusive lock, and read permission is called read lock or shared lock.

  In the conventional technique, as shown in FIG. 1, the cluster includes a lock server, a client A, and a client B in a method of applying for a write lock by a client. Client A locks for a write lock by using Remote Direct Memory Access (RDMA) protocol, for example, by using atomic operation Compare-and-Swap in RDMA protocol By applying to the server, the identifier of client A is written to the memory address of the lock server, that is, client A acquires a write lock by applying to the lock server, that is, the write lock is assigned to client A. . Client B asks the lock server for a write lock by using Compare-and-Swap, the lock server returns the identifier of client A to client B, and client B returns Compare-and-Swap. By using it, the client A applies for a write lock according to the identifier of the client A. Before client A releases the write lock, client B is in a write lock wait state.

  In the prior art implementation solution, if client A fails, the lock server does not recognize that client B is in the write lock standby state, so client B cannot obtain a write lock by application and always Waiting for write lock. From the foregoing description, it can be appreciated that the lock server in the prior art can obtain the lock state of only one current client.

  According to a first aspect, an embodiment of the present invention provides a lock management method in a cluster, the cluster includes a plurality of clients and a lock server, the lock server includes an interface card and a memory, The memory stores a write lock request queue, a write lock allocation identifier, and a read lock allocation count, and the write lock request queue is for a client resource that is in a write lock wait state for the shared resource and for the same shared resource. Used to record the identifier of the client in the cluster, including the identifier of the client that obtains the write lock, and the write lock assignment identifier is used to indicate whether a write lock for the shared resource has been assigned. Read lock allocation count Used to indicate the number of read locks allocated for a shared resource, the lock management method receives a first write lock request sent by a first client in a plurality of clients by an interface card The first write lock request includes a step of conveying an identifier of the first client and a memory address at a head of the queue of the write lock request queue, and a queue of the write lock request queue of the first client. To write to the first memory address and to determine whether the read lock is assigned by the interface card, query the read lock assignment count, and if the read lock is not assigned, write the write lock assignment identifier. Set to a lock-assigned state, send a message to the first client indicating that the first client acquires a write lock, and if a read lock is assigned, the second Sending a message to the first client, and the second message includes indicating that the first client is in a write lock wait state. In this embodiment of the invention, by using a write lock request queue in memory, a write lock assignment identifier, and a write lock assignment count, the lock server acquires a write lock or asks for a write lock. You can decide to wait.

  Referring to the first aspect, in a first possible implementation manner, the cluster further includes a second client, the method sent by the second client in the plurality of clients by the interface card. Receiving a second write lock request, wherein the second write lock request carries an identifier of the second client and a first memory address in the write lock request queue, wherein the first memory address is The identifier of the second client can be written, except for the memory address at the head of the queue of the write lock request queue, the step being the memory address in the sequence from the head of the queue to the end of the queue, The first memory in the write lock request queue Further comprising a step of writing the address, the interface card, and a step in which the second client sends a message to indicate that the write lock wait state to the second client. Therefore, the lock server can determine the client in the write lock waiting state by using the write lock request queue. Optionally, the first memory address is the first in the sequence from the queue head to the queue tail to which the second client identifier can be written, except for the memory address at the head of the queue of the write lock request queue. Memory address.

  Referring to the first aspect, in a second possible implementation scheme, the lock server memory includes a read lock request queue, and if the read lock allocation count indicates that a read lock is allocated, the read lock The request queue is used to record the identifier of the third client in the cluster that obtains a read lock for the shared resource.

  Referring to the first possible implementation scheme, in the third possible implementation scheme, the first write lock request further carries a lock lease, which is used to indicate the validity period of the write lock. Is done. By using a lock lease, the lock server may release the write lock according to the lock lease.

  Referring to the first possible implementation scheme, in the fourth possible implementation scheme, after the first client has acquired a write lock, the method uses a write sent by the first client by the interface card. A step of receiving a lock release request, the write lock release request is a step of conveying a memory address at the head of a queue of the write lock request queue, and a step of setting a write lock assignment identifier to a write lock unassigned state by an interface card And deleting the identifier of the first client from the memory address at the head of the write lock request queue by the interface card. The first client releases the write lock, so that other clients in the cluster may acquire the write lock.

  Referring to the first possible implementation scheme, in the fifth possible implementation scheme, if the first client fails after acquiring the write lock, the method will cause the interface card to write the write lock assignment identifier. And a step of deleting the identifier of the first client from the memory address at the head of the write lock request queue by the interface card. Optionally, the interface card receives notifications sent by other clients in the cluster to determine that the first client has failed. Releasing the failed first client's write lock can prevent the failed first client from holding the write lock for an extended period of time. Optionally, the interface card sends a notification to clients in the cluster except for the first client, which indicates that the write lock held by the first client has been released.

  Referring to the fourth or fifth possible implementation scheme, in the sixth possible implementation scheme, the method uses the interface card to determine the second client in the write lock wait state to determine the second client Querying the request queue; and sending, by the interface card, a notification to the second client to instruct the second client to apply to the interface card for a write lock. The lock server instructs a client in a write lock waiting state to request and apply for a write lock in a timely manner.

  Referring to the fifth possible implementation scheme, in the seventh possible implementation scheme, this method is a step of sending a notification to the clients in the cluster except for the first client by means of an interface card, , Further comprising indicating that the write lock held by the first client has been released.

  Referring to the fourth possible implementation scheme, in the eighth possible implementation scheme, the method is the step of receiving, by the interface card, a write lock request inquiry message sent by the first client and writing The lock request inquiry message carries the step of carrying the next memory address following the head of the write lock request queue, and the interface card determines the client identifier stored at the next memory address following the head of the write lock request queue. And a step of sending a write lock request inquiry response message to the first client by the interface card. The write lock request inquiry response message is a class stored in the next memory address. Further comprising the step of conveying the Ant identifier.

  Referring to the fourth possible implementation scheme, in the ninth possible implementation scheme, this method uses the interface card to determine the client identifier stored at the next memory address following the head of the write lock request queue. Stored in the next memory address by the interface card and a notification for instructing the client corresponding to the client identifier stored in the next memory address to apply for a write lock. Transmitting to the client corresponding to the client identifier. Therefore, the write lock may be applied according to a sequence starting from the top of the write lock request queue of the client in the write lock standby state.

  Referring to the fourth possible realization scheme, in the tenth possible realization scheme, the write lock request queue further stores the write lock priority of the client in the write lock wait state, and the method comprises an interface card. A step of receiving a write lock request inquiry message transmitted by the first client, and a step of inquiring for a write lock priority of a client in a write lock waiting state in the write lock request queue by an interface card, and The interface card sends a write lock request inquiry response message to the first client, and the inquiry response message is recorded in the write lock request queue of the client in the write lock standby state. Further comprising the step of conveying the identifier and write lock priority.

  Referring to the fourth possible implementation scheme, in the eleventh possible implementation scheme, the write lock request queue further stores the write lock priority of the client in the write lock standby state, the method comprising: In order to determine the client with the highest write lock priority, the step of inquiring for the write lock priority recorded in the write lock request queue of the client in the write lock waiting state and the interface card Send a notification to the client with the highest write lock priority to send a notification to the client with the highest write lock priority to instruct them to apply for a write lock. The client that has Further comprising the step of applying to seek a click.

  Referring to the fourth possible implementation scheme, in a twelfth possible implementation scheme, the method includes querying a write lock request queue by an interface card to determine a client in a write lock wait state; Sending a notification by the interface card to instruct at least two clients to send a write lock request to the interface card to at least two clients in a client in a write lock wait state; Including.

  Corresponding to the first aspect, according to the second aspect, an embodiment of the present invention provides a lock management method in a cluster, the cluster including a plurality of clients and a lock server, An interface card and memory, wherein the memory stores a write lock request queue, a write lock assignment identifier, and a read lock assignment count, wherein the write lock request queue is for a client in a write lock wait state for a shared resource. Used to record the identifier of the client in the cluster, including the identifier and the identifier of the client that obtains the write lock for the same shared resource, the write lock assignment identifier is assigned by the write lock for the shared resource Used to indicate whether or not The lock allocation count is used to indicate the number of read locks allocated for the shared resource, and the lock management method locks the first write lock request by the first client in the plurality of clients to the lock server. The first write lock request includes the step of conveying the identifier of the first client and the memory address at the head of the queue of the write lock request queue; Receiving the first message sent by the first message, indicating that the interface card writes the identifier of the first client to the memory address at the head of the queue of the write lock request queue; The client locks the write lock To indicate that the interface card is in a write lock standby state and that the interface card failed to write the identifier of the first client to the memory address at the head of the write lock request queue. Indicates that the first client sends a second write lock request to the interface card, wherein the second write lock request includes the first client identifier and the first in the write lock request queue. And the first memory address includes a step that is a memory address in a sequence from the head of the queue to the end of the queue to which the identifier of the first client can be written. Optionally, the first memory address is the first memory address in the sequence from the top of the queue to the end of the queue where the identifier of the first client can be written.

  Referring to the second aspect, in a first possible implementation scheme, the first write lock request and the second write lock request further carry a lock lease, and the lock lease determines the lifetime of the write lock. Used to indicate. The lock server may release the expired write lock of the first client according to the lock lease to prevent the first client from occupying the write lock for a long period of time.

  Referring to the second aspect, in a second possible implementation scheme, after the first client acquires a write lock, the method sends a write lock release request to the interface card by the first client. The step of releasing the write lock further includes a step of conveying a memory address at the head of the write lock request queue.

  Referring to the second possible realization scheme, in the third possible realization scheme, this method is a step of sending a write lock request inquiry message to the interface card by the first client. The message is a step of carrying the next memory address following the head of the write lock request queue and a step of receiving a write lock request inquiry response message sent by the interface card. A step of carrying the client identifier stored in the next memory address following the head of the lock request queue, and the client identifier carried in the write lock request inquiry response message by the first client Therefore, sending a notification to instruct the client to apply for a write lock request to the client corresponding to the client identifier stored at the next memory address following the head of the write lock request queue; Is further included.

  Referring to the second possible implementation scheme, in the fourth possible implementation scheme, this method comprises the steps of sending a write lock request inquiry message to the interface card by the first client and sent by the interface card. Receiving a write lock request inquiry response message, wherein the inquiry response message carries an identifier and a write lock priority recorded in a write lock queue of a client in a write lock standby state; The client determines the client having the highest write lock priority according to the write lock request inquiry response message, and the first client writes to the client having the highest write lock priority. A notification for instructing to transmit only lock request to the interface card, further comprising the step of transmitting to the client with the highest write lock priority.

  According to a third aspect, an embodiment of the present invention provides another lock management method in a cluster, the cluster including a first client and a lock server, the lock server comprising an interface card, a memory, And the memory stores a read lock request queue and a write lock assignment identifier, wherein the read lock request queue is in a read lock wait state for the same shared resource or acquires a read lock in the cluster. Used to record an identifier of a client, a write lock assignment identifier is used to indicate whether a write lock for a shared resource has been assigned, and a lock management method is used by an interface card by multiple clients. First read sent by the first client in The first read lock request carries the identifier of the first client and the first memory address in the read lock request queue; Writing a client identifier to a first memory address in a read lock request queue; and sending a first message to the first client by an interface card, the first message being a write lock assignment identifier Conveying. By using the read lock request queue, the read lock request status of the clients in the cluster can be recorded, i.e., the client is in a read lock waiting state or obtains a read lock.

  Referring to the third aspect, in a first possible implementation scheme, if the write lock assignment identifier indicates that a write lock has been assigned, the first message is received by the first client in a read lock wait state. Indicates that

  Referring to the third aspect, in a second possible implementation manner, the memory further stores a read lock allocation count, the read lock allocation count indicating the number of read locks allocated for the shared resource. If the write lock assignment identifier indicates that the write lock is not assigned, the interface card increments the read lock assignment count according to the number of read locks assigned to the first client and the first message Indicates that the first client acquires a read lock.

  Referring to the first possible implementation manner of the third aspect, in the third possible implementation manner, the plurality of clients further includes a second client, and the memory further stores a write lock request queue. The write lock request queue records the identifiers of clients in the cluster, including the identifiers of clients that are in a write lock wait state for shared resources and the identifiers of clients that acquire write locks for shared resources. And the write lock assignment identifier indicates that the write lock is assigned, the second client identifier is stored in the memory address at the head of the write lock request queue. The write lock request queue in the lock server's memory records the client that gets the write lock, the write lock is assigned, and the client in the read lock request queue is in the read lock wait state, so the lock server Information about the client that acquires the write lock is recorded, and information about the client that is in the read lock standby state is also recorded.

  Referring to the third aspect, in a fourth possible implementation manner, the plurality of clients further includes a third client, and the identifier of the third client is the memory address at the head of the queue of the read lock request queue. The first memory address that is stored and carried in the first read lock request in the read lock request queue can be written with the identifier of the first client, from the head of the read lock request queue to the end of the queue This is the memory address in the sequence up to. The read lock request queue in the lock server's memory may record multiple clients, and therefore the lock server will read multiple clients in read lock state, i.e., whether multiple clients are in read lock wait state. You may check if you want to acquire a lock. Optionally, the first memory address is the first memory address in the sequence from the top of the read lock request queue to the end of the queue where the identifier of the first client can be written.

  Referring to the third aspect, in a fifth possible implementation scheme, the first read lock request further carries a lock lease, which is used to indicate the validity period of the read lock and the lock If the lease expires, the lock server may release the read lock in a timely manner.

  Referring to the second possible implementation manner of the third aspect, in the 6th possible implementation manner, the method comprises receiving, by the interface card, a read lock release request sent by the first client. The read lock release request was assigned to the first client by the interface card carrying the first memory address in the read lock request queue storing the identifier of the first client. Decreasing the read lock allocation count in memory according to the number of read locks, and further deleting, by the interface card, the first client identifier from the first memory address in the read lock request queue. The first client may release the read lock, which may cause the lock server to assign a write lock. Optionally, the first client sends a read lock release request in accordance with notifications of other clients applying for a write lock.

  Referring to the second possible implementation scheme of the third aspect, in the seventh possible implementation scheme, if the first client fails after acquiring the read lock, this method is performed by the interface card. Reducing the read lock allocation count in the memory according to the number of read locks allocated to the first client, and the interface card deriving the first client identifier from the first memory address in the read lock request queue by the interface card. And deleting. If a failure occurs after the first client acquires the read lock, the lock server's interface card will lock the first client's read lock to prevent the failed client from holding the read lock for an extended period of time. release. Optionally, the interface card may determine that the first client has failed in accordance with other client notifications and then release the read lock held by the first client.

  According to a fourth aspect, an embodiment of the present invention provides another lock management method in a cluster, the cluster including a plurality of clients and a lock server, the lock server comprising an interface card and a memory. The memory stores a read lock request queue and a write lock assignment identifier, and the read lock request queue is in a read lock wait state for the same shared resource or is in a cluster that acquires a read lock Used to record the identifier of the client, the write lock assignment identifier is used to indicate whether or not a write lock for the shared resource has been assigned, and the lock management method is the first in the plurality of clients. Client sends first read lock request to interface card The first read lock request is transmitted by the interface card by the first client and carrying the identifier of the first client and the first memory address in the read lock request queue. Receiving a first message, the first message carrying a write lock assignment identifier.

  Referring to the fourth aspect, in a first possible implementation scheme, if the write lock assignment identifier indicates that a write lock has been assigned, the first message is received by the first client in a read lock wait state. Indicates that

  Referring to the fourth aspect, in the second possible implementation scheme, if the write lock assignment identifier indicates that the write lock is not assigned, the first message is obtained by the first client acquiring the read lock. It shows that.

  Referring to the fourth aspect, in a third possible implementation manner, the cluster further includes a second client, and the identifier of the second client is stored in the memory address at the head of the queue of the read lock request queue. The first memory address carried by the first read lock request in the read lock request queue can be written with the identifier of the first client from the head of the read lock request queue to the end of the queue. A memory address in the sequence. Optionally, the first memory address is the first memory address in the sequence from the top of the read lock request queue to the end of the queue where the identifier of the first client can be written.

  Referring to the fourth aspect, in a fourth possible implementation scheme, the first read lock request further carries a lock lease, which is used to indicate the validity period of the read lock.

  Referring to the second possible implementation manner of the fourth aspect, in the fifth possible implementation manner, if the first client acquires a read lock, the method is executed by the first client by the read lock. Sending a release request to the interface card, the read lock release request further comprising conveying a memory address in a read lock request queue in which the identifier of the first client is stored. Optionally, the first client receives a notification sent by another client applying for a write lock and performs a read lock release operation.

  According to a fifth aspect, an embodiment of the present invention provides another lock management method in a cluster, wherein the cluster includes a lock server, a first client, and a second client, the lock server comprising: An interface card and a memory, wherein the memory stores a write lock request queue and a write lock allocation identifier, and the first client identifier is stored at a memory address at the head of the queue of the write lock request queue; The queue further stores the identifier of the second client, the write lock assignment identifier indicates that a write lock is assigned, the first client acquires a write lock for the shared resource, and the second Client is in a write lock wait state for a shared resource and locked The processing method is a step of receiving the write lock release request of the first client by the interface card, and the write lock release request is carried by the step of conveying the memory address at the head of the queue of the write lock request queue and the interface card. A step of deleting the identifier of the first client from the write lock request queue according to the memory address at the head of the queue of the write lock request queue, and a step of receiving a write lock request inquiry message transmitted by the first client by the interface card. Yes, the write lock request inquiry message carries a memory address in the write lock request queue in which the second client identifier is stored; To send a write lock request inquiry response message to the first client, and the write lock request inquiry response message is sent by the first client via the interface card and the interface card. The write lock occupancy request, the write lock occupancy request includes a step of conveying an identifier of the second client and a memory address at the head of the queue of the write lock request queue, and a second by the interface card. Writing the client identifier to the memory address at the head of the write lock request queue. In this embodiment of the invention, when the first client releases the write lock, the write lock is assigned directly to the client in the write lock wait state recorded in the write lock request queue.

  Referring to the fifth aspect, in a first possible implementation scheme, the memory address in the write lock request queue, where the identifier of the second client is stored, is the next following the queue head of the write lock request queue. Memory address. Therefore, the client whose identifier is stored at the next memory address following the head of the write lock request queue preferentially acquires the write lock.

  Referring to the fifth aspect, in a second possible implementation scheme, the write lock request queue further stores the write lock priority of the second client, and the write lock priority of the second client is write The best client in the lock request queue that is waiting for a write lock. Therefore, the client having the highest write lock priority among clients in the write lock waiting state recorded in the write lock request queue preferentially acquires the write lock.

  According to a sixth aspect, an embodiment of the present invention provides another lock management method in a cluster, wherein the cluster includes a lock server, a first client, and a second client, the lock server comprising: The memory includes an interface card and a memory, and the memory stores a write lock request queue, a read lock request queue, a read lock allocation count, and a write lock allocation identifier, and the first client identifier is a head of the write lock request queue. The read lock request queue stores the identifier of the second client, the write lock assignment identifier indicates that a write lock is assigned, the read lock assignment count is zero, 1 client writes for shared resources The lock is acquired, the second client is in a read lock waiting state for the shared resource, and the lock management method is a step of receiving a write lock release request transmitted by the first client by the interface card. The write lock release request includes a step of conveying the memory address at the head of the write lock request queue, a step of setting the write lock assignment identifier to a write lock unassigned state by the interface card, and a write lock request by the interface card. Deleting the identifier of the first client from the write lock request queue in accordance with the memory address at the head of the queue of the queue, and a read lock request sent by the first client by the interface card. Receiving an inquiry message; sending a read lock request inquiry response message to the first client by means of the interface card; the read lock request inquiry response message carrying an identifier of the second client; Receiving, by the interface card, a read lock allocation count change request sent by the first client; and increasing the read lock allocation count in the memory according to the read lock allocation count change request by the interface card. When the first client's write lock is released, the read lock is assigned directly to the client in the read lock wait state recorded in the read lock request queue.

  According to a seventh aspect, an embodiment of the present invention provides another lock management method in a cluster, wherein the cluster includes a lock server, a first client, and a second client, the lock server comprising: An interface card and a memory, wherein the memory stores a write lock request queue and a write lock allocation identifier, and the first client identifier is stored at a memory address at the head of the queue of the write lock request queue; The queue further stores the identifier of the second client, the write lock assignment identifier indicates that a write lock is assigned, the first client acquires a write lock for the shared resource, and the second Client is in a write lock wait state for a shared resource and locked The processing method is a step of transmitting a write lock release request to the interface card by the first client. The write lock release request is transferred to the memory address at the head of the queue of the write lock request queue. When the first client identifier is deleted from the write lock request queue according to the memory address at the head of the lock request queue, the first client sends a write lock request inquiry message to the interface card. The inquiry message includes a step of carrying a memory address in a write lock request queue in which an identifier of the second client is stored, and an interface card by the first client. Receiving the write lock request inquiry response message transmitted by the step, wherein the write lock request inquiry response message carries the identifier of the second client, and the write lock occupation request is sent to the interface card by the first client. The write lock occupancy request includes a step of conveying the identifier of the second client and the memory address at the head of the queue of the write lock request queue, and the identifier of the second client is transmitted by the first client. A step of receiving a write lock occupation request response sent by the interface card indicating that the write lock request queue is written to the memory address at the head of the queue, and a first client sending a notification to the second client And the notification includes the step of indicating that the second client acquires a write lock. When the first client releases the write lock, the write lock is assigned directly to the client in the write lock wait state recorded in the write lock request queue.

  Referring to the seventh aspect, in a first possible implementation scheme, the memory address in the write lock request queue, where the identifier of the second client is stored, is the next following the queue head of the write lock request queue. Memory address. Therefore, the client whose identifier is stored at the next memory address following the head of the write lock request queue preferentially acquires the write lock.

  Referring to the seventh aspect, in a second possible implementation scheme, the write lock request queue further stores the write lock priority of the second client, and the write lock priority of the second client is write The best client in the lock request queue that is waiting for a write lock. Therefore, the client having the highest priority among the clients in the write lock waiting state recorded in the write lock request queue preferentially acquires the write lock.

  According to an eighth aspect, an embodiment of the present invention provides another lock management method in a cluster, wherein the cluster includes a lock server, a first client, and a second client, the lock server comprising: The memory includes an interface card and a memory, and the memory stores a write lock request queue, a read lock request queue, a read lock allocation count, and a write lock allocation identifier, and the first client identifier is a head of the write lock request queue. The read lock request queue stores the identifier of the second client, the write lock assignment identifier indicates that a write lock is assigned, the read lock assignment count is zero, 1 client writes for shared resources The lock is acquired, the second client is in a read lock waiting state for the shared resource, and the lock management method is a step of sending a write lock release request to the interface card by the first client, and the write lock For the release request, the step of transporting the memory address at the head of the write lock request queue, the interface card sets the write lock assignment identifier to the write lock unassigned state, and the write lock is performed according to the memory address at the head of the write lock request queue. When the identifier of the first client is deleted from the request queue, the first client sends a read lock request inquiry message to the interface card, and the first client Receiving a read lock request inquiry response message transmitted by the scan card, the read lock request inquiry response message carrying a second client identifier, and a read lock allocation count change request by the first client. Transmitting to the interface card. When the first client releases the read lock, the read lock is assigned directly to the client in the read lock wait state recorded in the read lock request queue.

  According to a ninth aspect, an embodiment of the present invention provides another lock management method in a cluster, wherein the cluster includes a lock server, a first client, and a second client, the lock server comprising: An interface card and a memory, wherein the memory stores a write lock request queue and a write lock allocation identifier, and the first client identifier is stored at a memory address at the head of the queue of the write lock request queue; The queue further stores the identifier of the second client, the write lock assignment identifier indicates that a write lock is assigned, the first client acquires a write lock for the shared resource, and the second Client is in a write lock wait state for a shared resource and locked The processing method is a step of transmitting a write lock release request to the interface card by the first client. The write lock release request is transferred to the memory address at the head of the queue of the write lock request queue. When the lock allocation identifier is set to the write lock unallocated state and the first client identifier is deleted from the write lock request queue according to the memory address at the head of the write lock request queue, the first client makes a write lock request inquiry Sending a message to the interface card, wherein the write lock request inquiry message is a memory address in the write lock request queue in which the identifier of the second client is stored. And receiving a write lock request inquiry response message sent by the interface card by the first client, wherein the write lock request inquiry response message carries the identifier of the second client; Sending a notification to the second client by the first client according to the identifier of the second client, the notification instructing the second client to send a write lock request to the interface card. Used for the purpose. When releasing the write lock, the first client instructs the client in the write lock waiting state to send a write lock request.

  Referring to the ninth aspect, in the first possible realization scheme, the memory address in the write lock request queue where the identifier of the second client is stored is the next following the queue head of the write lock request queue. Memory address. The client whose identifier is stored at the next memory address following the head of the write lock request queue preferentially obtains the write lock request notification transmitted by the first client.

  Referring to the ninth aspect, in the second possible implementation scheme, the write lock request queue further stores the write lock priority of the second client, and the write lock priority of the second client is write The best client in the lock request queue that is waiting for a write lock. Therefore, the client having the highest write lock priority among the clients in the write lock waiting state recorded in the write lock request queue preferentially obtains the write lock request notification transmitted by the first client. To do.

  According to a tenth aspect, an embodiment of the present invention provides another lock management method in a cluster, wherein the cluster includes a lock server, a first client, and a second client, the lock server comprising: The memory includes an interface card and a memory, and the memory stores a write lock request queue, a read lock request queue, a read lock allocation count, and a write lock allocation identifier, and the first client identifier is a head of the write lock request queue. The read lock request queue stores the identifier of the second client, the write lock assignment identifier indicates that a write lock is assigned, the read lock assignment count is zero, 1 client writes for shared resources The second client is in a read lock waiting state for the shared resource, and the lock management method is a step of sending a write lock release request to the interface card by the first client, The lock release request is written according to the step of conveying the memory address at the head of the write lock request queue, and the interface card sets the write lock assignment identifier to the write lock unassigned state, and writes according to the memory address at the head of the write lock request queue. If the identifier of the first client is deleted from the lock request queue, the first client sends a read lock request inquiry message to the interface card, and the first client Receiving a read lock request inquiry response message sent by the source card, the read lock request inquiry response message carrying a second client identifier, and the first client identifying the second client identifier And sending a notification to the second client, wherein the notification includes instructing the second client to apply for a read lock. When releasing the write lock, the first client instructs the second client in the read lock waiting state to apply for a read lock, and the second client changes the read lock allocation count. The request is sent to the interface card, the interface card changes the read lock allocation count, and the second client acquires the read lock.

  According to an eleventh aspect, an embodiment of the present invention provides another lock management method in a cluster, wherein the cluster includes a lock server, a first client, and a second client, the lock server comprising: An interface card and a memory, wherein the memory stores a write lock request queue, a read lock request queue, a read lock allocation count, and a write lock allocation identifier, and the read lock request queue stores an identifier of the first client. The second client identifier is stored at the memory address at the head of the write lock request queue, the write lock allocation identifier indicates that no write lock is allocated, and the read lock allocation count is determined by the first client. With the quantity of read locks acquired The first client acquires a read lock for the shared resource, the second client is in a write lock waiting state for the shared resource, and the lock management method is performed by the first client by the read lock. Sending a release request to the interface card, wherein the read lock release request carries a memory address in a read lock request queue in which the identifier of the first client is stored, and the interface card assigns a read lock. If the first client identifier is deleted from the read lock request queue according to the memory address in the read lock request queue where the count is decreased to 0 and the first client identifier is stored, Write lock required A step of transmitting an inquiry message to the interface card, wherein the write lock request inquiry message includes a step of conveying a memory address at the head of the queue of the write lock request queue, and a write lock request transmitted by the interface card by the first client. Receiving a query response message, wherein the write lock request query response message carries a second client identifier, and the first client sends a notification to the second client according to the second client identifier. Sending and the notification includes a step used to instruct the second client to apply for a write lock. When releasing the read lock, the first client asks the second client in the write lock waiting state whose identifier is recorded at the head of the write lock request queue to apply for the write lock. The second client sends a write lock assignment identifier change request to the interface card according to the notification, the interface card sets the write lock assignment identifier to the write lock assigned state, and the second client To get.

  According to a twelfth aspect, an embodiment of the present invention provides another lock management method in a cluster, wherein the cluster includes a lock server, a first client, and a second client, the lock server comprising: An interface card and a memory, wherein the memory stores a write lock request queue, a read lock request queue, a read lock allocation count, and a write lock allocation identifier, and the read lock request queue stores an identifier of the first client. The second client identifier is stored at the memory address at the head of the write lock request queue, the write lock allocation identifier indicates that no write lock is allocated, and the read lock allocation count is determined by the first client. With the quantity of read locks acquired The first client acquires a read lock for the shared resource, the second client is in a write lock waiting state for the shared resource, and the lock management method is performed by the first client by the read lock. Sending a release request to the interface card, wherein the read lock release request carries a memory address in a read lock request queue in which the identifier of the first client is stored; When the read lock allocation count is decreased to 0 and the first client identifier is deleted from the read lock request queue according to the memory address in the read lock request queue where the first client identifier is stored, Write by client A step of transmitting a lock request inquiry message to the interface card, wherein the write lock request inquiry message includes a step of conveying a memory address at the head of the queue of the write lock request queue, and a write sent by the interface card by the first client A step of receiving a lock request inquiry response message. The write lock request inquiry response message includes a step of conveying an identifier of the second client, and a write lock assignment identifier change request is transmitted to the interface card by the first client. And when the interface card sets the write lock assignment identifier to the write lock assigned state according to the write lock assignment identifier change request, The first client is sending a notification in accordance with the identifier of the second client to the second client, the notification, and a step of indicating that the second client obtains a write lock. When the first client releases the read lock, the write lock is assigned directly to the second client in the write lock wait state whose identifier is recorded at the head of the write lock request queue.

  According to a thirteenth aspect, an embodiment of the present invention provides another lock management method in a cluster, wherein the cluster includes a lock server, a first client, and a second client, the lock server comprising: An interface card and a memory, wherein the memory stores a write lock request queue, a read lock request queue, a read lock allocation count, and a write lock allocation identifier, and the read lock request queue stores an identifier of the first client. The second client identifier is stored at the memory address at the head of the write lock request queue, the write lock allocation identifier indicates that no write lock is allocated, and the read lock allocation count is determined by the first client. With the quantity of read locks acquired The first client acquires a read lock for the shared resource, the second client is in a write lock waiting state for the shared resource, and the lock management method is performed by the interface card by the first client. A read lock release request transmitted by the interface card, the read lock release request carrying a memory address in a read lock request queue storing an identifier of the first client; Decrementing the read lock allocation count to 0 and deleting the first client identifier from the read lock request queue in accordance with a memory address in the read lock request queue stored with the first client identifier; and Mosquito A write lock request inquiry message sent by the first client, the write lock request inquiry message includes a step of conveying a memory address at the head of the write lock request queue, and an interface card, Sending a write lock request inquiry response message to the first client, the write lock request inquiry response message carrying a second client identifier. When the read lock of the first client is released, the interface card is in a write lock standby state in which the identifier is recorded at the head of the queue of the write lock request queue in order to preferentially process the write lock. Ask for clients.

  According to a fourteenth aspect, an embodiment of the present invention provides another lock management method in a cluster, wherein the cluster includes a lock server, a first client, and a second client, the lock server comprising: An interface card and a memory, wherein the memory stores a write lock request queue, a read lock request queue, a read lock allocation count, and a write lock allocation identifier, and the read lock request queue stores an identifier of the first client. The second client identifier is stored at the memory address at the head of the write lock request queue, the write lock allocation identifier indicates that no write lock is allocated, and the read lock allocation count is determined by the first client. With the quantity of read locks acquired The first client acquires a read lock for the shared resource, the second client is in a write lock waiting state for the shared resource, and the lock management method is performed by the interface card by the first client. A read lock release request transmitted by the interface card, the read lock release request carrying a memory address in a read lock request queue storing an identifier of the first client; Decrementing the read lock allocation count to 0 and deleting the first client identifier from the read lock request queue in accordance with a memory address in the read lock request queue stored with the first client identifier; and Mosquito A write lock request inquiry message sent by the first client, the write lock request inquiry message includes a step of conveying a memory address at the head of the write lock request queue, and an interface card, Sending a write lock request inquiry response message to the first client, the write lock request inquiry response message being sent by the first client by the interface card and carrying the identifier of the second client The step of receiving the write lock assignment identifier change request and the interface card writes the write lock assignment identifier according to the write lock assignment identifier change request. Tsu and a step of setting to click allocated state. When the read lock of the first client is released, the write lock is directly assigned to the client in the write lock waiting state recorded at the head of the queue of the write lock request queue.

  According to a fifteenth aspect, an embodiment of the present invention provides another lock management method in a cluster, wherein the cluster includes a lock server, a first client, and a second client, the lock server comprising: An interface card and a memory, wherein the memory stores a write lock request queue and a write lock assignment identifier, the identifier of the first client is stored at a memory address at the head of the queue of the write lock request queue, and the second The client identifier is further stored at the next memory address following the head of the write lock request queue, the write lock assignment identifier indicates that a write lock is assigned, and the first client is for a shared resource. The second client acquires a write lock for the shared resource The lock management method is a step of receiving the write lock release request of the first client by the interface card, and the write lock release request is obtained by changing the memory address at the head of the queue of the write lock request queue. Conveying step, deleting the identifier of the first client from the write lock request queue according to the memory address at the head of the queue of the write lock request queue by the interface card, and continuing to the head of the queue of the write lock request queue by the interface card A step of inquiring for the identifier of the second client stored at the next memory address, and an identifier of the second client by the interface card are written at the head of the queue of the write lock request queue. Comprising a step of writing the physical address, the interface card, and sending a notification for instructing to obtain a write lock on the second client to the second client. In this embodiment of the invention, when the first client releases the write lock, the lock server assigns the write lock to the client in the write lock wait state recorded in the write lock request queue.

  According to a sixteenth aspect, an embodiment of the present invention provides another lock management method in a cluster, wherein the cluster includes a lock server, a first client, and a second client, the lock server comprising: The memory includes an interface card and a memory, and the memory stores a write lock request queue, a read lock request queue, a read lock allocation count, and a write lock allocation identifier. The read lock request queue stores the identifier of the second client, the write lock assignment identifier indicates that a write lock is assigned, the read lock assignment count is zero, 1 client writes for shared resources The second client is in a read lock waiting state for the shared resource, and the lock management method is a step of receiving, by the interface card, a write lock release request sent by the first client. Yes, the write lock release request includes a step of conveying the memory address at the head of the write lock request queue, a step of setting the write lock assignment identifier to the write lock unassigned state by the interface card, and a write lock by the interface card. Deleting the first client identifier from the write lock request queue according to the memory address at the head of the request queue, and the second client stored in the read lock request queue by the interface card. Querying the read lock request queue to determine the identifier of the client; increasing the read lock allocation count in memory by the interface card; and acquiring a read lock by the second card by the interface card. Sending a notification to indicate to the second client. When the first client's write lock is released, the lock server directly assigns the read lock to the client in the read lock waiting state recorded in the read lock request queue.

  According to a seventeenth aspect, an embodiment of the present invention provides another lock management method in a cluster, wherein the cluster includes a lock server, a first client, and a second client, the lock server comprising: An interface card and a memory, wherein the memory stores a write lock request queue, a read lock request queue, a read lock allocation count, and a write lock allocation identifier, and the read lock request queue stores an identifier of the first client. The second client identifier is stored at the memory address at the head of the write lock request queue, the write lock allocation identifier indicates that no write lock is allocated, and the read lock allocation count is determined by the first client. With the quantity of read locks acquired The first client acquires a read lock for the shared resource, the second client is in a write lock waiting state for the shared resource, and the lock management method is performed by the interface card by the first client. A read lock release request transmitted by the interface card, the read lock release request carrying a memory address in a read lock request queue storing an identifier of the first client; Decrementing the read lock allocation count to 0 and deleting the first client identifier from the read lock request queue in accordance with a memory address in the read lock request queue stored with the first client identifier; and Mosquito In order to determine the identifier of the second client by the command, inquiring of the memory address at the head of the queue of the write lock request queue, and writing to the second client by the interface card according to the identifier of the second client Sending a notification to the second client to instruct the interface card to apply for a lock. When the first client's read lock is released, the interface card is in a write lock wait state with an identifier recorded at the head of the write lock request queue to preferentially process the write lock. Ask for 2 clients.

  According to an eighteenth aspect, an embodiment of the present invention provides another lock management method in a cluster, wherein the cluster includes a lock server, a first client, and a second client, the lock server comprising: An interface card and a memory, wherein the memory stores a write lock request queue, a read lock request queue, a read lock allocation count, and a write lock allocation identifier, and the read lock request queue stores an identifier of the first client. The second client identifier is stored at the memory address at the head of the write lock request queue, the write lock allocation identifier indicates that no write lock is allocated, and the read lock allocation count is determined by the first client. With the quantity of read locks acquired The first client acquires a read lock for the shared resource, the second client is in a write lock waiting state for the shared resource, and the lock management method is performed by the interface card by the first client. A read lock release request transmitted by the interface card, the read lock release request carrying a memory address in a read lock request queue storing an identifier of the first client; Decrementing the read lock allocation count to 0 and deleting the first client identifier from the read lock request queue in accordance with a memory address in the read lock request queue stored with the first client identifier; and Mosquito Inquiring the memory address at the head of the write lock request queue to determine the identifier of the second client, and setting the write lock assignment identifier in the write lock assigned state by the interface card; Sending, by the interface card, a notification to the second client indicating that the second client acquires a write lock according to the identifier of the second client. When the read lock of the first client is released, the write lock is assigned to the client in the write lock waiting state recorded at the head of the write lock request queue.

  According to the foregoing embodiments, the embodiments of the present invention further provide a lock server, which includes a memory and an interface card configured to implement the functions of the lock server in the foregoing embodiments.

  According to the above embodiment, the embodiment of the present invention functions as the first client in the cluster described in the above embodiment to realize a solution corresponding to the above embodiment of the present invention. There is further provided a client configured to: The client includes a structural unit that implements the function of the first client in the cluster in the previous embodiment of the present invention, or implements the function of the first client in the cluster in the previous embodiment of the present invention. . Correspondingly, embodiments of the present invention further provide non-volatile computer readable storage media and computer program products. When the computer instructions included in the non-volatile computer-readable storage medium and the computer program product are loaded into the client's memory and the client's central processing unit (CPU) executes the computer instructions, the client The function of the first client in the cluster in the above-described embodiment is realized.

  Referring to the foregoing embodiment, the embodiment of the present invention further provides a cluster, the cluster includes a lock server and a client, and reference is made to the description of the foregoing embodiment for the lock server and the client. It may be broken.

  According to the lock management method in the cluster, the lock server, and the client in the cluster provided in the embodiment of the present invention, the lock server and the client can execute the read lock request, the write lock request, the write lock release request, and the read lock release request. When processing such an operation, the interface card and the memory of the lock server communicate directly with each other, and the central processing unit of the lock server does not need to process the aforementioned operation. Therefore, the interaction between the client and the lock server is reduced compared to communication using the (Transmission Control Protocol / Internet Protocol, TCP / IP) protocol.

It is a block diagram of the cluster in a prior art. It is a block diagram of the cluster by the Example of this invention. It is a block diagram of the lock server by the Example of this invention. FIG. 3 is a schematic diagram of a memory of a lock server according to an embodiment of the present invention. 6 is a flowchart for requesting a write lock according to an embodiment of the present invention. FIG. 3 is a schematic diagram of a memory of a lock server according to an embodiment of the present invention. FIG. 3 is a schematic diagram of a memory of a lock server according to an embodiment of the present invention. 6 is a flowchart for requesting a read lock according to an embodiment of the present invention. FIG. 3 is a schematic diagram of a memory of a lock server according to an embodiment of the present invention. FIG. 3 is a schematic diagram of a memory of a lock server according to an embodiment of the present invention. It is a schematic block diagram of the client by the Example of this invention.

  As shown in FIG. 2, the cluster in the embodiment of the present invention includes a lock server, a client A, and a client B, and the client A and the client B communicate with the lock server separately by using the RDMA protocol. The memory of the lock server stores a lock request queue, a read lock allocation count, and a write lock allocation identifier. For details, reference may be made to the following description.

  As shown in FIG. 3, the lock server includes a memory 301 and an interface card 302. The interface card 302 is a network interface card (Network Interface Card, NIC) that supports the Ethernet protocol (Ethernet) or an InfiniBand protocol. It may be an interface card based on it or other interface card capable of implementing a direct remote access to the memory, for example a protocol capable of implementing RDMA. The memory 301 in this embodiment of the present invention includes a dynamic random access memory (DRAM), a dual-inline memory module (DIMM), a semiconductor memory (Semiconductor Memory, SCM), and a nonvolatile memory. It may be a non-volatile memory (NVM) or a combination thereof, and is not limited in this embodiment of the present invention. The client may be a server, a personal computer, and other terminals. A client typically includes a CPU and memory. The client further includes an interface card that is generally configured to communicate with the lock server. The CPU, memory, and interface card communicate with each other using a bus. According to the cluster shown in FIG. 2, as shown in FIG. 4, in this embodiment of the present invention, the lock request queue in the memory 301 of the lock server is a write lock request queue. In another implementation, the lock request queue in the lock server's memory 301 is a read lock request queue. In another implementation, the lock request queues in the lock server memory 301 are a write lock request queue and a read lock request queue.

  In this embodiment of the present invention, the write lock request queue and the read lock request queue are data structures in the memory 301, and the write lock request queue is in a write lock wait state or the client that acquires the write lock. Used to store the identifier, the read lock request queue is used to store the identifier of the client that is in the read lock wait state or that acquires the read lock. In this embodiment of the invention, the described write lock request queue and read lock request queue store the identifiers of clients requesting the same shared resource, and requesting the same shared resource is a write for the same shared resource. Indicates applying for a lock or read lock. That is, the write lock request queue records the identifiers of clients in the cluster, including the identifiers of clients in a write lock wait state for shared resources and the identifiers of clients that acquire write locks for the same shared resource The read lock request queue is used to record the identifiers of clients in the cluster that are in the read lock wait state for the same shared resource or that acquire the read lock. The write lock assignment identifier is used to identify whether a write lock for the same shared resource has been assigned, and the read lock assignment count is the corresponding quantity of read locks assigned for the same shared resource. Used to identify. In a specific implementation of the read lock allocation count of memory 301, one memory address may be allocated to record the quantity of read locks allocated by the lock server, or multiple memory addresses are used, Each memory address records the quantity recorded in the read lock request queue of the read lock acquired by the client. In a specific implementation of this embodiment of the invention, the write lock request queue is a data structure in memory 301 and the read lock request queue is a data structure in memory 301. In a specific implementation, each of the write lock request queue and the read lock request queue may be an array or other structure.

  In this embodiment of the invention, storing the client identifier at a memory address in the write lock request queue and recording the client identifier in the write lock request queue have the same meaning. Similarly, storing the client identifier at a memory address in the read lock request queue and recording the client identifier in the read lock request queue have the same meaning. A write lock assignment identifier is used to identify whether a write lock has been assigned for the same shared resource, and a write lock assignment identifier is used to indicate whether a write lock has been assigned. Have the same meaning. In this embodiment of the invention, the cluster includes a plurality of clients, and the clients in the plurality of clients have the same meaning as the clients included in the plurality of clients. For example, the second client in the plurality of clients has the same meaning as the second client included in the plurality of clients.

  In a specific implementation, the lock server communicates with each client by using the interface card 302, and sends to each client the memory address at the head of the write lock request queue and the length information of the write lock request queue. Similarly, the memory address at the head of the read lock request queue and the length information of the read lock request queue are sent to each client, and information about the memory address of the write lock allocation identifier and the memory of the read lock allocation count Information about the address is sent to each client.

  Client A and client B communicate with the lock server by using the RDMA protocol. The client communicates with the lock server by using the RDMA protocol, and the interaction between the client and the lock server is reduced compared to performing communication by using the TCP / IP protocol.

  As shown in FIG. 5, an embodiment of the present invention provides a process for requesting a write lock by a client.

  Step 501: The interface card 302 receives the write lock request of the client A.

  Client A sends a write lock request to the lock server, and the write lock request carries the identifier of client A and the memory address at the head of the write lock request queue.

  The write lock request queue in memory 301 may be used to record client identifiers, including the identifiers of clients that are in a write lock wait state, and the identifiers of clients that acquire write locks. The write lock application status of the clients in the cluster may be determined according to the write lock request queue.

  Step 502: The interface card 302 writes the identifier of the client A into the memory address at the head of the write lock request queue.

  The lock server interface card 302 receives the write lock request, and, as shown in FIG. 6, writes the identifier of the client A according to the memory address carried by the write lock request at the head of the write lock request queue. Write to the top of the queue.

  If client A's identifier is successfully written to the head of the write lock request queue, this means that the lock server has not assigned a write lock to the client in the cluster and the client is not waiting for a write lock. Indicates. Optionally, interface card 302 returns a message to client A to indicate that client A's identifier has been written to the memory address at the head of the write lock request queue.

  Optionally, if the interface card 302 fails to write the client A identifier to the head of the write lock request queue, the interface card 302 will write the client A identifier to the head of the write lock request queue. A message indicating failure has been sent to client A. In this case, the client A may send the write lock request to the interface card 302 again, and the write lock request includes the identifier of client A and the next memory address following the memory address at the head of the queue of the write lock request queue. The interface card 302 writes the identifier of the client A to the next memory address in the write lock request queue. If the identifier of client A fails to be written to the next memory address in the write lock request queue, client A sequentially selects the third memory address starting from the head of the write lock request queue and Repeat the operation. Until client A's identifier is successfully written to the memory address in the write lock request queue, client A sends the write lock request again to interface card 302, and the write lock request is sent to client A's identifier and write lock request. Carry a third memory address in the queue, ie the write lock request carries a memory address in the write lock request queue to which the identifier of client A can be written. Client A may send a write lock request at fixed intervals, or if it receives a message indicating that client A's identifier failed to be written to the write lock request queue, it sends a write lock request. You may send it.

  Optionally, if the interface card 302 fails to write the client A identifier to the head of the write lock request queue, the interface card 302 starts at the head of the write lock request queue and the client A identifier is written. Query the write lock request queue sequentially for a memory address, write the client A identifier to the write lock request queue, the interface card 302 writes the client A identifier to the memory address in the write lock request queue A message to indicate that is sent to client A. Optionally, the message may carry a memory address in the write lock request queue where the identifier of client A is stored.

  Step 503: Queries whether a read lock has been assigned.

  In this embodiment of the invention, a write lock assignment identifier that is 0 indicates that the lock server does not assign a write lock, and a write lock assignment identifier that is 1 indicates that the lock server has assigned a write lock. An example is used.

  Optionally, if the interface card 302 successfully writes the identifier of client A to the head of the write lock request queue, the interface card 302 reads the read lock to determine whether a read lock is assigned. Queries the allocation count. If the lock server does not assign a read lock, the write lock assignment identifier is set to the write lock assigned state according to the memory address of the write lock assignment identifier (set to 1 in this embodiment of the invention) and the interface card 302 The client A sends a message to the client A indicating that it acquires the write lock. Illustratively, the message may carry a write lock assignment identifier and a read lock assignment count, where the write lock assignment identifier is 1 and the read lock assignment count is 0. A read lock assignment count of 0 indicates that no read lock has been assigned.

  Optionally, if the interface card 302 has successfully written the identifier of client A to the head of the write lock request queue, the interface card 302 has written that the identifier of client A has been written to the head of the write lock request queue. To the client A, the client A transmits a write lock assignment identifier change request to the interface card 302, and the write lock assignment identifier change request carries the memory address of the write lock assignment identifier, and the interface Card 302 queries the read lock assignment count to determine whether the lock server has assigned a read lock. If the lock server does not assign a read lock, the write lock assignment identifier is set to the write lock assigned state according to the memory address of the write lock assignment identifier (set to 1 in this embodiment of the invention) and the interface card 302 The client A sends a message to the client A indicating that it acquires the write lock. Specifically, the message may carry a write lock assignment identifier and a read lock assignment count, where the write lock assignment identifier is 1 and the read lock assignment count is 0.

  After interrogating the read lock allocation count, if the interface card 302 determines that the lock server does not allocate a read lock, the interface card 302 uses the write lock to indicate that client A successfully acquires the write lock. Set the assignment identifier to the write lock assigned state, that is, set the write lock assignment identifier to 1. That is, the write lock is successfully assigned to client A. If the interface card 302 determines that the lock server has assigned a read lock after querying the read lock assignment count, the interface card 302 does not set the write lock assignment identifier to 1, that is, the write lock assignment identifier is Still in the write lock unassigned state (in this embodiment of the invention, the write lock assignment identifier is 0 in this case), client A is in the write lock wait state, and interface card 302 A message is sent to client A to indicate that it is in a write lock wait state. Illustratively, the message may carry a write lock assignment identifier and a read lock assignment count, where the write lock assignment identifier is zero and the read lock assignment count is not zero. A non-zero read lock assignment count indicates that a read lock is assigned.

  In this embodiment of the invention, the interface card 302 queries the read lock allocation count and determines that the lock server does not allocate a read lock (the read lock allocation count is 0), and the interface card 302 allocates a write lock allocation. Set the identifier to 1.

  In a cluster, if the lock server assigns a read lock, that is, if a shared resource that client A needs to change is read by another client in the cluster, write permission is assigned to client A That is, a write lock cannot be assigned. Therefore, when the identifier of the client A is written at the head of the write lock request queue, it is necessary to determine whether or not the lock server has assigned the read lock. When the interface card 302 obtains an inquiry that the lock server does not allocate a read lock, the client in the head of the write lock request queue acquires the write lock, that is, the client A acquires the write lock. . If the interface card 302 obtains an inquiry from the lock server that it has assigned a read lock, the client A waits for a write lock.

  When the interface card 302 fails to write the identifier of client A to the head of the write lock request queue according to the memory address carried in the write lock request sent by client A at the head of the write lock request queue. In order to find the memory address where the identifier of client A can be written, the write lock request queue is queried sequentially starting from the top of the write lock request queue queue, and the identifier of client A is written to the write lock request queue It is. The queue head of the write lock request queue records the client that first applied for the write lock, and one write lock can be assigned to only one client. Therefore, if the client at the head of the write lock request queue has acquired a write lock or is waiting for a write lock, the identifier of client A will be written at the head of the queue of the write lock request queue. Fail.

  In this embodiment of the invention, the read lock allocation count in memory 301 records that the identifier of client A was successfully written to the head of the write lock request queue and no read lock was allocated, i.e., the client An example where A acquires a write lock is used. Based on this, in another embodiment, the lock server interface card 302 receives the write lock request sent by client B, and the write lock request sent by client B includes the client B identifier and the write lock. Carries the memory address at the head of the request queue. Since the identifier of client A is written at the head of the write lock request queue, the interface card 302 fails to write the identifier of client B at the head of the write lock request queue. Optionally, interface card 302 sends a message to client B to indicate that client B's identifier failed to be written to the head of the write lock request queue. The interface card 302 writes the identifier of client B to the next memory address following the head of the write lock request queue, that is, starting from the head of the write lock request queue, as shown in FIG. The request is in the second position of the write lock request queue. For a specific method of writing the identifier of client B to the next memory address following the queue head of the write lock request queue, reference may be made to the above description of writing the identifier of client A to the write lock request queue, Details are not described here. Optionally, the interface card 302 queries the write lock request queue for a memory address in the sequence from the head of the write lock request queue to the end of the queue where the client identifier can be written, and identifies the client Is sent to client B to notify client B of the memory address where can be written. Optionally, the memory address to which the client identifier can be written may be the first memory address in the sequence from the top of the write lock request queue to the end of the queue to which the client identifier can be written. .

  In this case, the write lock assignment identifier in memory 301 is set to the write lock assigned state (set to 1 in this embodiment of the invention), ie, the write lock is in the queue head of the write lock request queue. Assigned to client A, client B is in a write lock wait state. The interface card 302 no longer changes the write lock assignment identifier in the memory 301. Optionally, interface card 302 sends a message to client B indicating that client B is in a write lock wait state. Specifically, the message may carry a memory address in the write lock request queue where the identifier of client B is stored. Client B determines that client B is in a write lock wait state according to the memory address. Therefore, the lock server determines the write lock request state of the client in the cluster in this case, that is, the write lock is assigned to the client A, and the client B is in the write lock waiting state. Assigning a write lock to client A is also referred to as client A holding the write lock and client A being the write lock holder. Optionally, the write lock request sent by the client to the lock server may further carry a write lock lease, i.e., the validity time of the write lock held by the client, when the client expires. If the lease has not been renewed, the write lock is automatically disabled.

  As shown in FIG. 8, an embodiment of the present invention further provides a process for requesting a read lock by a client. In this embodiment of the invention, the lock server further includes a read lock request queue. For a description of the write lock request queue in this embodiment of the invention, reference may be made to the above description. The read lock request queue is used to store an identifier of a client that is in a read lock waiting state or acquires a read lock. Therefore, the lock server may determine the read lock application status of the clients in the cluster according to the read lock request queue. The quantity of read locks allocated may be determined according to the read lock allocation count.

  Step 801: The interface card 302 receives the read lock request transmitted by the client C.

  In this embodiment of the invention, memory 301 further includes a read lock request queue and the cluster further includes client C. The lock server interface card 302 receives the read lock request sent by the client C, and the read lock request carries the identifier of the client C and the memory address at the head of the queue of the read lock request queue.

  Step 802: The interface card 302 writes the identifier of the client C into the read lock request queue.

  Specifically, the interface card 302 writes the identifier of the client C to the memory address at the head of the read lock request queue, and the identifier of the other client in the cluster is not written to the memory address at the head of the queue of the read lock request queue. In this case, as shown in FIG. 9, the identifier of the client C is successfully written to the memory address at the head of the read lock request queue. Optionally, the interface card 302 sends a message to client A indicating that the identifier of client C has been written to the memory address at the head of the read lock request queue.

  When the identifier of another client in the cluster is written to the memory address at the head of the read lock request queue, the identifier of client C fails to be written to the memory address at the head of the queue of the read lock request queue. Optionally, interface card 302 sends a message to client C to indicate that client C's identifier failed to be written to the head of the read lock request queue. In this case, client C may send a read lock request again to interface card 302, which carries the identifier of client C and the next memory address following the head of the read lock request queue, The interface card 302 reads the identifier of the client C and writes it to the next memory address following the head of the read lock request queue. If Client C's identifier fails to be written to the next memory address following the head of the read lock request queue, the above operation is repeated and Client C's identifier succeeds at the memory address in the read lock request queue. Client C sends the read lock request back to interface card 302 until the read lock request carries the identifier of client C and the third memory address starting from the top of the queue of the read lock request queue; That is, the read lock request carries a memory address where the identifier of client C can be written. Client C may send a read lock request periodically, or send a read lock request when it receives a message indicating that Client C's identifier failed to be written to the read lock request queue. Also good. Optionally, the interface card 302 queries the read lock request queue for a memory address in the sequence from the head of the read lock request queue to the end of the queue to which the client identifier can be written, and identifies the client Is sent to client C to notify client C of the memory address where it can be written. Optionally, the memory address to which the client identifier can be written is the first memory address in the sequence from the top of the read lock request queue to the end of the queue to which the client identifier can be written. .

  Optionally, if the interface card 302 fails to write the identifier of client C to the head of the read lock request queue, the interface card 302 starts with the head of the queue of the read lock request queue and the client C identifier is written. Sequentially query the read lock request queue for a memory address, write the client C identifier to the read lock request queue, the interface card 302 writes the client C identifier to the memory address in the read lock request queue A message is sent to client C to indicate this. Optionally, the message may carry a memory address in the read lock request queue where the identifier of client C is stored.

  Shared resources in the cluster may be read simultaneously by multiple clients. Thus, a read lock may be shared by multiple clients, i.e., multiple clients may simultaneously hold a read lock. In this case, multiple clients are read lock holders at the same time. Thus, in the read lock assignment count, the count may be used to indicate whether the lock server has assigned a read lock. For example, if the read lock allocation count is 0, this indicates that the lock server does not allocate a read lock. Each time the lock server allocates a read lock, the read lock allocation count is incremented by one. Thus, if the lock server does not assign a write lock (in this embodiment of the invention, the write lock assignment identifier is 0), the client may acquire a read lock.

  Step 803: Increase the read lock allocation count.

  Optionally, if interface card 302 writes the identifier of client C to the read lock request queue, interface card 302 increments the read lock assignment count by 1, and interface card 302 adds the write lock assignment identifier and the read lock assignment. Returns the count to client C. Further, when the write lock allocation identifier is 1, client C sends a read lock allocation count change request to the interface card 302, and the interface card 302 decrements the read lock allocation count by 1 according to the read lock allocation count change request. Let

  Optionally, if interface card 302 writes client C's identifier to the read lock request queue and the write lock assignment identifier is 1, then interface card 302 indicates that client C is in a read lock wait state. Message to client C. Specifically, the message may carry a write lock assignment identifier, and client C determines that client C is in a read lock wait state according to the write lock assignment identifier.

  From the foregoing description, whether the message sent to client C by interface card 302 indicates that client C has acquired a read lock or is in a read lock wait state, this is the identifier of client C. Can be recognized indicating that has been written to a memory address in the read lock request queue.

  Optionally, if interface card 302 writes client C's identifier to the read lock request queue and the write lock assignment identifier is 0, interface card 302 increases the read lock assignment count by one. Further, the interface card 302 transmits a message to the client C to indicate that the client C acquires the read lock. For example, the message carries a write lock assignment identifier, and the write lock assignment identifier is zero. Optionally, if the lock server has assigned a write lock (write lock assignment identifier is 1), the client in the read lock request queue is in a read lock wait state and the read lock assignment count does not increase. Further, the interface card 302 transmits a message to the client C to indicate that the client C is in the read lock standby state. For example, the message carries a write lock assignment identifier, and the write lock assignment identifier is 1.

  In this embodiment of the present invention, an example is used in which the interface card 302 reads the identifier of client C and successfully writes it to the memory address at the head of the lock request queue. In this case, the client in the cluster does not acquire the read lock or is not in the read lock waiting state, and the write lock assignment identifier records that the write lock is assigned (the write lock assignment identifier is 1). ). In this case, the client C is in a read lock waiting state. Optionally, a read lock request sent by client C to the lock server may further carry a read lock lease, i.e., the validity time of the read lock held by client C, when the validity time expires. If client C has not renewed the lease, the read lock is automatically disabled.

  In this embodiment of the invention, the cluster further includes client D, and the lock server interface card 302 receives the read lock request sent by client D. The read lock request sent by client D carries the identifier of client D and the memory address at the head of the read lock request queue. Since the identifier of client C is stored at the memory address at the head of the read lock request queue, as shown in FIG. 10, the interface card 302 follows the identifier of client D following the head of the queue of the read lock request queue. Write to the memory address. For specific solutions, reference may be made to the description of writing the identifier of client C to the read lock request queue, and details are not described here. Since client A holds a write lock (write lock assignment identifier is 1), client C is in a read lock wait state and client D is also in a read lock wait state.

  In this embodiment of the invention, the client uses the RDMA protocol to send a lock request to the lock server interface card 302, and the lock server memory 301 records the lock status of the clients in the cluster. The lock server records the state of all locks, and the lock server can determine the state of the client such as normal or faulty. Thus, if a client holding a lock fails, the lock held by the failed client may be released in a timely manner. Optionally, the lock server determining the state of the client includes determining the client state using heartbeat detection between the lock server and the client. Optionally, heartbeat detection is performed between clients to determine the state of the client, and the normal client reports information about the failed client to the lock server. The lock server releases the lock held by the failed client according to the information about the failed client. Optionally, if the failed client holds a write lock, the lock server interface card 302 sets the write lock assignment identifier in memory 301 to 0 and the identifier of the failed client from the head of the write lock request queue. Is deleted. If the failed client holds a read lock, the lock server interface card 302 decrements the read lock allocation count in the memory 301 by 1 and deletes the failed client identifier from the read lock request queue. Optionally, other normal clients may also perform the aforementioned operations on the lock server to release the lock held by the failed client. For example, another normal client sends a lock release request to the interface card 302, and the lock release request carries the identifier of the failed client, and the interface card 302 performs the aforementioned lock release operation. Optionally, after the lock server interface card 302 releases the write lock held by the failed client, the interface card 302 sends a notification to the other client and the notification is written by the failed client. Indicates that the lock has been released. Similarly, after the lock server interface card 302 releases the read lock held by the failed client, the interface card 302 sends a notification to the other clients, and the notification is read lock held by the failed client. Indicates that has been released.

  In this embodiment of the invention, client A further includes operations to hold the write lock and release the write lock. The client A transmits a write lock release request to the interface card 302, and the write lock release request carries the memory address at the head of the queue of the write lock request queue. Optionally, the interface card 302 deletes the identifier of client A from the memory address at the head of the write lock request queue, and the interface card 302 sets the write lock assignment identifier to the write lock unassigned state (ie, 1 Change from 0 to 0). Optionally, the interface card 302 deletes the identifier of client A from the memory address at the head of the write lock request queue, and the interface card 302 notifies client A that the identifier of client A has been deleted. A transmits a write lock assignment identifier change request to the interface card 302, and the interface card 302 sets the write lock assignment identifier to a write lock unassigned state (ie, changes from 1 to 0).

  Optionally, when client A releases the write lock, this method is a step in which client A sends a write lock request inquiry message to interface card 302, where the write lock request inquiry message is stored in the write lock request queue. Carrying the next memory address following the head of the queue, inquiring the interface card 302 for the identifier of client B stored at the next memory address following the head of the write lock request queue, and the interface card 302, a write lock request inquiry response message is sent to client A. The write lock request inquiry response message carries the identifier of client B; The client A sends a notification to the client B to instruct the client B to apply for a write lock according to the identifier of the client B carried in the write lock request inquiry response message; To sending a write lock request to the interface card 302 according to the notification of the client A. For details, reference may be made to the above description of sending a write lock request by a client, and details are not described here. Therefore, the write lock may be applied according to a sequence starting from the top of the write lock request queue of the client in the write lock standby state. Optionally, after client A releases the write lock, the lock server interface card 302 queries and asks for the identifier of client B stored at the next memory address following the head of the write lock request queue. 302 sends a notification to client B to instruct client B to apply for a write lock, and client B sends a write lock request message to interface card 302 in accordance with the notification sent by interface card 302. Send to.

  Optionally, in the foregoing embodiment, the write lock request sent by the client to the interface card 302 further carries the client's write lock priority, and the write lock request queue includes the client's identifier and write lock priority. If the client A releases the write lock, the method sends a write lock request inquiry message to the interface card 302 by the client A, and sends a write lock request inquiry response message to the client A by the interface card 302. The inquiry response message includes a step of conveying the identifier and the write lock priority recorded in the write lock request queue of the client in the write lock standby state. To include. In this embodiment of the invention, it is used as an example that client B has the highest write lock priority. Client A determines the client with the highest write lock priority according to the write lock request inquiry response message, and client A notifies client B to send a write lock request to interface card 302 To client B. For details, reference may be made to the above description of sending a write lock request by a client, and details are not described here. Therefore, the write lock may be applied according to the write lock priority of the client in the write lock standby state. Optionally, in the foregoing embodiment, the write lock request sent by the client to the interface card 302 further carries the client's write lock priority, and the write lock request queue includes the client identifier and the write lock priority. Remember. After client A releases the write lock, the lock server interface card 302 requests the write lock request of the client in the write lock wait state to determine the client with the highest write lock priority, eg, client B. Queries the write lock priority recorded in the queue. The interface card 302 sends a notification to the client B to instruct the client B to apply for a write lock, and the client B interfaces the write lock request message according to the notification sent by the interface card 302. Send to card 302.

  Optionally, if the write lock request queue records that multiple clients are in the write lock wait state when client A releases the write lock, this method causes client A to send a write lock request query message. Sending to the interface card 302; querying the write lock request queue to determine a client in the write lock waiting state by the interface card 302; and sending a write lock request inquiry response message to the client A by the interface card 302. The write lock request inquiry response message includes a step of conveying an identifier of a client in the write lock standby state and a write lock by the client A. Sending a notification to instruct the client to send a write lock request to the interface card 302 to at least two of the clients in the write lock wait state according to the write request inquiry response message. In addition. Thus, clients in the write lock wait state recorded in the write lock request queue have the same opportunity to acquire a write lock. Optionally, when client A releases the write lock, the method includes: querying the write lock request queue by interface card 302 to determine which client is in the write lock wait state; Further comprising: sending a notification to instruct at least two clients to send a write lock request to the interface card 302 to at least two clients in the write lock waiting state.

  Optionally, when client A releases the write lock, if the read lock request queue stores the identifiers of clients C and D, i.e., clients C and D are in the read lock wait state, Sending a read lock request inquiry message to the interface card 302 by the client A; querying the read lock request queue to determine the clients C and D in the read lock waiting state by the interface card 302; This is a step of sending a read lock request inquiry response message to the client A by the card 302. The read lock request inquiry response message carries the identifiers of the clients C and D in the read lock standby state. Further comprising the step of. Optionally, client A sends a notification to client C and D in the read lock waiting state to instruct client C and D to apply for a read lock according to the read lock request inquiry response message. The clients C and D transmit the read lock allocation count change request separately to the interface card 302, and the interface card 302 increases the read lock allocation count according to the client C and D read lock allocation count change request. Optionally, client A sends a notification to client C in read lock wait state according to the read lock request inquiry response message, whereby client C applies for a read lock. The client C transmits a read lock allocation count change request to the interface card 302, and the interface card 302 increases the read lock allocation count according to the client C read lock allocation change request. Therefore, all clients in the read lock waiting state recorded in the read lock request queue may acquire the read lock. Optionally, when client A releases the write lock, the method includes interfacing the read lock request queue with interface card 302 to determine clients C and D that are in the read lock wait state; The card 302 sends a notification to the clients C and D in the read lock waiting state to instruct the clients C and D to apply for a read lock, so that the clients C and D can read. The method further includes separately transmitting a lock allocation count change request to the interface card 302 and increasing the read lock allocation count by the interface card 302 according to the read lock allocation count change request of the clients C and D.

  Optionally, when client A releases the write lock, this method is a step in which client A sends a write lock release request to interface card 302, where the write lock release request is queued in the write lock request queue. Specifically, the method includes a step of transporting the top memory address and a step of deleting the identifier of the client A from the top memory address of the write lock request queue by the interface card 302. Client A transmits a write lock request inquiry message to interface card 302, and the write lock request inquiry message carries the next memory address following the head of the write lock request queue. The interface card 302 inquires for the identifier of the client B stored at the next memory address following the head of the write lock request queue. The interface card 302 transmits a write lock request inquiry response message to the client A, and the write lock request inquiry response message carries the identifier of the client B. The client A transmits a write lock occupation request to the interface card 302 according to the write lock request inquiry response message, and the write lock occupation request carries the memory address at the head of the queue of the write lock request queue and the identifier of the client B. The interface card 302 writes the identifier of the client B into the memory address at the head of the write lock request queue. The interface card 302 transmits a write lock occupation request response message to the client A to indicate that the identifier of the client B has been written to the memory address at the head of the write lock request queue. The client A sends a notification to the client B indicating that the client B acquires the write lock according to the write lock occupation request response message. Therefore, it can be ensured that the client waiting for the write lock stored at the next memory address following the head of the write lock request queue can acquire the write lock. Optionally, when client A releases the write lock, the method queries interface card 302 for the identifier of client B stored at the next memory address following the top of the write lock request queue queue; The interface card 302 sends the client B identifier to the memory address at the head of the write lock request queue, and the interface card 302 sends a notification to the client B indicating that the client B acquires the write lock. A step.

  Optionally, the write lock request sent by the client to the interface card 302 further carries the client's write lock priority, the write lock request queue stores the client's identifier and write lock priority, and client A When releasing the write lock, this method is a step in which the client A sends a write lock release request to the interface card 302, and the write lock release request carries the memory address at the head of the queue of the write lock request queue. A step of deleting the identifier of the client A from the memory address at the head of the write lock request queue by the interface card 302. The client A sends a write lock request inquiry message to the interface card 302, the interface card 302 sends a write lock request inquiry response message to the client A, and the write lock request response message is sent to the client in the write lock standby state. The identifier and the write lock priority recorded in the write lock request queue are conveyed. In this embodiment of the invention, it is used as an example that client B has the highest write lock priority. The client A transmits a write lock occupation request to the interface card 302 according to the write lock request inquiry response message, and the write lock occupation request carries the memory address at the head of the queue of the write lock request queue and the identifier of the client B. The interface card 302 writes the identifier of the client B into the memory address at the head of the write lock request queue. The interface card 302 transmits a write lock occupation request response message to the client A to indicate that the identifier of the client B has been written to the memory address at the head of the write lock request queue. The client A sends a notification to the client B indicating that the client B acquires the write lock according to the write lock occupation request response message. Optionally, the write lock request sent by the client to interface card 302 further carries the client's write lock priority, and the write lock request queue stores the client's identifier and write lock priority. When the client A releases the write lock, the interface card 302 inquires for the identifier and the write lock priority recorded in the write lock request queue of the client in the write lock standby state. In this embodiment of the invention, it is used as an example that client B has the highest write lock priority. The interface card 302 writes the identifier of the client B to the memory address at the head of the write lock request queue, and the interface card 302 transmits a notification to the client B indicating that the client B acquires the write lock.

  Optionally, the write lock request queue records the identifiers of multiple clients in the write lock wait state, and when client A releases the write lock, this method allows client A to interface the write lock release request. The write lock release request is transmitted to the card 302. The interface of the write lock request queue is sent from the memory address at the head of the queue of the write lock request queue by the interface card 302. Specifically deleting the identifier. Client A transmits a write lock request inquiry message to interface card 302. The interface card 302 transmits a write lock request inquiry response message to the client A, and the write lock request response message carries the identifier recorded in the write lock request queue of the client in the write lock standby state. The client A randomly determines a client, for example, the client B, according to the write lock request inquiry response message, and sends a write lock occupation request to the interface card 302. The write lock occupation request is the memory at the head of the queue of the write lock request queue. Carries the address and client B identifier. The interface card 302 writes the identifier of the client B into the memory address at the head of the write lock request queue. The interface card 302 transmits a write lock occupation request response message to the client A to indicate that the identifier of the client B has been written to the memory address at the head of the write lock request queue. The client A sends a notification to the client B indicating that the client B acquires the write lock according to the write lock occupation request response message. Optionally, when client A releases the write lock, the method interrogates the interface card 302 for an identifier recorded in the write lock request queue of the client that is in the write lock wait state; A step of randomly determining a client, for example, client B, from a client in a write lock standby state by means of the card 302, and a step of writing the identifier of the client B to the memory address at the head of the write lock request queue by means of the interface card 302; , Further comprising: sending a notification to the client B indicating that the client B acquires the write lock by the interface card 302.

  Optionally, when client A releases the write lock, if the read lock request queue stores the identifiers of clients C and D, this method causes client A to send a write lock request query message to interface card 302. A step of querying the read lock request queue to determine the clients C and D in the read lock waiting state by the interface card 302, and a read lock request query response message to the client A by the interface card 302. The read lock request inquiry response message includes the steps of conveying the identifiers of the clients C and D in the read lock standby state, and the client A makes a read lock request inquiry. Sending a read lock allocation count change request to the interface card 302 according to the response message, wherein the read lock assignment count change request further comprises conveying an assigned number of read locks. Optionally, the number of read locks assigned is 2, and the interface card 302 increases the read lock assignment count according to the number of read locks assigned. The interface card 302 returns a read lock allocation count change request response to the client A, and the client A transmits a notification to the clients C and D. Optionally, the assigned read lock quantity is 1, and the interface card 302 increases the read lock assignment count according to the assigned read lock quantity. The interface card 302 returns a read lock allocation count change request response to the client A, and the client A instructs the client C or D to acquire the read lock. Optionally, when client A releases the write lock, if the read lock request queue stores the identifiers of clients C and D, the method causes interface card 302 to cause client C and D in the read lock wait state. Querying the read lock request queue to determine a read lock allocation count according to the number of read locks assigned to clients C and D by interface card 302, and read lock by interface card 302. Further sending a notification to the client C or D to indicate that has been acquired.

  Optionally, when clients C and D that acquire the read lock release the read lock, client C sends a read lock release request to the interface card 302, and the read lock release request includes the identifier of client C, It carries the memory address in the read lock request queue where the identifier of client C is stored. The interface card 302 deletes the identifier of client C from the read lock request queue and decreases the read lock allocation count. Similarly, client D releases the read lock, and with reference to the operation described above, the read lock allocation count is reduced to zero. The client D further transmits a write lock request inquiry message to the interface card 302, and the write lock request inquiry message carries the memory address at the head of the write lock request queue. The interface card 302 returns a write lock request inquiry response message to the client D, and the write lock request inquiry response message carries the identifier of the client stored in the memory address at the head of the write lock request queue. The client is instructed to apply to the interface card 302 for a write lock according to the client identifier. Applying to the interface card 302 for a write lock by the client includes sending a write lock assignment identifier change request to the interface card 302 by the client and setting the write lock assignment identifier to 1 by the interface card 302. . Optionally, when the clients C and D that acquire the read lock release the read lock, the interface card 302 queries the client identifier stored in the memory address at the head of the queue of the write lock request queue, and the interface card 302 Instructs the client to apply to the interface card 302 for a write lock according to the client identifier.

  Optionally, when clients C and D that acquire the read lock release the read lock, client C sends a read lock release request to the interface card 302, and the read lock release request includes the identifier of client C, It carries the memory address in the read lock request queue where the identifier of client C is stored. The interface card 302 deletes the identifier of client C from the read lock request queue and decreases the read lock allocation count. Similarly, client D releases the read lock, and with reference to the operation described above, the read lock allocation count is reduced to zero. The client D transmits a write lock assignment identifier change request to the interface card 302. The interface card 302 changes the write lock assignment identifier to be in the write lock assigned state (set to 1 in this embodiment of the invention). The interface card 302 returns a write lock assignment identifier change request response to the client D, and the write lock assignment identifier change request response carries the identifier of the client stored in the memory address at the head of the write lock request queue. Client D instructs the client to acquire a write lock according to the identifier of the client. Optionally, when clients C and D that acquire the read lock release the read lock, the interface card 302 changes the write lock assignment identifier to be in the write lock assigned state (this embodiment of the invention). In order to instruct the client to acquire a write lock, the interface card 302 inquires the identifier of the client stored in the memory address at the head of the write lock request queue.

  Optionally, this embodiment of the present invention further provides a read lock recovery policy. In this embodiment of the invention, the cluster further includes client E. When the client E sends a write lock request to the interface card 302, here, for the specific operation, reference may be made to the above-described operation of sending the write lock request by the client B. In a write lock wait state, clients C and D hold a read lock, and client E instructs clients C and D to release the read lock. Client C sends a read lock release request to interface card 302. For a specific operation, reference may be made to the above-described operation for releasing the read lock by the client C. Client D sends a read lock release request to interface card 302. For a specific operation, reference may be made to the above-described operation for releasing the read lock by the client C. After the read lock held by clients C and D is released, the read lock allocation count in memory 301 is zero. Optionally, the interface card 302 sends a message to the client E to instruct the client E to apply for a write lock. Optionally, interface card 302 sends a message to client D indicating that client D's read lock has been successfully released, and client D requests client E for a write lock. A message is sent to client E to instruct

  In the above-described embodiment of the present invention, an example where the client applies for one read lock each time is used for illustration. If during the client read lock application, the client applied for multiple read locks, the interface card 302 increases the read lock allocation count in the memory 301 according to the number of read locks requested and The identifier is recorded in the read lock request queue. During read lock release, the read lock allocation count in memory 301 decreases according to the number of read locks applied and multiple client identifiers are removed from the read lock request queue. The client may send a write lock request by using the atomic operation Compare-and-Swap in the RDMA protocol, and the client locks the read by using the atomic operation Fetch-and-Add in the RDMA protocol. A request may be sent.

  In this embodiment of the invention, the client sends an inquiry message, such as a write lock request inquiry message or a read lock request inquiry message, to the interface card 302, where the inquiry message is a memory address or read lock in the write lock request queue. Multiple query target memory addresses, such as memory addresses in the request queue, may be carried at once, or the query message may carry one query target memory address at a time. It is completed by using the inquiry message.

  According to the intra-cluster lock management solution provided in the embodiments of the present invention, a client 1100 is provided correspondingly. As shown in FIG. 11, the client 1100 is applied to the cluster and functions as a first client in a plurality of clients in the cluster. The cluster further includes a lock server described in an embodiment of the present invention, and the lock server includes an interface card 302 and a memory 301. The memory 301 includes a write lock request queue, a write lock allocation identifier, a read lock allocation count, and the like. Remember. The write lock request queue records the identifiers of clients in the cluster, including the identifiers of clients that are in a write lock wait state for shared resources and the identifiers of clients that acquire write locks for the same shared resource. The write lock allocation identifier is used to indicate whether a write lock for the shared resource has been allocated, and the read lock allocation count indicates the number of read locks allocated for the shared resource. Used for. The client 1100 includes a transmission unit 1101 and a reception unit 1102. The transmission unit 1101 is configured to transmit a first write lock request to the interface card 302 of the lock server, and the first write lock request includes an identifier of the client 1100 and a memory address at the head of the queue of the write lock request queue. Transport. The receiving unit 1102 is configured to receive the first message transmitted by the interface card 302, and the first message is sent to the memory address at the head of the queue of the write lock request queue by the interface card 302 writing the identifier of the client 1100. This indicates that the client 1100 has acquired a write lock or is in a write lock standby state. When the first message indicates that the interface card 302 failed to write the identifier of the client 1100 to the memory address at the head of the write lock request queue, the transmission unit 1101 sends the second write lock request to the interface card 302. And the second write lock request carries the identifier of the client 1100 and the first memory address in the write lock request queue, the first memory address being the identifier of the client 1100. A memory address in the sequence from the head of the queue to the end of the queue that can be written. Optionally, the first memory address is the first memory address in the sequence from the head of the queue to the end of the queue where the identifier of the client 1100 can be written.

  In the client 1100 shown in FIG. 11 provided in this embodiment of the invention, optionally, the sending unit 1101 sends a write lock release request to the interface card 302 after the client 1100 has acquired a write lock. The write lock release request carries the memory address at the head of the write lock request queue.

  In another embodiment of the present invention, the client 1100 shown in FIG. 11 is applied to a cluster and functions as a first client in a plurality of clients. The cluster further includes a lock server. The lock server includes an interface card 302 and a memory 301. The memory 301 stores a read lock request queue and a write lock assignment identifier. The read lock request queue is used to record the identifier of the client in the cluster that is in the read lock wait state for the same shared resource or that acquires the read lock, and the write lock assignment identifier is the shared resource Used to indicate whether a write lock for has been allocated. The sending unit 1101 is configured to send a first read lock request to the interface card 302, the first read lock request carrying an identifier of the client 1100 and a first memory address in the read lock request queue. To do. The receiving unit 1102 is configured to receive a first message sent by the interface card 302, the first message carrying a write lock assignment identifier. Optionally, if the write lock assignment identifier indicates that a write lock has been assigned, the first message indicates that the client 1100 is in a read lock wait state. Optionally, if the write lock assignment identifier indicates that the write lock is not assigned, the first message indicates that the client 1100 acquires the read lock. Optionally, the plurality of clients further includes a second client, and the identifier of the second client is stored in the memory address at the head of the read lock request queue. In this case, the first memory address carried by the first read lock request in the read lock request queue can be written with the identifier of the client 1100 from the head of the read lock request queue to the end of the queue. A memory address in the sequence. Optionally, the first memory address is the first memory address in the sequence from the top of the read lock request queue to the end of the queue where the identifier of the client 1100 can be written. Optionally, prior to sending the first read lock request to the interface card 302, the sending unit 1101 is further configured to send a second read lock request to the interface card 302, the second read lock request. Carries the identifier of the client 1100 and the memory address at the head of the read lock request queue. If the interface card 302 fails to read the identifier of the client 1100 and write it to the memory address at the head of the read lock request queue, the receiving unit 1102 is further configured to receive the second message sent by the interface card 302 And the second message indicates that the read lock request has failed. Optionally, if the client 1100 acquires a read lock, the sending unit 1102 is further configured to send a read lock release request to the interface card 302, where the read lock release request stores the identifier of the client 1100. , Carry the memory address in the read lock request queue.

  In another embodiment of the present invention, the client 1100 shown in FIG. 11 is applied to a cluster and functions as a first client, and the cluster further includes a lock server and a second client. The lock server includes an interface card 302 and a memory 301. The memory 301 stores a write lock request queue and a write lock assignment identifier, and the identifier of the client 1100 is stored in a memory address at the head of the queue of the write lock request queue. The write lock request queue further stores the identifier of the second client, the write lock assignment identifier indicates that a write lock is assigned, and the client 1100 acquires a write lock for the shared resource. The second client is in a write lock wait state for the shared resource. The transmission unit 1101 is configured to transmit a write lock release request to the interface card 302. The write lock release request carries the memory address at the head of the write lock request queue, and the interface card 302 receives the write lock request queue. When the identifier of the client 1100 is deleted from the write lock request queue according to the memory address at the head of the queue, the write lock request inquiry message is transmitted to the interface card 302, and the write lock request inquiry message is the identifier of the second client. Carries the memory address in the write lock request queue. The receiving unit 1102 is configured to receive the write lock request inquiry response message transmitted by the interface card 302, and the write lock request inquiry response message carries the identifier of the second client. The transmission unit 1101 is configured to transmit a write lock occupation request to the interface card 302, and the write lock occupation request carries the identifier of the second client and the memory address at the head of the queue of the write lock request queue. The receiving unit 1102 is further configured to receive a write lock occupancy request response sent by the interface card 302, wherein the write lock occupancy request response is a memory address at the head of the queue of the write lock request queue. To be written to. The sending unit 1101 is further configured to send a notification to the second client, the notification indicating that the second client acquires a write lock. Optionally, the memory address in the write lock request queue where the identifier of the second client is stored is the next memory address following the queue head of the write lock request queue. Optionally, the write lock request queue further stores the write lock priority of the second client, and the write lock priority of the second client is in a write lock wait state recorded in the write lock request queue. The best among clients.

  In another embodiment of the present invention, the client 1100 shown in FIG. 11 is applied to a cluster and functions as a first client, and the cluster further includes a lock server and a second client. The lock server includes an interface card 302 and a memory 301. The memory 301 stores a write lock request queue, a read lock request queue, a read lock allocation count, and a write lock allocation identifier. The identifier of the client 1100 is stored in the memory address at the head of the write lock request queue, the read lock request queue stores the identifier of the second client, and the write lock assignment identifier is assigned with the write lock. , The read lock allocation count is 0, the client 1100 acquires a write lock for the shared resource, and the second client is in a read lock wait state for the shared resource. The sending unit 1101 is configured to send a write lock release request to the interface card 302. The write lock release request carries the memory address at the head of the write lock request queue, and the interface card 302 receives the write lock assignment identifier. It is configured to send a read lock request inquiry message to the interface card 302 when the write lock request queue is set and the identifier of the client 1100 is deleted from the write lock request queue according to the memory address at the head of the write lock request queue. The The receiving unit 1102 is configured to receive the read lock request inquiry response message transmitted by the interface card 302, and the write lock request inquiry response message carries the identifier of the second client. The sending unit 1101 is further configured to send a read lock allocation count change request to the interface card 302, whereby the second client obtains the read lock.

  In another embodiment of the present invention, the client 1100 shown in FIG. 11 is applied to a cluster and functions as a first client, and the cluster further includes a lock server and a second client. The lock server includes an interface card 302 and a memory 301. The memory 301 stores a write lock request queue and a write lock assignment identifier. The identifier of the client 1100 is stored in the memory address at the head of the write lock request queue, the write lock request queue further stores the identifier of the second client, and the write lock assignment identifier is assigned a write lock. The client 1100 acquires a write lock for the shared resource and the second client is in a write lock wait state for the shared resource. The sending unit 1101 is configured to send a write lock release request to the interface card 302. The write lock release request carries the memory address at the head of the write lock request queue, and the interface card 302 receives the write lock assignment identifier. It is configured to send a write lock request inquiry message to the interface card 302 when the write lock request queue is set and the identifier of the client 1100 is deleted from the write lock request queue according to the memory address at the head of the write lock request queue. The write lock request inquiry message carries a memory address in the write lock request queue in which the identifier of the second client is stored. The receiving unit 1102 is configured to receive the write lock request inquiry response message transmitted by the interface card 302, and the write lock request inquiry response message carries the identifier of the second client. The sending unit 1101 sends a notification to the second client according to the identifier of the second client, and the notification is used to instruct the second client to send a write lock request to the interface card 302. The Optionally, the memory address in the write lock request queue where the identifier of the second client is stored is the next memory address following the queue head of the write lock request queue. Optionally, the write lock request queue further stores the write lock priority of the second client, and the write lock priority of the second client is in a write lock wait state recorded in the write lock request queue. The best among clients.

  In another embodiment of the present invention, the client 1100 shown in FIG. 11 is applied to a cluster and functions as a first client, and the cluster further includes a lock server and a second client. The lock server includes an interface card 302 and a memory 301. The memory 301 stores a write lock request queue, a read lock request queue, a read lock allocation count, and a write lock allocation identifier. The identifier of the client 1100 is stored in the memory address at the head of the write lock request queue, the read lock request queue stores the identifier of the second client, and the write lock assignment identifier is assigned with the write lock. , The read lock allocation count is 0, the client 1100 acquires a write lock for the shared resource, and the second client is in a read lock wait state for the shared resource. The sending unit 1101 is configured to send a write lock release request to the interface card 302. The write lock release request carries the memory address at the head of the write lock request queue, and the interface card 302 receives the write lock assignment identifier. It is configured to send a read lock request inquiry message to the interface card 302 when the write lock request queue is set and the identifier of the client 1100 is deleted from the write lock request queue according to the memory address at the head of the write lock request queue. The The receiving unit 1102 is configured to receive a read lock request inquiry response message sent by the interface card 302, and the read lock request inquiry response message carries the identifier of the second client. The sending unit 1101 is further configured to send a notification to the second client according to the identifier of the second client, the notification instructing the second client to apply for a read lock. used. The second client transmits a read lock allocation count change request to the interface card 302 according to the notification. The interface card 302 increases the read lock assignment count according to the number of read locks assigned to the second client.

  In another embodiment of the present invention, the client 1100 shown in FIG. 11 is applied to a cluster and functions as a first client, and the cluster further includes a lock server and a second client. The lock server includes an interface card 302 and a memory 301. The memory 301 stores a write lock request queue, a read lock request queue, a read lock allocation count, and a write lock allocation identifier. The read lock request queue stores the identifier of the client 1100, the identifier of the second client is stored in the memory address at the head of the queue of the write lock request queue, and the write lock assignment identifier indicates that no write lock is assigned. The read lock allocation count is the number of read locks acquired by the client 1100, the client 1100 acquires a read lock for the shared resource, and the second client waits for the write lock for the shared resource Is in a state. The sending unit 1101 is configured to send a read lock release request to the interface card 302, and the read lock release request carries a memory address in the read lock request queue where the identifier of the client 1100 is stored, and the interface If the card 302 decrements the read lock allocation count to 0 and deletes the client 1100 identifier from the read lock request queue according to the memory address in the read lock request queue where the client 1100 identifier is stored, the write lock request inquiry The message is configured to be transmitted to the interface card 302, and the write lock request inquiry message carries the memory address at the head of the write lock request queue. The receiving unit 1102 is configured to receive the write lock request inquiry response message transmitted by the interface card 302, and the write lock request inquiry response message carries the identifier of the second client. The sending unit 1101 is further configured to send a notification to the second client according to the identifier of the second client, wherein the notification is for instructing the second client to apply for a write lock. used. The second client transmits a write lock assignment identifier change request to the interface card 302 according to the notification. The interface card 302 sets the write lock assignment identifier to the write lock assigned state.

  In another embodiment of the present invention, the client 1100 shown in FIG. 11 is applied to a cluster and functions as a first client, and the cluster further includes a lock server and a second client. The lock server includes an interface card 302 and a memory 301. The memory 301 stores a write lock request queue, a read lock request queue, a read lock allocation count, and a write lock allocation identifier. The read lock request queue stores the identifier of the client 1100, the identifier of the second client is stored in the memory address at the head of the queue of the write lock request queue, and the write lock assignment identifier indicates that no write lock is assigned. The read lock allocation count is the number of read locks acquired by the client 1100, the client 1100 acquires a read lock for the shared resource, and the second client waits for the write lock for the shared resource Is in a state. The sending unit 1101 is configured to send a read lock release request to the interface card 302, and the read lock release request carries a memory address in the read lock request queue where the identifier of the client 1100 is stored, and the interface If the card 302 decrements the read lock allocation count to 0 and deletes the client 1100 identifier from the read lock request queue according to the memory address in the read lock request queue where the client 1100 identifier is stored, the write lock request inquiry The message is configured to be transmitted to the interface card 302, and the write lock request inquiry message carries the memory address at the head of the write lock request queue. The receiving unit 1102 receives the write lock request inquiry response message transmitted by the interface card 302, and the write lock request inquiry response message carries the identifier of the second client. The transmission unit 1101 transmits a write lock assignment identifier change request to the interface card 302. When the interface card 302 sets the write lock assignment identifier to the write lock assigned state according to the write lock assignment identifier change request, the transmission unit 1101 It is further configured to send a notification to the second client according to the identifier, the notification indicating that the second client acquires a write lock.

  For functions implemented by the client 1100 provided in this embodiment of the present invention, reference may be made to the descriptions corresponding to Client A, Client B, Client C, and Client D in the previous embodiment. For the effects realized by the client 1100, reference may be made to the description in the foregoing embodiment.

  For the client 1100 shown in FIG. 11, the implementation method is that the above-mentioned unit is incorporated in the client 1100, and the above-mentioned unit may be loaded into the memory of the client 1100, and the CPU of the client 1100 In order to implement the functions of the corresponding embodiment of the embodiment, instructions in the memory are executed. In other implementations, the units included in the client 1100 may be implemented by hardware or may be implemented by a combination of software and hardware. The aforementioned units are also referred to as structural units.

  This embodiment of the present invention further provides a non-volatile computer readable storage medium and a computer program product. When the computer instructions included in the non-volatile computer readable storage medium and the computer program product are loaded into the memory of the client 1100 shown in FIG. 11, the CPU realizes the corresponding function in the above-described embodiment of the present invention. Execute computer instructions loaded into memory.

  It should be appreciated that in the embodiments provided in the present invention, the disclosed apparatus and method may be implemented in other manners. For example, the unit division in the described apparatus embodiment is merely logical function division and may be other division in actual implementation. For example, multiple units or components may be combined or integrated into other systems, or some functions may be ignored or not performed. Furthermore, the mutual or direct coupling or communication connection shown or described may be realized by using several interfaces. Indirect coupling or communication connections between devices or units may be realized in electrical, mechanical or other forms.

  A unit described as a separate part may or may not be physically separated, and the part shown as a unit may be a physical unit or not a physical unit. Alternatively, they may be arranged at one location or distributed over a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the objectives of the example solutions.

  Furthermore, the functional units in the embodiments of the present invention may be integrated into one processing unit, or each of the units may physically exist alone, or two or more units may be combined into one unit. Integrated into.

Claims (44)

A lock management method in a cluster, wherein the cluster includes a plurality of clients and a lock server, the lock server includes an interface card and a memory, and the memory includes a write lock request queue, a write lock allocation identifier, A read lock allocation count, and the write lock request queue includes an identifier of a client in a write lock wait state for a shared resource and an identifier of a client that acquires a write lock for the same shared resource, Used to record the identifier of the client in the cluster, the write lock assignment identifier is used to indicate whether the write lock for the shared resource has been assigned, and the read lock assignment count is , A method that is used to indicate the quantity of read lock allocated to the serial shared resource,
Receiving, by the interface card, a first write lock request sent by a first client of the plurality of clients, wherein the first write lock request includes an identifier of the first client and the first client Carrying the memory address at the head of the write lock request queue;
In order to write the identifier of the first client to the memory address at the head of the write lock request queue by the interface card, and to determine whether or not a read lock is allocated by the interface card, Query the read lock allocation count, and if the read lock is not allocated, the interface card sets the write lock allocation identifier to the write lock allocated state, and the interface card causes the first client to write the write lock Sending a message to the first client indicating acquisition of a lock;
If the read lock has been assigned, the interface card sends a second message to the first client, the second message being in a write lock wait state by the first client. A method comprising the steps of indicating. Receiving, by the interface card, a second write lock request sent by a second client in the plurality of clients, wherein the second write lock request includes an identifier of the second client and the second client A first memory address in the write lock request queue, and the first memory address is written with the identifier of the second client except for the memory address at the head of the write lock request queue. A step of being a memory address in a sequence from the queue head to the queue tail,
Writing the identifier of the second client to the first memory address in the write lock request queue by the interface card;
The method according to claim 1, further comprising: sending, by the interface card, a message to the second client indicating that the second client is in a write lock wait state.   The memory of the lock server further includes a read lock request queue, and if the read lock allocation count indicates that the read lock is allocated, the read lock request queue is the read for the shared resource. The method of claim 1, used to record an identifier of a third client in the cluster that obtains a lock.   The method of claim 1, wherein the first write lock request further carries a lock lease, and the lock lease is used to indicate a lifetime of the write lock. After the first client acquires the write lock,
Receiving a write lock release request sent by the first client by the interface card, the write lock release request carrying the memory address at the head of the queue of the write lock request queue; ,
Setting the write lock assignment identifier to a write lock unassigned state by the interface card;
The method according to claim 2, further comprising: deleting, by the interface card, the identifier of the first client from the memory address at the head of the queue of the write lock request queue. Querying the write lock request queue with the interface card to determine the second client in the write lock wait state;
6. The method further comprising: sending, by the interface card, a notification to the second client to instruct the second client to apply for the interface card for the write lock. The method described in 1. If the first client fails after acquiring the write lock,
Setting the write lock assignment identifier to a write lock unassigned state by the interface card;
The method according to claim 1, further comprising: deleting, by the interface card, the identifier of the first client from the memory address at the head of the write lock request queue.   Sending a notification by the interface card to clients in the cluster except for the first client, the notification indicating that the write lock held by the first client has been released; The method of claim 7 further comprising a step. A lock management method in a cluster, wherein the cluster includes a plurality of clients and a lock server, the lock server includes an interface card and a memory, and the memory includes a write lock request queue, a write lock allocation identifier, A read lock allocation count, and the write lock request queue includes an identifier of a client in a write lock wait state for a shared resource and an identifier of a client that acquires a write lock for the same shared resource, Used to record the identifier of the client in the cluster, the write lock assignment identifier is used to indicate whether the write lock for the shared resource has been assigned, and the read lock assignment count is , A method that is used to indicate the quantity of read lock allocated to the serial shared resource,
Sending a first write lock request to the interface card of the lock server by a first client of the plurality of clients, wherein the first write lock request includes an identifier of the first client; Carrying a memory address at the head of the write lock request queue;
Receiving a first message sent by the interface card by the first client, the first message being sent by the interface card to the identifier of the first client in the write lock request queue; Indicating writing to the memory address at the head of the queue and indicating that the first client acquires the write lock or is in a write lock wait state;
If the first message indicates that the interface card failed to write the identifier of the first client to the memory address at the head of the write lock request queue, the first client Sending a second write lock request to the interface card, wherein the second write lock request carries the identifier of the first client and a first memory address in the write lock request queue. And wherein the first memory address is a memory address in a sequence from the head of the queue to the end of the queue to which the identifier of the first client can be written.   10. The method of claim 9, wherein the first write lock request and the second write lock request further carry a lock lease, and the lock lease is used to indicate a lifetime of the write lock. . After the first client acquires the write lock,
Sending a write lock release request to the interface card by the first client, the write lock release request further comprising conveying the memory address at the head of the queue of the write lock request queue; The method of claim 9. A lock management method in a cluster, wherein the cluster includes a plurality of clients and a lock server, the lock server includes an interface card and a memory, and the memory includes a read lock request queue, a write lock allocation identifier, And the read lock request queue is used to record an identifier of a client in the cluster that is in a read lock wait state for the same shared resource or obtains a read lock, and the write A lock assignment identifier is a method used to indicate whether a write lock for the shared resource has been assigned,
Receiving, by the interface card, a first read lock request sent by a first client in the plurality of clients, wherein the first read lock request includes an identifier of the first client and the first client; Carrying a first memory address in a read lock request queue;
Writing the identifier of the first client to the first memory address in the read lock request queue by the interface card;
Transmitting by the interface card a first message to the first client, the first message carrying the write lock assignment identifier.   13. The method of claim 12, wherein if the write lock assignment identifier indicates that the write lock is assigned, the first message indicates that the first client is in a read lock wait state.   The memory further stores a read lock allocation count, wherein the read lock allocation count is used to indicate a quantity of read locks allocated for the shared resource, wherein the write lock is not allocated. If the write lock assignment identifier indicates, the interface card increments the read lock assignment count according to the number of read locks assigned to the first client, and the first message is read by the first client. The method of claim 12, wherein the method indicates obtaining a lock.   The plurality of clients further includes a second client, the memory further stores a write lock request queue, the write lock request queue including an identifier of a client in a write lock wait state for the shared resource; The write lock assignment identifier used to record an identifier of the client in the cluster, wherein the write lock is assigned, including an identifier of the client that obtains the write lock for the shared resource 14. The method of claim 13, wherein the second client identifier is stored in a memory address at the head of the write lock request queue. The plurality of clients further include a third client, and the identifier of the third client is stored in a memory address at the head of the queue of the read lock request queue;
The queue of the read lock request queue, in which the identifier of the first client can be written to the first memory address carried in the first read lock request in the read lock request queue. The method of claim 12, wherein the memory address is in a sequence from the beginning to the end of the queue.   The method of claim 12, wherein the first read lock request further carries a lock lease, the lock lease being used to indicate a lifetime of the read lock. If the first client acquires the read lock,
Receiving the read lock release request sent by the first client by the interface card, wherein the read lock release request is the read lock request queue in which the identifier of the first client is stored; Carrying the first memory address within;
Reducing the read lock allocation count in the memory by the interface card according to the number of read locks allocated to the first client;
15. The method of claim 14, further comprising: deleting, by the interface card, the identifier of the first client from the first memory address in the read lock request queue. If the first client fails after acquiring the read lock,
Reducing the read lock allocation count in the memory by the interface card according to the number of read locks allocated to the first client;
15. The method of claim 14, further comprising: deleting, by the interface card, the identifier of the first client from the first memory address in the read lock request queue. A lock management method in a cluster, wherein the cluster includes a plurality of clients and a lock server, the lock server includes an interface card and a memory, and the memory includes a read lock request queue, a write lock allocation identifier, And the read lock request queue is used to record an identifier of a client in the cluster that is in a read lock wait state for the same shared resource or obtains a read lock, and the write A lock assignment identifier is a method used to indicate whether a write lock for the shared resource has been assigned,
Sending a first read lock request to the interface card by a first client of the plurality of clients, wherein the first read lock request includes an identifier of the first client and the read lock request. Carrying a first memory address in a queue;
Receiving, by the first client, a first message sent by the interface card, the first message carrying the write lock assignment identifier.   21. The method of claim 20, wherein if the write lock assignment identifier indicates that the write lock is assigned, the first message indicates that the first client is in a read lock wait state.   21. The method of claim 20, wherein the first message indicates that the first client acquires a read lock if the write lock assignment identifier indicates that the write lock is not assigned. The plurality of clients further includes a second client, and the identifier of the second client is stored in a memory address at the head of the queue of the read lock request queue;
The queue of the read lock request queue, in which the identifier of the first client can be written to the first memory address carried in the first read lock request in the read lock request queue. 21. The method of claim 20, wherein the memory address is in a sequence from the beginning to the end of the queue.   21. The method of claim 20, wherein the first read lock request further carries a lock lease, and the lock lease is used to indicate a lifetime of a read lock. If the first client acquires the read lock,
Sending a read lock release request to the interface card by the first client, the read lock release request being in the read lock request queue in which the identifier of the first client is stored; 23. The method of claim 22, further comprising the step of carrying a memory address. A lock server, wherein the lock server is applied to a cluster, the cluster further includes a plurality of clients, the lock server includes an interface card and a memory, and the memory includes a write lock request queue and a write lock. Configured to store an allocation identifier and a read lock allocation count, wherein the write lock request queue obtains a write lock for the same shared resource as an identifier of a client in a write lock waiting state for the shared resource And the write lock assignment identifier is used to indicate whether or not the write lock for the shared resource has been assigned. Read the above Ri lock allocation count is a lock server used to indicate the quantity of read lock allocated to said shared resource,
The interface card is configured to receive a first write lock request transmitted by a first client in the plurality of clients, wherein the first write lock request includes an identifier of the first client. The memory address at the head of the write lock request queue is conveyed,
The interface card writes the identifier of the first client to the memory address at the head of the write lock request queue and determines whether a read lock is assigned to determine whether a read lock is assigned. If the read lock is not assigned, the write lock assignment identifier is set to a write lock assigned state, and a message indicating that the first client acquires the write lock is sent to the first lock. Further configured to send to the client,
If the read lock is assigned, the device is further configured to send a second message to the first client, the second message indicating that the first client is in a write lock wait state. Show lock server.   The interface card is further configured to receive a second write lock request sent by a second client in the plurality of clients, wherein the second write lock request is an identifier of the second client. And the first memory address in the write lock request queue, wherein the first memory address is the identifier of the second client except for the memory address at the head of the write lock request queue. Is written to the first memory address in the write lock request queue, the memory address in a sequence from the queue head to the queue tail, and the identifier of the second client can be written to the first memory address in the write lock request queue, The second client is in the write lock wait state Sending a message to indicate to the second client, the lock server according to claim 26.   The memory is further configured to store a read lock request queue, and when the read lock allocation count indicates that the read lock has been allocated, the read lock request queue is configured for the shared resource. 27. The lock server of claim 26, used to record an identifier of a third client in the cluster that obtains a read lock. After the first client acquires the write lock,
The interface card is further configured to receive a write lock release request sent by the first client, wherein the write lock release request carries the memory address at the head of the queue of the write lock request queue. The write lock assignment identifier is further configured to set the write lock unassigned state and to delete the identifier of the first client from the memory address at the head of the queue of the write lock request queue. 26. The lock server according to 26. If the first client fails after acquiring the write lock,
The interface card is further configured to set the write lock assignment identifier to a write lock unassigned state and delete the identifier of the first client from the memory address at the head of the queue of the write lock request queue. The lock server according to claim 26. A client, wherein the client is applied to a first client in a plurality of clients in a cluster, the cluster further including a lock server, the lock server including an interface card and memory, wherein the memory is A write lock request queue, a write lock allocation identifier, and a read lock allocation count, wherein the write lock request queue is a write lock wait queue for a shared resource and a write for the same shared resource Used to record the identifier of the client in the cluster, including the identifier of the client that obtains the lock, the write lock assignment identifier indicating whether the write lock for the shared resource has been assigned or not. The Is used, the read lock allocated count is a client used to indicate the quantity of read lock allocated to said shared resource, said first client,
A transmission unit configured to transmit a first write lock request to the interface card of the lock server, wherein the first write lock request includes an identifier of the first client and a write lock request queue; A transmission unit that carries the memory address at the head of the queue;
A receiving unit configured to receive a first message transmitted by the interface card, the first message being sent by the interface card to the identifier of the first client in the write lock request queue; A receiving unit that indicates writing to the memory address at the head of the queue and indicating that the first client acquires the write lock or is in a write lock wait state;
If the first message indicates that the interface card has failed to write the identifier of the first client to the memory address at the head of the queue of the write lock request queue, Is further configured to transmit the write lock request to the interface card, wherein the second write lock request carries the identifier of the first client and a first memory address in the write lock request queue. And the first memory address is a memory address in a sequence from the head of the queue to the end of the queue to which the identifier of the first client can be written.   The sending unit is further configured to send a write lock release request to the interface card after the first client has acquired the write lock, the write lock release request being sent from the write lock request queue. The client of claim 31, carrying the memory address at the head of a queue. A lock server, wherein the lock server is applied to a cluster, the cluster further includes a plurality of clients, the lock server includes an interface card and memory, and the memory includes a read lock request queue and a write lock. The read lock request queue records an identifier of a client in the cluster that is in a read lock wait state for the same shared resource or obtains a read lock. The write lock assignment identifier is a lock server used to indicate whether a write lock for the shared resource has been assigned,
The interface card is configured to receive a first read lock request sent by a first client in the plurality of clients, wherein the first read lock request includes an identifier of the first client. A first memory address in the read lock request queue, writes the identifier of the first client to the first memory address in the read lock request queue, and writes a first message to the first memory address. A lock server configured to send to the client of the first message, wherein the first message carries the write lock assignment identifier.   34. The lock server of claim 33, wherein the first message indicates that the first client is in a read lock waiting state if the write lock assignment identifier indicates that the write lock is assigned. .   The memory further stores a read lock allocation count, wherein the read lock allocation count is used to indicate a quantity of read locks allocated for the shared resource, wherein the write lock is not allocated. If the write lock assignment identifier indicates, the interface card is further configured to increase the read lock assignment count according to the number of read locks assigned to the first client, and the first message is the first message 34. The lock server of claim 33, indicating that one client obtains a read lock.   The plurality of clients further includes a second client, and the memory is further configured to store a write lock request queue, wherein the write lock request queue is in a write lock wait state for the shared resource. Used to record an identifier of a client in the cluster, including an identifier of a client and an identifier of a client that obtains the write lock for the shared resource, and wherein the write lock is assigned The lock server according to claim 34, wherein when the write lock assignment identifier indicates, the identifier of the second client is stored in a memory address at the head of the queue of the write lock request queue. The plurality of clients further include a third client, and the identifier of the third client is stored in a memory address at the head of the queue of the read lock request queue;
The queue of the read lock request queue, in which the identifier of the first client can be written to the first memory address carried in the first read lock request in the read lock request queue. The lock server according to claim 33, which is a memory address in a sequence from the head to the tail of the queue.   When the first client acquires the read lock, the interface card is further configured to receive a read lock release request sent by the first client, wherein the read lock release request is The first memory address in the read lock request queue, in which the identifier of one client is stored, carries the read in the memory according to the number of read locks assigned to the first client 36. The lock server of claim 35, further configured to decrement a lock allocation count and delete the identifier of the first client from the first memory address in the read lock request queue.   If the first client fails after obtaining the read lock, the interface card decrements the read lock allocation count in the memory according to the number of read locks allocated to the first client. 36. The lock server of claim 35, wherein the lock server is configured to delete the identifier of the first client from the first memory address in the read lock request queue. A client, the client being applied to a cluster and functioning as a first client in a plurality of clients, the cluster further comprising a lock server, the lock server comprising an interface card and memory; The memory stores a read lock request queue and a write lock assignment identifier, and the read lock request queue is in a read lock wait state for the same shared resource or is in the cluster that acquires a read lock. Used to record a client identifier, wherein the write lock assignment identifier is a client used to indicate whether a write lock for the shared resource has been assigned, wherein the first client is ,
A transmission unit configured to transmit a first read lock request to the interface card, wherein the first read lock request includes an identifier of the first client and a first in the read lock request queue; A transmission unit carrying a memory address;
A receiving unit configured to receive a first message transmitted by the interface card, wherein the first message includes a receiving unit carrying the write lock assignment identifier.   41. The client of claim 40, wherein the first message indicates that the first client is in a read lock wait state when the write lock assignment identifier indicates that the write lock is assigned.   41. The client of claim 40, wherein if the write lock assignment identifier indicates that the write lock is not assigned, the first message indicates that the first client acquires a read lock. The plurality of clients further includes a second client, and the identifier of the second client is stored in a memory address at the head of the queue of the read lock request queue;
The queue of the read lock request queue, in which the identifier of the first client can be written to the first memory address carried in the first read lock request in the read lock request queue. 41. The client of claim 40, wherein the client is a memory address in a sequence from the beginning to the end of the queue.   The sending unit is further configured to send a read lock release request to the interface card, the read lock release request being in the read lock request queue in which the identifier of the first client is stored. 43. The client of claim 42, carrying a memory address.

Images