Service control method and system, electronic equipment and storage medium

Abstract

The invention provides a service control method and system, electronic equipment and a storage medium, relates to the technical field of communication, and can solve the problems of data competition and data disorder in a supply chain financial system. According to the specific technical scheme, when a first service request is received, a first service identification number contained in the first service request serves as a key value, and a corresponding lock state in Redis is checked; if it is found that the service corresponding to the first service request is not locked currently, immediately obtaining a Redis lock and starting to process the service, and automatically releasing the Redis lock after the service processing is completed; if it is detected that the service corresponding to the first service request is locked by other requests, the newly arrived second service request is not immediately rejected or the corresponding service processing is not immediately executed, and the lock is circularly attempted to be obtained in the background according to the preset retry interval time and the maximum retry number of times, so that the service processing is not immediately executed. The method is used for high-concurrency management until successful acquisition or the maximum number of retry times is reached.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a service control method, system, electronic device, and storage medium. Background Technology

[0002] With the deep integration of "Internet + Finance + Industry," supply chain finance is developing rapidly. However, existing supply chain finance systems face severe challenges in high-concurrency scenarios. These systems rely on database locking mechanisms, which struggle to effectively handle concurrent operations by multiple users on the same business transaction, leading to data contention and data corruption, thus affecting the security and reliability of the supply chain finance system. Summary of the Invention

[0003] This application provides a business control method, system, electronic device, and storage medium for implementing mutual exclusion control of the same business in high-concurrency scenarios, effectively preventing data competition and data corruption problems in supply chain finance systems.

[0004] To achieve the above objectives, the embodiments of this application adopt the following technical solutions:

[0005] In a first aspect, this application provides a business control method, the method comprising: receiving a first business request, the first business request being initiated by a first user terminal through a supply chain finance system, the first business request including a first business identifier number; using the first business identifier number as a first key value, checking the Redis lock status corresponding to the first key value in a Redis service, wherein the Redis lock status includes a locked state or an unlocked state; if the Redis lock corresponding to the first key value is in an unlocked state, then acquiring the Redis lock corresponding to the first key value from the Redis service for the first business request; when the first business request acquires the Redis lock corresponding to the first key value, executing a first business process corresponding to the first business request; and releasing the Redis lock corresponding to the first key value after the first business process is executed; if, during the execution of the first business process, a second business request is received, and it is detected that the Redis lock corresponding to the first key value is in a locked state, then for the second business request, cyclically attempting to acquire the Redis lock corresponding to the first key value from the Redis service based on a preset retry interval and a maximum number of retries; the second business request being initiated by a second user terminal through a supply chain finance system, the second business request including the first business identifier number.

[0006] In the first aspect, this application replaces traditional database locks with Redis locks. Since Redis locks respond much faster than database locks, the system can handle concurrent requests more quickly.

[0007] Furthermore, this application uses the business identifier number as a Redis key for lock control when multiple users (such as a first user terminal and a second user terminal) simultaneously request to operate on the same business (such as a certain order), ensuring that only one request can process the business (such as the order) at the same time. This fundamentally avoids data competition and data corruption problems, and improves the security and reliability of the supply chain finance system.

[0008] In addition, this application introduces a cyclical retry mechanism based on a preset retry interval and a maximum number of retries. When the second service request detects that the lock is occupied, it will not fail immediately or execute the corresponding service immediately. Instead, it will retry according to the retry interval and the maximum number of retries. This strategy can avoid system overload caused by frequent retries and improve the success rate of requests.

[0009] In one possible implementation of the first aspect, the first service request and the second service request belong to the same mutually exclusive service group. The requests in the mutually exclusive service group correspond to different service processes associated with the same service indicated by the first service identifier number, and the data operated by the different service processes includes the same target data.

[0010] The same transaction (such as payment for an order or settlement of a bill) may be processed simultaneously by multiple user terminals. Traditional solutions are prone to data contention and data corruption (such as duplicate deductions or overpayments due to multiple user terminals concurrently modifying the same transaction (e.g., the same order)). This application uses a mutual exclusion business group mechanism to ensure that only one request can process the transaction at a time, thus completely avoiding concurrency conflicts. For example, suppose a payment request (first business request) for a certain transaction (e.g., order A) is being processed, and another terminal also initiates a settlement request (second business request) for the same transaction (e.g., order A). Since they belong to the same mutual exclusion business group, the second request will be blocked or enter a retry queue until the first request completes and releases the lock. In this way, data access can be precisely controlled, concurrency conflicts can be avoided, and data consistency can be improved.

[0011] In one possible implementation of the first aspect, if the second business request acquires the Redis lock corresponding to the first key value, then the second business processing corresponding to the second business request is executed; and after the second business processing is completed, the Redis lock corresponding to the first key value is released.

[0012] This application employs a standard "acquire lock - execute business logic - release lock" process to ensure that only one business process can operate on critical data at a time. When the first business request acquires the lock, all subsequent requests for the same business identifier enter a waiting state. Once the second business request successfully acquires the lock, it immediately executes its business logic, avoiding unnecessary waiting and enabling the system to continuously process valid requests. This prevents resource idleness and further improves system resource utilization while ensuring system security and reliability.

[0013] In one possible implementation of the first aspect, the Redis service includes multiple mapping relationships between key-value pairs and corresponding Redis lock states. The method further includes: if, during the execution of the first business process, a third business request is received, the third business request being initiated by a third user terminal through a supply chain finance system, and the third business request including a second business identifier number, the second business identifier number being different from the first business identifier number; using the second business identifier number as the second key-value pair, checking the Redis lock state corresponding to the second key-value pair in the Redis service; if the Redis lock corresponding to the second key-value pair is in an unlocked state, then obtaining the Redis lock corresponding to the second key-value pair from the Redis service for the third business request; when the third business request obtains the Redis lock corresponding to the second key-value pair, executing the first business process and the third business process corresponding to the third business request in parallel.

[0014] This application addresses the issue where, while the system is processing a first business request (e.g., payment for order A), if a third business request (e.g., settlement for order B) is received, and these two requests have different business identifiers, the system will independently check their corresponding Redis locks. If the lock for order A is already held (being processed), but the lock for order B is not held, the system will immediately acquire the lock for order B and execute both business processes in parallel. This prevents the processing of one business from blocking the execution of other unrelated businesses, supporting high-concurrency business processing and thus improving system throughput and processing efficiency.

