Business processing method and apparatus in distributed system and distributed system

Abstract

This application provides a business processing method, apparatus, and distributed system in a distributed system. The method, upon detecting a business request containing a lock annotation tag in a distributed concurrency lock annotation, requests a lock from the lock manager to lock the target shared resource corresponding to the target business, enabling precise control of the shared resource. When it is determined that the lock manager has already locked the target shared resource, the method triggers the controller to execute the target business and monitors the execution information. When the execution information meets preset lock release conditions, the method triggers the lock manager to release the lock on the target shared resource, ensuring that the distributed concurrency lock is released promptly. The execution information is then fed back to the user through the gateway. This method achieves unified management of the acquisition and release of distributed concurrency locks, simplifies system code, and improves system performance.

Description

Technical Field

[0001] This application relates to the field of distributed concurrent lock technology, and more specifically, to a business processing method, apparatus, and distributed system in a distributed system. Background Technology

[0002] As distributed systems become the preferred choice for big data processing, high-availability services, and complex business logic, concurrency control has become a critical challenge, especially the deadlock problem caused by distributed locks. Deadlock leads to resource contention between nodes, causing system performance degradation or even crashes, affecting stability and availability.

[0003] However, existing technologies require additional lock management code to be written in the code to eliminate the risk of deadlock. This not only makes the code more complex, but may also have an adverse impact on the original business. Summary of the Invention

[0004] The purpose of this application is to provide a business processing method, apparatus and distributed system in a distributed system, which simplifies the system code and improves the system's operating performance while ensuring the original business logic and mitigating the risk of deadlock.

[0005] In a first aspect, embodiments of this application provide a business processing method in a distributed system, applied to an interceptor between a gateway and a controller in the distributed system. The interceptor is implemented based on AOP (Aspect-Oriented Programming) technology. The method includes: checking whether a business request to be processed contains a lock annotation tag with a distributed concurrency lock annotation; wherein the business request is initiated by a user and sent to the controller after passing through the gateway; the lock annotation tag indicates that the target business corresponding to the business request needs to access shared resources in the distributed system, and the shared resources in the distributed system are all managed by a lock manager; if so, requesting the lock manager to lock the target shared resource corresponding to the target business; wherein the lock manager locks the target shared resource when it is in an unlocked state; when it is determined that the lock manager has locked the target shared resource for the user, triggering the controller to execute the target business and monitoring the execution information of the controller executing the target business; when the execution information meets a preset lock release condition, triggering the lock manager to release the lock on the target shared resource and feeding back the execution information to the user through the gateway.

[0006] In one possible implementation, requesting the lock manager to lock the target shared resource corresponding to the target service for a user includes: sending a first request to the lock manager for the user to lock the target shared resource corresponding to the target service; and when the lock manager returns a first response indicating that the target shared resource has been successfully locked based on the first request, it is determined that the lock manager has locked the target shared resource for the user.

[0007] In one possible implementation, before requesting the lock manager to lock the target shared resource corresponding to the target service for the user, the method further includes: sending a verification request to the lock manager to check whether the target shared resource corresponding to the target service is in a locked state; when receiving a verification response from the lock manager that the target shared resource is in an unlocked state, performing the step of requesting the lock manager to lock the target shared resource corresponding to the target service for the user.

[0008] In one possible implementation, the distributed concurrent lock annotation also includes a custom polling count, polling timeout, and polling interval. The method further includes: when receiving a verification response from the lock manager indicating that the target service is in a locked state, sending the verification request to the lock manager multiple times according to the polling interval; if the number of verification requests sent exceeds the polling count, and / or if the duration of the multiple verification requests exceeds the polling timeout, then feeding back the information that the target service is in a locked state to the user through the gateway.

[0009] In one possible implementation, triggering the lock manager to release the lock on the target shared resource when the execution information meets the preset lock release conditions includes: if the execution information meets the condition that the business processing of the target business has been completed, then sending a second request to the lock manager to release the lock for the target business, thereby triggering the lock manager to release the lock on the target shared resource.

[0010] In one possible implementation, the distributed concurrent lock annotation also includes the validity period of the distributed concurrent lock, and the execution information includes the execution duration; when the execution information meets the preset lock release conditions, triggering the lock manager to release the lock on the target shared resource includes: if the execution duration is longer than the validity period of the distributed concurrent lock, then sending a second request to the lock manager to release the lock for the target business, so as to trigger the lock manager to release the lock on the target shared resource.

[0011] In one possible implementation, the above method further includes: intercepting business requests sent by users; if the resource corresponding to the business request is a shared resource, setting a distributed concurrency lock annotation in the business request, and storing the business request containing the distributed concurrency lock annotation in a business waiting pool; wherein, the distributed concurrency lock annotation includes an unlock annotation tag; if the resource corresponding to the business request is not a shared resource, then storing the business request in the business waiting pool; and determining the business request to be processed at the current moment from the business waiting pool.

