A distributed lock system architecture

Abstract

A distributed lock system architecture provided by the present invention includes: a plurality of lock application clients for providing a client interface for applying for a lock and sending a lock acquisition or release request through the client interface; a plurality of lock storage servers for storing lock data information; a lock allocation server cluster communicatively connected to the plurality of lock application clients and the plurality of lock storage servers, and the plurality of lock allocation servers within the lock allocation server cluster are communicatively connected. The lock allocation server cluster is configured to receive the lock acquisition or release request, access the lock data information of the plurality of lock storage servers, process the lock acquisition or release request, and send the access result to one of the lock application clients. This system architecture does not require the same server to handle the logical processing of locks and the data services of locks, improving the flexibility, system scalability, and resource utilization rate of the distributed lock system architecture, and reducing the time for fault recovery.

Description

Technical Field

[0001] The present invention relates to the technical field of distributed systems, and in particular to a distributed lock system architecture. Background Art

[0002] With the rapid development of the Internet industry, the era of cloud computing has arrived. In the era of cloud computing, most services need to be deployed in a distributed environment, and many basic distributed services need to maintain high consistency and high reliability of data. In order to improve data reliability and access rate, some distributed systems often have multiple backups of a piece of data, and they are distributed on different servers. When writing data, in order to maintain data consistency, it is necessary to implement concurrency control technology to ensure that only one process writes the same data at a time. At present, concurrency control technology mainly adopts blocking concurrency control method.

[0003] At present, the existing distributed locking technologies mainly include Chubby, Zookeeper, Redis and Memcached, among which Chubby is a lock service designed by Google to solve the problem of loosely coupled small computers synchronizing their own behaviors or reaching consistency on some data in a high-speed communication network. It is a lock service independent of data and is committed to solving the availability problem facing a large number of clients; Apache's Zookeeper is an open source implementation based on Chubby, and its usage scenarios and advantages and disadvantages are consistent with Chubby; Redis is a high-performance NoSql database in the form of key-value, which supports a series of instructions ending with NX, that is, set if not exist, and uses these instructions to implement a distributed lock mechanism. For example, if the client wants to obtain a lock named M, it can use the instruction setNX M value. If it returns 1, it means that the acquisition is successful, and if it returns 0, it means that the lock has been occupied by other processes; Memcached is a key-value in-memory database, often used as a distributed cache system, and distributed locks are implemented through the add instruction. For a lock, the successful execution of the add instruction means that the lock is acquired, and if the execution fails, it means that the lock has been occupied.

[0004] However, in terms of existing technologies, Chubby is primarily designed to meet the availability of a large number of clients, while other indicators such as throughput, response time, and scalability are secondary considerations. Because Google's distributed services try to use long transactions, Chubby's response time and fault recovery time are both relatively long. In addition, Chubby is not only a distributed lock service, but also used to consider some data management issues often encountered in distributed applications, such as: unified naming service, state synchronization service, cluster management, etc. There are too many things to solve, and when it is only needed as a distributed lock service, it is too bloated; Redis is a pure NoSql database and does not provide any other support for implementing lock logic, so the lock applicant can only poll Redis all the time. This method is not only a waste of the applicant's resources, but also increases the Redis load. If each thread of the client needs to establish a connection with Redis, Redis resources will be exhausted quickly; Memcached is similar to Redis. The lock application can only poll Memcached all the time, resulting in a waste of resources, and the servers in the Memcached cluster do not communicate with each other, so Memcached has a single point of failure problem. Summary of the invention

[0005] In order to solve the technical problems of long fault recovery time, poor system scalability and resource waste of distributed locks in the prior art, the present invention provides a distributed lock system architecture, which adopts a strategy of separating the lock logic processing and the lock data service. There is no need to process the lock logic processing and the lock data service based on the same server, which improves the flexibility, system scalability and resource utilization of the distributed lock system architecture and reduces the fault recovery time.

[0006] The present invention provides a distributed lock system architecture, including:

[0007] Multiple lock application clients, used to provide a client interface for applying for locks and send lock or unlock requests through the client interface;

[0008] Multiple lock storage servers, used to store lock data information;