[0015] In one possible implementation of the first aspect, for the second business request, the Redis lock corresponding to the first key-value pair is repeatedly attempted to be acquired based on a preset retry interval and a maximum number of retries. Specifically, this includes: for the second business request, attempting to acquire the Redis lock corresponding to the first key-value pair; if the Redis lock corresponding to the first key-value pair is successfully acquired, the second business logic is executed directly; otherwise, the next attempt is initiated after waiting for the retry interval. The method also includes: if the Redis lock corresponding to the first key-value pair is successfully acquired within the maximum number of retries, the second business logic is executed normally; if the Redis lock corresponding to the first key-value pair is not successfully acquired after reaching the maximum number of retries, the process is terminated and an exception is displayed.

[0016] In high-concurrency scenarios, multiple requests may compete for the same lock simultaneously. A simple "failure to acquire on the first attempt results in an error" strategy would lead to a large number of legitimate requests being discarded incorrectly. This application utilizes an intelligent retry mechanism to allow requests to attempt multiple times within a reasonable timeframe, significantly improving the success rate. Furthermore, the maximum number of retries limits prevents requests from waiting indefinitely due to extreme conditions (such as locks being held for extended periods), thus avoiding impacts on system performance.

[0017] In one possible implementation of the first aspect, when the first business request acquires the Redis lock corresponding to the first key-value pair, the first business processing corresponding to the first business request is executed. Specifically, this includes: when the first business request successfully acquires the Redis lock corresponding to the first key-value pair, processing the business-related data of the first business processing corresponding to the first business request; storing the processing result of the first business processing in a database, including MySQL and MongoDB, where MySQL is used to store structured data and MongoDB is used to store unstructured data; and releasing the Redis lock corresponding to the first key-value pair after the first business processing is completed. Specifically, this includes: after the first business processing is completed and the processing result of the first business processing is stored in the database, automatically releasing the Redis lock corresponding to the first key-value pair using aspect-oriented programming (AOP) technology.

[0018] This application effectively solves the "partial success" problem by strictly binding Redis locks to the entire business processing process. That is, the lock is only released after the business processing is complete and data storage is successful, thus preventing other requests from reading intermediate state data. Furthermore, MySQL is used to store structured data with high consistency requirements, ensuring data security, while MongoDB is used to store unstructured data such as logs and documents, improving system throughput. The advantage of this collaborative storage is that it can improve the system's processing speed.

[0019] In one possible implementation of the first aspect, the supply chain finance system includes a user layer, a business layer, and a data storage layer. The method includes: after receiving a first business request, the user layer forwards the first business request to the business layer; after receiving the first business request from the user layer, the business layer checks the Redis lock status corresponding to the first key value in the Redis service, using the first business identifier number as the first key value; if the Redis lock corresponding to the first key value is unlocked, the business layer acquires the Redis lock corresponding to the first key value from the Redis service for the first business request; when the first business request acquires the Redis lock corresponding to the first key value, it executes a first business process corresponding to the first business request; and sends the processing result of the first business process to the data storage layer; and after the first business process is completed, it releases the Redis lock corresponding to the first key value; after receiving the processing result of the first business process sent by the business layer, the data storage layer stores the processing result in the database; the business request includes an issuance request, a receipt request, a transfer request, a financing request, or a clearing request.

[0020] The supply chain finance system of this application adopts a layered design of user layer, business layer and data storage layer. Each layer has a clear responsibility and works together to complete the processing of business requests. The user layer focuses on interaction, the business layer processes logic, and the data storage layer ensures storage reliability. The layered architecture design makes the system easier to maintain. In addition, each layer can be optimized in a targeted manner, thereby facilitating further expansion.

[0021] Secondly, this application provides a supply chain finance system, comprising: a request receiving module, configured to receive a first business request, wherein the first business request is initiated by a first user terminal through the supply chain finance system, and the first business request includes a first business identifier number; a Redis lock status checking module, configured to check the Redis lock status corresponding to the first key value in the Redis service using the first business identifier number as the first key value, wherein the Redis lock status includes a locked state or an unlocked state; and a business processing module, configured to, if the Redis lock corresponding to the first key value is in an unlocked state, obtain the Redis lock corresponding to the first key value from the Redis service for the first business request; and when the first business request obtains the lock, the module processes the request. When the Redis lock corresponding to the first key-value pair is acquired, the first business processing associated with the first business request is executed. The Redis lock release module is used to release the Redis lock corresponding to the first key-value pair after the first business processing is completed. The business processing module is also used to, if a second business request is received during the execution of the first business processing and the Redis lock corresponding to the first key-value pair is detected to be in a locked state, attempt to acquire the Redis lock corresponding to the first key-value pair from the Redis service in a loop based on a preset retry interval and a maximum number of retries for the second business request. The second business request is initiated by the second user terminal through the supply chain finance system, and the second business request includes the first business identifier number.

[0022] Thirdly, an electronic device is provided, the method comprising: a memory and at least one processor. The memory is communicatively connected to the processor. The memory is used to store computer program code, the computer program code including computer instructions. When the processor executes the computer instructions, it causes the electronic device to perform the method as described in the first aspect and any possible implementation thereof.

[0023] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer instructions. When executed by a processor, these computer instructions are used to implement the method described in the first aspect and any possible implementation thereof.

[0024] Fifthly, embodiments of this application provide a computer program product that, when running on a computer or executed by the computer's processor, implements the method described in the first aspect and any possible design of the method.

[0025] It is understood that the beneficial effects achieved by the supply chain finance system described in the second aspect, the electronic device described in the third aspect, the computer-readable storage medium described in the fourth aspect, and the computer program product described in the fifth aspect can be referred to as the beneficial effects in the first aspect and any possible implementation thereof, and will not be repeated here. Attached Figure Description

[0026] Figure 1 A schematic diagram of the software architecture of a supply chain finance system provided in this application embodiment;

[0027] Figure 2 A flowchart illustrating a business control method for a supply chain finance system provided in this application embodiment;

[0028] Figure 3 A schematic diagram of the structure of a supply chain finance system provided in this application embodiment;

[0029] Figure 4 A flowchart illustrating a supply chain finance system method provided in this application embodiment;

[0030] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0031] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this embodiment, unless otherwise stated, "a plurality of" means two or more.

[0032] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0033] The technical solutions provided in this application, including the collection, storage, use, processing, transmission, provision, and disclosure of financial data or user data, comply with relevant laws and regulations and do not violate public order and good morals.

[0034] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.

[0035] With the booming development of the digital economy and the in-depth advancement of the industrial internet, the integration model of "Internet + Finance + Industry" is deeply merging, and supply chain finance is also developing rapidly.

[0036] Against the backdrop of explosive growth in supply chain finance business, supply chain finance systems need to cope with peak periods of high concurrency and high traffic in a short period of time. This high-concurrency scenario places extremely high demands on the system's processing power, stability, and real-time performance. Traditional system architecture and data processing methods are no longer sufficient to meet the needs of current business development, and technological upgrades and architectural optimizations are urgently needed.

