Distributed lock processing system based on Golang
By using the grpc framework for communication in a distributed lock processing system, the high latency problem caused by the HTTP protocol in the prior art is solved, the efficiency of distributed lock processing is improved and the utilization of server resources is optimized.
Patent Information
- Application Number
- CN202311467966.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2023-11-06
- Publication Date
- 2025-05-06
AI Technical Summary
The existing distributed lock processing solution provided by the Golang language sends requests through the HTTP protocol, resulting in higher delays and lower efficiency.
The grpc framework is used to communicate and connect between the client and the server. The client generates a grpc lock request or release lock request. The server performs the corresponding lock or release operation when receiving the request.
By using the grpc framework, the latency between the client and the server is reduced, the efficiency of distributed lock processing is improved, and the waste of server resources caused by invalid requests is reduced.
Smart Images
Figure CN119938293A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of communication technologies, and in particular to a Golang-based distributed lock processing system. Background Art
[0002] As Internet technology becomes increasingly mature, distributed deployment of services has become the mainstream, and distributed locks play an irreplaceable role in scenarios where multiple services compete for resources.
[0003] Golang (also known as Go) is a statically strongly typed, compiled, concurrent programming language. Using the high-performance, high-concurrency Golang language as the development language, the distributed lock processing solution provided not only has clear and single functional responsibilities, but also facilitates the location of fault points and has low costs.
[0004] However, the existing distributed lock processing solution provided by the Golang language sends requests through the Hypertext Transfer Protocol (HTTP). Due to the high latency of HTTP itself, the distributed lock processing efficiency is low. Summary of the invention
[0005] The problem to be solved by the present invention is: how to improve the distributed lock processing efficiency.
[0006] To solve the above problems, an embodiment of the present invention provides a distributed lock processing system based on Golang, the system comprising:
[0007] grpc client, suitable for generating grpc lock request or grpc lock release request;
[0008] The grpc server is connected to the grpc client using the grpc protocol communication, and is suitable for determining the corresponding resource to be locked based on the grpc lock request when receiving the grpc lock request, and performing a lock operation on the resource to be locked; and determining the corresponding resource to be released based on the grpc lock release request when receiving the grpc lock release request, and performing a release operation on the resource to be released.
[0009] Optionally, the grpc client stores identification information of locked resources and the remaining locking time of each locked resource.
[0010] Optionally, the grpc client is further adapted to determine whether the resource to be locked has been locked before generating the grpc lock request, and generate the grpc lock request when the resource to be locked is not locked.
[0011] Optionally, the grpc client is further adapted to determine whether the resource to be locked has been locked before generating the grpc lock request, and generate the grpc lock request when the resource to be locked has been locked and the remaining lock time is 0.
[0012] Optionally, the grpc client is also suitable for determining whether the resource to be locked has been locked before generating the grpc lock request, and when the resource to be locked has been locked and the remaining lock time is greater than 0, obtaining lock time adjustment information, and generating the grpc lock request based on the lock time adjustment information to adjust the lock time of the resource to be locked.
[0013] Optionally, the adjusting the locking time of the resource to be locked includes: increasing the locking time of the resource to be locked, or shortening the locking time of the resource to be locked.
[0014] Optionally, the grpc client is also suitable for adjusting information according to the lock duration and updating storage information.
[0015] Optionally, the grpc lock request includes: lock resource identification information, lock duration information and identification information of the grpc lock request.
[0016] Optionally, the grpc client is further adapted to determine whether the resource to be released has been locked and not released before generating the grpc lock release request, and generate the grpc lock release request when the resource to be released has been locked and not released.
[0017] Optionally, the grpc lock release request includes: identification information of the grpc lock release request and identification information of the resource to be released.
[0018] Optionally, the grpc server is adapted to perform flow control on the grpc client after receiving the grpc locking request, and perform a locking operation on the resource to be locked when the grpc locking request is a legitimate request.
[0019] Optionally, performing a locking operation on the resource to be locked includes:
[0020] Performing a locking operation on the area where the resource to be locked is located;
[0021] After performing a locking operation on the area where the resource to be locked is located, performing a locking operation on the resource to be locked;
[0022] A release operation is performed on the area where the resource to be locked is located, and information indicating successful locking is sent to the grpc client.
[0023] Optionally, the grpc server is adapted to perform flow control on the grpc client after receiving the grpc lock release request, and perform a release operation on the resource to be released when the grpc lock release request is a legitimate request.
[0024] Optionally, performing a release operation on the resource to be released includes:
[0025] Performing a locking operation on the area where the to-be-released resources are located;
[0026] After performing a locking operation on the area where the to-be-released resource is located, performing a releasing operation on the to-be-released resource;
[0027] A release operation is performed on the area where the resource to be released is located, and information indicating a successful release is sent to the grpc client.
[0028] Compared with the prior art, the technical solution of the embodiment of the present invention has the following advantages:
[0029] The scheme of the present invention is applied, and the grpc client and the grpc server use the grpc framework communication connection, the grpc client can generate a grpc lock request or a grpc lock release request, and the grpc server determines the corresponding resource to be locked based on the grpc lock request when receiving the grpc lock request, and performs a lock operation on the resource to be locked, and the grpc server determines the corresponding resource to be released based on the grpc lock release request when receiving the grpc lock release request, and performs a release operation on the resource to be released. Compared with the communication connection established using HTTP, the communication connection established using the grpc framework has a smaller delay between the grpc client and the grpc server, so the request generated by the grpc client can be sent to the grpc server more quickly, so as to perform the corresponding distributed lock processing, so the distributed lock processing efficiency can be effectively improved.
[0030] Furthermore, before generating the grpc lock request, a grpc client is set to determine whether the resource to be locked has been locked. When the resource to be locked is not locked, the grpc lock request is generated. Compared with the scheme of setting the grpc server to verify the validity of the grpc lock request after receiving the grpc lock request, it can be determined in advance whether the grpc lock request can be generated, further improving the distributed lock processing efficiency. In addition, the waste of server resources caused by the invalidity of the grpc lock request can be reduced.
[0031] Furthermore, before generating the grpc lock request, the grpc client is set to determine whether the resource to be locked has been locked, and the grpc lock request is generated only when the resource to be locked has been locked and the remaining lock duration is 0. Compared with the scheme of setting the grpc server to verify the validity of the grpc lock request after receiving the grpc lock request, it can be determined in advance whether the grpc lock request can be generated, further improving the distributed lock processing efficiency. In addition, the waste of server resources caused by the invalidity of the grpc lock request can be reduced.
[0032] Furthermore, before generating the grpc lock request, a grpc client is set to determine whether the resource to be locked has been locked, and when the resource to be locked has been locked and the remaining lock time is greater than 0, the lock time adjustment information is obtained, and the grpc lock request is generated based on the lock time adjustment information. In this way, when the resource to be locked has been locked, the lock time of the resource to be locked can be adjusted to meet the renewal requirements of the distributed lock.
[0033] Furthermore, after receiving a grpc lock request or a grpc lock release request, the grpc server performs flow control on the grpc client, thereby preventing malicious requests from causing grpc service processing failures and improving the security of distributed lock processing.
[0034] Furthermore, before generating a grpc lock release request, a grpc client is set to determine whether the resource to be released has been locked and not released, and the grpc lock release request is generated only when the resource to be released has been locked and not released. Compared with the scheme of setting a grpc server to verify the validity of the grpc lock release request after receiving the grpc lock release request, it can be determined in advance whether the grpc lock release request can be generated, further improving the distributed lock processing efficiency. In addition, the waste of server resources caused by the invalidity of the grpc lock release request can be reduced. BRIEF DESCRIPTION OF THE DRAWINGS
[0035] Figure 1 It is a structural diagram of a Golang-based distributed lock processing system in an embodiment of the present invention;
[0036] Figure 2 It is a schematic diagram of a process in which a grpc server performs a locking operation on the resource to be locked in one embodiment of the present invention;
[0037] Figure 3 It is a flow chart of the grpc server performing a release operation on the resource to be locked in one embodiment of the present invention. DETAILED DESCRIPTION
[0038] The existing distributed lock processing solution provided by Golang language uses the HTTP protocol to establish a communication connection between the client and the server. The client can send an HTTP lock request or an HTTP lock release request to the server, and the server performs the corresponding distributed lock processing operation.
[0039] Since HTTP itself has a high latency, the distributed lock processing efficiency is low.
[0040] In addition, in the above scheme, the client is only used to generate HTTP lock request or HTTP lock release request. Before generating the request, it does not verify whether the request to be generated is valid. Instead, the server verifies whether the received request is valid after receiving the request. The so-called verification of the request to be generated is to verify whether the resource corresponding to the request to be generated is allowed to be locked.
[0041] However, for the server, each time after receiving a request, before verifying whether the received request is valid, it needs to perform a series of other operations, such as verifying whether the received request is legal, etc. Once the received request is invalid, the operations performed by the server before verifying whether the received request is valid are meaningless, which not only wastes server resources, but also prolongs the distributed lock processing time and further reduces the distributed lock processing efficiency.
[0042] In order to make the above-mentioned objects, features and advantages of the present invention more obvious and easy to understand, specific embodiments of the present invention are described in detail below with reference to the accompanying drawings.
[0043] Reference Figure 1 The embodiment of the present invention provides a Golang-based distributed lock processing system, and the Golang-based distributed lock processing system includes: a grpc client 11 and a grpc server 12. Among them:
[0044] The grpc client 11 is suitable for generating a grpc lock request or a grpc lock release request;
[0045] The grpc server 12 is connected to the grpc client 11 using a grpc framework communication connection, and is suitable for determining the corresponding resource to be locked based on the grpc lock request when receiving the grpc lock request, and performing a locking operation on the resource to be locked; and determining the corresponding resource to be released based on the grpc lock release request when receiving the grpc lock release request, and performing a release operation on the resource to be released.
[0046] grpc (Google Remote Procedure Call) is a modern, open source, high-performance remote procedure call (RPC) framework that can run in any environment. The grpc framework can effectively connect services within and between data centers through pluggable load balancing, tracking, health checks, and authentication support. It is also suitable for the last mile of distributed computing, connecting devices, mobile applications, and browsers to backend services.
[0047] In a specific implementation, the Protocol Buffers compiler and the grpc tool can be used in advance to generate the code for the grpc client 11 and the grpc server 12, and then the server provided by grpc is used to implement the grpc server 12, and then the client library provided by gRPC is used to implement the grpc client 11, thereby establishing a grpc framework communication connection between the grpc client 11 and the grpc server 12.
[0048] Since the grpc framework uses Protocol Buffers as the data format, it provides bidirectional streaming remote procedure calls (RPC), multi-language support, plug-in interceptors and other functions, which can greatly improve the communication efficiency between services. In addition, in the Go language, gRPC can be used to quickly build distributed services, and gRPC provides a rich application programming interface (API) and examples, which is very easy to use.
[0049] In an embodiment of the present invention, the grpc client 11 generates a grpc lock request or a grpc lock release request, and uses the grpc framework to interact with the grpc server 12, thereby improving the processing efficiency of distributed locks.
[0050] In one embodiment of the present invention, the grpc client 11 may store identification information of locked resources and the remaining lock duration of each locked resource. The locked resources include expired locked resources and unexpired locked resources.
[0051] For example, the grpc client 11 may store a mapping table of locked resources and remaining lock durations. Based on the mapping table, all locked resources so far and the remaining lock durations corresponding to each locked resource may be obtained. When the remaining lock duration is 0, the corresponding locked resource has expired. When the remaining lock duration is greater than 0, the corresponding locked resource is currently in a locked state.
[0052] In the prior art, the client is only used to generate an HTTP lock request or an HTTP lock release request. Before generating the request, it does not verify whether the request to be generated is valid. After receiving the request, the server verifies whether the received request is valid.
[0053] In an embodiment of the present invention, in order to further improve the efficiency of distributed lock processing and save server resources, and to minimize unnecessary grpc lock requests and grpc lock release requests, the grpc client 11 can be set to verify whether the request to be generated is valid before generating the grpc lock request and the grpc lock release request. If the request to be generated is invalid, there is no need to generate the request, the distributed lock processing flow ends immediately, and the grpc server does not need to perform related processing operations on the invalid request. If the request to be generated is valid, the request can be generated, so that the grpc server can perform related processing operations on the valid request.
[0054] In one embodiment of the present invention, the grpc client 11 is adapted to determine whether the resource to be locked has been locked before generating the grpc lock request, and generate the grpc lock request when the resource to be locked is not locked.
[0055] Specifically, before generating a grpc lock request, the grpc client 11 can obtain the identification information of the resource to be locked. For example, the grpc client 11 obtains the identification information of the resource to be locked through the user's input operation. After obtaining the identification information of the resource to be locked, the grpc client 11 can compare the identification information of the resource to be locked with the identification information of the stored locked resource. If the identification information of the resource to be locked is the same as the identification information of a stored locked resource, the resource to be locked is considered to be a locked resource. If the identification information of the resource to be locked is different from the identification information of a stored locked resource, it is considered that the resource to be locked is not locked. At this time, the grpc client 11 can generate the grpc lock request.
[0056] In another embodiment of the present invention, the grpc client 11 is further adapted to determine whether the resource to be locked has been locked before generating the grpc lock request, and generate the grpc lock request when the resource to be locked has been locked and the remaining lock time is 0.
[0057] Specifically, before generating a grpc lock request, the grpc client 11 can obtain the identification information of the resource to be locked. After obtaining the identification information of the resource to be locked, the grpc client 11 can compare the identification information of the resource to be locked with the identification information of the stored locked resource. If the identification information of the resource to be locked is the same as the identification information of a stored locked resource, the resource to be locked is considered to be a locked resource. At this time, the remaining lock duration corresponding to the locked resource that is the same as the resource to be locked can be further obtained. If the remaining lock duration corresponding to the locked resource that is the same as the resource to be locked is 0, it indicates that the locked resource that is the same as the resource to be locked has expired and can be locked again, so the grpc lock request can be generated.
[0058] In order to meet the needs of certain scenarios, the lock duration of resources that are currently locked can also be adjusted.
[0059] Specifically, in another embodiment of the present invention, the grpc client 11 is also suitable for determining whether the resource to be locked has been locked before generating the grpc lock request, and when the resource to be locked has been locked and the remaining lock time is greater than 0, obtaining the lock time adjustment information, and generating the grpc lock request based on the lock time adjustment information to adjust the lock time of the resource to be locked.
[0060] In a specific implementation, the grpc client 11 can obtain the identification information of the resource to be locked before generating a grpc lock request. After obtaining the identification information of the resource to be locked, the grpc client 11 can compare the identification information of the resource to be locked with the identification information of the stored locked resource. If the identification information of the resource to be locked is the same as the identification information of a stored locked resource, the resource to be locked is considered to be a locked resource. At this time, the remaining lock duration corresponding to the locked resource that is the same as the resource to be locked can be further obtained. If the remaining lock duration corresponding to the locked resource that is the same as the resource to be locked is greater than 0, it indicates that the locked resource that is the same as the resource to be locked is currently in a locked state.
[0061] After determining that the resource to be locked is currently in a locked state, the lock duration adjustment information can be obtained. For example, the grpc client 11 can obtain the lock duration adjustment information through the user's input operation. Subsequently, the grpc client 11 can generate a grpc lock request based on the lock duration adjustment information to adjust the lock duration of the resource to be locked. Among them, the adjustment of the lock duration of the resource to be locked may include: increasing the lock duration of the resource to be locked, or shortening the lock duration of the resource to be locked.
[0062] Specifically, the locking duration adjustment information may include adjustment mode indication information and adjustment duration indication information. The adjustment mode indication information may indicate whether to increase or decrease the locking duration of the resource to be locked. The adjustment duration indication information is used to indicate a specific duration value.
[0063] In some embodiments, the value of the specific duration may be the value of the duration adjustment amount. For example, when the adjustment mode indication information indicates to increase the lock duration of the resource to be locked, and the adjustment duration indication information indicates that the specific adjustment duration is 10s, the grpc server may increase the lock duration of the resource to be locked by 10s based on the grpc lock request.
[0064] In other embodiments, the value of the specific duration may also be the value of the lock duration of the resource to be locked after adjustment. For example, when the adjustment mode indication information indicates to increase the lock duration of the resource to be locked, and the adjustment duration indication information indicates that the specific duration of the adjustment is 10s, the grpc server may increase the lock duration of the resource to be locked to 10s based on the grpc lock request.
[0065] In a specific implementation, the grpc client 11 can update the stored information in real time, including real-time updates of locked resources and the corresponding remaining lock durations. For example, when the grpc client 11 generates a grpc lock request, the grpc client 11 can synchronously add the identification information of the locked resources in the grpc lock request to the stored information, or update the remaining lock duration corresponding to the stored locked resources. When the grpc client 11 generates a grpc lock release request, the grpc client 11 can synchronously change the remaining lock duration of the corresponding locked resource to 0 in the stored information. When the grpc client 11 generates the grpc lock request based on the lock duration adjustment information, the grpc client 11 can also update the remaining lock duration corresponding to the stored locked resource based on the lock duration adjustment information.
[0066] In a specific implementation, the grpc server 12 is adapted to perform flow control on the grpc client 11 after receiving the grpc locking request, and perform a locking operation on the resource to be locked when the grpc locking request is a legitimate request.
[0067] In a specific implementation, performing a locking operation on the resource to be locked may include:
[0068] Performing a locking operation on the area where the resource to be locked is located;
[0069] After performing a locking operation on the area where the resource to be locked is located, performing a locking operation on the resource to be locked;
[0070] A release operation is performed on the area where the resource to be locked is located, and information indicating successful locking is sent to the grpc client.
[0071] Figure 2 FIG. 1 is a flow chart of a grpc server performing a locking operation on the resource to be locked in one embodiment of the present invention. Figure 2 The specific process of the grpc server performing the locking operation on the resource to be locked may include:
[0072] Step 201, receiving a grpc lock request.
[0073] Step 202: Authenticate the grpc lock request.
[0074] In a specific implementation, an IP whitelist may be stored in the grpc server, and the IP whitelist includes IP addresses with grpc service call permissions.
[0075] In order to ensure the security of the service, the grpc server can compare the IP address that sends the grpc lock request with the IP whitelist. When the IP address of the received grpc lock request is not in the IP whitelist, execute step 203, otherwise execute step 204.
[0076] Step 203: Return information indicating that the distributed lock processing has failed.
[0077] Step 204, determine whether the traffic of the grpc client is within the allowed traffic range.
[0078] In a specific implementation, the grpc client that sends the grpc lock request performs flow control based on a sliding window algorithm to prevent malicious requests, such as limiting the grpc client to a maximum of 10 requests per second and a maximum of 1,000 requests per minute.
[0079] When the traffic of the grpc client is not within the allowed traffic range, execute step 203, otherwise execute step 205.
[0080] Step 205, determine whether the parameters of the grpc lock request are legal.
[0081] In a specific implementation, the grpc lock request includes: lock resource identification information name, lock duration information expire, and identification information uniq_key of the grpc lock request. Among them, the lock resource identification information name can be a string. The lock duration information expire can be an unsigned integer, and the unit can be milliseconds. The identification information uniq_key of the grpc lock request can also be a string.
[0082] It should be noted that the lock duration information expire can represent the expiration timestamp of the distributed lock. When the resource to be locked corresponding to the grpc lock request is not locked or has been locked but expired, the lock duration information expire refers to the total lock duration after the grpc server locks the resource to be locked. When the resource to be locked corresponding to the grpc lock request has been locked but not expired, the lock duration information expire refers to the lock duration adjustment information.
[0083] Determine whether the parameters of the grpc lock request are legal, for example, whether the lock duration information expire is an integer, whether the range of the lock duration information expire is legal, whether the lock resource identification information name is a string, etc.
[0084] When it is determined that the parameters of the grpc lock request are legal, step 206 is executed, otherwise step 203 is executed.
[0085] Step 206: determine the area where the resource to be locked is located.
[0086] Due to the high frequency of use of distributed locks, distributed locks can usually be divided into 8 to 256 areas. The specific number can be configured according to the actual system concurrency. The larger the concurrency, the larger the number of areas. Initialize the core data structure map according to the configured n areas. Map is a native data structure of the go language. The key value of the map can be defined as ranging from 0 to n-1, and value is a linked list of locks for each area. The outer layer of the linked list is wrapped with a layer of sync.mutex. Sync.mutex is a mutex lock in the go language, which is used for concurrency control. Perform a 32-bit cyclic redundancy check (crc32) operation on the lock resource identification information name in the grpc lock request to obtain the check result m, and then calculate m%n to obtain k, where k is the remainder after n is divided by m. k is the area number to which the lock resource is mapped. The information of this lock will be saved in a linked list with area number k, where k∈(0, n-1).
[0087] Step 207: performing a locking operation on the area where the resource to be locked is located.
[0088] In the specific implementation, after determining that the area number is k, the grpc server can call map[k].m.lock to add a mutex lock to the area. By adding a mutex lock to the area, it can be ensured that only one thread can operate the area, which can effectively avoid program errors caused by concurrent operations.
[0089] Step 208: performing a locking operation on the resource to be locked.
[0090] The lock operation is performed on the resource to be locked, that is, the parameter information of the grpc lock request of the lock is saved, including the lock resource identification information name, the lock duration information expire and the identification information uniq_key of the grpc lock request. The parameter information of the grpc lock request is saved in the linked list of the area where the resource to be locked is located. After the parameter information of the grpc lock request is saved, the lock operation on the resource to be locked is completed.
[0091] In some embodiments, when the lock duration information expire is the lock duration adjustment information, the grpc server can also determine the total lock duration of the resource to be locked based on the lock duration information expire, and save it in a linked list in the area where the resource to be locked is located.
[0092] Step 209: performing a release operation on the area where the resource to be locked is located.
[0093] In a specific implementation, the grpc server can call map[k].m.unlock to release the mutex lock of the area.
[0094] Step 210, returning information indicating that the locking is successful.
[0095] After the mutex lock of the operated area is released, a lock success message can be returned to the user, that is, the user is informed that the specified resource to be locked is locked successfully.
[0096] exist Figure 2 In the illustrated embodiment, since the grpc client has verified the validity of the grpc lock request, the grpc server can directly perform a lock operation on the resource to be locked after the permission authentication, current limiting control and legality verification of the grpc lock request have passed, without having to verify the validity of the grpc lock request.
[0097] Of course, in some embodiments, in order to further improve the reliability of distributed lock processing, the grpc server can also verify the validity of the grpc lock request again after the permission authentication, current limiting control and legality verification of the grpc lock request are passed, that is, to determine whether the resource to be locked corresponding to the grpc lock request has been locked. When the resource to be locked is not locked, execute step 208, or, when the resource to be locked has been locked and the remaining lock time is 0, execute step 208.
[0098] In one embodiment of the present invention, the grpc client is further adapted to determine whether the resource to be released has been locked and not released before generating the grpc lock release request, and to generate the grpc lock release request when the resource to be released has been locked and not released.
[0099] Specifically, before generating a grpc lock release request, the grpc client 11 can obtain the identification information of the resource to be released. For example, the grpc client 11 obtains the identification information of the resource to be released through the user's input operation. After obtaining the identification information of the resource to be released, the grpc client 11 can compare the identification information of the resource to be released with the identification information of the stored locked resource. If the identification information of the resource to be released is the same as the identification information of a stored locked resource, the resource to be released is considered to be a locked resource. If the identification information of the resource to be released is different from the identification information of a stored locked resource, the resource to be released is considered to be not locked.
[0100] When the resource to be released is a locked resource, the grpc client 11 can further obtain the remaining lock duration of the locked resource. When the remaining lock duration of the locked resource is greater than 0, it is considered that the locked resource has not been released. At this time, the grpc client 11 can generate the grpc lock request.
[0101] The grpc client 11 is configured to verify whether the grpc lock release request to be generated is valid before generating the grpc lock release request. The grpc lock release request is generated only when the grpc lock release request to be generated is valid. This can avoid the waste of resources of the grpc server due to the invalid grpc lock release request. Moreover, when the grpc lock release request to be generated is invalid, there is no need to generate the grpc lock release request, which can improve the processing efficiency of distributed locks.
[0102] In one embodiment of the present invention, the grpc server is adapted to perform flow control on the grpc client after receiving the grpc lock release request, and perform a release operation on the resource to be released when the grpc lock release request is a legitimate request.
[0103] In one embodiment of the present invention, performing a release operation on the to-be-released resource may include:
[0104] Performing a locking operation on the area where the to-be-released resources are located;
[0105] After performing a locking operation on the area where the to-be-released resource is located, performing a releasing operation on the to-be-released resource;
[0106] A release operation is performed on the area where the resource to be released is located, and information indicating a successful release is sent to the grpc client.
[0107] Figure 3 FIG. 1 is a flow chart of a grpc server executing a release operation on the resource to be locked in one embodiment of the present invention. Figure 3The specific process of the grpc server performing the release operation on the resource to be locked may include:
[0108] Step 301, receiving a grpc lock release request.
[0109] Step 302: Authenticate the grpc lock release request.
[0110] Similarly, the IP address that sends the grpc release lock request can be compared with the IP whitelist. When the IP address that sends the grpc release lock request is not in the IP whitelist, step 303 is executed, otherwise step 304 is executed.
[0111] Step 303: Return information indicating that the distributed lock processing has failed.
[0112] Step 304, determine whether the traffic of the grpc client is within the allowed traffic range.
[0113] In a specific implementation, the grpc client that sends the grpc lock request performs flow control based on a sliding window algorithm to prevent malicious requests.
[0114] When the traffic of the grpc client is not within the allowed traffic range, execute step 303, otherwise execute step 305.
[0115] Step 305, determine whether the parameters of the grpc lock release request are legal.
[0116] In a specific implementation, the grpc lock release request may include: the name of the resource to be released name' and the identification information uniq_key' of the grpc lock release request. The name of the resource to be released name' and the identification information uniq_key' of the grpc lock release request may be strings.
[0117] Determine whether the parameters of the grpc lock release request are legal, that is, determine whether the resource name to be released name' exists and whether the format of the resource name to be released name' is legal.
[0118] Step 306, determine the area where the grpc lock release request is located.
[0119] In the specific implementation, assuming that the distributed lock is divided into n regions, the name of the resource to be released in the grpc release lock request can be subjected to a 32-bit cyclic redundancy check (crc32) operation to obtain the check result h, and then h%n is calculated to obtain g, where g is the remainder after n is divided by h. g is the region number to which the resource to be released is mapped, and the information of this release lock will be stored in a linked list with region number g, where g∈(0,n-1).
[0120] Step 307: performing a locking operation on the area where the to-be-released resources are located.
[0121] In the specific implementation, after determining that the area number is g, the grpc server can call map[k].m.lock to add a mutex lock to the area. By adding a mutex lock to the area, it can be ensured that only one thread can operate the area, which can effectively avoid program errors caused by concurrent operations.
[0122] Step 308: performing a release operation on the resource to be released.
[0123] In a specific implementation, a release operation is performed on the resource to be released, that is, the lock resource in the memory is released.
[0124] Step 309: performing a release operation on the area where the to-be-released resources are located.
[0125] In a specific implementation, the grpc server can call map[k].m.unlock to release the mutex lock of the area.
[0126] Step 310: Return information indicating successful unlocking.
[0127] By using the Golang-based distributed lock processing system in the embodiment of the present invention, after the mutex lock of the operated area is released, an unlocking success message can be returned to the user, that is, the user is informed that the designated resource to be released is unlocked successfully.
[0128] Compared with the current mainstream distributed lock processing solutions, this solution is first of all a customized distributed lock solution, not an auxiliary function of a third-party application. The functional responsibilities are clear and single, and errors are easier to locate. Secondly, this solution greatly reduces the access cost. It only requires 2 to 3 parameters and initiates a grpc call, which greatly reduces the threshold for use. Finally, since this solution uses grpc to provide services, it also has better performance in network transmission efficiency and stability. The long-link bidirectional stream transmission mode of grpc and high data compression efficiency have natural advantages over traditional http solutions.
[0129] Although the present invention is disclosed as above, the present invention is not limited thereto. Any person skilled in the art can make various changes and modifications without departing from the spirit and scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the scope defined by the claims.
Claims
1. A distributed lock processing system based on Golang, characterized in that: include: grpc client, suitable for generating grpc lock request or grpc lock release request; The grpc server is connected to the grpc client using the grpc protocol communication, and is adapted to determine the corresponding resource to be locked based on the grpc locking request when receiving the grpc locking request, and perform a locking operation on the resource to be locked; And when the grpc lock release request is received, the corresponding resources to be released are determined based on the grpc lock release request, and a release operation is performed on the resources to be released.
2. The Golang-based distributed lock processing system according to claim 1, characterized in that: The grpc client stores identification information of locked resources and the remaining lock duration of each locked resource.
3. The Golang-based distributed lock processing system according to claim 1, characterized in that: The grpc client is also suitable for determining whether the resource to be locked has been locked before generating the grpc lock request, and generating the grpc lock request when the resource to be locked is not locked.
4. The Golang-based distributed lock processing system according to claim 1, characterized in that: The grpc client is also suitable for determining whether the resource to be locked has been locked before generating the grpc lock request, and generating the grpc lock request when the resource to be locked has been locked and the remaining lock time is 0.
5. The Golang-based distributed lock processing system according to claim 1, characterized in that: The grpc client is also suitable for determining whether the resource to be locked has been locked before generating the grpc lock request, and when the resource to be locked has been locked and the remaining lock time is greater than 0, obtaining lock time adjustment information, and generating the grpc lock request based on the lock time adjustment information to adjust the lock time of the resource to be locked.
6. The Golang-based distributed lock processing system according to claim 5, characterized in that: The adjusting the locking time of the resource to be locked includes: increasing the locking time of the resource to be locked, or shortening the locking time of the resource to be locked.
7. The Golang-based distributed lock processing system according to claim 5, characterized in that: The grpc client is also suitable for adjusting information according to the locking duration and updating storage information.
8. The Golang-based distributed lock processing system according to claim 1, characterized in that: The grpc lock request includes: lock resource identification information, lock duration information and identification information of the grpc lock request.
9. The Golang-based distributed lock processing system according to claim 1, characterized in that: The grpc client is also suitable for determining whether the resource to be released has been locked and not released before generating the grpc lock release request, and generating the grpc lock release request when the resource to be released has been locked and not released.
10. The Golang-based distributed lock processing system according to claim 1, characterized in that: The grpc lock release request includes: identification information of the grpc lock release request and identification information of the resource to be released.
11. The Golang-based distributed lock processing system according to claim 1, characterized in that: The grpc server is adapted to perform flow control on the grpc client after receiving the grpc locking request, and to perform a locking operation on the resource to be locked when the grpc locking request is a legitimate request.
12. The Golang-based distributed lock processing system according to claim 11, characterized in that: Performing a locking operation on the resource to be locked includes: Performing a locking operation on the area where the resource to be locked is located; After performing a locking operation on the area where the resource to be locked is located, performing a locking operation on the resource to be locked; A release operation is performed on the area where the resource to be locked is located, and information indicating successful locking is sent to the grpc client.
13. The Golang-based distributed lock processing system according to claim 1, characterized in that: The grpc server is adapted to perform flow control on the grpc client after receiving the grpc lock release request, and to perform a release operation on the resource to be released when the grpc lock release request is a legitimate request.
14. The Golang-based distributed lock processing system according to claim 13, characterized in that: Performing a release operation on the resource to be released includes: Performing a locking operation on the area where the to-be-released resources are located; After performing a locking operation on the area where the to-be-released resource is located, performing a releasing operation on the to-be-released resource; A release operation is performed on the area where the resource to be released is located, and information indicating a successful release is sent to the grpc client.