[0009] A lock allocation server cluster is communicatively connected to multiple lock application clients and multiple lock storage servers, and multiple lock allocation servers in the lock allocation server cluster are communicatively connected to each other. The lock allocation server cluster is used to receive the lock or unlock request, access the lock data information of multiple lock storage servers, process the lock or unlock request, and send the access result to one of the lock application clients.

[0010] In the above-mentioned distributed lock system architecture, each of the lock application clients includes:

[0011] A client interface module, used to provide a client interface for applying for a lock, and to send a lock or unlock request for a process through the client interface;

[0012] A locking / unlocking module is communicatively connected to the client interface module, and is used for receiving the locking or unlocking request and sending the locking or unlocking request to the lock allocation server.

[0013] In the above-mentioned distributed lock system architecture, each of the lock application clients further includes:

[0014] A load balancing module is communicatively connected to the lock / unlock module and the lock allocation server cluster, and is used to receive the lock or unlock request and send the lock or unlock request to the lock allocation server using a load balancing method.

[0015] In the above-mentioned distributed lock system architecture, a load balancing module adopts a load balancing method to send the lock or unlock request to a lock allocation server, specifically including:

[0016] The load balancing module periodically sends a server list request to the lock allocation server to obtain a first lock allocation server list stored in the lock allocation server;

[0017] When a new lock allocation server name exists in the first lock allocation server list, updating a second lock allocation server list stored in the lock application client based on the first lock allocation server list;

[0018] Based on the updated second lock allocation server list, a communication connection is established with a new lock allocation server, and the lock or unlock request is sent to one of the lock allocation servers or one of the new lock allocation servers.

[0019] In the above-mentioned distributed lock system architecture, each of the lock application clients further includes:

[0020] A deadlock prevention module is communicatively connected to the locking / unlocking module and is used to store a set of processes that have obtained locks; when a process applies for a lock request, if the lock to be added is already in the set, the lock request is prohibited; otherwise, the lock to be added is added to the set; when a process applies for an unlock request, the lock to be released is removed from the set.

[0021] In the above-mentioned distributed lock system architecture, each of the lock application clients further includes:

[0022] a fault detection module, communicatively connected to the load balancing module and the lock allocation server cluster, configured to receive fault information of the load balancing module and delete the name of the corresponding lock allocation server in the second lock allocation server list according to the fault information;

[0023] It is also used to periodically send heartbeat packets to a plurality of the lock allocation servers respectively, and obtain the first lock allocation server list stored by one of the lock allocation servers;

[0024] When the return result of the heartbeat packet is an error, deleting the name of the corresponding lock allocation server in the second lock allocation server list;

[0025] When the first lock allocation server list stored in one of the lock allocation servers has different lock allocation server names from the first lock allocation server lists stored in the other lock allocation servers, the different lock allocation server names are deleted from the second lock allocation server list.

[0026] In the above-mentioned distributed lock system architecture, each of the lock allocation servers includes:

[0027] a maintenance cluster module, communicatively connected to a load balancing module, a fault detection module and the remaining lock allocation servers in a lock allocation server cluster, and configured to send the first lock allocation server list to a load balancing module according to the server list request, and send the first lock allocation server list to a fault detection module according to the heartbeat packet;

[0028] Also used for establishing a communication connection with a new lock allocation server when a new lock allocation server joins the lock allocation server cluster, and updating the first lock allocation server list, and sending the updated first lock allocation server list to a load balancing module according to the server list request;

[0029] A lock logic processing module is communicatively connected to the load balancing module and the plurality of lock storage servers, and is used to receive the lock or unlock request, access the lock data information of the plurality of lock storage servers, process the lock or unlock request, and send the access result to the lock application client.

[0030] In the above-mentioned distributed lock system architecture, each of the lock logic processing modules includes:

[0031] a first thread, configured to receive and parse the lock or unlock request, and send the lock or unlock request;

[0032] A plurality of second threads are used to access a plurality of lock storage servers according to the lock or unlock request of the first thread, process the lock or unlock request, and send the access result to the lock application client.

[0033] The above-mentioned distributed lock system architecture, wherein the multiple lock storage servers adopt a master-slave mode, including

[0034] a master lock storage server, communicatively connected to a lock allocation server cluster, for writing and storing the lock data information;