[0037] Currently, supply chain finance systems generally use database locks (row locks or table locks at the database level) to handle concurrency control. When multiple users operate on the same transaction at the same time, this mechanism may cause data competition and data corruption due to lock contention, affecting the normal operation of the business (such as causing financial losses and financial risks), and seriously threatening the security and reliability of the supply chain finance system.

[0038] To address the aforementioned technical issues, this application provides a business control method for a supply chain finance system based on the remote dictionary service Redis. The main idea is as follows:

[0039] When a first business request is received from a first user terminal through the supply chain finance system, the system uses the first business identifier number contained in the first business request as the key to check the corresponding lock status in Redis. If it is found that the business corresponding to the first business request is not currently locked, the system immediately acquires the Redis lock and begins processing the business. The Redis lock is automatically released after the business is processed. If it is detected that the business corresponding to the first business request is already locked by another request, the newly arrived second business request will not be immediately rejected nor will the corresponding business processing be executed immediately. Instead, it will attempt to acquire the lock in the background in a loop according to the preset retry interval and the maximum number of retries until it is successfully acquired or the maximum number of retries is reached.

[0040] This application employs a Redis lock mechanism, using the business identifier as the key, when multiple business requests simultaneously attempt to operate on the same transaction (such as a single order). This ensures that only one request can process the transaction at a time, fundamentally avoiding data races and data corruption issues, and improving the security and reliability of the supply chain finance system. Furthermore, because Redis locks respond much faster than database locks, the system can handle concurrent requests more quickly.

[0041] In addition, this application introduces a cyclical retry mechanism based on a preset retry interval and a maximum number of retries. When the second business request detects that the lock is occupied, it will not fail immediately or execute the corresponding business processing immediately. Instead, it will retry according to the retry interval and the maximum number of retries. This strategy can avoid system overload caused by frequent retries and improve the success rate of requests.

[0042] The embodiments provided in this application will now be described in detail with reference to the accompanying drawings.

[0043] Figure 1 This is a schematic diagram of the software architecture of a supply chain finance system provided in this application.

[0044] like Figure 1 As shown, a supply chain finance system can include a user layer, a business layer, and a data storage layer. The user layer can include multiple access methods such as PCs, mini-programs, and mobile devices, allowing users to perform the entire business process, including issuance, receipt, financing applications, order transfers, and clearing and settlement. Optionally, the supply chain finance system can also include a Redis service, which can include multiple key-value pairs mapping relationships between corresponding Redis lock states.

[0045] The business layer, as the core processing unit of the entire system, can include a request receiving module 11, a Redis lock status checking module 12, a business processing module 13, and a Redis lock release module 14. The business layer is responsible for handling user requests, controlling concurrent access, executing business logic, and performing other business processing operations.

[0046] The data storage layer can include a MySQL database (15) and a MongoDB database (16). MySQL can be used to store highly structured data, such as transaction data and account information. MongoDB is suitable for storing unstructured data, such as business documents and process logs. MySQL database (15) and MongoDB database (16) work together to ensure the persistence and efficient storage of business data.

[0047] In some embodiments, after receiving a first service request, the user layer forwards the first service request to the service layer.

[0048] After receiving the first business request from the user layer, the business layer uses the first business identifier number as the first key value and checks the Redis lock status corresponding to the first key value in the Redis service. If the Redis lock corresponding to the first key value is unlocked, the business layer requests the Redis lock corresponding to the first key value from the Redis service for the first business request. When the first business request acquires the Redis lock corresponding to the first key value, the business layer executes the first business processing corresponding to the first business request and sends the processing result of the first business processing to the data storage layer. After the first business processing is completed, the business layer releases the Redis lock corresponding to the first key value.

[0049] Redis is a high-performance key-value in-memory database that supports various data structures, including strings, lists, sets, sorted sets, and hashes. Its main features include high performance, rich data structures, data persistence, master-slave replication, and high availability. It is widely used in caching, real-time analytics, message queues, and many other fields.

[0050] After receiving the processing result of the first business process sent by the business layer, the data storage layer stores the processing result in the database.

[0051] The following is combined Figure 1 For an illustrative explanation of how the user layer, business layer, and data storage layer of a supply chain finance system work together, please refer to [link to relevant documentation]. Figure 1 .

[0052] S101. Receive the first business request initiated by the user through PC / mini-program / mobile terminal (including but not limited to: issuance request, receipt request, order transfer request, financing request or settlement request), and forward the first business request to the request receiving module 11. The first business request includes the first business identifier number.

[0053] S102. After verifying the legality of the first business request, the request receiving module 11 can forward the first business request to the Redis lock status checking module 12. After receiving the first business request, the Redis lock status checking module 12 can use the first business identifier number in the first business request as the first key value to check the Redis lock status corresponding to the first key value in the Redis service.

[0054] If the Redis lock corresponding to the first key-value pair is unlocked, then a request is made to the Redis service to acquire the Redis lock corresponding to the first key-value pair for the first business transaction. Optionally, the Redis service can also be deployed in other systems and can interact with supply chain finance systems.

[0055] If the Redis lock corresponding to the first key value is locked, then a queuing waiting mechanism will be entered.

[0056] S103. When the system successfully acquires the Redis lock for the first business request, the system can call the business processing module 13 to execute the first business processing corresponding to the first business request.

[0057] S104. After the business processing module 13 completes the first business processing corresponding to the first business request, the system can call the Redis lock release module 14 to release the Redis lock corresponding to the first key value.

[0058] S105. After the business processing module 13 completes the first business processing corresponding to the first business request, it can store the unstructured data in the processing result in the MongoDB database 16.

[0059] S106. After the business processing module 13 completes the first business processing corresponding to the first business request, the structured data in the processing result can be stored in the MySQL database 15.

[0060] The supply chain finance system of this application adopts a layered design of user layer, business layer and data storage layer. Each layer has a clear responsibility and works together to complete the processing of business requests. The user layer focuses on interaction, the business layer processes logic, and the data storage layer ensures storage reliability. The layered architecture design makes the system easier to maintain. In addition, each layer can be optimized in a targeted manner, thereby facilitating further expansion.

[0061] This application builds a distributed lock service based on Redis middleware, providing a standardized access method that facilitates simple and rapid integration of lock mechanisms into existing microservice systems. Furthermore, by introducing a Redis-based distributed lock mechanism into the supply chain finance system, a serialized processing mechanism for the same business transaction is implemented. This prevents business anomalies such as overselling and duplicate payments, thereby ensuring system accuracy. The serialized processing mechanism for the same business transaction also prevents malicious competition for the same transaction, thus ensuring system stability.