[0012] Secondly, embodiments of this application provide a business processing device in a distributed system, applied to an interceptor between a gateway and a controller in the distributed system. The interceptor is implemented based on AOP (Aspect-Oriented Programming) technology. The device may include: a checking unit, used to check whether a business request to be processed contains a lock annotation tag with a distributed concurrency lock annotation; wherein the business request is initiated by a user and sent to the controller after passing through the gateway; the lock annotation tag indicates that the target business corresponding to the business request needs to access shared resources in the distributed system, and the shared resources in the distributed system are all managed by a lock manager; an application unit, used to apply to the lock manager to lock the target shared resource corresponding to the target business when the checking result of the checking unit is yes; wherein the lock manager locks the target shared resource when it is in an unlocked state; a triggering unit, used to trigger the controller to execute the target business when it is determined that the lock manager has locked the target shared resource for the user, and to monitor the execution information of the controller executing the target business; and, when the execution information meets a preset lock release condition, to trigger the lock manager to release the lock on the target shared resource, and to feed back the execution information to the user through the gateway.

[0013] Thirdly, embodiments of this application provide a distributed system, which includes: a gateway, a controller, and an interceptor between the gateway and the controller; the interceptor is implemented based on AOP (Aspect-Oriented Programming) technology; the gateway is used to receive and forward service requests sent by users; and to receive and forward execution information of the target service corresponding to the service request fed back by the interceptor to the corresponding user; the interceptor is used to execute the service processing method in the distributed system of the first aspect; the controller is used to execute the target service corresponding to the service request under the triggering of the interceptor.

[0014] Fourthly, embodiments of this application provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement any of the method steps described in the first aspect above.

[0015] Fifthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements any of the steps described in the first aspect above.

[0016] In a sixth aspect, embodiments of this application provide a computer program product comprising a computer program that, when executed by a processor, implements any of the steps described in the first aspect above.

[0017] The business processing method, apparatus, and distributed system provided in this application embodiment check whether the business request to be processed contains the lock annotation tag in the distributed concurrency lock annotation. This allows the interceptor to distinguish whether the business request to be processed needs to access shared resources. If the lock annotation tag is included, the target shared resource that the target business corresponding to the business request needs to access is the target shared resource. The interceptor then requests the lock manager to lock the target shared resource corresponding to the business request. The lock manager responds to the request and locks the target shared resource when it is in an unlocked state. When it is determined that the lock manager has locked the target shared resource for the user, the controller is triggered to execute the target business. This locking method and the timing of triggering the controller to execute the business can ensure that the business execution process of other users is not interrupted when the target shared resource is locked by other users' businesses, thus ensuring the integrity of the business processing corresponding to the shared resource and reducing the probability of deadlock. By monitoring the execution information of the controller executing the target business, when the execution information meets the preset lock release conditions, the lock manager is triggered to release the lock on the target shared resource corresponding to the target business, thereby ensuring that the lock corresponding to the target shared resource is released in a timely manner, fully guaranteeing the timeliness of resource access in the distributed system. The above method achieves unified management of the acquisition and release of distributed concurrent locks. By using AOP technology, it is not necessary to write additional lock management code for each business. While ensuring the original business logic and mitigating the risk of deadlock, it simplifies the system code and improves the system's operating performance. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This application provides a schematic diagram of the structure of a distributed system according to an embodiment of the present application.

[0020] Figure 2 A flowchart illustrating a business processing method in a distributed system provided in an embodiment of this application;

[0021] Figure 3 A flowchart illustrating another business processing method in a distributed system provided in this application embodiment;

[0022] Figure 4 A schematic diagram of the structure of a service processing device in a distributed system provided in this application embodiment;

[0023] Figure 5 This is a schematic diagram of the business processing of a distributed system provided in an embodiment of this application. Detailed Implementation

[0024] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application. Unless otherwise defined, the technical or scientific terms used in this application should have the ordinary meaning understood by those skilled in the art. The terms "first," "second," and similar terms used in this application do not indicate any order, quantity, or importance, but are only used to distinguish different components. The terms "comprising" or "including," etc., mean that the element or object preceding the word covers the element or object listed after the word and its equivalents.

[0025] For ease of understanding, the terms used in the embodiments of this application are explained below:

[0026] Aspect: A core concept in AOP (Aspect-Oriented Programming), used to modularize cross-cutting concerns and enhance or modify program behavior without modifying the original code through predefined patterns.

[0027] Note: As Java metadata, it provides additional descriptions for the code, supports runtime or compile-time reading and processing, and is often combined with aspects to achieve efficient programming.

[0028] Distributed concurrent locks: A synchronization mechanism in a distributed system used to control access to shared resources by multiple threads, ensuring data consistency and integrity.

[0029] Shared resources refer to resources that can be accessed simultaneously by multiple threads or processes in a multi-threaded or multi-process environment. Synchronization mechanisms are required to avoid data conflicts.

[0030] Figure 1 This is a schematic diagram of the structure of a distributed system provided in an embodiment of this application. Figure 1 As shown, the system may include: a gateway 11, a controller 12, an interceptor 13 and a lock manager 14 located between the gateway 11 and the controller 12, and a storage device 15 for storing the resources of the distributed system. The devices interact with each other through communication connections.

[0031] Gateway 11 acts as a bridge device for users (also known as user terminals, terminal devices, or user equipment) to access the distributed system. It is used to receive and forward interactive information between users and the distributed system, such as service requests sent by users and the processing results of the distributed system for those service requests.

[0032] Controller 12 is used to execute the business corresponding to the business request.

[0033] Interceptor 13 is implemented based on AOP technology. It can intercept business requests from various users and determine the type of resource accessed by the request based on the destination address in each request. If the accessed resource is a shared resource, a distributed concurrency lock annotation is added to the request; if the accessed resource is a non-shared resource, no lock annotation is added. The distributed concurrency lock annotation indicates that the target business corresponding to the request needs to access a shared resource in the distributed system.