[0035] A plurality of slave lock storage servers are communicatively connected to a master lock storage server and a lock allocation server cluster, and are used to store lock data information stored by a master lock storage server, and are also used for a lock allocation server to access and read the lock data information.

[0036] In the above-mentioned distributed lock system architecture, the lock data information includes:

[0037] Lock ID number and lock status information.

[0038] Technical effects or advantages of the present invention:

[0039] The present invention provides a distributed lock system architecture, including multiple lock application clients, which are used to provide a client interface for applying for a lock and send a lock or unlock request through the client interface; multiple lock memories, which are used to store lock data information; a lock allocation server cluster, which is communicatively connected to multiple lock application clients and multiple lock storage servers, and multiple lock allocation servers in the lock allocation server cluster are communicatively connected, and the lock allocation server cluster is used to receive lock or unlock requests, access lock data information of multiple lock storage servers, and process lock or unlock requests, and send the access results to a lock application client. In the above manner, the distributed lock system architecture adopts a strategy of separating the logical processing of the lock and the data service of the lock, and there is no need to process the logical processing of the lock and the data service of the lock based on the same server, which improves the flexibility, system scalability and resource utilization of the distributed lock system architecture and reduces the time for fault recovery. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Figure 1 A schematic diagram of the structure of a distributed lock system architecture provided by an embodiment of the present invention;

[0041] Figure 2 A schematic diagram of the structure of a lock application client provided by an embodiment of the present invention;

[0042] Figure 3 A schematic diagram of a structure for implementing load balancing provided in an embodiment of the present invention;

[0043] Figure 4 A schematic diagram of the structure of a lock allocation server provided in an embodiment of the present invention;

[0044] In the above picture:

[0045] 1. Lock application client; 11. Client interface module; 2. Lock / unlock module; 13. Load balancing module; 14. Deadlock prevention module; 15. Fault detection module; 2. Lock allocation server cluster; 21. Lock allocation server; 201. Maintenance cluster module; 202. Lock logic processing module; 3. Lock storage server; 31. Master lock storage server; 32. Slave lock storage server. DETAILED DESCRIPTION

[0046] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0047] Obviously, the drawings described below are only some examples or embodiments of the present application. For ordinary technicians in the field, the present application can also be applied to other similar scenarios based on these drawings without creative work. In addition, it can also be understood that although the efforts made in this development process may be complex and lengthy, for ordinary technicians in the field related to the content disclosed in the present application, some changes such as design, manufacturing or production based on the technical content disclosed in the present application are just conventional technical means, and should not be understood as insufficient content disclosed in the present application. The reference to "embodiment" in the present application means that the specific features, structures or characteristics described in conjunction with the embodiment can be included in at least one embodiment of the present application. The phrase appears in various positions in the specification and does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. It is explicitly and implicitly understood by ordinary technicians in the field that the embodiments described in the present application can be combined with other embodiments without conflict. Unless otherwise defined, the technical terms or scientific terms involved in the present application should be the common meaning understood by people with general skills in the technical field to which the present application belongs. The words "one", "a", "a kind of", "the" and the like used in this application do not indicate a quantitative limitation and may indicate the singular or the plural. The terms "include", "comprise", "have" and any variations thereof used in this application are intended to cover non-exclusive inclusions; for example, a process, method, system, product or device that includes a series of steps or modules (units) is not limited to the listed steps or units, but may also include steps or units that are not listed, or may also include other steps or units that are inherent to these processes, methods, products or devices. The words "connect", "connected", "coupled" and the like used in this application are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect.

[0048] The "multiple" involved in this application refers to two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, "A and / or B" can mean: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship. The terms "first", "second", "third", etc. involved in this application are merely used to distinguish similar objects and do not represent a specific ordering of objects.

[0049] In order to solve the technical problems of long fault recovery time, poor system scalability and resource waste of distributed locks in the prior art, the present invention provides a distributed lock system architecture, which adopts a strategy of separating the lock logic processing and the lock data service. There is no need to process the lock logic processing and the lock data service based on the same server, which improves the flexibility, system scalability and resource utilization of the distributed lock system architecture and reduces the fault recovery time.

[0050] The technical solution of the present invention is described in detail below in conjunction with specific embodiments and the accompanying drawings.