[0062] It should be noted that the system architecture described in the embodiments of this application is for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and does not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of system architecture, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0063] See Figure 2 This application provides a flowchart of a business control method for a supply chain finance system. (See attached diagram.) Figure 2 As shown, the method provided in this application embodiment can be applied to a supply chain finance system. Specifically, this method can be executed through a server, business control device, computer, or chip within the supply chain finance system; this application does not limit its implementation. Specifically, it includes the following steps S201 to S205.

[0064] S201. A first business request is received. The first business request is initiated by the first user terminal through the supply chain finance system. The first business request includes a first business identifier number.

[0065] In some embodiments, a first business request is received. This first business request is initiated by a first user terminal through the supply chain finance system, and includes a first business identifier number. The first business request can be a business operation application initiated by a user or enterprise user (such as a supplier or financial institution) within the supply chain finance system, such as a financial transaction application for financing, bill transfer, or contract signing. For example, a supplier (the first user terminal) submits an accounts receivable financing application to a bank's supply chain finance system.

[0066] The first business identifier number can be a unique identifier assigned to each business by the supply chain finance system for accurate tracking of business transactions. For example, the first business identifier number (OF00001) can be used to represent a specific business transaction of a core enterprise (such as a supplier).

[0067] For example, a simple introduction to the way to obtain a business request: a supplier can submit a financing application to the supply chain finance system through a computer PC (i.e., a user terminal) and generate a business request OF00001-002 (the first business request). OF00001-002 can represent the 002nd business operation on the business with business identifier number OF00001.

[0068] The first user terminal can be a device with wireless transceiver capabilities, such as a mobile phone, tablet computer, wearable device, in-vehicle device, augmented reality (AR) / virtual reality (VR) device, laptop computer, ultra-mobile personal computer (UMPC), netbook, personal digital assistant (PDA), etc. This application does not limit the specific device form of the first user terminal.

[0069] For example, the service in this application can be a specific order, the service identifier number can be used to indicate the unique identifier number of the order, and the processing request for the service can be used to indicate a service processing for the order. For ease of understanding, the first service request, the first service identifier number, the first user terminal, and the exemplary scenario described above are merely illustrative examples and do not constitute a limitation on this application.

[0070] In this way, by associating business requests with business identifiers (such as OF00001→OF00001-002), it is ensured that operations (such as financing, signing, etc.) are all bound to the business, thus avoiding data confusion.

[0071] S202. Using the first business identifier number as the first key value, check the Redis lock status corresponding to the first key value in the Redis service. The Redis lock status includes a locked state or an unlocked state.

[0072] In some embodiments, the system uses a first business identifier number as the first key value to check the Redis lock status corresponding to the first key value in the Redis service. For example, if a supplier submits a financing application request OF00001-002, the system needs to check whether this business has been locked. The system uses OF00001 as the key value to query the Redis service for the Redis lock status corresponding to that key value and returns the status result.

[0073] In Redis, a locked state indicates that a transaction (the transaction with the first business identifier) ​​is being processed (such as during financing review or electronic signature execution), and other concurrent requests must wait. An unlocked state indicates that the transaction can proceed normally into the processing stage.

[0074] In this way, Redis locks can ensure that the same business transaction (such as a certain order) is not processed repeatedly by multiple threads within the same time period, thereby preventing problems such as duplicate loan disbursements and improving the security and reliability of the system.

[0075] S203. If the Redis lock corresponding to the first key value is in an unlocked state, then request the Redis service to acquire the Redis lock corresponding to the first key value for the first business.

[0076] In some embodiments, when it is detected that the Redis lock corresponding to the first key-value pair is unlocked, a request can be made to the Redis service to acquire the Redis lock corresponding to the first key-value pair for the first business. For example, a supplier submits a financing application, and the business identifier number corresponding to this application is the first business identifier number. Upon inspection, it is found that this business is not locked (e.g., the first key-value pair does not exist in the Redis service or is marked as unlocked). Then, a request is made to the Redis service to acquire the Redis lock corresponding to the first key-value pair for the first business. If the request returns success, it indicates that the first business has exclusively acquired the execution right for this business.

[0077] In this way, when it is detected that the Redis lock corresponding to the first key value is in an unlocked state, an application is immediately made to the Redis service to lock the key value, so as to ensure the exclusive execution right of the current business request and thus prevent concurrent operations from causing data inconsistency.

[0078] In some embodiments, when it is detected that the Redis lock corresponding to the first key-value is in a locked state, the system can repeatedly attempt to acquire the Redis lock corresponding to the first key-value from the Redis service based on a preset retry interval and a maximum number of retries. The process for detecting that the Redis lock corresponding to the first key-value is in a locked state can be referred to in subsequent step S205, which describes the process for detecting that the Redis lock corresponding to the second key-value is in a locked state; therefore, it will not be repeated here.

[0079] S204. When the first business request acquires the Redis lock corresponding to the first key value, execute the first business processing corresponding to the first business request, and release the Redis lock corresponding to the first key value after the first business processing is completed.

[0080] In some embodiments, when a first business request acquires the Redis lock corresponding to the first key-value pair, the first business process corresponding to the first business request is executed. After the first business process is completed, the Redis lock corresponding to the first key-value pair is released to ensure that other concurrent requests can continue to process the business. In this way, a closed-loop mechanism of locking → processing → releasing the business ensures business consistency.

[0081] S205. If a second business request is received during the execution of the first business process, and it is detected that the Redis lock corresponding to the first key value is in a locked state, then for the second business request, based on the preset retry interval and maximum number of retries, the Redis lock corresponding to the first key value is attempted to be acquired from the Redis service in a loop; the second business request is initiated by the second user terminal through the supply chain finance system, and the second business request includes the first business identifier number.

[0082] In some embodiments, if a second business request is received during the execution of the first business process, and it is detected that the Redis lock corresponding to the first key value is in a locked state, then for the second business request, the Redis lock corresponding to the first key value is attempted to be acquired from the Redis service in a loop based on a preset retry interval and a maximum number of retries; the second business request is initiated by the second user terminal through the supply chain finance system, and the second business request includes the first business identifier number.

[0083] In some embodiments, the first business request and the second business request belong to the same mutually exclusive business group. Requests within the mutually exclusive business group correspond to different business processes associated with the same business, indicated by the first business identifier number. In some possible implementations, the data operated by these different business processes includes the same target data. The same business transaction (such as payment for an order) may be operated simultaneously by multiple user terminals. Traditional solutions are prone to data contention and data corruption (such as duplicate deductions or overpayments for the same order) due to multiple user terminals concurrently processing (e.g., modifying) the same business transaction or the same target data corresponding to the same business. This application, through a mutually exclusive business group mechanism, ensures that only one request can process the business at a time, thereby completely avoiding concurrency conflicts. For example, the first business request and the second business request are mutually exclusive; for instance, two operation requests for the same order are executed sequentially according to the request order.

