A request processing method and device

Abstract

The present invention discloses a request processing method and device, and relates to the field of computer technology. A specific implementation of the method includes: the access layer receives a request to be processed, determines the calling method corresponding to the request, and obtains a distributed lock key name corresponding to the calling method; determines a service node corresponding to the distributed lock key name, and distributes the request to the service node; and locks the request through the service node to forward the request to the application corresponding to the service node for processing. This implementation implements the distributed lock logic by configuring the distributed lock on the Nginx access layer, without embedding the distributed lock logic in the business code, and by combining the consistent hash with the local lock, all requests for the same distributed lock key are sent to the same Nginx node.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a request processing method and device. Background Art

[0002] Currently, large websites and applications are deployed in a distributed manner, and data consistency issues will arise in distributed scenarios. Based on the distributed CAP theory, "no distributed system can simultaneously meet consistency, availability, and partition tolerance, and can only meet two of them at most." Many systems will make trade-offs between these three at the beginning of their design.

[0003] In most scenarios in the Internet field, it is usually chosen to sacrifice strong consistency in exchange for high reliability, that is, the system only needs to maintain "eventual consistency". This requires the support of many technical solutions, such as database distributed transactions and distributed locks, to ensure that a method (i.e. a piece of business code) can only be executed by one thread in one machine at the same time.

[0004] In the process of implementing the present invention, the inventors found that the prior art has at least the following problems:

[0005] Both distributed transactions and distributed locks are business-intrusive, and require the distributed lock logic to be embedded in the relevant locations of the business code for coupling. As a result, various distributed lock logics are distributed in the business code, and each operation needs to be processed on the original business code, which is cumbersome. Summary of the invention

[0006] In view of this, an embodiment of the present invention provides a request processing method and device, which can at least solve the problem in the prior art that distributed lock logic needs to be added to the original business code.

[0007] To achieve the above object, according to one aspect of an embodiment of the present invention, a request processing method is provided, comprising:

[0008] The access layer receives the request to be processed, determines the calling method corresponding to the request, and obtains the distributed lock key name corresponding to the calling method;

[0009] Determine a service node corresponding to the distributed lock key name, and distribute the request to the service node; wherein the service node is located in the access layer;

[0010] The request is locked by the service node so as to forward the request to the application corresponding to the service node for processing.

[0011] Optionally, before the access layer receives the request to be processed, the method further includes:

[0012] Receive a distributed lock configuration request in a distributed lock configuration center to obtain distributed lock configuration information; wherein the distributed lock configuration information includes a distributed lock key name, a lock duration, and a lock wait timeout duration;

[0013] An access layer corresponding to the distributed lock configuration information is determined to distribute the distributed lock configuration information to the determined access layer.

[0014] Optionally, the determining a service node corresponding to the distributed lock key name includes:

[0015] A service node cluster corresponding to the distributed lock key name is determined, and consistent hash scheduling is performed on the service node cluster to obtain a service node that processes the request.

[0016] Optionally, the locking process on the request by the service node includes:

[0017] The service node starts the local lock in a blocking lock mode to only lock the request;

[0018] After forwarding the request to the application corresponding to the service node for request processing, the method further includes:

[0019] The service node receives the request processing completion information fed back by the application, and releases the local lock.

[0020] To achieve the above object, according to another aspect of an embodiment of the present invention, a request processing device is provided, comprising:

[0021] A request receiving module, configured to receive a request to be processed at the access layer, determine a calling device corresponding to the request, and obtain a distributed lock key name corresponding to the calling device;

[0022] A node determination module, used to determine a service node corresponding to the distributed lock key name, and distribute the request to the service node; wherein the service node is located in the access layer;

[0023] The locking processing module is used to lock the request through the service node so as to forward the request to the application corresponding to the service node for processing.

[0024] Optionally, an information configuration module is also included, for:

[0025] Receive a distributed lock configuration request in a distributed lock configuration center to obtain distributed lock configuration information; wherein the distributed lock configuration information includes a distributed lock key name, a lock duration, and a lock wait timeout duration;

[0026] An access layer corresponding to the distributed lock configuration information is determined to distribute the distributed lock configuration information to the determined access layer.

[0027] Optionally, the node determination module is used to: determine a service node cluster corresponding to the distributed lock key name, perform consistent hash scheduling on the service node cluster, and obtain a service node that processes the request.

[0028] Optionally, the locking processing module is used to:

[0029] The service node starts a local lock in a blocking lock mode to perform locking control only on the request; and