[0051] This embodiment provides a distributed lock system architecture, including:

[0052] Multiple lock application clients 1, used to provide a client interface for applying for a lock and send a lock or unlock request through the client interface;

[0053] A plurality of lock storage servers 3, used for storing lock data information;

[0054] A lock allocation server cluster 2 is communicatively connected to multiple lock application clients 1 and multiple lock storage servers 3, and multiple lock allocation servers 21 in the lock allocation server cluster 2 are communicatively connected. The lock allocation server cluster 2 is used to receive the lock or unlock request, access the lock data information of the multiple lock storage servers 3, and process the lock or unlock request, and send the access result to the lock application client 1.

[0055] A distributed lock system architecture provided in this embodiment adopts a strategy of separating the lock's logical processing and the lock's data service. There is no need to process the lock's logical processing and the lock's data service on the same server, which improves the flexibility, system scalability and resource utilization of the distributed lock system architecture and reduces the time for fault recovery.

[0056] Specifically, refer to Figure 1 , Figure 1 A structural diagram of a distributed lock system architecture provided by an embodiment of the present invention. The present invention provides a distributed lock system architecture, including: multiple lock application clients 1, multiple lock storage servers 3 and a lock allocation server cluster 2, wherein the lock allocation server cluster 2 is communicatively connected with the multiple lock application clients 1 and the multiple lock storage servers 3. The lock allocation server cluster 2 includes multiple lock allocation servers 21, and the number of lock application clients 1 in the distributed lock system architecture is much greater than the number of lock allocation servers 21.

[0057] The lock application client 1 is used to provide the lock client interface and send a lock or unlock request through the client interface. Figure 2Each lock application client 1 includes a client interface module 11, a lock / unlock module 12, a load balancing module 13, a deadlock prevention module 14, and a fault detection module 15, wherein a client interface module 11 is connected to a lock / unlock module 12 in communication, a lock / unlock module 12 is connected to a deadlock prevention module 14 and a load balancing module 13 in communication, a load balancing module 13 is connected to a lock allocation server cluster 2 and a fault detection module 15 in communication, and a fault detection module 15 is connected to a lock allocation server cluster 2 in communication. In this embodiment, the client interface module 11 is used to provide a client interface for applying for a lock, and sends a lock or unlock request of a process through the client interface. The user program sends a lock or unlock request of a process through the client interface. In this embodiment, the client interface module 11 provides all API interfaces for lock application access, and is the entrance to all functional modules of the client, mainly composed of three API interfaces shown in Table 1. The lock / unlock module 12 is used to send a lock or unlock request of a process sent by a client interface module 11 to a lock allocation server 21 in the lock allocation server cluster 2. The lock / unlock module 12 implements the lock or unlock request sent to the lock allocation server cluster 2, and sends the lock or unlock request to the lock allocation server cluster 2 through the socket interface.

[0058] Table 1 Client API interface

[0059] Function Name parameter Return Type illustrate init String fileName bool Initialize the client instance lock int lockID bool Lock unlock int lockID bool Unlock

[0060] The load balancing module 13 is used to receive a lock or unlock request, and use a load balancing method to send the lock or unlock request to a lock allocation server 21 in the lock allocation server cluster 2. Specifically, the load balancing module 13 receives a lock or unlock request from a lock / unlock module 12, wherein the load balancing module 13 uses a load balancing method to send the lock or unlock request to a lock allocation server 21, which specifically includes:

[0061] A load balancing module 13 periodically sends a server list request to a lock allocation server 21 to obtain a first lock allocation server list stored in the lock allocation server 21;

[0062] When a new lock allocation server name exists in the first lock allocation server list, a second lock allocation server list stored in the lock application client 1 is updated based on the first lock allocation server list;

[0063] Based on the updated second lock allocation server list, a communication connection is established with the new lock allocation server, and a lock or unlock request is sent to a lock allocation server 21 or a new lock allocation server.