[0034] In practical implementation, distributed concurrent lock annotations can include not only lock annotation tags, but also other information for controlling the behavior of distributed concurrent locks, depending on the actual application scenario. This includes information such as the number of polling times, polling timeout time, polling interval, and the validity period of the distributed concurrent lock (or "duration for releasing the distributed concurrent lock").

[0035] The lock manager 14 is used to lock and unlock the shared resources in the aforementioned memory 15.

[0036] The interceptor 13 can interact with the lock manager 14 to lock and unlock shared resources at appropriate times. The interceptor 13 can also interact with the controller 12 to control the timing of business execution and monitor the progress of business execution.

[0037] This embodiment provides a business processing method in a distributed system. The method is illustrated using an interceptor applied to the aforementioned distributed system as an example. Figure 2 As shown, the method may include the following steps:

[0038] Step S210: Check whether the business request to be processed contains a lock annotation tag with a distributed concurrent lock annotation.

[0039] The service request is initiated by the user and sent to the controller via the gateway; the lock annotation tag indicates that the target service corresponding to the service request needs to access shared resources in the distributed system, and the shared resources in the distributed system are all managed by the lock manager.

[0040] In this embodiment, business requests from different users or different business requests from the same user can be obtained by the interceptor after being forwarded by the gateway. That is, these business requests are intercepted by the interceptor before reaching the controller. For a distributed system, there may be multiple different business requests waiting to be processed at the same time. The business requests to be processed can be determined according to the order in which they are received or according to the urgency of the business corresponding to each business request. The specific method for determining the business requests to be processed can be referred to relevant technologies, which will not be elaborated here.

[0041] Step S220: When it is detected that the pending business request contains a lock annotation tag, request the lock manager to lock the target shared resource corresponding to the target business for that user.

[0042] The lock manager locks the target shared resource when it is in an unlocked state.

[0043] In this embodiment, the lock manager is a component in a distributed system used to manage and coordinate access to shared resources by multiple processes or threads. When an interceptor detects that a pending business request contains a lock annotation, it indicates that the target business corresponding to the request needs to access a shared resource in the distributed system. The interceptor can request the lock manager to lock the target shared resource for that user, ensuring that only the process or thread with that business request can access the target shared resource at any given time. After receiving the lock request from the interceptor, the lock manager checks whether the target shared resource is in an unlocked state. If the target shared resource is found to be unlocked, the lock manager locks the target shared resource. After successful locking, the lock status of the target shared resource is updated to "locked," thus allowing only the process or thread with that business request to obtain exclusive access to the target shared resource. This avoids competition for the shared resource by multiple other processes or threads, ensuring the stability and concurrency of the distributed system.

[0044] If the target shared resource is detected to be in a locked state, it indicates that the target shared resource has been occupied by other business requests. At this time, the lock manager can send a locking failure indication message to the interceptor, so that the interceptor can send a business request failure indication message to the user through the gateway. This indication message may include the existence of the same business request being executed.

[0045] Step S230: When it is determined that the lock manager has locked the target shared resource for the user, the controller is triggered to execute the target service, and the execution information of the controller executing the target service is monitored.

[0046] In this embodiment, after the interceptor determines that the lock manager has successfully locked the target shared resource, it can send a service request to the controller to execute the target service, thereby triggering the controller to execute the target service.

[0047] During the execution of the target business by the controller, the interceptor can monitor the execution status of the target business in real time. According to the order of monitoring time, it can obtain the execution information monitored at different monitoring time points. This execution information can include execution duration, execution status (such as success, failure, exception, etc.).

[0048] Step S240: When the execution information meets the preset lock release conditions, the lock manager is triggered to release the lock on the target shared resource and the execution information is fed back to the user through the gateway.

[0049] In this embodiment, the preset lock release conditions can be set according to the execution status of the service. After obtaining the execution information monitored at each monitoring time point, the interceptor needs to verify whether the execution information meets the preset lock release conditions. When the execution information meets the preset lock release conditions, the interceptor can trigger the lock manager to release the lock on the target shared resource, and then feed back the execution information to the user through the gateway. When the execution information does not meet the preset lock release conditions, the interceptor needs to continue monitoring the execution status of the target service executed by the controller, obtain the execution information at the next adjacent monitoring time point, and return to the step of verifying whether the execution information meets the preset lock release conditions, until the obtained execution information meets the preset lock release conditions.

[0050] The business processing method in the distributed system provided in this application embodiment checks whether the business request to be processed contains the lock annotation tag in the distributed concurrency lock annotation. This allows the interceptor to distinguish whether the business request to be processed needs to access shared resources. If the lock annotation tag is included, the target shared resource that the target business corresponding to the business request needs to access is the target shared resource. The interceptor then requests the lock manager to lock the target shared resource corresponding to the business request. The lock manager responds to the request and locks the target shared resource when it is in an unlocked state. When it is determined that the lock manager has locked the target shared resource for the user, the controller is triggered to execute the target business. This locking method and the timing of triggering the controller to execute the business can ensure that the business execution process of other users is not interrupted when the target shared resource is locked by other users' businesses, thus ensuring the integrity of the business processing corresponding to the shared resource and reducing the probability of deadlock. By monitoring the execution information of the controller executing the target business, when the execution information meets the preset lock release conditions, the lock manager is triggered to release the lock on the target shared resource corresponding to the target business, thereby ensuring that the lock corresponding to the target shared resource is released in a timely manner, fully guaranteeing the timeliness of resource access in the distributed system. The above method achieves unified management of the acquisition and release of distributed concurrent locks. By using AOP technology, it is not necessary to write additional lock management code for each business. While ensuring the original business logic and mitigating the risk of deadlock, it simplifies the system code and improves the system's operating performance.