[0030] The service node receives the request processing completion information fed back by the application, and releases the local lock.

[0031] To achieve the above objective, according to another aspect of an embodiment of the present invention, a request processing electronic device is provided.

[0032] The electronic device of an embodiment of the present invention includes: one or more processors; a storage device for storing one or more programs, when the one or more programs are executed by the one or more processors, the one or more processors implement any of the request processing methods described above.

[0033] To achieve the above objective, according to another aspect of an embodiment of the present invention, a computer-readable medium is provided, on which a computer program is stored, and when the program is executed by a processor, any of the above request processing methods is implemented.

[0034] According to the solution provided by the present invention, one embodiment of the above invention has the following advantages or beneficial effects: providing a solution for implementing distributed lock pre-positioning based on the ngx_lua access layer, which only requires the configuration of distributed locks on the Nginx access layer to implement the distributed lock logic, without the need to embed the distributed lock logic in the business code.

[0035] The further effects of the above-mentioned non-conventional optional manner will be described below in conjunction with specific implementation examples. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] The accompanying drawings are used to better understand the present invention and do not constitute an improper limitation of the present invention.

[0037] Figure 1This is a main flow chart of a request processing method according to an embodiment of the present invention;

[0038] Figure 2 is a flowchart of an optional request processing method according to an embodiment of the present invention;

[0039] Figure 3 This is a schematic diagram of distributed lock configuration information distribution according to an embodiment of the present invention;

[0040] Figure 4 is a schematic diagram of main modules of a request processing device according to an embodiment of the present invention;

[0041] Figure 5 is an exemplary system architecture diagram to which embodiments of the present invention may be applied;

[0042] Figure 6 It is a schematic diagram of the structure of a computer system of a mobile device or a server suitable for implementing an embodiment of the present invention. DETAILED DESCRIPTION

[0043] The following is a description of exemplary embodiments of the present invention in conjunction with the accompanying drawings, including various details of the embodiments of the present invention to facilitate understanding, which should be considered as merely exemplary. Therefore, it should be recognized by those of ordinary skill in the art that various changes and modifications may be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for clarity and conciseness, the description of well-known functions and structures is omitted in the following description.

[0044] It should be noted that the embodiments of the present invention are mainly applicable to Nginx (using Nginx at the access layer is currently a more mainstream solution), and implement distributed lock pre-positioning based on some of its existing mechanisms. Among them, Nginx (engine x) is a high-performance HTTP and reverse proxy web server, which has the characteristics of small memory usage, strong concurrency, and rich functions.

[0045] See also Figure 1 , which shows a main flow chart of a request processing method provided by an embodiment of the present invention, including the following steps:

[0046] S101: The access layer receives a request to be processed, determines a calling method corresponding to the request, and obtains a distributed lock key name corresponding to the calling method;

[0047] S102: Determine a service node corresponding to the distributed lock key name, and distribute the request to the service node; wherein the service node is located in the access layer;

[0048] S103: Lock the request through the service node to forward the request to the application corresponding to the service node for processing.

[0049] In the above implementation, for step S101, the request sent by the user at the client will reach the request access layer. After receiving the user request, the access layer will first determine the calling method corresponding to the request.

[0050] Each application needs to support multiple functions, and each function is a request. For example, entertainment applications support user login, video playback, commenting, liking, forwarding, downloading and other functions. Every time a user uses a function, the client needs to issue a request to call the method corresponding to the function, that is, the URL address (Uniform Resource Locator), which corresponds to a piece of business code.

[0051] Some requests require locking, while others do not. Requests from different users that use the same function and do not affect each other do not require locking, such as obtaining a friend list; however, requests that may have an impact require locking, such as requests to accumulate likes. If it is determined that distributed lock processing is not required, the request is forwarded to the Java application according to the normal load balancing configuration.

[0052] The specific judgment method is to predetermine which requests need to be locked and set the corresponding relationship between their calling methods and distributed lock configuration information. If the query has corresponding distributed lock configuration information, it means that the request needs to be locked, and then the distributed lock key in the distributed lock configuration information is extracted.

[0053] For step S102, if the current request needs to be processed by distributed lock, the following operations are performed: the key of the distributed lock is in the format of $url?$arg, and consistent hash scheduling can be performed between corresponding Nginx clusters according to the key to ensure that requests with the same distributed lock key are distributed to the same Nginx node.

[0054] Nginx has various load balancing strategies, such as polling, consistent hashing, etc., which can be configured according to actual conditions. The present invention uses consistent hashing scheduling.