[0064] In this embodiment, sending a lock or unlock request to a lock allocation server 21 or a new lock allocation server means, based on the updated second lock allocation server list (including the original lock allocation server and the new lock allocation server), selecting a lock allocation server 21 or a new lock allocation server, and sending the lock or unlock request to this lock allocation server 21 or this new lock allocation server. When there is no new lock allocation server name in the first lock allocation server list, and the lock allocation server name in the first lock allocation server list is consistent with the lock allocation server name in the second lock allocation server list, a load balancing module 13 selects a lock allocation server 21 based on the second lock allocation server list, and sends the lock or unlock request to this lock allocation server 21.

[0065] In this embodiment, load balancing is implemented on the lock application client 1 based on the load balancing module 13. Since the number of lock application clients 1 is far greater than the number of lock allocation servers 21 in the lock allocation server cluster 2, the overhead of the lock allocation server 21 will be allocated to the lock application client 1, which greatly reduces the burden of the distributed lock system architecture and, at the same time, increases the fault handling capability and scalability of the distributed system architecture.

[0066] The deadlock prevention module 14 is used to store a set of processes that have obtained locks; when a process applies for a lock request, if the lock to be added is already in the set, the lock request is prohibited; otherwise, the lock to be added is added to the set; when a process applies for an unlock request, the lock to be released is removed from the set.

[0067] In this embodiment, deadlock is generally caused by occupying resources and waiting for resources. In this embodiment, deadlock is prevented by allowing only one process to occupy at most one resource. The set of processes that have obtained locks stored by the lock application client 1 is a hash set, which is a HaveLockThreadSet data structure.

[0068] A fault detection module 15 is used to receive fault information from a load balancing module 13 and delete the name of the corresponding lock allocation server in the second lock allocation server list according to the fault information;

[0069] It is also used to periodically send heartbeat packets to multiple lock allocation servers 21 respectively, and obtain a first lock allocation server list stored in a lock allocation server 21;

[0070] When the return result of the heartbeat packet is an error, deleting the name of the corresponding lock allocation server in the second lock allocation server list;

[0071] When the first lock allocation server list stored in a lock allocation server 21 has different lock allocation server names from the first lock allocation server lists stored in other lock allocation servers 21, the different lock allocation server names are deleted from the second lock allocation server list.

[0072] In this embodiment, when a load balancing module 13 sends a server request list to a lock allocation server 21 and returns an RST response, timeout, or unreachable error, it indicates that the lock allocation server 21 has a fault, and the load balancing module 13 sends the fault information to a fault detection module 15, and deletes the name of the faulty lock allocation server from the second lock allocation server list stored in the lock application client 1; when a fault detection module 15 sends a heartbeat packet to a lock allocation server 21, and the return result of the heartbeat packet is an error, the lock allocation server 21 is deleted from the second lock allocation server list stored in the lock application client 1. If the lock allocation server names in the first lock allocation server list obtained from the remaining lock allocation servers 21 are all the same, and the first lock allocation server list obtained from a lock allocation server 21 has a lock allocation server name different from the first lock allocation server list, it is considered that the lock allocation server 21 corresponding to the different lock allocation server name is faulty, and the name of the lock allocation server 21 is deleted from the second lock allocation server list.

[0073] In a specific application, as time goes by, the second lock allocation server list stored by all lock application clients 1 deletes the name of the failed lock allocation server, thereby achieving the purpose of rapid fault detection.

[0074] The lock allocation server cluster 2 is used to receive lock or unlock requests, access lock data information of multiple lock storage servers 21, process lock or unlock requests, and send the access results to a lock application client 1. The lock data information includes a lock ID number and lock status information. Specifically, the lock allocation server cluster 2 includes multiple lock allocation servers 21, and the multiple lock allocation servers 21 in the lock allocation server cluster 2 are communicatively connected. Each lock allocation server 21 includes a maintenance cluster module 201 and a lock logic processing module 202, wherein a maintenance cluster module 201 is communicatively connected to a load balancing module 13, a fault detection module 15 and the remaining lock allocation servers 21 in the lock allocation server cluster 2, and a lock logic processing module 202 is communicatively connected to a load balancing module 13 and multiple lock storage servers 3. A maintenance cluster module 201 is used to send the first lock allocation server list to a balancing load module 13 according to a server list request, and to send the first lock allocation server list to a fault detection module 15 according to a heartbeat packet; it is also used to establish a communication connection with a new lock allocation server when a new lock allocation server joins a lock allocation server cluster 2, and to update the first lock allocation server list, and to send the updated first lock allocation server list to a balancing load module 13 according to the server list request; a lock logic processing module 202 is used to receive a lock or unlock request, access the lock data information of multiple lock storage servers 3, and process the lock or unlock request, and send the access result to a lock application client 1.