[0051] As one possible implementation, to avoid service processing stagnation caused by multiple different services accessing the same shared resource simultaneously, this embodiment employs a locking and unlocking mechanism for shared resources. The lock manager locks the target shared resource corresponding to the target service when it is unlocked. If the target shared resource is already locked, other requests for that target shared resource must wait. Therefore, before executing the step of requesting the lock manager to lock the target shared resource corresponding to the target service for that user, the method further includes: the interceptor can send a verification request to the lock manager to check whether the target shared resource corresponding to the target service is locked; when receiving a verification response from the lock manager indicating that the target service is unlocked, the method executes the step of requesting the lock manager to lock the target shared resource corresponding to the target service for that user. By verifying whether the shared resource is locked in advance, some services that do not need to acquire a lock can skip the locking process, avoiding the waiting time caused by attempting to acquire a lock.

[0052] As one possible implementation, the step of requesting the lock manager to lock the target shared resource corresponding to the target service for the user can include: the interceptor can send a first request to the lock manager to lock the target shared resource for the user; when the lock manager returns a first response indicating that the lock has successfully locked the target shared resource based on the first request, it is determined that the lock manager has locked the target shared resource corresponding to the target service for the user. By sending the first request, the lock manager can be effectively notified that the target service corresponding to the user needs to access the target shared resource. When the first response is received, it can be clearly stated that the lock manager has locked the target shared resource for the user, thus enhancing the simplicity and reliability of the interaction between the two parties.

[0053] As one possible implementation, the distributed concurrent lock annotation can also include custom polling count, polling timeout, and polling interval. When a target shared resource is detected to be in a locked state, it indicates that the target shared resource has been occupied by other business requests. At this time, the lock manager can also start a pre-configured polling mechanism to acquire the distributed concurrent lock. The parameters involved in the polling mechanism include: polling count, polling timeout, and polling interval. The polling count is the maximum number of polls; the polling timeout is the total duration for acquiring the distributed concurrent lock; and the polling interval is the interval between each poll to acquire the distributed concurrent lock. Correspondingly, the above method also includes: when receiving a verification response from the lock manager indicating that the target shared resource corresponding to the target business is in a locked state, sending multiple verification requests to the lock manager according to the polling interval; if the number of verification requests sent exceeds the polling count, and / or, if the duration of multiple verification requests exceeds the polling timeout, then feeding back the information that the target shared resource corresponding to the target business is in a locked state to the user through the gateway.

[0054] In the above implementation, the polling mechanism can repeatedly check the locking status of the target shared resource in a short period of time. Once the lock of the target shared resource is released, it can be acquired immediately, improving the response speed of lock acquisition. Simultaneously, setting the number of polling attempts can prevent business requests that have not acquired the distributed concurrent lock from polling indefinitely, thus avoiding network resource occupation; setting the polling timeout can prevent business requests that cannot acquire the distributed concurrent lock from polling continuously, leading to deadlock; and setting the polling interval can effectively reduce frequent requests to the lock acquisition service, preventing the interceptor from getting stuck due to excessively fast polling.

[0055] As one possible implementation, the aforementioned preset lock release condition can be a condition set based on the execution status of the service, indicating that the service processing is complete, or a condition set based on the execution duration of the service, indicating that the service processing time is too long. The condition for service completion can include conditions where the service execution status is successful and conditions where the service execution status is failed. The condition for excessively long service processing time refers to a condition where the service execution duration exceeds the normal execution duration of the service's code.

[0056] Therefore, when the execution information meets the preset lock release conditions, the steps to trigger the lock manager to release the lock on the target shared resource can include the following:

[0057] Method 1: Check the execution status in the execution information. If the execution status in the execution information is detected as successful or failed, it indicates that the execution information meets the condition of business processing completion in the preset lock release conditions. At this time, send a second request to the lock manager to release the lock for the target business, so as to trigger the lock manager to release the lock for the target business.

[0058] This approach ensures that the distributed concurrent lock is released in a timely manner after the business process is completed, regardless of whether the business process is successful or not, effectively reducing the risk of deadlock caused by omissions or abnormal business processing.

[0059] Method 2: The distributed concurrent lock annotation can include the validity period of the distributed concurrent lock, which represents the maximum duration of business processing. In specific implementation, the execution duration is obtained from the execution information; if the execution duration is greater than the validity period of the distributed concurrent lock, a second request to release the lock for the target business is sent to the lock manager to trigger the lock manager to release the lock for the target business.

[0060] This approach can handle extreme situations such as system crashes, ensuring that locks are automatically reclaimed after expiration even in such circumstances, thus effectively preventing deadlocks caused by abnormal release of distributed locks. As long as the execution duration is longer than the validity period, the distributed concurrent lock can be released, effectively preventing deadlocks, significantly improving system stability and security, and ensuring the normal processing of subsequent business requests.