[0084] In this context, the second service request and the first service request share the same first service identifier number, indicating that the second service request and the first service request are different service processing operations performed on the same service. For example, the first service request (e.g., OF00001-002) and the second service request (e.g., OF00001-003) belong to the same first service identifier number (OF00001). The first service request OF00001-002 can represent the 002nd service operation on the service with service identifier number OF00001, while the second service request OF00001-003 can represent the 003rd service operation on the service with service identifier number OF00001. It should be understood that the 003rd service operation is an operation following the 002nd service operation.

[0085] The second user terminal can also be a device with wireless transceiver capabilities. The specific device form can be referred to the aforementioned first user terminal, and will not be repeated here.

[0086] The retry interval can be used to indicate how long the system waits after detecting that a Redis lock is held before trying to acquire the Redis lock again. This interval can avoid frequent queries to the Redis service and reduce server load.

[0087] The maximum number of retries can be used to indicate the maximum number of times the system will attempt to acquire a Redis lock before giving up on it. This can be used to prevent infinite retries or long waiting times for users.

[0088] It should be understood that the retry interval and maximum number of retries can be set differently depending on the different business requests.

[0089] The following is a simple example scenario: When the first business request (e.g., OF00001-002) is processing and holding a Redis lock (key value OF00001), if the second business request (e.g., OF00001-003) arrives and detects that the Redis lock has been occupied, it will repeatedly attempt to acquire the Redis lock according to the preset retry interval (e.g., 1 second) and the maximum number of retries (e.g., 3 times).

[0090] It should be understood that the above exemplary descriptions do not constitute a limitation on this application.

[0091] Thus, in the method provided in this application, a Redis lock is used instead of a traditional database lock. Since the response speed of a Redis lock is much faster than that of a database lock, the system can handle concurrent requests more quickly.

[0092] Furthermore, this application uses the business identifier as a Redis key for lock control when multiple users (such as a first user terminal and a second user terminal) simultaneously request to operate the same business (such as the payment of a certain order). This ensures that only one request can process the business (such as a certain order) at the same time, fundamentally avoiding the problems of data competition and data disorder, and improving the security and reliability of the supply chain finance system.

[0093] In addition, this application introduces a cyclical retry mechanism based on a preset retry interval and a maximum number of retries. When the second business request detects that the lock is occupied, it will not fail immediately, but will retry according to the retry interval and the maximum number of retries. This strategy can both avoid system overload caused by frequent retries and improve the success rate of requests.

[0094] In some embodiments, if the second business request acquires the Redis lock corresponding to the first key value, then the second business process corresponding to the second business request is executed; and after the second business process is completed, the Redis lock corresponding to the first key value is released.

[0095] For example, when the second business request successfully acquires the Redis lock corresponding to the first key-value pair, the system can exclusively use the Redis lock to manage the corresponding business. Then, the system can execute the second business process corresponding to the second business request (such as an approval operation, modification operation, etc.). After the second business process is completed, the system will release the Redis lock corresponding to the first key-value pair to avoid deadlock. It should be understood that the above exemplary description does not constitute a limitation on this application.

[0096] This application employs a standard "acquire lock - execute business logic - release lock" process to ensure that only one business process can operate on critical data at a time. When the first business request acquires the lock, all subsequent requests for the same business identifier enter a waiting state. Once the second business request successfully acquires the lock, it immediately executes its business logic, avoiding unnecessary waiting and enabling the system to continuously process valid requests. This prevents resource idleness and further improves system resource utilization while ensuring system security and reliability.

[0097] In some embodiments, the Redis service includes multiple mapping relationships between key-value pairs and corresponding Redis lock states. The method further includes: if a third business request is received during the execution of the first business process, the third business request being initiated by a third user terminal through a supply chain finance system, the third business request including a second business identifier number, the second business identifier number being different from the first business identifier number; using the second business identifier number as the second key-value pair, checking the Redis lock state corresponding to the second key-value pair in the Redis service; if the Redis lock corresponding to the second key-value pair is in an unlocked state, then obtaining the Redis lock corresponding to the second key-value pair from the Redis service for the third business request; when the third business request obtains the Redis lock corresponding to the second key-value pair, executing the first business process and the third business process corresponding to the third business request in parallel.

[0098] The Redis service includes a mapping table, which contains multiple key-value pairs and their corresponding Redis lock states. For example, OF00001-LOCKED can be used to indicate that order OF00001 is locked (e.g., being processed), and OF00002-None can be used to indicate that order OF00002 is not locked.

[0099] The third business request (e.g., OF00002-003) belongs to a different business than the first business request (e.g., not a request for the same order). The second business identifier (OF00002) is different from the first business identifier (OF00001), therefore their Redis locks are independent and can be processed in parallel. For example, user A operates on order OF00001, and user B simultaneously operates on another order OF00002. These two orders are independent of each other, and the supply chain system allows parallel processing of these two orders.

[0100] The third user terminal can also be a device with wireless transceiver capabilities. The specific device form can be referred to the aforementioned first user terminal, and will not be repeated here.

[0101] The Redis lock state corresponding to the second key value can be referenced from the Redis lock state corresponding to the first key value in step S202 above, and will not be repeated here.

[0102] For example, this application addresses the issue where, while the system is processing a first business request (e.g., payment for order A), if a third business request (e.g., settlement for order B) is received, and these two requests have different business identifiers, the system independently checks their corresponding Redis locks. If the lock for order A is already held (e.g., being processed), but the lock for order B is not held, the system can immediately acquire the lock for order B and execute both business processes in parallel. This prevents the processing of one business from blocking the execution of other unrelated businesses, supporting high-concurrency business processing and thus improving system throughput and processing efficiency.

[0103] In some embodiments, for a second business request, the method cyclically attempts to acquire the Redis lock corresponding to the first key-value pair based on a preset retry interval and a maximum number of retries. Specifically, this includes: for the second business request, attempting to acquire the Redis lock corresponding to the first key-value pair; if the Redis lock corresponding to the first key-value pair is successfully acquired, the second business logic is executed directly; otherwise, the method waits for the retry interval and then initiates the next attempt. The method further includes: if the Redis lock corresponding to the first key-value pair is successfully acquired within the maximum number of retries, the second business logic is executed normally; if the Redis lock corresponding to the first key-value pair is not successfully acquired after reaching the maximum number of retries, the process is terminated and an exception is displayed.