[0075] In this embodiment, a lock logic processing module 202 includes:

[0076] A first thread, used to receive and parse a lock or unlock request, and send a lock or unlock request;

[0077] The plurality of second threads are used to access the plurality of lock storage servers 3 according to a lock or unlock request of a first thread, process the lock or unlock request, and send the access result to a lock application client 1.

[0078] In this embodiment, a first thread receives and analyzes a lock or unlock request from a load balancing module 13 .

[0079] In a specific application, the first thread may be a Master thread, and the second thread may be a LockHander thread. The Master thread receives and parses the lock or unlock request and stores it in the memory pool. A simple remainder is calculated based on the IDs of the locks to be added and the locks to be released in the memory pool to obtain the remainder hash. Different hashes correspond to different LockHander threads. The lock or unlock request is sent to a LockHander thread based on the remainder hash. A LockHander thread receives the lock or unlock request and creates a socket. It accesses multiple lock storage servers 3 based on the lock or unlock request and sends the access return result to a lock application client 1. When the access return result returns the correct lock / unlock information (i.e., the lock is not occupied to meet the lock requirement, or meets the unlock requirement), the information is sent to a lock application client 1. When the access return result returns the information that the lock is occupied, the socket is added to the waiting array until the lockable information is returned. A maintenance cluster module 201 has only one keep thread, establishes a listening socket, accepts a connection between a lock application client 1 and other lock allocation servers 21, and then processes the communication between the lock allocation servers 21, as well as the server list request and heartbeat packet of the lock application client 1.

[0080] Multiple lock storage servers 3 are used to store lock data information. Specifically, multiple lock storage servers 3 adopt a master-slave mode, including

[0081] A master lock storage server 31, communicatively connected to a lock allocation server cluster 2, for writing and storing lock data information;

[0082] A plurality of slave lock storage servers 32 are communicatively connected to a master lock storage server 31 and a lock allocation server cluster 2, and are used to store lock data information stored by a master lock storage server 31, and are also used by a lock allocation server 21 to access and read lock data information.

[0083] In specific applications, high-performance Redies is used as a lock storage solution, and lock data information is stored in a key-value format, where key represents the lock ID and value represents the lock status information, where value equals 1 and indicates that the lock can be used, and value equals 0 and indicates that the lock is occupied. The master-slave storage mode provided in this embodiment improves the availability of the distributed lock system architecture and reduces the time for data recovery in the event of a failure.

[0084] A distributed lock system architecture provided in this embodiment adopts a strategy of separating the lock's logical processing and the lock's data service. There is no need to process the lock's logical processing and the lock's data service on the same server, which improves the flexibility, system scalability and resource utilization of the distributed lock system architecture and reduces the time for fault recovery.

[0085] This embodiment provides a distributed lock system architecture. The specific workflow of a lock application client applying for locking or unlocking is as follows:

[0086] The user program sends a lock or unlock request to the lock / unlock module 12 through the client interface module 11, and the lock / unlock module 12 sends the lock or unlock request to the load balancing module 13. The load balancing module 13 selects a lock allocation server 21 based on the second lock allocation server list stored in the lock application client 1 (this lock allocation server list is periodically updated), and sends the lock or unlock request to this lock allocation server 21. The lock allocation server 21 accesses the slave lock storage server 32. When applying for a lock request, if the lock to be added is not stored in the slave lock storage server 32, the lock is written into the master lock storage server 31 in the form of key-value for storage. If the lock to be added is already stored in the slave lock storage server 32, the lock request is processed according to the status information of the lock storage, and the access result is sent to the lock application client 1; when applying for an unlock request, the unlock request is processed according to the status information of the lock stored in the slave lock storage server 32, and the access result is sent to the lock application client 1.