[0061] As one possible implementation, the validity period in the distributed concurrent lock annotation can be a predefined fixed execution duration. However, since the processing time of different business operations varies—for example, the execution time for reading data from a log file may differ from the execution time for writing data to that log file—different execution validity periods can be configured according to different business operations to obtain a mapping table between different business operations and different execution validity periods. This execution validity period can be no less than the normal execution time of the corresponding business code. For example, if the normal execution time of business code A is 5ms, then the execution validity period configured for business A can be 5ms or 6ms.

[0062] In practice, the target execution validity period corresponding to the business request can be determined based on the mapping table of different services and different execution validity periods. The original validity period of the distributed concurrent lock in the distributed concurrent lock annotation is updated with the target execution validity period to obtain the validity period in the distributed concurrent lock annotation corresponding to the business request.

[0063] Furthermore, the impact of controller processing resources on business processing can be considered to adjust the mapping relationship between different businesses and different execution validity periods in the mapping table. Specifically, under different controller available resources, the execution duration of different businesses in historical time periods can be obtained. For example, within a historical time period, the execution duration of business A, business B, and business C can be obtained when the controller's available resources are 20%, 30%, 50%, 70%, and 100% of all resources. This data can then be used as training samples to train the regression analysis model to obtain a trained execution validity period model. The trained execution validity period model is used to describe the relationship between the execution duration of different businesses and changes in available resources. The regression analysis model to be trained can be a linear regression model, decision tree regression, random forest regression, or support vector regression, etc.

[0064] To manage business requests more systematically, the method further includes: intercepting user-sent business requests; if the resource corresponding to the business request is a shared resource, setting a distributed concurrency lock annotation in the business request, and storing the business request containing the distributed concurrency lock annotation in a business waiting pool; if the resource corresponding to the business request is not a shared resource, storing the business request in the business waiting pool; and determining the pending business request at the current moment from the business waiting pool. In this embodiment, the business requests in the business waiting pool can be sorted according to a first-in, first-out (FIFO) principle. In this way, lock annotation tags can be pre-set for business requests involving shared resources, so that subsequent processing can distinguish whether a business request needs to access shared resources, i.e., whether resource locking and unlocking is required, allowing for targeted processing of business requests and optimizing business request management. See also... Figure 3 The flowchart shown is for another type of business processing in a distributed system. This method is illustrated using the above-mentioned interceptor as an example, and includes the following steps:

[0065] Step S310: Intercept the service request sent by the user and check whether the service request needs to access shared resources. If yes, proceed to step S311; if no, proceed to step S312.

[0066] Whether a service request needs to access shared resources can be determined by either the service type identifier corresponding to the service request or by the access address corresponding to the service request. As one possible implementation, in this embodiment, shared and non-shared resources can reside in two different storage areas. The access address corresponding to the service request can determine the storage area to which the resource belongs, thereby determining whether the service request needs to access shared resources.

[0067] Step S311: Set the distributed concurrency lock annotation in the business request, store the business request containing the distributed concurrency lock annotation in the business waiting pool, and then execute step S313.

[0068] In this embodiment, the distributed concurrent lock annotation includes a lock annotation tag; in a specific implementation, the distributed concurrent lock annotation may also include the number of polling times, polling timeout time, polling interval, validity period of the distributed concurrent lock, key parameters of the distributed concurrent lock, etc.

[0069] Step S312: Store the service request in the service waiting pool, and then execute step S313.

[0070] Step S313: Determine the target business request to be processed at the current moment from the business waiting pool.

[0071] Step S314: Check whether the target business request contains a lock annotation tag with a distributed concurrency lock annotation. If yes, proceed to step S315; otherwise, proceed to step S316.

[0072] Step S315: Send a verification request to the lock manager to check whether the target shared resource corresponding to the target service is in a locked state, and then execute step S317.

[0073] Step S316: Trigger the controller to execute the target service corresponding to the target service request.

[0074] Step S317: Receive the verification response returned by the lock manager and check whether the verification response indicates that the target shared resource is in an unlocked state. If yes, proceed to step S318; otherwise, proceed to step S319.

[0075] In this embodiment, the verification response can indicate that the target shared resource is in an unlocked state or that the target shared resource is in a locked state, which means that the target shared resource has been occupied by other service requests.

[0076] Step S318: The user sends a first request to the lock manager to lock the target shared resource corresponding to the target service, and then steps S320 are executed.

[0077] Step S319: Send verification requests to the lock manager multiple times according to the polling time interval, and then return to execute step S317.

[0078] In this embodiment, if the number of verification requests sent exceeds the polling count, and / or if the duration of multiple verification requests exceeds the polling timeout, the return operation can be stopped, and then the information that the target service is in a locked state can be fed back to the user through the gateway.

[0079] Step S320: Receive the first response returned by the lock manager based on the first request, and check whether the first response indicates that the target shared resource has been successfully locked. If yes, proceed to step S321; otherwise, return to step S318.

[0080] In this embodiment, the first response can be interpreted as the target shared resource being successfully locked, indicating that the target shared resource has been occupied by the service request, or it can be interpreted as the target shared resource being locked failing.

[0081] If locking fails, the process can return to the first step of sending the user's request to the lock manager to lock the target shared resource corresponding to the target business. At this point, the number of times the process can be returned can be set according to business requirements to ensure that the target shared resource is locked.