[0055] For step S103, the Nginx node starts the local lock through the lua-resty-lock function provided by OpenResty. When the local lock is acquired, the request is forwarded to the corresponding Java application for processing, so that only one Java application is executed at the same time, solving the problem of distributed concurrency.

[0056] However, if the local lock is not acquired through lua-resty-lock, ngx.sleep in ngx_lua is called to make the coroutine sleep for a certain period of time (for example, a few milliseconds) and then retry. If the retry time exceeds a certain period, an http 504 timeout error is returned to the client.

[0057] Among them, OpenResty is a high-performance Web platform based on Nginx and Lua. It integrates a large number of sophisticated Lua libraries, third-party modules, and most dependencies. Therefore, the local lock function of Nginx can be implemented by using the lua-resty-lock provided by it.

[0058] lua-resty-lock is a blocking lock based on Nginx shared memory (ngx.shared.DICT) (implemented based on Nginx time events), and will not block Nginx worker processes. When a request obtains the lock, subsequent attempts to obtain the lock for the key again will be blocked here, but other requests will not be blocked. When the first request to obtain the lock updates the obtained data to the cache, subsequent requests will no longer return to the source backend application, thereby protecting the backend application.

[0059] After the Java application completes processing the request, the Nginx node releases the local lock after receiving the information that the request has been processed, so that other requests can continue to grab the lock.

[0060] The method provided in the above embodiment realizes distributed lock control by combining consistent hashing with local locks. Consistent hash scheduling ensures that requests for the same distributed lock key are sent to the same Nginx node. The local lock can only determine whether there is a lock for this key on the current Nginx node without considering other Nginx nodes, so that only one Java application can execute operations on the request at the same time.

[0061] See also Figure 2 , shows a schematic flow chart of an optional request processing method according to an embodiment of the present invention, comprising the following steps:

[0062] S201: receiving a distributed lock configuration request in a distributed lock configuration center, and obtaining distributed lock configuration information; wherein the distributed lock configuration information includes a distributed lock key name, a lock duration, and a lock waiting timeout duration;

[0063] S202: Determine an access layer corresponding to the distributed lock configuration information, and distribute the distributed lock configuration information to the determined access layer;

[0064] S203: The access layer receives the request to be processed, determines the calling method corresponding to the request, and obtains the distributed lock key name corresponding to the calling method;

[0065] S204: Determine a service node corresponding to the distributed lock key name, and distribute the request to the service node; wherein the service node is located in the access layer;

[0066] S205: Lock the request through the service node to forward the request to the application corresponding to the service node for processing.

[0067] In the above embodiment, for steps S203 to S205, see Figure 1 The description of steps S101 to S103 is not repeated here.

[0068] In the above implementation, for steps S201 and S202, firstly, the distributed lock information is configured in the distributed lock configuration center, and a distributed lock configuration information is set for each business that needs to be locked (which can be selected by the developer), specifically including:

[0069] Table 1 Distributed lock configuration information

[0070]

[0071]

[0072] Among them, the lock time is used to indicate that after the request obtains the local lock, if it is not released within the set time (lock_time), the lock will be automatically released; and the lock waiting timeout time indicates the timeout time that the request waits for to obtain the local lock. If the lock is still not obtained within this time, a 504 timeout is returned.

[0073] Traditional distributed locks generally require configuration of lock time and timeout time to avoid service abnormalities entering deadlock and other situations, resulting in all requests being unable to obtain responses for a long time.

[0074] After the distributed lock configuration is completed for each business, the configured information will be sent to each ngx_lua request access layer. For details, see Figure 3 Among them, the server directly connected to the client is usually called an access server, and one or more access servers constitute the access layer.

[0075] The access layer has the following functions:

[0076] 1) Maintain the network connection with the client and manage the client's network status;

[0077] 2) Receive client requests and forward the requests to the business layer, as well as forward the data sent by the business layer to the client;

[0078] 3) Local access, load balancing, and optimized network experience.

[0079] It should be noted that for systems with a single function, few users, and low concurrency, the access layer and the business layer can be selectively merged. However, for complex systems, the merger of the two will inevitably lead to the complication of the code of a certain business module, so the two are usually made independent.

[0080] In the prior art, only the access layer is provided, and no distributed lock configuration is provided. In addition, only some forwarding rules are usually configured in the access layer, and most existing applications are deployed in this way.

[0081] The method provided in the above embodiment pre-sets the distributed lock configuration and distributes it to each access layer, so as to directly implement the distributed lock logic in the access layer without embedding the distributed lock logic in the business code.