[0104] For example, user A initiates a first business request OF00001-001, which already holds the Redis lock OF00001. User B initiates a second business request OF00001-002, which needs to wait for the lock to be released before retrying. The retry interval for the second business request is 1 second, and the maximum number of retries is 3. Initially, OF00001 in Redis is locked (held by OF00001-001). At this point, the second business request begins its first attempt to acquire the Redis lock, receives a notification that the Redis lock is held, waits for 1 second, then makes a second attempt, again receives a notification that the Redis lock is held, waits another 1 second, and finally makes a third attempt, again receiving a notification that the Redis lock is held. The system can then terminate the process of the first business request. It should be understood that the above exemplary description does not constitute a limitation on this application.

[0105] In high-concurrency scenarios, multiple requests may compete for the same lock simultaneously. A simple "failure to acquire on the first attempt results in an error" strategy would lead to a large number of legitimate requests being discarded incorrectly. This application utilizes an intelligent retry mechanism to allow requests to attempt multiple times within a reasonable timeframe, significantly improving the success rate. Furthermore, the maximum number of retries limits prevents requests from waiting indefinitely due to extreme conditions (such as locks being held for extended periods), thus avoiding impacts on system performance.

[0106] In some embodiments, when a first business request acquires the Redis lock corresponding to a first key-value pair, a first business process corresponding to the first business request is executed. This includes: processing the business-related data of the first business process corresponding to the first business request when the first business request successfully acquires the Redis lock; storing the processing result of the first business process in a database, including MySQL and MongoDB, where MySQL is used to store structured data and MongoDB is used to store unstructured data; and releasing the Redis lock corresponding to the first key-value pair after the first business process is completed. This specifically includes: automatically releasing the Redis lock corresponding to the first key-value pair using aspect-oriented programming (AOP) technology after the first business process is completed and the processing result is stored in the database. For example, user A initiates a first business request OF00001-002, and the system attempts to acquire the Redis lock OF00001. If the lock is successfully acquired, the first business process (such as risk control review, credit limit calculation, etc.) is executed. The system can write the processing result to MySQL and MongoDB. MySQL is used to store structured data, such as business IDs, statuses, and amounts, and is used to ensure data consistency through transactions. MongoDB is used to store unstructured data, such as dynamic data like logs and attachments. Once the first business process is completed and its result is stored in the database, the lock is automatically released via an AOP interceptor. It should be understood that the above exemplary description does not constitute a limitation of this application.

[0107] This application effectively solves the "partial success" problem by strictly binding Redis locks to the entire business processing process. That is, the lock is only released after the business processing is complete and data storage is successful, thus preventing other requests from reading intermediate state data. Furthermore, MySQL is used to store structured data with high consistency requirements, ensuring the security of transaction data, while MongoDB is used to store unstructured data, improving system throughput. The advantage of this collaborative storage is that it can improve the system's processing speed.

[0108] In some embodiments, the supply chain finance system includes a user layer, a business layer, and a data storage layer. The method includes: after receiving a first business request, the user layer forwards the first business request to the business layer; after receiving the first business request sent by the user layer, the business layer checks the Redis lock status corresponding to the first key value in the Redis service using the first business identifier number as the first key value; if the Redis lock corresponding to the first key value is in an unlocked state, the business layer obtains the Redis lock corresponding to the first key value from the Redis service for the first business request; when the first business request obtains the Redis lock corresponding to the first key value, it executes a first business process corresponding to the first business request; and sends the processing result of the first business process to the data storage layer; and after the first business process is completed, it releases the Redis lock corresponding to the first key value; after receiving the processing result of the first business process sent by the business layer, the data storage layer stores the processing result in the database; the business request includes an issuance request, a receipt request, a transfer request, a financing request, or a clearing request.

[0109] The supply chain finance system of this application adopts a layered design of user layer, business layer and data storage layer. Each layer has a clear responsibility and works together to complete the processing of business requests. The user layer focuses on interaction, the business layer processes logic, and the data storage layer ensures storage reliability. The layered architecture design makes the system easier to maintain. In addition, each layer can be optimized in a targeted manner, thereby facilitating further expansion.

[0110] Figure 3 This is a schematic diagram of the structure of a supply chain finance system provided as an embodiment of this application. Figure 3 As shown, the supply chain finance system 10 includes: a request receiving module 11, a Redis lock status checking module 12, a business processing module 13, and a Redis lock release module 14.

[0111] The request receiving module 11 is used to receive a first business request, which is initiated by the first user terminal through the supply chain finance system. The first business request includes a first business identifier number.

[0112] The Redis lock status checking module 12 is used to check the Redis lock status corresponding to the first key value in the Redis service, with the first business identifier number as the first key value. The Redis lock status includes a locked state or an unlocked state.

[0113] The business processing module 13 is used to obtain the Redis lock corresponding to the first key value from the Redis service if the Redis lock corresponding to the first key value is in an unlocked state; when the first business request obtains the Redis lock corresponding to the first key value, it executes the first business processing associated with the first business request.

[0114] The Redis lock release module 14 is used to release the Redis lock corresponding to the first key-value pair after the first business process is completed.

[0115] The business processing module 13 is further configured to, if a second business request is received during the execution of the first business processing and the Redis lock corresponding to the first key value is detected to be in a locked state, attempt to acquire the Redis lock corresponding to the first key value from the Redis service in a loop based on a preset retry interval and a maximum number of retries for the second business request; the second business request is initiated by the second user terminal through the supply chain finance system and includes the first business identifier number.

[0116] In other embodiments, the first service request and the second service request belong to the same mutually exclusive service group. The requests in the mutually exclusive service group correspond to different service processes associated with the same service indicated by the first service identifier number, and the data operated by the different service processes includes the same target data.

[0117] In other embodiments, the above-mentioned business processing module 13 is further configured to: if the second business request acquires the Redis lock corresponding to the first key value, execute the second business processing corresponding to the second business request, and release the Redis lock corresponding to the first key value after the second business processing is completed.

[0118] In other embodiments, the Redis service includes multiple mapping relationships between key-value pairs and corresponding Redis lock states. If, during the execution of the first business processing, the request receiving module receives a third business request initiated by a third user terminal through the supply chain finance system, and this third business request includes a second business identifier number, which is different from the first business identifier number, the Redis lock state checking module 12 is further configured to check the Redis lock state corresponding to the second key-value pair in the Redis service, using the second business identifier number as the second key-value pair. The business processing module 13 is further configured to: if the Redis lock corresponding to the second key-value pair is in an unlocked state, then obtain the Redis lock corresponding to the second key-value pair from the Redis service for the third business request; when the third business request obtains the Redis lock corresponding to the second key-value pair, execute the first business processing and the third business processing corresponding to the third business request in parallel.