[0082] Step S321: Trigger the controller to execute the target service, monitor the execution information of the controller executing the target service, and then execute step S322.

[0083] Step S322: Monitor whether the execution information meets the preset lock release condition. If yes, proceed to step S323; otherwise, return to step S321.

[0084] Step S323: The lock manager is triggered to release the lock on the target shared resource and the execution information is fed back to the user through the gateway.

[0085] The above method, by checking whether the target business request contains a lock annotation tag with a distributed concurrency lock annotation, can distinguish whether the target business request needs to access shared resources. Therefore, for target business requests that do not need to access shared resources, the controller can directly trigger the execution of the corresponding target business request, thus efficiently handling such requests. For target business requests that need to access shared resources, to avoid business processing exceptions, the aforementioned locking and unlocking processing is applied to the target shared resource corresponding to the target business request. The locking and unlocking timing is triggered by an interceptor, reducing changes to the original business processing logic code, optimizing the locking and unlocking implementation, and facilitating the operation of the distributed system.

[0086] Corresponding to the above method, this application also provides a schematic diagram of the structure of a service processing device in a distributed system, such as... Figure 4 As shown, the device includes:

[0087] The inspection unit 410 is used to check whether the business request to be processed contains a lock annotation tag of distributed concurrency lock annotation; wherein, the business request is initiated by the user and sent to the controller after passing through the gateway; the lock annotation tag indicates that the target business corresponding to the business request needs to access the shared resources in the distributed system, and the shared resources in the distributed system are all managed by the lock manager;

[0088] The application unit 420 is used to apply to the lock manager to lock the target shared resource corresponding to the target service by the user when the check result of the check unit is yes; wherein, the lock manager locks the target shared resource when it is in an unlocked state;

[0089] Triggering unit 430 is used to trigger the controller to execute the target service when it is determined that the lock manager has locked the target shared resource for the user, and to monitor the execution information of the controller executing the target service; and when the execution information meets the preset lock release conditions, to trigger the lock manager to release the lock on the target shared resource, and to feed back the execution information to the user through the gateway.

[0090] The aforementioned device uses an interceptor to check whether the pending business request contains a lock annotation tag in the distributed concurrency lock annotation. This allows the interceptor to distinguish whether the pending business request needs to access a shared resource. If it contains a lock annotation tag, the target shared resource that the business request needs to access is the target shared resource. The interceptor then requests the lock manager to lock the target shared resource corresponding to the business request. The lock manager responds to the request and locks the target shared resource if it is currently unlocked. When it is determined that the lock manager has locked the target shared resource for the user, the controller is triggered to execute the target business. This locking method and the timing of triggering the controller to execute the business ensure that the business execution process of other users is not interrupted when the target shared resource is locked by other users' businesses, thus ensuring the integrity of the business processing corresponding to the shared resource and reducing the probability of deadlock. By monitoring the execution information of the controller executing the target business, when the execution information meets the preset lock release conditions, the lock manager is triggered to release the lock on the target shared resource corresponding to the target business, thereby ensuring that the lock on the target shared resource is released in a timely manner, fully guaranteeing the timeliness of resource access in the distributed system. The above method achieves unified management of the acquisition and release of distributed concurrent locks. By using AOP technology, it is not necessary to write additional lock management code for each business. While ensuring the original business logic and mitigating the risk of deadlock, it simplifies the system code and improves the system's operating performance.

[0091] As one possible implementation, the application unit 420 is specifically used to: send a first request to the lock manager to lock the target shared resource corresponding to the target service; and when it receives a first response from the lock manager indicating that the lock has been successfully locked based on the first request, it determines that the lock manager has locked the target shared resource for the user.

[0092] As one possible implementation, the application unit 420 is further configured to: send a verification request to the lock manager to check whether the target shared resource corresponding to the target service is in a locked state; when receiving a verification response from the lock manager that the target shared resource is in an unlocked state, execute the step of requesting the lock manager to lock the target shared resource corresponding to the target service for the user.

[0093] As one possible implementation, the distributed concurrent lock annotation also includes a custom polling count, polling timeout, and polling interval; the application unit 420 is also used to: when receiving a verification response from the lock manager indicating that the target service is in a locked state, send verification requests to the lock manager multiple times according to the polling interval; if the number of verification requests sent exceeds the polling count, and / or, if the duration of the multiple verification requests exceeds the polling timeout, then feed back the information that the target service is in a locked state to the user through the gateway.

[0094] As one possible implementation, the triggering unit 430 is specifically used to: if the execution information meets the condition that the business processing of the target business has been completed, send a second request to the lock manager to release the lock for the target business, so as to trigger the lock manager to release the lock on the target shared resource.

[0095] As one possible implementation, the distributed concurrent lock annotation also includes the validity period of the distributed concurrent lock, and the execution information includes the execution duration; the triggering unit 430 is also specifically used to: if the execution duration is longer than the validity period of the distributed concurrent lock, send a second request to the lock manager to release the lock for the target business, so as to trigger the lock manager to release the lock on the target shared resource.

[0096] As one possible implementation, the device may further include:

[0097] The interception unit is used to intercept business requests sent by users;

[0098] A storage unit is configured to, if the resource corresponding to the service request is a shared resource, set a distributed concurrency lock annotation in the service request and store the service request containing the distributed concurrency lock annotation in the service waiting pool; wherein, the distributed concurrency lock annotation includes an unlock annotation tag; and, if the resource corresponding to the service request is not a shared resource, store the service request in the service waiting pool.