[0082] See also Figure 4 , which shows a schematic diagram of main modules of a request processing device 400 provided in an embodiment of the present invention, including:

[0083] The request receiving module 401 is used for the access layer to receive the request to be processed, determine the calling device corresponding to the request, and obtain the distributed lock key name corresponding to the calling device;

[0084] A node determination module 402 is used to determine a service node corresponding to the distributed lock key name and distribute the request to the service node; wherein the service node is located in the access layer;

[0085] The locking processing module 403 is used to lock the request through the service node to forward the request to the application corresponding to the service node for processing.

[0086] The implementation device of the present invention further includes an information configuration module 404 (not shown in the figure), which is used to:

[0087] Receive a distributed lock configuration request in a distributed lock configuration center to obtain distributed lock configuration information; wherein the distributed lock configuration information includes a distributed lock key name, a lock duration, and a lock wait timeout duration;

[0088] An access layer corresponding to the distributed lock configuration information is determined to distribute the distributed lock configuration information to the determined access layer.

[0089] In the implementation device of the present invention, the node determination module 402 is used to:

[0090] A service node cluster corresponding to the distributed lock key name is determined, and consistent hash scheduling is performed on the service node cluster to obtain a service node that processes the request.

[0091] In the implementation device of the present invention, the locking processing module 403 is used to:

[0092] The service node starts the local lock in a blocking lock mode to only lock the request;

[0093] The service node receives the request processing completion information fed back by the application, and releases the local lock.

[0094] In addition, the specific implementation content of the device described in the embodiment of the present invention has been described in detail in the method described above, so the repeated content will not be described again here.

[0095] Figure 5 An exemplary system architecture 500 is shown in which embodiments of the present invention may be applied.

[0096] like Figure 5 As shown, the system architecture 500 may include terminal devices 501, 502, 503, a network 504 and a server 505 (just an example). The network 504 is used to provide a medium for communication links between the terminal devices 501, 502, 503 and the server 505. The network 504 may include various connection types, such as wired, wireless communication links or optical fiber cables, etc.

[0097] The user can use the terminal devices 501, 502, 503 to interact with the server 505 through the network 504 to receive or send messages, etc. Various communication client applications can be installed on the terminal devices 501, 502, 503.

[0098] The terminal devices 501 , 502 , and 503 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop computers, desktop computers, and the like.

[0099] The server 505 may be a server that provides various services, such as a background management server that provides support for shopping websites browsed by users using the terminal devices 501 , 502 , and 503 (only as an example).

[0100] It should be noted that the method provided in the embodiment of the present invention is generally executed by the server 505 , and accordingly, the device is generally set in the server 505 .

[0101] It should be understood that Figure 5The number of terminal devices, networks and servers in the embodiment is only for illustration. Any number of terminal devices, networks and servers may be provided according to implementation requirements.

[0102] Reference below Figure 6 , which shows a schematic diagram of the structure of a computer system 600 of a terminal device suitable for implementing an embodiment of the present invention. Figure 6 The terminal device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present invention.

[0103] like Figure 6 As shown, the computer system 600 includes a central processing unit (CPU) 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage part 608 into a random access memory (RAM) 603. In the RAM 603, various programs and data required for the operation of the system 600 are also stored. The CPU 601, the ROM 602, and the RAM 603 are connected to each other via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0104] The following components are connected to the I / O interface 605: an input section 606 including a keyboard, a mouse, etc.; an output section 607 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN card, a modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the I / O interface 605 as needed. A removable medium 611, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 610 as needed, so that a computer program read therefrom is installed into the storage section 608 as needed.

[0105] In particular, according to the embodiments disclosed in the present invention, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present invention include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 609, and / or installed from the removable medium 611. When the computer program is executed by the central processing unit (CPU) 601, the above-mentioned functions defined in the system of the present invention are executed.

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

[0107] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present invention. In this regard, each box in the flow chart or block diagram can represent a module, a program segment, or a part of a code, and the above-mentioned module, program segment, or a part of a code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flow chart, and the combination of the boxes in the block diagram or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0108] The modules involved in the embodiments of the present invention may be implemented by software or hardware. The modules described may also be set in a processor. For example, they may be described as follows: a processor includes a receiving module, a determining module, and an acquiring module. The names of these modules do not, in some cases, limit the modules themselves. For example, the acquiring module may also be described as a "data acquisition module".

[0109] As another aspect, the present invention further provides a computer-readable medium, which may be included in the device described in the above embodiment; or may exist independently without being assembled into the device. The above computer-readable medium carries one or more programs, and when the above one or more programs are executed by a device, the device includes:

[0110] The access layer receives the request to be processed, determines the calling method corresponding to the request, and obtains the distributed lock key name corresponding to the calling method;

[0111] Determine a service node corresponding to the distributed lock key name, and distribute the request to the service node; wherein the service node is located in the access layer;

[0112] The request is locked by the service node so as to forward the request to the application corresponding to the service node for processing.

[0113] According to the technical solution of the embodiment of the present invention, distributed lock control is implemented by combining consistent hashing with local locks. Consistent hash scheduling ensures that requests for the same distributed lock key are sent to the same Nginx node. The local lock can only determine whether there is a lock for this key on the current Nginx node without considering other Nginx nodes, so that only one Java application can perform operations on the request at the same time.

[0114] The above specific implementations do not constitute a limitation on the protection scope of the present invention. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions may occur depending on design requirements and other factors. Any modification, equivalent substitution and improvement made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. A request processing method, characterized in that: include: The access layer receives a request to be processed, determines a calling method corresponding to the request, and obtains a distributed lock key name corresponding to the calling method, including: if the query has distributed lock configuration information corresponding to the calling method, determines that the request needs to be processed by distributed lock, and extracts the distributed lock key name in the distributed lock configuration information; wherein, the request that needs to be locked is determined, and the corresponding relationship between the calling method of the request and the distributed lock configuration information is set; Determine a service node corresponding to the distributed lock key name, and distribute the request to the service node; wherein the service node is located in the access layer; The request is locked by the service node to forward the request to the application corresponding to the service node for processing; wherein the service node starts a local lock, and when the local lock is acquired, the request is forwarded to the application for processing, so that only one application is executed at the same time.

2. The method according to claim 1, characterized in that Before the access layer receives the request to be processed, the method further includes: Receive a distributed lock configuration request in a distributed lock configuration center to obtain distributed lock configuration information; wherein the distributed lock configuration information includes a distributed lock key name, a lock duration, and a lock wait timeout duration; An access layer corresponding to the distributed lock configuration information is determined to distribute the distributed lock configuration information to the determined access layer.

3. The method according to claim 1, characterized in that The determining of the service node corresponding to the distributed lock key name includes: A service node cluster corresponding to the distributed lock key name is determined, and consistent hash scheduling is performed on the service node cluster to obtain a service node that processes the request.

4. The method according to claim 1, characterized in that: The locking process of the request by the service node includes: The service node starts the local lock in a blocking lock mode to only lock the request; After forwarding the request to the application corresponding to the service node for request processing, the method further includes: The service node receives the request processing completion information fed back by the application, and releases the local lock.

5. A request processing device, characterized in that: include: A request receiving module, used for receiving a request to be processed at the access layer, determining a calling device corresponding to the request, and obtaining a distributed lock key name corresponding to the calling device, including: if the query has distributed lock configuration information corresponding to the calling method, determining that the request needs to be processed by distributed lock, and extracting the distributed lock key name in the distributed lock configuration information; wherein, determining a request that needs to be processed by locking, and setting a corresponding relationship between the calling method of the request and the distributed lock configuration information; A node determination module, used to determine a service node corresponding to the distributed lock key name, and distribute the request to the service node; wherein the service node is located in the access layer; A lock processing module is used to lock the request through the service node so as to forward the request to the application corresponding to the service node for processing; wherein the service node starts a local lock, and when the local lock is acquired, the request is forwarded to the application for processing so that only one application is executed at the same time.

6. The device according to claim 5, characterized in that It also includes an information configuration module for: Receive a distributed lock configuration request in a distributed lock configuration center to obtain distributed lock configuration information; wherein the distributed lock configuration information includes a distributed lock key name, a lock duration, and a lock wait timeout duration; An access layer corresponding to the distributed lock configuration information is determined to distribute the distributed lock configuration information to the determined access layer.

7. The device according to claim 5, characterized in that The node determination module is used to: A service node cluster corresponding to the distributed lock key name is determined, and consistent hash scheduling is performed on the service node cluster to obtain a service node that processes the request.

8. The device according to claim 5, characterized in that The locking processing module is used to: The service node starts a local lock in a blocking lock mode to perform locking control only on the request; and The service node receives the request processing completion information fed back by the application, and releases the local lock.

9. An electronic device, characterized in that: include: one or more processors; a storage device for storing one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1 to 4.

10. A computer readable medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method according to any one of claims 1 to 4 is implemented.

Images