[0119] In other embodiments, the aforementioned business processing module 13 is used to repeatedly attempt to acquire the Redis lock corresponding to the first key-value pair for the second business request, based on a preset retry interval and a maximum number of retries. Specifically, the business processing module 13 is further configured to attempt to acquire the Redis lock corresponding to the first key-value pair for the second business request. If the Redis lock corresponding to the first key-value pair is successfully acquired, the second business logic is executed directly; otherwise, the next attempt is initiated after waiting for the retry interval. The business processing module 13 is further configured to: if the Redis lock corresponding to the first key-value pair is successfully acquired within the maximum number of retries, the second business logic is executed normally; if the Redis lock corresponding to the first key-value pair is not successfully acquired after reaching the maximum number of retries, the process is terminated and an exception is displayed.

[0120] In other embodiments, the aforementioned business processing module 13 is used to execute a first business process corresponding to the first business request when the first business request acquires the Redis lock corresponding to the first key value. Specifically, the business processing module 13 is further used to process the business-related data of the first business process corresponding to the first business request when the first business request successfully acquires the Redis lock corresponding to the first key value; and to store the processing result of the first business process in a database, including MySQL and MongoDB, wherein MySQL is used to store structured data and MongoDB is used to store unstructured data. The aforementioned Redis lock release module 14 is used to release the Redis lock corresponding to the first key value after the first business process is executed. Specifically, the Redis lock release module 14 is used to automatically release the Redis lock corresponding to the first key value through aspect-oriented programming (AOP) technology after the first business process is executed and the processing result of the first business process is stored in the database.

[0121] The implementation principle and beneficial effects of the method shown in the above method embodiments provided in this application can be found in the relevant descriptions in the method embodiments, and will not be repeated here.

[0122] Figure 4 A flowchart illustrating a supply chain finance system method provided for this application. Please refer to [link / reference]. Figure 4 In this system, the supply chain finance system and the database can interact with each other.

[0123] S401, Receive the first service request and lock it.

[0124] In some embodiments, a first service request is received, and the service identifier number of the first service request is detected to be the first service identifier number. After detecting that the service identifier number of the first service request is the first service identifier number, the Redis lock status corresponding to the first key value in the Redis service can be checked using the first service identifier number as the first key value.

[0125] If the Redis lock corresponding to the first key-value pair is in an unlocked state, then the first business request will acquire the Redis lock, that is, the first business request will acquire the Redis lock corresponding to the first key-value pair.

[0126] S402. Execute the first business processing corresponding to the first business request.

[0127] In some embodiments, when the Redis lock corresponding to the first key value is successfully acquired for the first business request, the first business processing corresponding to the first business request is executed.

[0128] S403, Release the lock and store the processing result.

[0129] In some embodiments, after the first business process is completed, the Redis lock corresponding to the first key-value pair is released, and the processing result is transmitted to the database for data update.

[0130] S404. During the first service processing, a second service request is received, and the second service request enters the waiting queue.

[0131] In some embodiments, if a second business request is received during the execution of the first business process, and the business identifier number of the second business request is also the first business identifier number, the second business request is placed in a waiting queue. In the waiting queue, the second business request may attempt to acquire the Redis lock corresponding to the first key-value pair from the Redis service in a loop based on a preset retry interval and a maximum number of retries.

[0132] It should be understood that when the second business request is placed in the waiting queue, it is imperceptible to the user and can ensure that mutually exclusive operations have a sequential order, preventing data corruption issues caused by dirty reads or phantom reads.

[0133] If, after the system completes the first business processing of the first business request and releases the Redis lock, the second business request can acquire the Redis lock corresponding to the first key-value pair, then the system can begin executing the second business processing corresponding to the second business request, and release the Redis lock corresponding to the first key-value pair after the second business processing is completed.

[0134] S405. During the first service processing, a third service request is received and processed in parallel with the first service request.

[0135] In some embodiments, during the execution of the first business process, if a third business request is received, and it is detected that the business identifier number of the third business request is the same as the second business identifier number, and the Redis lock corresponding to the second business identifier number is in an unlocked state, the third business request is locked, and the third business process corresponding to the third business request is executed. At this time, the first business request and the third business request are processed in parallel, that is, the first business process of the first business request and the third business process of the third business request are executed in parallel.

[0136] This application employs a standardized modular design, which reduces access complexity, supports rapid adaptation and expansion for various application systems, and achieves low-latency processing through a lightweight architecture. It is simple, versatile, and effective. Furthermore, due to its standardized modular design, the method provided in this application can be reused in scenarios beyond supply chain finance, enabling rapid configuration and use. The method provided in this application utilizes a distributed transaction mechanism and dynamic resource allocation, ensuring the accuracy of business operations and the correctness of processes under high concurrency and high traffic conditions.

[0137] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 5 As shown, the electronic device 50 includes: a memory 501, a transceiver 502, and at least one processor 503.

[0138] The transceiver 502 is used to interact with other devices to send and receive data. For example, in this embodiment, the transceiver 502 can be used to exchange data with an external database.

[0139] The memory 501 stores computer program code, which includes computer instructions. These computer instructions run in the electronic device 50 to implement the method described in the above-described method embodiments. For example, the memory may include high-speed random access memory (RAM), and may also include non-volatile memory (NVM), such as at least one disk storage device, or a USB flash drive, portable hard drive, read-only memory, magnetic disk, or optical disk, etc.

[0140] Processor 503 can be a general-purpose processor, including a Central Processing Unit (CPU), a network processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. Processor 503 can also be other general-purpose processors. The general-purpose processor can be a microprocessor or any conventional processor.

[0141] The memory 501, transceiver 502, and processor 503 are communicatively connected. For example, the memory 501 and transceiver 502 can be connected to the processor 503 via a system bus and communicate with each other. The system bus can be a peripheral component interconnect (PCI) bus, an extended industry standard architecture (EISA) bus, an industry standard architecture (ISA) bus, etc. The system bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the figure, but this does not mean that there is only one bus or one type of bus. The memory 501 is used to store computer program code, which includes computer instructions. When the processor 503 executes the computer instructions, the electronic device performs the method shown in the above method embodiment.

[0142] Optionally, the memory 501 can be either independent or integrated with the processor 503. When the memory 501 is configured independently, it is connected to the processor 503 via a system bus. The electronic device provided in this application can be used to execute the service control method provided in the above embodiments.

[0143] This application also provides a chip for executing instructions, which is used to execute the technical solution of the business control method of the supply chain finance system in the above embodiments.

[0144] This application also provides a computer-readable storage medium storing computer instructions. When these computer instructions are executed by a processor, they are used to implement the technical solution of the business control method of the supply chain finance system described in the above embodiments. Specifically, when the computer instructions are executed by a processor, the electronic device can execute the technical solution of the business control method of the supply chain finance system described in the above embodiments.