[0099] The determination unit is used to determine the pending business requests corresponding to the current moment from the business waiting pool.

[0100] This embodiment also provides a distributed system, which includes: a gateway, a controller, and an interceptor between the gateway and the controller. The interceptor is implemented based on AOP (Aspect-Oriented Programming) technology.

[0101] The gateway is used to receive and forward service requests sent by users; and to receive and forward the execution information of the target service corresponding to the service request fed back by the interceptor to the user.

[0102] Interceptors are used to execute the business processing methods in the aforementioned distributed system;

[0103] The controller is used to execute the target business corresponding to the business request when triggered by the interceptor.

[0104] For interceptors implemented using AOP (Aspect-Oriented Programming) technology, the process involves first defining a distributed concurrency lock annotation (@DistributedLock) to mark items requiring distributed concurrency locks, then defining an aspect class to intercept items annotated with @DistributedLock, and declaring both the distributed concurrency lock annotation and the aspect annotation on this aspect class to obtain an aspect. The aspect annotation includes around advice. This aspect uses around advice to insert behavior during program execution using information related to the distributed concurrency lock annotation. Around advice instructs the interceptor to request a lock from the lock manager for the target business before triggering the controller to execute the target business; and to trigger the lock manager to release the lock for the target business when the controller executes the target business and the execution information meets the preset lock release conditions. Shared resources in the distributed system are managed through the lock manager. The lock manager can be a utility class, used to call the lock acquisition or release methods of stored distributed concurrency locks to lock or release the shared resources corresponding to the business request.

[0105] See Figure 5 The diagram illustrates a business processing mechanism in a distributed system. The system includes a gateway, a controller, an interceptor, and a lock manager. The method may include the following steps:

[0106] In step S510, the gateway sends the user's service request to the interceptor.

[0107] Step S511: The interceptor checks whether the service request to be processed contains a lock annotation tag with a distributed concurrency lock annotation. If yes, proceed to step S512; otherwise, trigger the controller to execute the target service so that the controller can send the execution information back to the corresponding user through the gateway.

[0108] The lock annotation tag indicates that the target business corresponding to the business request needs to access shared resources in the distributed system, and the shared resources in the distributed system are all managed by the lock manager.

[0109] In step S512, the interceptor sends a first request to the lock manager to lock the target shared resource corresponding to the target service for the user; wherein, the lock manager locks the target shared resource when it is in an unlocked state.

[0110] In step S513, the lock manager sends a first response to the interceptor, indicating that the target shared resource has been successfully locked, based on the first request.

[0111] Based on the first request, the lock manager calls the acquireLock method to execute a specific lock acquisition SQL statement (ACQUIRE_LOCK_SQL) to lock the target shared resource corresponding to the target business. Then, it sends a first response to the interceptor confirming that the target shared resource corresponding to the target business has been successfully locked.

[0112] Step S514: The interceptor sends a service request to the controller;

[0113] Step S515: The controller executes the target service.

[0114] In step S516, the interceptor monitors the execution information of the target service executed by the controller and checks whether the execution information meets the preset lock release condition. If yes, proceed to step S517; otherwise, return to step S516.

[0115] In step S517, the interceptor sends a second request to the lock manager to release the lock for the target service.

[0116] In step S518, the lock manager sends a second response to the interceptor, based on the second request, indicating that the lock on the target shared resource has been successfully released.

[0117] The lock manager calls the releaseLock method based on the second request to execute a specific lock release SQL statement (RELEASE_LOCK_SQL) to release the lock on the target shared resource corresponding to the target service. Then, it sends a second response to the interceptor to confirm the successful release of the lock on the target shared resource corresponding to the target service.

[0118] In step S519, the interceptor sends the execution information back to the user through the gateway.

[0119] The distributed system provided in this application forwards a user's business request to an interceptor through a gateway. The interceptor checks whether the business request to be processed contains a lock annotation tag in a distributed concurrency lock annotation. This allows the interceptor to distinguish whether the business request needs to access a shared resource. If it contains a lock annotation tag, the interceptor determines that the target shared resource corresponding to the business request needs to access it, and then requests the lock manager to lock the target shared resource corresponding to the business request. The lock manager responds to the request and locks the target shared resource if it is currently unlocked, ensuring that only the business request can access the target shared resource. After the lock manager confirms that the user has locked the target shared resource, it feeds back the information that the target shared resource is locked to the interceptor, which then triggers the controller to execute the target business. This locking method and the timing of triggering the controller to execute business logic ensure that the execution of other users' business processes is not interrupted when the target shared resource is locked by other users' business processes. This guarantees the integrity of the business processing corresponding to the shared resource and reduces the probability of deadlocks. The interceptor monitors the execution information of the controller executing the target business. When the execution information meets the preset lock release conditions, it triggers the lock manager to release the lock on the target shared resource corresponding to the target business, thereby ensuring that the lock on the target shared resource is released in a timely manner, fully guaranteeing the timeliness of resource access in the distributed system. The above method achieves unified management of the acquisition and release of distributed concurrent locks. Using AOP technology, it is not necessary to write additional lock management code for each business. While ensuring the original business logic and mitigating the risk of deadlocks, it simplifies the system code and improves the system's operating performance.

[0120] This application also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the business processing method in the above-mentioned distributed system.