[0087] The above description is only the preferred embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A distributed lock system architecture, It is characterized in that include: Multiple lock application clients, used to provide a client interface for applying for locks and send lock or unlock requests through the client interface; Multiple lock storage servers, used to store lock data information; A lock allocation server cluster is communicatively connected to multiple lock application clients and multiple lock storage servers, and multiple lock allocation servers in the lock allocation server cluster are communicatively connected to each other. The lock allocation server cluster is used to receive lock or unlock requests, access lock data information of multiple lock storage servers, process lock or unlock requests, and send access results to the lock application client; Among them, each lock application client includes: The client interface module is used to provide a client interface for applying for a lock and send a lock or unlock request for a process through the client interface; A lock / unlock module, which is communicatively connected to the client interface module, is used to receive a lock or unlock request and send the lock or unlock request to the lock allocation server; A load balancing module, which is communicatively connected to the locking / unlocking module and the lock allocation server cluster, is used to receive a locking or unlocking request and send the locking or unlocking request to the lock allocation server using a load balancing method; Specifically include: The load balancing module periodically sends a server list request to the lock allocation server to obtain a first lock allocation server list stored in the lock allocation server; When a new lock allocation server name exists in the first lock allocation server list, the second lock allocation server list stored in the lock application client is updated based on the first lock allocation server list; Based on the updated second lock allocation server list, a communication connection is established with the new lock allocation server, and a lock or unlock request is sent to the lock allocation server or the new lock allocation server.

2. The distributed lock system architecture according to claim 1, It is characterized in that Each of the lock application clients also includes: A deadlock prevention module is communicatively connected to the locking / unlocking module and is used to store a set of processes that have obtained locks; when a process applies for a lock request, if the lock to be added is already in the set, the lock request is prohibited; otherwise, the lock to be added is added to the set; when a process applies for an unlock request, the lock to be released is removed from the set.

3. The distributed lock system architecture according to claim 1, It is characterized in that Each of the lock application clients also includes: a fault detection module, communicatively connected to the load balancing module and the lock allocation server cluster, configured to receive fault information of the load balancing module and delete the name of the corresponding lock allocation server in the second lock allocation server list according to the fault information; It is also used to periodically send heartbeat packets to the plurality of lock allocation servers respectively, and obtain the first lock allocation server list stored by the lock allocation server; When the return result of the heartbeat packet is an error, deleting the name of the corresponding lock allocation server in the second lock allocation server list; When the first lock allocation server list stored in the lock allocation server has different lock allocation server names from the first lock allocation server lists stored in the other lock allocation servers, the different lock allocation server names are deleted from the second lock allocation server list.

4. The distributed lock system architecture according to claim 3, It is characterized in that Each of the lock allocation servers comprises: a maintenance cluster module, which is communicatively connected to the load balancing module, the fault detection module and the remaining lock allocation servers in the lock allocation server cluster, and is used to send the first lock allocation server list to the load balancing module according to the server list request, and send the first lock allocation server list to the fault detection module according to the heartbeat packet; Also used for establishing a communication connection with a new lock allocation server when a new lock allocation server joins the lock allocation server cluster, and updating the first lock allocation server list, and sending the updated first lock allocation server list to the load balancing module according to the server list request; The lock logic processing module is communicatively connected to the load balancing module and the plurality of lock storage servers, and is used to receive the lock or unlock request, access the lock data information of the plurality of lock storage servers, process the lock or unlock request, and send the access result to the lock application client.

5. The distributed lock system architecture according to claim 4, It is characterized in that Each of the lock logic processing modules comprises: A first thread is used to receive and parse the lock or unlock request, and send the lock or unlock request; A plurality of second threads are used to access a plurality of the lock storage servers according to the lock or unlock request of the first thread, process the lock or unlock request, and send the access result to the lock application client.

6. The distributed lock system architecture according to claim 1, It is characterized in that The multiple lock storage servers adopt a master-slave mode, including A master lock storage server, communicatively connected to the lock allocation server cluster, for writing and storing the lock data information; A plurality of slave lock storage servers are communicatively connected to the master lock storage server and the lock allocation server cluster, and are used to store the lock data information stored by the master lock storage server, and are also used for the lock allocation server to access and read the lock data information.

7. The distributed lock system architecture according to claim 1, It is characterized in that The lock data information includes: Lock ID number and lock status information.

Images