[0145] This application also provides a computer program product, which includes a computer program stored in a computer-readable storage medium. At least one processor can read the computer program from the computer-readable storage medium. When the at least one processor executes the computer program, it can implement the technical solution of the business control method of the supply chain finance system in the above embodiments.

[0146] The aforementioned computer-readable storage media can be implemented from any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The computer-readable storage media can be any available medium accessible to a general-purpose or special-purpose computer.

[0147] An exemplary computer-readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the computer-readable storage medium can also be a component of the processor. The processor and the computer-readable storage medium can reside in an application-specific integrated circuit (ASIC). Alternatively, the processor and the computer-readable storage medium can exist as discrete components in an electronic control unit or main control device; this application does not limit this.

[0148] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or modules, and may be electrical, mechanical, or other forms.

[0149] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to implement the solution of this embodiment according to actual needs.

[0150] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing unit, or each module can exist physically separately, or two or more modules can be integrated into one unit. The unit composed of the above modules can be implemented in hardware or in the form of hardware plus software functional units.

[0151] The integrated modules described above, implemented as software functional modules, can be stored in a computer-readable storage medium. These software functional modules, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods of the various embodiments of this application.

[0152] It should be understood that the steps of the method disclosed in the embodiments of this application can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules in the processor.

[0153] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0154] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A service control method characterized by, The method comprises: receiving a first service request, the first service request being initiated by a first user terminal through a supply chain finance system, the first service request comprising a first service identification number; checking a Redis lock state corresponding to the first key value in the Redis service with the first service identification number as the first key value, wherein the Redis lock state comprises a locked state or an unlocked state; if the Redis lock corresponding to the first key value is in the unlocked state, acquiring the Redis lock corresponding to the first key value for the first service request in the Redis service; when the first service request acquires the Redis lock corresponding to the first key value, performing first service processing corresponding to the first service request, and releasing the Redis lock corresponding to the first key value after the first service processing is completed; if a second service request is received during the execution of the first service processing, and it is detected that the Redis lock corresponding to the first key value is in the locked state, then for the second service request, the Redis lock corresponding to the first key value is attempted to be acquired in the Redis service based on a preset retry interval time and a maximum retry number of cycles; the second service request is initiated by a second user terminal through the supply chain finance system, and the second service request comprises the first service identification number.

2. The method of claim 1, wherein, The first service request and the second service request belong to the same mutually exclusive service group, the requests in the mutually exclusive service group correspond to different service processing of the same service associated with the first service identification number, and the data operated by the different service processing comprises the same target data.

3. The method according to claim 1 or 2, characterized in that, The method further comprises: if the second service request acquires the Redis lock corresponding to the first key value, performing second service processing corresponding to the second service request, and releasing the Redis lock corresponding to the first key value after the second service processing is completed.

4. The method of claim 1, wherein, The Redis service comprises a mapping relationship between a plurality of key values and corresponding Redis lock states; the method further comprises: if a third service request is received during the execution of the first service processing, the third service request being initiated by a third user terminal through the supply chain finance system, the third service request comprising a second service identification number, and the second service identification number being different from the first service identification number; checking a Redis lock state corresponding to the second key value in the Redis service with the second service identification number as the second key value; if the Redis lock corresponding to the second key value is in the unlocked state, acquiring the Redis lock corresponding to the second key value for the third service request in the Redis service; when the third service request acquires the Redis lock corresponding to the second key value, performing the first service processing and third service processing corresponding to the third service request in parallel.

5. The method of claim 1, wherein, The method comprises the following steps: The method comprises the following steps: The method further comprises: If the first key value corresponding Redis lock is successfully acquired within the maximum number of retries, the second business logic is executed normally. If the first key value corresponding Redis lock is still not successfully acquired after the maximum number of retries is reached, the process is terminated and an exception is prompted.

6. The method of claim 1, wherein, When the first business request acquires the first key value corresponding Redis lock, the first business processing corresponding to the first business request is executed, which comprises the following steps: When the first business request successfully acquires the first key value corresponding Redis lock, the business related data of the first business processing corresponding to the first business request is processed. The processing result of the first business processing is stored in a database, which comprises Mysql and MongoDb. The first key value corresponding Redis lock is released after the first business processing is completed, which comprises the following steps: When the first business processing is completed and the processing result of the first business processing is stored in the database, the first key value corresponding Redis lock is automatically released by using aspect-oriented programming (AOP) technology.

7. The method of claim 1, wherein, The supply chain financial system comprises a user layer, a business layer, and a data storage layer. The user layer forwards the first business request to the business layer after receiving the first business request. The business layer checks the Redis lock state corresponding to the first key value in the Redis service after receiving the first business request sent by the user layer. If the first key value corresponding Redis lock is in an unlocked state, the first key value corresponding Redis lock is acquired for the first business request.

8. A supply chain finance system, characterized by, When the first business request acquires the first key value corresponding Redis lock, the first business processing corresponding to the first business request is executed. The processing result of the first business processing is sent to the data storage layer. The first key value corresponding Redis lock is released after the first business processing is completed. The data storage layer stores the processing result in a database after receiving the processing result of the first business processing sent by the business layer. The business request comprises an issuing request, a receiving request, a transfer request, a financing request, or a clearing request. The method comprises the following steps: The request receiving module is configured to receive a first service request, the first service request being initiated by a first user terminal through a supply chain financial system, and the first service request comprising a first service identification number; The Redis lock state checking module is configured to check a Redis lock state corresponding to the first key value in a Redis service by taking the first service identification number as the first key value, wherein the Redis lock state comprises a locked state or an unlocked state; The service processing module is configured to: if the Redis lock corresponding to the first key value is in the unlocked state, acquire the Redis lock corresponding to the first key value for the first service request from the Redis service; and when the first service request acquires the Redis lock corresponding to the first key value, execute a first service processing corresponding to the first service request. The Redis lock releasing module is configured to release the Redis lock corresponding to the first key value after the first service processing is completed. The service processing module is further configured to: if a second service request is received during the execution of the first service processing, and it is detected that the Redis lock corresponding to the first key value is in the locked state, then for the second service request, acquire the Redis lock corresponding to the first key value from the Redis service based on a preset retry interval time and a maximum retry number of cycles; the second service request being initiated by a second user terminal through the supply chain financial system, and the second service request comprising the first service identification number.

9. An electronic device, comprising: The electronic device comprises: The memory and at least one processor; the memory is in communication connection with the processor; the memory is configured to store computer program code, the computer program code comprising computer instructions; when the processor executes the computer instructions, the electronic device executes the method according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer instructions, and the computer instructions are executed by the processor to implement the method according to any one of claims 1-7.

11. A computer program product, characterised in that, When the computer program product is running on the computer / being executed by the processor of the computer, the method according to any one of claims 1-7 is implemented.

Images