[0121] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the business processing method described above in the distributed system.

[0122] This application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the business processing method described above in the distributed system.

[0123] Those skilled in the art will understand that the embodiments in this application can be provided as methods, systems, or computer program products. Therefore, the embodiments in this application can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, the embodiments in this application can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0124] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0125] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0126] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0127] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A business processing method in a distributed system, characterized in that, An interceptor applied between a gateway and a controller in a distributed system, the interceptor being implemented based on AOP (Aspect-Oriented Programming) technology, the method comprising: Check whether the pending business request contains a lock annotation tag with a distributed concurrency lock annotation; wherein, the business request is initiated by the user and sent to the controller after passing through the gateway; the lock annotation tag indicates that the target business corresponding to the business request needs to access the shared resources in the distributed system, and the shared resources in the distributed system are all managed by the lock manager; If so, the lock manager is requested to lock the target shared resource corresponding to the target service for the user; wherein the lock manager locks the target shared resource when it is in an unlocked state; When it is determined that the lock manager has locked the target shared resource for the user, the controller is triggered to execute the target service, and the execution information of the controller executing the target service is monitored; When the execution information meets the preset lock release conditions, the lock manager is triggered to release the lock on the target shared resource, and the execution information is fed back to the user through the gateway.

2. The method as described in claim 1, characterized in that, Requesting the lock manager to lock the target shared resource corresponding to the target service for the user includes: The user sends a first request to the lock manager to lock the target shared resource corresponding to the target service; When the lock manager receives a first response indicating that it has successfully locked the target shared resource based on the first request, it is determined that the lock manager has locked the target shared resource for the user.

3. The method as described in claim 1, characterized in that, Before requesting the lock manager to lock the target shared resource corresponding to the target service for the user, the method further includes: Send a verification request to the lock manager to check whether the target shared resource corresponding to the target service is in a locked state; When a verification response from the lock manager indicating that the target shared resource is in an unlocked state is received, the step of requesting the lock manager to lock the target shared resource corresponding to the target service for the user is executed.

4. The method as described in claim 3, characterized in that, The distributed concurrent lock annotation also includes custom polling count, polling timeout, and polling interval; the method also includes: When a verification response indicating that the target service is in a locked state is received from the lock manager, the verification request is sent to the lock manager multiple times according to the polling time interval; If the number of times the verification request is sent exceeds the number of polling attempts, and / or if the duration of multiple verification requests exceeds the polling timeout, then the gateway will send information that the target service is in a locked state back to the user.

5. The method as described in claim 1, characterized in that, When the execution information meets the preset lock release conditions, triggering the lock manager to release the lock on the target shared resource includes: If the execution information satisfies the condition that the target service has completed its processing, a second request to release the lock for the target service is sent to the lock manager to trigger the lock manager to release the lock on the target shared resource.

6. The method as described in claim 1, characterized in that, The distributed concurrent lock annotation also includes the validity period of the distributed concurrent lock, and the execution information includes the execution duration; When the execution information meets the preset lock release conditions, triggering the lock manager to release the lock on the target shared resource includes: If the execution time exceeds the validity period of the distributed concurrent lock, a second request to release the lock for the target service is sent to the lock manager to trigger the lock manager to release the lock on the target shared resource.

7. The method as described in claim 1, characterized in that, The method further includes: Intercepting user-sent business requests; If the resource corresponding to the business request is a shared resource, a distributed concurrency lock annotation is set in the business request, and the business request containing the distributed concurrency lock annotation is stored in the business waiting pool; wherein, the distributed concurrency lock annotation includes an unlock annotation tag; If the resource corresponding to the service request does not belong to the shared resource, then the service request is stored in the service waiting pool; The pending business requests corresponding to the current moment are determined from the business waiting pool.

8. A business processing device in a distributed system, characterized in that, An interceptor used in a distributed system between a gateway and a controller, the interceptor being implemented based on AOP (Aspect-Oriented Programming) technology, the device comprising: The inspection unit is used to check whether the business request to be processed contains a lock annotation tag of distributed concurrency lock annotation; wherein, the business request is initiated by the user and sent to the controller after passing through the gateway; the lock annotation tag indicates that the target business corresponding to the business request needs to access the shared resources in the distributed system, and the shared resources in the distributed system are all managed by the lock manager; The application unit is used to apply to the lock manager to lock the target shared resource corresponding to the target service for the user when the check result of the check unit is yes; wherein the lock manager locks the target shared resource when it is in an unlocked state; The triggering unit is configured to, when it is determined that the lock manager has locked the target shared resource for the user, trigger the controller to execute the target service and monitor the execution information of the controller executing the target service; and, when the execution information meets the preset lock release conditions, trigger the lock manager to release the lock on the target shared resource and feed back the execution information to the user through the gateway.

9. A distributed system, characterized in that, The system includes: a gateway, a controller, and an interceptor between the gateway and the controller; the interceptor is implemented based on AOP (Aspect-Oriented Programming) technology. The gateway is configured to receive and forward service requests sent by users; and to receive and forward the execution information of the target service corresponding to the service request fed back by the interceptor to the user. The interceptor is used to execute the business processing method in the distributed system according to any one of claims 1-7; The controller is used to execute the target service corresponding to the service request when triggered by the interceptor.

10. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1-7.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method of any one of claims 1-7.

12. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the method of any one of claims 1-7.

Images