Bill processing method and device based on distributed lock

Abstract

The embodiments of this specification provide a bill processing method and device based on distributed locks, wherein a bill processing method based on distributed locks includes: first, obtaining a transfer task of accounts receivable in a bill assigned to a distributed process, wherein the bill records at least one account receivable obtained by payment based on a credit limit; secondly, calling a distributed lock service to add a distributed lock to the bill, performing transfer processing of each account receivable to a third-party organization, and sending a lock request to a bill processing system through an interface call, so that the bill processing system locks the bill and updates the lock status corresponding to each account receivable in a lock status record table to a locked status; finally, if the request response returned by the bill processing system is a successful lock, the distributed lock is unlocked.

Description

Technical Field

[0001] This document relates to the field of data processing technology, and in particular to a bill processing method and device based on distributed locks. Background Art

[0002] With the continuous development and promotion of the Internet, the application scope of online services provided based on the Internet is becoming wider and wider, and the establishment and improvement of the credit system is also ongoing. Credit platforms that provide various credit services to users have emerged. Many credit platforms provide users with various credit-based services such as credit leasing, credit borrowing and repayment, and credit trials; however, in the process of users using the credit services provided by the credit platforms, it is inevitable that overdue situations caused by failure to perform the contract will occur, which brings certain challenges to the fund providers. In view of this, how to improve the efficiency of processing bills generated by users in the process of credit services has become the focus of attention of all parties. Summary of the invention

[0003] One or more embodiments of this specification provide a first distributed lock-based bill processing method, including: obtaining a transfer task of accounts receivable in a bill assigned to a distributed process; the bill records at least one account receivable obtained through payment based on a credit limit. Calling a distributed lock service to add a distributed lock to the bill, performing transfer processing of each account receivable to a third-party institution, and sending a lock request to a bill processing system through an interface call, so that the bill processing system locks the bill and updates the lock status of each account receivable in a lock status record table. If the request response returned by the bill processing system is a successful lock, the distributed lock is unlocked.

[0004] One or more embodiments of this specification provide a second method for bill processing based on distributed locks, including: receiving a lock request for each receivable in a bill sent by an asset management system through an interface call; the bill records at least one receivable obtained through payment based on a credit limit; the lock request cooperates with the asset management system to transfer the receivables to a third-party institution. If the distributed process detects that the bill does not have a distributed lock added, the distributed lock service is called to lock the bill, and the lock status of each receivable is updated in the lock status record table. A request response for the lock request is generated and returned to the asset management system.

[0005] One or more embodiments of the present specification provide a first distributed lock-based bill processing device, including: a task acquisition module, configured to acquire a task for transferring receivables in a bill assigned to a distributed process; the bill records at least one receivable obtained through payment based on a credit limit. A calling module, configured to call a distributed lock service to add a distributed lock to the bill, transfer each receivable to a third-party institution, and send a lock request to the bill processing system through an interface call, so that the bill processing system locks the bill and updates the lock status of each receivable in the lock status record table. An unlocking module, configured to unlock the distributed lock if the request response returned by the bill processing system is a successful lock.

[0006] One or more embodiments of the present specification provide a second bill processing device based on distributed locks, including: a receiving module, configured to receive a lock request for each receivable in a bill sent by an asset management system through an interface call; the bill records at least one receivable obtained through payment based on a credit limit; the lock request cooperates with the asset management system to transfer and process the receivables to a third-party institution. The locking module is configured to call a distributed lock service to lock the bill if the distributed process detects that the bill has not been added with a distributed lock, and to update the lock status of each receivable in the lock status record table. The response module is configured to generate a request response for the lock request and return it to the asset management system.

[0007] One or more embodiments of the present specification provide a first bill processing device, including: a processor; and a memory configured to store computer executable instructions, wherein when the computer executable instructions are executed, the processor: obtains a task for transferring receivables in a bill assigned to a distributed process; the bill records at least one receivable obtained through payment based on a credit limit. Call a distributed lock service to add a distributed lock to the bill, perform transfer processing of each receivable to a third-party institution, and send a lock request to the bill processing system through an interface call, so that the bill processing system locks the bill and updates the lock status of each receivable in the lock status record table. If the request returned by the bill processing system corresponds to a successful lock, the distributed lock is unlocked.

[0008] One or more embodiments of the present specification provide a second bill processing device, including: a processor; and a memory configured to store computer executable instructions, wherein when the computer executable instructions are executed, the processor: receives a lock request for each receivable in a bill sent by an asset management system through an interface call; the bill records at least one receivable obtained through payment based on a credit limit; and the lock request cooperates with the asset management system to transfer and process the receivables to a third-party institution. If the distributed process detects that the bill does not have a distributed lock added, the distributed lock service is called to lock the bill, and the lock status of each receivable is updated in the lock status record table. A request response for the lock request is generated and returned to the asset management system.

[0009] One or more embodiments of the present specification provide a first computer-readable storage medium for storing computer-executable instructions, which implement the following process when executed: obtaining a transfer task for accounts receivable in a bill assigned to a distributed process; the bill records at least one account receivable obtained through payment based on a credit limit. Calling a distributed lock service to add a distributed lock to the bill, performing transfer processing of each account receivable to a third-party institution, and sending a lock request to a bill processing system through an interface call, so that the bill processing system locks the bill and updates the lock status of each account receivable in a lock status record table. If the request response returned by the bill processing system is a successful lock, the distributed lock is unlocked.

[0010] One or more embodiments of the present specification provide a second computer-readable storage medium for storing computer-executable instructions, which implement the following process when executed: receiving a lock request for each receivable in a bill sent by the asset management system through an interface call; the bill records at least one receivable obtained through payment based on a credit limit; the lock request cooperates with the asset management system to transfer the receivables to a third-party institution. If the distributed process detects that the bill does not have a distributed lock added, the distributed lock service is called to lock the bill, and the lock status of each receivable is updated in the lock status record table. A request response for the lock request is generated and returned to the asset management system. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In order to more clearly illustrate one or more embodiments of the present specification or the technical solutions in the prior art, the drawings required for use in the embodiments or the prior art descriptions are briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present specification. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative labor. Figure 1 A schematic diagram of an implementation environment of a bill processing method based on a distributed lock provided for one or more embodiments of this specification; Figure 2 A flow chart of a first distributed lock-based bill processing method provided for one or more embodiments of this specification; Figure 3 A processing sequence diagram of a bill processing method based on a distributed lock applied to bill transfer and repayment scenarios provided in one or more embodiments of this specification; Figure 4 A flow chart of a second distributed lock-based bill processing method provided for one or more embodiments of this specification; Figure 5 A schematic diagram of a first distributed lock-based bill processing device embodiment provided for one or more embodiments of this specification; Figure 6 A schematic diagram of a second embodiment of a bill processing device based on a distributed lock provided for one or more embodiments of this specification; Figure 7 A schematic diagram of the structure of a first distributed lock-based bill processing device provided for one or more embodiments of this specification; Figure 8 A schematic diagram of the structure of a second distributed lock-based bill processing device provided for one or more embodiments of this specification. DETAILED DESCRIPTION

[0012] In order to enable those skilled in the art to better understand the technical solutions in one or more embodiments of this specification, the technical solutions in one or more embodiments of this specification will be clearly and completely described below in conjunction with the drawings in one or more embodiments of this specification. Obviously, the described embodiments are only part of the embodiments of this specification, not all of them. Based on one or more embodiments of this specification, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of this document.

[0013] The bill processing method based on distributed locks provided in one or more embodiments of this specification can be applied to the implementation environment of bill transfer. Figure 1 , the implementation environment at least includes an asset management system 101 and a bill processing system 102; Among them, the asset management system 101 can be configured with a server cluster to support bill transfer. The asset management system 101 manages the customer's asset information and performs operations related to bill transfer. The asset management system 101 interacts with the bill processing system 102 to send lock requests and unlock requests to ensure smooth bill transfer and achieve data consistency and transaction security during the bill transfer process; the bill processing system 102 can be configured with servers and databases to store and process bill information, as well as process bill-related operations and transaction requests.

[0014] In addition, the implementation environment may also include a data platform 103, which detects the bills, determines the overdue bills whose overdue duration exceeds a preset duration threshold, and creates corresponding transfer tasks based on the overdue bills.

[0015] Specifically, the asset management system 101 calls the distributed lock service to add a distributed lock to the bill according to the transfer task created by the data platform 103, and then the asset management system 101 sends a lock request to the bill processing system 102 through an interface call. After receiving the lock request, the bill processing system 102 detects the lock status record corresponding to the receivables in the bill. If the lock status of each receivable is unlocked, the bill processing system 102 performs the lock processing and updates the lock status of each receivable in the lock status record table. After the lock is successful, the bill processing system 102 returns a successful lock response to the asset management system 101; accordingly, after receiving the repayment request, the asset management system 101 sends an unlock request to the bill processing system 102. The bill processing system 102 receives the unlock request, and performs an unlock operation on the receivables corresponding to the corresponding lock status record according to the processing identifier carried in the request, and updates the lock status of the receivables to unlocked. During the entire bill transfer process, the asset management system 101, the bill processing system 102 and the data platform 103 interact and collaborate to ensure that the bill transfer is efficient, secure and orderly.

[0016] One or more embodiments of a bill processing method based on a distributed lock provided in this specification are as follows: Reference Figure 2 The distributed lock-based bill processing method provided in this embodiment specifically includes steps S202 to S206.

[0017] Step S202, obtaining the task of transferring the receivables in the bill allocated to the distributed process.

[0018] In this embodiment, the transfer task refers to the task of transferring receivables from one party to another party, specifically, transferring the ownership of the receivables from one party to another party. The essence of the transfer of ownership is that the recipient of the receivables to be repaid is changed from one party to another party, that is, the repayment object after the transfer is changed from one party to another party.

[0019] Specifically, the transfer task may be a task to transfer the ownership of the receivables in the bill to a third-party institution. The task contains specific information of the transfer, such as detailed information of the receivables, transfer amount, transfer object, etc. After the transfer of ownership, the collection, recording and write-off of the receivables are also transferred. During this process, when repayment is processed, the repayment funds will also be paid to the third-party institution for the write-off of the receivables. The third-party institution can be a financial institution, an asset management company or other types of investment entities. The third-party institution realizes the transfer of assets by purchasing or taking over the receivables.

[0020] Specifically, during the execution of the transfer task, the receivables need to be frozen to maintain consistency in the processing during the transfer process. In order to reduce the duration of freezing receivables, that is, to reduce the impact caused by freezing receivables, a distributed architecture can be adopted. Specifically, the transfer task can be assigned to a distributed process, so that multiple transfer tasks can be processed in parallel, improving processing efficiency and reducing the waiting time of a single task, thereby shortening the overall freezing time of receivables. Distributed processing can be used to avoid conflicts and maintain data consistency during the transfer process.

[0021] The receivables refer to the receivables generated after the customer makes payments based on the credit line. Each receivable is a debt. Specifically, when a customer uses a product based on the credit line for consumption or expenditure, the lending institution will provide the customer with a corresponding credit line. After the customer uses this part of the line to make payments, the lending institution owns the receivables from the customer.

[0022] Optionally, the bill records at least one receivable obtained by payment based on the credit limit.

[0023] Among them, the credit line refers to a credit limit that can be used for payment set for users by financial institutions or third-party payment platforms based on the user's credit status and repayment ability. This limit represents the maximum amount that a customer can consume or trade through credit when the account balance is insufficient. The credit line is usually used in credit cards or other forms of financial products, allowing customers to consume within the limit and then repay within the agreed repayment period.

[0024] In actual applications, a transfer task can be created after detecting the overdue duration after the repayment period of the bill expires. For example, the data platform can detect the overdue duration of the bill and create a corresponding transfer task when it is detected that the overdue duration after the repayment period of the bill expires exceeds the preset duration threshold.

[0025] Specifically, in the process of creating a transfer task, the transfer task can be created for a single receivable. In this scenario, each transfer task assembly only contains one receivable, that is, one receivable represents one bill. At this time, the transfer task and the receivable are one-to-one. In this case, the structure of the transfer task is relatively simple, and each task independently handles the transfer of one receivable.

[0026] In addition, transfer tasks can also be created for the entire bill. In this scenario, one bill is assembled under one transfer task, but multiple receivables can be processed in parallel under this bill. Multiple receivables correspond to one transfer task, that is, the transfer task and receivables are one-to-many. At this time, multiple receivables under the same bill can be merged into one transfer task to improve processing efficiency.

[0027] By identifying and recording the receivables generated after payment based on the credit limit, the transfer task of the receivables in the bill assigned to the distributed process is obtained, so as to perform subsequent transfer processing of the receivables. Specifically, in an optional implementation manner provided by this embodiment, the transfer task is generated in the following manner: Detecting whether the overdue period after the repayment period of the bill exceeds a preset time threshold; If yes, extract each receivable in the bill and create a transfer task for each receivable, or create a transfer task for the bill; If not, no action will be taken.

[0028] Among them, the overdue duration refers to the length of time after the repayment period of the bill expires and the customer has not made repayment; the preset time threshold refers to the pre-set limit value of the overdue duration, which is used to determine whether the bill is seriously overdue, thereby triggering the creation of a transfer task.

[0029] During the specific execution process, the repayment status of all bills can be obtained in real time, and the repayment period and actual repayment time of each bill can be recorded. When the repayment period of the bill expires, the overdue time, that is, the time difference between the actual repayment time and the repayment period, is calculated, and then the overdue time is compared with the preset time threshold. If the overdue time exceeds the preset time threshold, the bill is determined to be an overdue bill, and a transfer task is created based on the information of each receivable in the bill. The transfer task contains information about related receivables, such as the amount of receivables, the due date of receivables, etc. Finally, the created transfer task is assigned to the distributed process, and the distributed process performs the specific transfer operation; if the overdue time of the bill does not exceed the preset time threshold, that is, the bill has not reached the overdue level that requires transfer, the bill will not be processed, and it only needs to wait for repayment or further overdue conditions.

[0030] Step S204, calling the distributed lock service to add a distributed lock to the bill, transferring each receivable to a third-party organization, and sending a lock request to the bill processing system through an interface call, so that the bill processing system locks the bill and updates the lock status of each receivable in the lock status record table.

[0031] As mentioned above, on the basis of obtaining the transfer task of receivables in the bill assigned to the distributed process, in order to avoid concurrency conflicts when processing the bill and prevent the bill from being modified by other processes during the transfer process, the distributed lock service is called to add a distributed lock to the bill. The distributed lock ensures that during the bill transfer process, the transfer of different receivables under the same bill can be carried out in an orderly manner, avoiding lock conflicts and data inconsistency problems.

[0032] In actual applications, when it is detected that the overdue time after the repayment period of the bill exceeds the preset time threshold, the receivables in the bill are extracted and corresponding transfer tasks are created. These transfer tasks are then assigned to the distributed process for processing. In the distributed process, when a transfer request for each receivable is initiated, the bill processing system detects the lock status record corresponding to the receivable in the bill. If the lock status is unlocked, the lock processing is performed and the lock status is updated to unlocked. At the same time, the corresponding identifier is associated with the receivable. This process is implemented through a distributed lock service to ensure the consistency of locks in a distributed environment.

[0033] Furthermore, in order to avoid data inconsistencies or conflicts during the transfer process, the relevant bills and receivables need to be frozen before the transfer task is executed. The freezing operation can be achieved by setting the corresponding lock status in the lock status record table. When the lock status is set to locked, any attempt to modify or access these bills and receivables will be delayed until the lock status is updated to unlocked, thereby ensuring that the status of the bills and receivables will not be changed by other operations during the transfer process to ensure data consistency.

[0034] During the specific execution process, the bill processing process adopts a distributed architecture, and the transfer tasks are assigned to multiple distributed processes for parallel processing to achieve efficient bill management and transfer operations. In the distributed architecture, the asset management system and the bill processing system communicate through interface calls, where the asset management system is responsible for initiating the transfer task of the receivables in the bill, and performing the transfer processing of each receivable to a third-party institution. The bill processing system is responsible for receiving lock requests, calling the distributed lock service to lock the bill, and updating the lock status of each receivable in the lock status record table; the distributed processes in the distributed architecture can independently read and process the transfer tasks. When it is detected that the bill has not been added with a distributed lock, the distributed lock service is called to lock the bill to achieve the correct execution of the transfer task and data synchronization.

[0035] In the specific implementation, first determine the bill to be transferred and the receivables included in the bill, and then call the distributed lock service to add a distributed lock to the target bill to prevent other systems from modifying the bill during the transfer process to ensure the consistency of the transfer process. After the bill is locked, send a transfer request to the third-party agency to start the transfer process of the receivables, and then send a lock request to the bill processing system through a preset interface to perform subsequent operations. In an optional implementation method provided in this embodiment, the transfer process of each receivable to the third-party agency includes: A respective transfer task is created for each receivable in the bill, and the created transfer task is assigned to a distributed process for ownership transfer processing.

[0036] During the specific implementation process, we first analyze the accounts receivable in the bill and decide whether to merge these accounts receivable to simplify the transfer process and improve processing efficiency. For the merged accounts receivable, we create a transfer task, which includes detailed information on the accounts receivable, the target third-party agency for the transfer, etc. For unmerged accounts receivable, we create an independent transfer task for each account receivable. The created transfer tasks are assigned to distributed processes, and each process is responsible for processing one or more transfer tasks, thereby realizing parallel processing of ownership transfer.

[0037] For example, customer A's bill contains two receivables, RMB 1,000 and RMB 2,000 respectively. You can choose to merge the two amounts into one transfer task and transfer them to third-party institution B at one time, or you can choose to create an independent transfer task for each amount and transfer them to B separately. In the case of merged processing, the distributed process only needs to perform one transfer operation, while in the case of independent processing, each process handles the transfer of one amount separately, and the transfer operations are processed in parallel.

[0038] In addition, in order to improve the transfer efficiency and reduce the complexity of the transfer process, the receivables in the bill can be transferred as a whole by merging. Specifically, in another optional implementation provided by this embodiment, the transfer of the receivables to the third party institution also includes: The accounts receivable in the bill are merged, a transfer task is created based on the merged amount, and the transfer task is assigned to a distributed process for ownership transfer processing.

[0039] Furthermore, after the corresponding transfer tasks are created for the receivables in the bill, the created transfer tasks will be assigned to the distributed process for ownership transfer processing, and the transfer processing of each receivable will be carried out to a third-party institution, that is, the ownership of the receivables will be transferred from the original fund provider to the third-party institution. After the ownership transfer, when the subsequent repayment processing is carried out, the repayment funds will also be paid to the third-party institution to write off the receivables.

[0040] In the specific implementation process, it is optional that after the transfer of ownership is completed, the owner of each receivable is changed from the fund provider corresponding to the credit line to a third-party institution. Among them, the third-party institution refers to the recipient of the receivables after the transfer, that is, the third-party institution that ultimately receives and manages the specific receivables.

[0041] During specific implementation, the asset management system sends a transfer request for receivables to a third-party institution. The transfer request for receivables contains detailed information on the receivables to be transferred. The third-party institution decides whether to accept the transfer request based on its own service rules. After the third-party institution confirms acceptance of the transfer and the transfer is completed, the asset management system updates the billing records and changes the ownership of each receivable from the funding provider corresponding to the credit line to the third-party institution.

[0042] In this embodiment, the bill processing system is responsible for locking the bill to ensure that the bill status can be effectively controlled during the bill transfer process to avoid data inconsistency caused by concurrent operations. Accordingly, during the bill transfer process, the bill of the bill processing system needs to be frozen synchronously to avoid conflicts during the transfer process. Specifically, a lock request is sent to the bill processing system through an interface call, so that the bill processing system locks the bill and updates the lock status of each receivable in the lock status record table.

[0043] The bill processing system can also adopt a distributed architecture in the process of locking bills, adding distributed locks to bills through distributed lock services to achieve efficient and accurate locking operations, while ensuring the sequentiality and consistency of the transfer process by effectively coordinating and managing transfer requests for different accounts receivable.

[0044] As described above, while calling the distributed lock service to add a distributed lock to the bill and performing the transfer processing of each receivable to the third-party institution, a lock request can also be sent to the bill processing system through an interface call, so that the bill processing system locks the bill and updates the lock status of each receivable in the lock status record table to achieve the security and consistency of bill processing. In an optional implementation manner provided by this embodiment, locking the bill and updating the lock status of each receivable in the lock status record table includes: Performing lock verification on the bill; If the verification is passed, the distributed lock service is called to add a distributed lock to the bill, and the lock status of each receivable carried by the lock request in the lock status record table is updated to a locked state, and a lock success request response is generated; If the verification fails, a lock failure request response is generated.

[0045] Among them, the lock status record table refers to a data table used to manage and record the lock status during the receivables transfer process; for example, as shown in Table 1, the core fields of the following lock status record table include: customer ID (Identification), that is, the customer's unique identifier, used to distinguish different customers; bill number, that is, the unique identifier of the bill, used to distinguish different bills under the customer; debt number, that is, the unique identifier of the receivable, used to distinguish different receivables under the same bill; processing batch number, that is, the batch identifier of the processing, used to distinguish batches of the same receivable at different times or different processing; lock status, that is, whether the current receivable is locked, used to control concurrent access during the receivables transfer process; the lock status record table records the lock status of each receivable during the receivables transfer process to ensure that only one processing batch can operate on a certain receivable at the same time, thereby avoiding concurrent conflicts and data inconsistency problems. At the same time, the lock status record table supports reentrancy of locks, that is, different receivables under the same bill can be locked in different batches, thereby improving the efficiency of bill processing.

[0046]

[0047] Table 1 Specifically, before trying to lock the bill, the bill is first locked to determine whether the bill is locked by other processes. If the verification passes, the distributed lock service is called to add a distributed lock to the bill to ensure the consistency of the bill status during the transfer process. At the same time, the lock status of each receivable carried in the lock request is updated to "locked status" in the lock status record table. The bill processing system generates a request response for successful locking and returns the request response. If the verification fails, that is, the bill has been locked by other processes, the bill processing system generates a request response for failed locking and returns the request response to avoid potential data conflicts.

[0048] Further, the above statement is locked and verified. After the verification is passed, the distributed lock statement is called to add a distributed lock, and the lock status of each receivable is updated in the lock status record table. In an optional implementation provided by this embodiment, the lock status of each receivable is updated in the lock status record, including: Read the first identifier associated with each receivable in the lock status record table; If the read result is empty, determining the second identifier carried in the lock request as the first identifier of each receivable; If the read result is not empty, detecting whether the first identifier is consistent with the second identifier; If so, the lock status of each receivable carried by the lock request in the lock status record table is updated to a locked status; If not, the bill management system returns a lock request response refusing the lock request.

[0049] Among them, the first identifier refers to the identifier associated with each receivable in the lock status record table, which is used to record the processing batch to which the current receivable belongs, thereby distinguishing different processing operation batches, ensuring that operations within the same processing batch can be re-entered and operations between different processing batches are mutually exclusive; the second identifier refers to the identifier carried in the lock request, which is used to identify the current transfer operation batch.

[0050] In specific implementation, in order to enable the transfer operations of different receivables in the same bill to proceed in an orderly manner and avoid unnecessary lock conflicts, when a transfer request for a certain receivable is initiated, the bill processing system first checks the lock status of the receivable in the lock status record table. If the receivable is not currently locked, the first identifier associated with the receivable is further read. If the first identifier is empty, it indicates that the receivable has not been locked by any processing batch before. At this time, the second identifier carried in the lock request (i.e., the identifier of the current transfer operation) is used as the first identifier of the receivable, and the lock status of the receivable is updated to the locked state; if the read first identifier is not empty, the first identifier is compared with the second identifier for consistency. If they are consistent, it indicates that the current transfer request belongs to the same processing batch, reentry is allowed, no new locking operation is performed, and the existing lock status remains unchanged; if they are inconsistent, it indicates that the current transfer request belongs to a different processing batch. In order to ensure that operations between different processing batches are mutually exclusive, the bill processing system returns a request response to reject the lock and prevents new transfer operations.

[0051] For example, there are two receivables in the bill of customer A, namely receivable 1 and receivable 2. First, a transfer request for receivable 1 is initiated. At this time, a record is created for receivable 1 in the lock status record table, and the lock status of receivable 1 is updated to locked. At the same time, the second identifier (assuming batchNo001) is used as the first identifier. Then, a transfer request for receivable 2 is initiated in the same processing batch. First, it is checked that the lock status of receivable 2 is unlocked. The first identifier is read as empty, so the second identifier batchNo001 is used as the first identifier, and receivable 2 is transferred to the lock status record table. The lock status of item 2 is updated to the locked status. Based on this, the two transfer requests within the same processing batch are allowed to be executed, realizing the reentrant operation. If a transfer request for receivables 1 corresponding to a new processing batch batchNo002 is initiated when the processing batch of batchNo001 is not completed, and it is checked at this time that the first identifier (batchNo001) and the second identifier (batchNo002) of receivables 1 are inconsistent, a request response refusing to lock is returned to prevent new transfer operations, thereby realizing that operations under the same processing batch can be reentrant, but operations under different processing batches cannot be reentrant.

[0052] It should be noted that after calling the distributed lock service to add a distributed lock to the statement, the process of transferring the receivables to a third-party institution and the process of sending a lock request to the bill processing system through an interface call can be executed serially during the specific execution process. For example, first transfer the receivables to the third-party institution, and then send the lock request through the interface call, or first send the lock request through the interface call, and then transfer the receivables to the third-party institution. In addition, they can also be executed in parallel, such as using two parallel threads to respectively execute the process of transferring the receivables to the third-party institution and the process of sending the lock request through the interface call.

[0053] The above-mentioned bill processing process requires the cooperation of the asset management system and the bill processing system. During the transfer process, in order to avoid data inconsistencies and conflicts, the asset management system needs to lock the bills and receivables involved when initiating the transfer of receivables to achieve consistency in the transfer operation. At the same time, in order to maintain synchronization, the bill processing system also needs to freeze the corresponding bills and receivables to ensure that no other changes occur during the transfer process.

[0054] It should be noted that the transfer task is processed through distributed processes, and the bill processing system adds distributed locks to the bill through distributed processes and updates the lock status of the receivables in the bill in the lock status record table, so as to avoid conflicts caused by inconsistent data during the transfer process. Here, the number of distributed processes can be set according to actual processing needs. Specifically, the number of distributed processes in the distributed architecture can be made consistent, so as to ensure that the amount of tasks processed by each process is the same, so that the processing time is close and synchronization is achieved; the task allocation can also be dynamically adjusted according to the processing capacity of each distributed process, that is, different numbers of tasks are assigned to different distributed processes, so that processes with strong processing capabilities take on more tasks to achieve parallel processing and improve overall processing efficiency; through the distributed architecture and distributed processes, the transfer and processing of receivables can be carried out smoothly, and the processing efficiency and synchronization can be improved.

[0055] Step S206: If the request response returned by the bill processing system indicates that the lock is successful, the distributed lock is unlocked.

[0056] In this embodiment, a distributed lock service is called to unlock the bill, and the bill processing system determines the receivables to be unlocked and updates the lock status of the receivables, thereby marking the bill corresponding to the receivables as unlocked, so as to avoid conflicts caused by data inconsistency during the unlocking process. Specifically, the bill processing system can also adopt a distributed architecture in the process of processing bill unlocking to ensure data consistency during the unlocking process; the above-mentioned distributed lock is added to the bill by calling the distributed lock service, the transfer of each receivable is processed to a third-party institution, and the lock request is sent to the bill processing system through an interface call to lock the bill and update the lock status of each receivable. In this step, if the bill processing system returns a request response for successful locking, the distributed lock is further unlocked and subsequent operations are performed.

[0057] During the specific execution process, after the lock is successfully locked and a lock success request response is received, if a repayment or other bill operation request is received, the bill processing system calls the distributed lock service to unlock the distributed lock to realize the circulation of the bill and the transfer of repayment funds and the cancellation of funds. In an optional implementation manner provided in this embodiment, unlocking the distributed lock includes: Unlock the distributed lock of the bill and send an unlock request to the bill processing system, so that the bill processing system performs the following operations in response to the unlock request: Determine the receivables to be unlocked according to the second identifier carried in the received unlocking request, and update the lock state of the receivables to be unlocked in the lock state record table to an unlocked state; If it is detected that the lock status of each receivable in at least one receivable recorded in the lock status record table is unlocked, the bill is marked as unlocked.

[0058] In specific implementation, after completing the transfer processing of the receivables in the bill, an unlocking request is sent to the bill processing system through an interface call. The unlocking request contains a second identifier. After receiving the unlocking request, the bill processing system searches and determines all the receivables that need to be unlocked in the lock status record table according to the second identifier. For each determined receivable to be unlocked, the lock status of the receivable to be accepted in the lock status record table is updated to an unlocked state; then the lock status record table is checked. If it is found that the lock status of all receivables in the bill has been updated to an unlocked state, the overall status of the bill is marked as unlocked; through the locking and unlocking mechanism of the distributed lock, it is achieved that during the bill processing process, only one process can operate on the bill at the same time, avoiding data conflicts and concurrency problems. At the same time, strict control of the unlocking process also ensures the stability and reliability of the bill processing system when processing a large number of bills.

[0059] For example, the asset management system has completed the transfer processing of receivables debtId001 and debtId002 under the statement billNo001. At this time, the lock status record table records that the lock status of these two receivables is locked, and the processing batch number is batchNo001. After the transfer is completed, an unlocking request sent by the asset management system is received, which carries the processing batch number batchNo001. The corresponding receivables debtId001 and debtId002 are found according to the processing batch number, and the lock status of the receivables is updated to unlocked. After checking and confirming that all receivables have been unlocked, the bill billNo001 is marked as unlocked, allowing subsequent repayment operations to process the bill.

[0060] Further, when the bill processing system receives an unlocking request and determines the receivables to be unlocked according to the second identifier carried in the unlocking request, and updates the lock status of the receivables to be unlocked in the lock status record table, it is necessary to first detect whether the first identifier associated with the receivables to be unlocked in the lock status record table is consistent with the second identifier to ensure that the lock status of the receivables can be updated only when the identifiers match. In an optional implementation provided by this embodiment, after the operation of determining the receivables to be unlocked according to the second identifier carried in the received unlocking request is executed, and before the operation of updating the lock status of the receivables to be unlocked in the lock status record table to an unlocked state is executed, it also includes: Detecting whether the first identifier associated with the receivables to be unlocked in the lock status record table is consistent with the second identifier; If yes, executing the operation of updating the lock status of the receivables to be unlocked in the lock status record table to an unlocked state; If not, a request response rejecting the unlock request is received.

[0061] In specific implementation, first, an unlocking request is sent to the bill processing system through an interface call. The request includes a second identifier for identifying the receivables to be unlocked. When the request is received, the receivables to be unlocked specified in the request are determined, and then the lock status record table is queried to obtain the first identifier associated with the receivables to be unlocked, and the first identifier is compared with the second identifier in the unlocking request to verify the request. If the two are consistent, the lock status record table is updated, and the lock status of the receivables to be unlocked is updated from a locked state to an unlocked state. Finally, the lock status of all receivables in the bill is checked. If all are unlocked, the bill is marked as unlocked, indicating that the bill can be operated on. If the first identifier is inconsistent with the second identifier in the unlocking request, the bill processing system may reject the unlocking request and return a request response rejecting the unlocking, and may require the correct identifier to be provided again to ensure the consistency of the unlocking.

[0062] For example, it is necessary to unlock the receivable debtId001 under the bill number billId001. The receivable was previously locked by the processing batch number batchNo001. First, an unlock request is sent, and batchNo001 is carried in the request as the second identifier. After receiving the request, the lock status record table is queried to find the first identifier associated with debtId001, that is, batchNo001. Since the first identifier is consistent with the second identifier, the lock status of the receivable debtId001 is updated to unlocked. Then the lock status of all receivables under billId001 is checked, and it is found that they are all unlocked. Therefore, billId001 is marked as unlocked, and new operations are allowed on the bill. If the second identifier in the unlock request is inconsistent with the first identifier, the unlock request will be rejected and the existing lock status will remain unchanged.

[0063] In addition, after the above-mentioned locking check is performed on the bill, if the check fails, a lock failure request response is generated. Correspondingly, if a lock failure request response returned by the bill processing system is received, a rollback process is performed. In an optional implementation manner provided by this embodiment, after the lock failure request response operation is generated, the following is also included: Performing rollback processing of the transferred task; Optionally, the rollback process includes at least one of the following: unlocking the bill for calling the distributed lock service to add a distributed lock, and changing the owner of each receivable from the third-party institution to the funding provider corresponding to the credit limit.

[0064] In specific implementation, after receiving the response to the request for locking failure, first determine the bills and receivables that need to be rolled back, and then start the rollback mechanism, that is, send an unlock request through the distributed lock service interface to request unlocking of the previously locked bills. After the bill processing system unlocks the bill, it removes the locked status of the bill and updates the ownership record of the receivables at the same time, updating the ownership information from the third-party institution to the original funding provider to ensure the accuracy and consistency of the data. After the rollback process is completed, the rollback operation is recorded for subsequent auditing and troubleshooting.

[0065] It should be noted that the rollback process can be: unlocking the bill to which a distributed lock has been added, and / or changing the ownership of each receivable from a third-party institution to the original fund provider, and / or unlocking the bill to which a distributed lock has been added, and changing the ownership of each receivable from a third-party institution to the original fund provider.

[0066] As described above, in the process of transferring the receivables in the bill, a transfer request can be initiated to a third-party institution, and the corresponding receivables can be locked in the bill processing system to avoid data inconsistency caused by concurrent operations during the transfer process. During this process, if a repayment request is received, the bill processing system first checks the lock status records of all receivables in the bill: if a repayment is requested during the locking process, it will be detected that the bill or the receivables in the bill have been locked. At this time, the repayment process will not be executed immediately, but it will be necessary to wait until the lock status of all relevant receivables is unlocked before the repayment request can be processed; if a repayment is requested after the locking is completed, the lock status records of all receivables in the bill will be checked accordingly. If the lock status of all receivables is unlocked at this time, the repayment request will be allowed to be executed, and the repayment funds will be transferred to the third-party institution to write off the funds of each receivable in the bill.

[0067] Optionally, repayment can be processed in the following ways: Query the lock status of at least one receivable in the bill record in the lock status record table of the asset management system and the lock status record table of the bill processing system; If the lock status of each receivable in the bill is unlocked, the repayment funds will be transferred to the third-party institution to write off the funds of each receivable in the bill.

[0068] For example, customer A has a bill that includes two receivables. He now decides to transfer the two accounts to a third-party institution B. During the transfer process, he first requests the distributed lock service to lock the bill and sends a lock request to the bill processing system. After the lock request is successfully responded to, the lock status record table is updated to update the lock status of the two receivables to a locked status. After the transfer operation is completed, a request to unlock is initiated, and the bill processing system updates the lock status to an unlocked status. At this time, if customer A makes a repayment operation and detects that the lock status of all receivables in the bill are unlocked, the repayment funds can be transferred to the third-party institution B for payment verification.

[0069] To summarize, the present embodiment provides a method for bill processing based on distributed locks. In the process of bill processing based on distributed locks, a distributed lock is added to the bill by calling a distributed lock service, so that when processing the transfer task of accounts receivable in the bill, concurrency conflicts can be effectively prevented to ensure data consistency and atomicity of operations; a lock request is sent to the bill processing system through an interface call, so that the bill processing system can lock the bill and update the corresponding lock status in the lock status record table to a locked status, thereby improving the efficiency and security of bill processing; if the request response returned by the bill processing system is a successful lock, the distributed lock is unlocked. This processing mechanism ensures the smooth progress of the bill processing process, and also ensures the unlocking operation after the lock is successful, thereby avoiding long-term locking of resources.

[0070] The implementation process of the first distributed lock-based bill processing method provided above can be executed by the asset management system, and the implementation process of the second distributed lock-based bill processing method provided in the following method embodiment can be executed by the bill processing system. The two can cooperate with each other during the execution process. Therefore, when reading the above implementation process, you can refer to the corresponding content of the following second distributed lock-based bill processing method embodiment. Correspondingly, when reading the following second distributed lock-based bill processing method embodiment, you can also refer to the corresponding content of the above method embodiment.

[0071] The following is an example of an application of a distributed lock-based bill processing method provided in this embodiment in the scenario of bill transfer and repayment, and further describes the distributed lock-based bill processing method provided in this embodiment. Figure 3 , specifically including the following steps.

[0072] Step S302, obtaining the transfer task of the receivables in the bill.

[0073] Step S304, calling the distributed lock service statement to add a distributed lock.

[0074] Step S306: Send a lock request to the bill processing system through an interface call.

[0075] Step S314, retrieve the transfer task and execute the transfer operation of the receivables.

[0076] Step S316, completing the unlock notification task.

[0077] Step S320, receiving a lock successful request response.

[0078] Step S322, sending a notification unlock request.

[0079] The above steps S302 to S306, S314 to S316, and S320 to S322 provided in this embodiment are executed by the asset management system. It should be noted that the above steps S302 to S306, S314 to S316, and S320 to S322 executed by the asset management system and the steps S308 to S312, S318, and S324 to S332 executed by the bill processing system in the following embodiment can cooperate with each other during the execution process. Therefore, when reading this embodiment, please refer to the corresponding contents of steps S308 to S312, S318, and S324 to S332 provided in the following method embodiment, and when reading the following method embodiment, please refer to the corresponding contents of steps S302 to S306, S314 to S316, and S320 to S322 provided in this embodiment.

[0080] It should be noted that any one of steps S302 to S332 or any combination of multiple steps can be replaced by the corresponding technical means provided in the above steps S202 to S206 according to the needs of implementation and deployment, and will not be described one by one here.

[0081] One or more embodiments of the second distributed lock-based bill processing method provided in this specification are as follows: Reference Figure 4 The bill processing method based on distributed locks provided in this embodiment can be executed by a bill processing system, and specifically includes steps S402 to S406.

[0082] Step S402, receiving a lock request for each receivable in the bill sent by the asset management system through an interface call.

[0083] In actual applications, during the transfer process, receivables need to be frozen to maintain consistency in the processing of the transfer process. In order to reduce the duration of freezing receivables, that is, to reduce the impact caused by freezing receivables, a distributed architecture can be adopted. Specifically, the transfer task can be assigned to a distributed process, so that multiple transfer tasks can be processed in parallel, improving processing efficiency and reducing the waiting time of a single task, thereby shortening the overall freezing time of receivables. Distributed processing can be used to avoid conflicts and maintain data consistency during the transfer process.

[0084] The receivables refer to the receivables generated after the customer makes payments based on the credit line. Each receivable is a debt. Specifically, when a customer uses a product based on the credit line for consumption or expenditure, the lending institution will provide the customer with a corresponding credit line. After the customer uses this part of the line to make payments, the lending institution owns the receivables from the customer.

[0085] Optionally, the bill records at least one receivable obtained by payment based on the credit limit.

[0086] Among them, the credit line refers to a credit limit that can be used for payment set for users by financial institutions or third-party payment platforms based on the user's credit status and repayment ability. This limit represents the maximum amount that a customer can consume or trade through credit when the account balance is insufficient. The credit line is usually used in credit cards or other forms of financial products, allowing customers to consume within the limit and then repay within the agreed repayment period.

[0087] Optionally, the locking request is sent in conjunction with the asset management system to a third-party institution for transfer processing of the receivables; the third-party institution may be a financial institution, an asset management company or other types of investment entities, and the third-party institution realizes the transfer of assets by purchasing or taking over the receivables.

[0088] In actual applications, the transfer tasks of each receivable can be created after detecting the overdue duration after the repayment period of the bill expires. For example, the data platform can detect the overdue duration of the bill and create a corresponding transfer task when it is detected that the overdue duration after the repayment period of the bill expires exceeds the preset duration threshold.

[0089] Specifically, in the process of creating a transfer task, the transfer task can be created for a single receivable. In this scenario, each transfer task assembly only contains one receivable, that is, one receivable represents one bill. At this time, the transfer task and the receivable are one-to-one. In this case, the structure of the transfer task is relatively simple, and each task independently handles the transfer of one receivable.

[0090] In addition, transfer tasks can also be created for the entire bill. In this scenario, one bill is assembled under one transfer task, but multiple receivables can be processed in parallel under this bill. Multiple receivables correspond to one transfer task, that is, the transfer task and receivables are one-to-many. At this time, multiple receivables under the same bill can be merged into one transfer task to improve processing efficiency.

[0091] Step S404: If the distributed process detects that the bill has not been added with a distributed lock, the distributed lock service is called to lock the bill, and the lock status of each receivable is updated in the lock status record table.

[0092] As mentioned above, based on the lock request for each receivable in the bill sent by the asset management system through the interface call, if the distributed process detects that the bill has not been added with a distributed lock, in order to avoid concurrency conflicts when processing the bill and prevent the bill from being modified by other processes during the transfer process, the distributed lock service is called to add a distributed lock to the bill. The distributed lock ensures that during the bill transfer process, the transfer of different receivables under the same bill can be carried out in an orderly manner, avoiding lock conflicts and data inconsistencies. In actual applications, when it is detected that the overdue time after the repayment period of the bill exceeds the preset time threshold, the receivables in the bill are extracted and the corresponding transfer tasks are created. These transfer tasks are then assigned to the distributed process for processing. In the distributed process, when the asset management system initiates a transfer request for each receivable, the lock status record corresponding to the receivable in the bill is detected. If the lock status is unlocked, the lock processing is performed, and the lock status is updated to unlocked. At the same time, the corresponding identifier is associated with the receivable. This process is implemented through a distributed lock service to ensure the consistency of locks in a distributed environment.

[0093] Furthermore, in order to avoid data inconsistencies or conflicts during the transfer process, the relevant bills and receivables need to be frozen before the transfer task is executed. The freezing operation can be achieved by setting the corresponding lock status in the lock status record table. When the lock status is set to locked, any attempt to modify or access these bills and receivables will be delayed until the lock status is updated to unlocked, thereby ensuring that the status of the bills and receivables will not be changed by other operations during the transfer process to ensure data consistency.

[0094] During the specific execution process, the bill processing process adopts a distributed architecture, and the transfer tasks are assigned to multiple distributed processes for parallel processing to achieve efficient bill management and transfer operations. In the distributed architecture, the asset management system and the bill processing system communicate through interface calls, where the asset management system is responsible for initiating the transfer task of the receivables in the bill, and performing the transfer processing of each receivable to a third-party institution. The bill processing system is responsible for receiving lock requests, calling the distributed lock service to lock the bill, and updating the lock status of each receivable in the lock status record table; the distributed processes in the distributed architecture can independently read and process the transfer tasks. When it is detected that the bill has not been added with a distributed lock, the distributed lock service is called to lock the bill to achieve the correct execution of the transfer task and data synchronization.

[0095] In specific implementation, the distributed process determines whether the target bill has been locked by other processes by querying the status of the distributed lock service. If the bill is not locked, the distributed process sends a lock request to the distributed lock service, requesting to lock the bill to achieve security and consistency in bill processing. In an optional implementation provided by this embodiment, if the distributed process detects that the bill has not been added with a distributed lock, the distributed lock service is called to lock the bill, and before the lock status update operation is performed on each receivable in the lock status record table, it includes: Performing lock verification on the bill; If the verification passes, it is determined that no distributed lock is added to the bill; If the verification fails, a lock failure request response is generated.

[0096] Among them, the lock status record table refers to a data table used to manage and record the lock status during the receivables transfer process; for example, as shown in Table 2, the core fields of the lock status record table include: customer ID (Identification), that is, the customer's unique identifier, used to distinguish different customers; bill number, that is, the unique identifier of the bill, used to distinguish different bills under the customer; debt number, that is, the unique identifier of the receivable, used to distinguish different receivables under the same bill; processing batch number, that is, the batch identifier of the processing, used to distinguish batches of the same receivable at different times or different processing; lock status, that is, whether the current receivable is locked, used to control concurrent access during the receivables transfer process; the lock status record table records the lock status of each receivable during the receivables transfer process to ensure that only one processing batch can operate on a certain receivable at the same time, thereby avoiding concurrent conflicts and data inconsistency problems. At the same time, the lock status record table supports reentrancy of locks, that is, different receivables under the same bill can be locked in different batches, thereby improving the efficiency of bill processing.

[0097]

[0098] Table 2 Specifically, before trying to lock the bill, the bill is first locked to determine whether the bill has been locked by other processes. If the verification passes, the distributed lock service is called to add a distributed lock to the bill to ensure the consistency of the bill status during the transfer process. At the same time, the lock status of each receivable carried in the lock request is updated to "locked status" in the lock status record table, and a successful lock request response is generated and returned to the asset management system; if the verification fails, that is, the bill has been locked by other processes, a failed lock request response is generated to notify the asset management system that the lock operation cannot be performed at present to avoid potential data conflicts.

[0099] Further, the above statement is locked and verified. After the verification is passed, the distributed lock statement is called to add a distributed lock, and the lock status of each receivable is updated in the lock status record table. In an optional implementation provided by this embodiment, the lock status of each receivable is updated in the lock status record, including: Read the first identifier associated with each receivable in the lock status record table; If the read result is empty, determining the second identifier carried in the lock request as the first identifier of each receivable; If the read result is not empty, detecting whether the first identifier is consistent with the second identifier; If so, the lock status of each receivable carried by the lock request in the lock status record table is updated to a locked status; If not, a lock request rejection response is returned to the asset management system.

[0100] Among them, the first identifier refers to the identifier associated with each receivable in the lock status record table, which is used to record the processing batch to which the current receivable belongs, thereby distinguishing different processing operation batches, ensuring that operations within the same processing batch can be re-entered and operations between different processing batches are mutually exclusive; the second identifier refers to the identifier carried in the lock request, which is used to identify the current transfer operation batch.

[0101] In specific implementation, in order to ensure that the transfer operations of different receivables in the same bill can be carried out in an orderly manner and avoid unnecessary lock conflicts, when a transfer request for a certain receivable is initiated, the lock status of the receivable in the lock status record table is first checked. If the receivable is not currently locked, the first identifier associated with the receivable is further read. If the first identifier is empty, it indicates that the receivable has not been locked by any processing batch before. At this time, the second identifier carried in the lock request (that is, the identifier of the current transfer operation) is used as the first identifier of the receivable, and the lock status of the receivable is updated to the locked state; if the read first identifier is not empty, the first identifier is compared with the second identifier for consistency. If they are consistent, it indicates that the current transfer request belongs to the same processing batch, reentry is allowed, no new locking operation is performed, and the existing lock status remains unchanged; if they are inconsistent, it indicates that the current transfer request belongs to a different processing batch. In order to ensure that operations between different processing batches are mutually exclusive, a request response rejecting the lock is returned to prevent new transfer operations.

[0102] For example, suppose there are two receivables in the bill of customer A, namely receivable 1 and receivable 2. First, a transfer request for receivable 1 is initiated. At this time, a record is created for receivable 1 in the lock status record table, and the lock status of receivable 1 is updated to locked. At the same time, the second identifier (assuming batchNo001) is used as the first identifier. Then, a transfer request for receivable 2 is initiated in the same processing batch. First, it is checked that the lock status of receivable 2 is unlocked. The first identifier is read as empty, so the second identifier batchNo001 is used as the first identifier. The lock state of accounts receivable 2 is updated to the locked state. Based on this, the two transfer requests in the same processing batch are allowed to be executed, realizing the reentrancy of the operation. If a transfer request for accounts receivable 1 corresponding to a new processing batch batchNo002 is initiated when the processing batch of batchNo001 is not completed, and it is checked that the first identifier (batchNo001) and the second identifier (batchNo002) of accounts receivable 1 are inconsistent, then a request response for refusing to lock is returned to prevent new transfer operations, thereby realizing the mutual exclusivity of operations between different processing batches.

[0103] The above-mentioned bill processing process requires the cooperation of the asset management system and the bill processing system. During the transfer process, in order to avoid data inconsistencies and conflicts, the bill processing system needs to freeze the corresponding bills and receivables to ensure that no other changes occur during the transfer process. At the same time, in order to maintain synchronization, the asset management system also needs to lock the bills and receivables involved when initiating the transfer of receivables to achieve consistency in the transfer operation.

[0104] It should be noted that distributed locks are added to the bill through the distributed process and the lock status of the receivables in the bill is updated in the lock status record table, and the asset management system processes the transfer task through the distributed process, so as to avoid conflicts caused by inconsistent data during the transfer process. Here, the number of distributed processes can be set according to actual processing needs. Specifically, the number of distributed processes in the distributed architecture can be made consistent, so as to ensure that the amount of tasks processed by each process is the same, so that the processing time is close and synchronization is achieved; task allocation can also be dynamically adjusted according to the processing capacity of each distributed process, that is, different numbers of tasks are assigned to different distributed processes, so that processes with strong processing capabilities take on more tasks to achieve parallel processing and improve overall processing efficiency; through the distributed architecture and distributed processes, the transfer and processing of receivables can be smoothly carried out, and processing efficiency and synchronization can be improved.

[0105] Step S306: Generate a request response for the lock request and return it to the asset management system.

[0106] In this embodiment, by determining the receivables to be unlocked and updating the lock status of the receivables, the bill corresponding to the receivables is marked as unlocked, and the asset management system calls the distributed lock service to unlock the bill, thereby avoiding conflicts caused by data inconsistency during the unlocking process. Specifically, the asset management system can also adopt a distributed architecture in the process of processing the bill unlocking to ensure the consistency of data during the unlocking process; after the above-mentioned distributed process detects that the distributed lock is not added to the bill, it calls the distributed lock service to add a distributed lock to the bill, and updates the lock status of each receivable in the lock status record table. In this step, a request response to the lock request is generated to return to the asset management system, and subsequent operations are performed.

[0107] During the specific execution process, when the lock is successfully locked and a request response of successful lock is returned, if the asset management system receives a repayment or other bill operation request, the distributed lock is unlocked to realize the circulation of the bill and the transfer of repayment funds and the cancellation of funds, etc. In an optional implementation manner provided by this embodiment, the step of generating a request response to the lock request and returning it to the asset management system also includes: Unlocking the distributed lock of the bill; The unlocking of the distributed lock of the bill includes: Determine the receivables to be unlocked according to the second identifier carried in the received unlocking request, and update the lock state of the receivables to be unlocked in the lock state record table to an unlocked state; If it is detected that the lock status of each receivable in at least one receivable recorded in the lock status record table is unlocked, the bill is marked as unlocked.

[0108] In specific implementation, after completing the transfer processing of receivables in the bill, the asset management system sends an unlocking request through an interface call, and the unlocking request contains a second identifier. After receiving the unlocking request, the lock status record table is searched and determined according to the second identifier. For each determined receivable to be unlocked, the lock status of the receivable to be accepted in the lock status record table is updated to an unlocked state; then the lock status record table is checked, and if it is found that the lock status of all receivables in the bill has been updated to an unlocked state, the overall status of the bill is marked as unlocked; through the locking and unlocking mechanism of the distributed lock, it is achieved that during the bill processing process, only one process can operate on the bill at the same time, avoiding data conflicts and concurrency problems. At the same time, strict control of the unlocking process also ensures the stability and reliability of the bill processing system when processing a large number of bills.

[0109] For example, assuming that the asset management system has completed the transfer processing of receivables debtId001 and debtId002 under statement billNo001, the lock status record table records that the lock status of these two receivables is locked, and the processing batch number is batchNo001. After the transfer is completed, an unlocking request is received from the asset management system, which carries the processing batch number batchNo001. The corresponding receivables debtId001 and debtId002 are found according to the processing batch number, and the lock status of the receivables is updated to unlocked. After checking and confirming that all receivables have been unlocked, the bill billNo001 is marked as unlocked, allowing subsequent repayment operations to process the bill.

[0110] Further, when receiving an unlock request and determining the receivables to be unlocked according to the second identifier carried in the unlock request, and updating the lock status of the receivables to be unlocked in the lock status record table, it is first necessary to detect whether the first identifier associated with the receivables to be unlocked in the lock status record table is consistent with the second identifier, to ensure that the lock status of the receivables can be updated only when the identifiers match. In an optional implementation provided by this embodiment, after the operation of determining the receivables to be unlocked according to the second identifier carried in the received unlock request is executed, and before the operation of updating the lock status of the receivables to be unlocked in the lock status record table to an unlocked state is executed, it also includes: Detecting whether the first identifier associated with the receivables to be unlocked in the lock status record table is consistent with the second identifier; If yes, executing the operation of updating the lock status of the receivables to be unlocked in the lock status record table to an unlocked state; If not, the unlock request is rejected.

[0111] In specific implementation, an unlocking request is first received, and the unlocking request includes a second identifier for identifying the receivables to be unlocked. When the request is received, the receivables to be unlocked specified in the request are determined, and then the lock status record table is queried to obtain the first identifier associated with the receivables to be unlocked, and the first identifier is compared with the second identifier in the unlocking request to verify the request. If the two are consistent, the lock status record table is updated, and the lock status of the receivables to be unlocked is updated from a locked state to an unlocked state. Finally, the lock status of all receivables in the bill is checked. If all are unlocked, the bill is marked as unlocked, indicating that the bill can be subjected to new operations; if the first identifier is inconsistent with the second identifier in the unlocking request, the unlocking request can be rejected, and the correct identifier can be required to be re-provided to ensure the consistency of the unlocking.

[0112] For example, suppose you need to unlock the receivable debtId001 under the bill number billId001. The receivable was previously locked by the processing batch number batchNo001. First, send an unlock request, and carry batchNo001 as the second identifier in the request. After receiving the request, query the lock status record table to find the first identifier associated with debtId001, that is, batchNo001. Since the first identifier is consistent with the second identifier, the lock status of the receivable debtId001 is updated to unlocked. Then check the lock status of all receivables under billId001, and find that they are all unlocked. Therefore, mark billId001 as unlocked, and allow new operations on the bill. If the second identifier in the unlock request is inconsistent with the first identifier, the unlock request will be rejected and the existing lock status will remain unchanged.

[0113] In addition, after the above-mentioned lock verification of the bill, if the verification fails, a lock failure request response is generated. Correspondingly, if a lock failure request response returned by the bill processing system is received, a rollback process is performed. In an optional implementation manner provided by this embodiment, the following operations are performed after the lock failure request response is generated: Performing rollback processing of the transferred task; Optionally, the rollback process includes at least one of the following: unlocking the bill for calling the distributed lock service to add a distributed lock, and changing the owner of each receivable from the third-party institution to the funding provider corresponding to the credit limit.

[0114] In specific implementation, after the asset management system receives a request for failed locking, it first determines the bills and receivables that need to be rolled back, and then starts the rollback mechanism, that is, sending an unlock request through the distributed lock service interface to request unlocking of the previously locked bills. After receiving the unlock request sent by the asset management system, it performs the unlocking process and removes the locked status of the bill. At the same time, it updates the ownership record of the receivables and updates the ownership information from the third-party institution to the original funding provider to ensure the accuracy and consistency of the data. After the rollback process is completed, the rollback operation is recorded for subsequent auditing and troubleshooting.

[0115] It should be noted that the rollback process can be: unlocking the bill to which a distributed lock has been added, and / or changing the ownership of each receivable from a third-party institution to the original fund provider, and / or unlocking the bill to which a distributed lock has been added, and changing the ownership of each receivable from a third-party institution to the original fund provider.

[0116] As described above, in the process of transferring the receivables in the bill, a transfer request can be initiated to a third-party institution, and the corresponding receivables can be locked in the bill processing system to avoid data inconsistency caused by concurrent operations during the transfer process. During this process, if a repayment request is received, the bill processing system first checks the lock status records of all receivables in the bill: if a repayment is requested during the locking process, it will be detected that the bill or the receivables in the bill have been locked. At this time, the repayment process will not be executed immediately, but it will be necessary to wait until the lock status of all relevant receivables is unlocked before the repayment request can be processed; if a repayment is requested after the locking is completed, the lock status records of all receivables in the bill will be checked accordingly. If the lock status of all receivables is unlocked at this time, the repayment request will be allowed to be executed, and the repayment funds will be transferred to the third-party institution to write off the funds of each receivable in the bill.

[0117] Optionally, repayment can be processed in the following ways: Query the lock status of at least one receivable in the bill record in the lock status record table of the asset management system and the lock status record table of the bill processing system; If the lock status of each receivable in the bill is unlocked, the repayment funds will be transferred to the third-party institution to write off the funds of each receivable in the bill.

[0118] For example, customer A has a bill that includes two receivables. He now decides to transfer the two accounts to a third-party institution B. During the transfer process, he first requests the distributed lock service to lock the bill and sends a lock request to the bill processing system. After the lock request is successfully responded to, the lock status record table is updated to update the lock status of the two receivables to a locked status. After the transfer operation is completed, a request to unlock is initiated, and the bill processing system updates the lock status to an unlocked status. At this time, if customer A makes a repayment operation and detects that the lock status of all receivables in the bill are unlocked, the repayment funds can be transferred to the third-party institution B for payment verification.

[0119] To sum up, the present embodiment provides a bill processing method based on distributed locks. In the process of bill processing based on distributed locks, the method first receives the lock request for each receivable in the bill sent by the asset management system through an interface call, and then detects whether the target bill has been locked. If the distributed process detects that the target bill has not added a distributed lock, the distributed lock service is called to lock the bill, and the lock status of each receivable in the lock status record table is updated to a locked status, thereby improving the efficiency and security of bill processing. After generating a request response to the lock request and returning it to the asset management system, if the request response is a request response for a failed lock, it indicates that the corresponding bill or the receivables in the bill have been locked and the transfer operation cannot be performed; if the request response is a request response for a successful lock, it indicates that the bill or the receivables in the bill are not locked, and the transfer operation can be performed. This processing mechanism ensures the smooth progress of the bill processing process.

[0120] The following is an example of an application of a distributed lock-based bill processing method provided in this embodiment in the scenario of bill transfer and repayment, and further describes the distributed lock-based bill processing method provided in this embodiment. Figure 3 , specifically including the following steps.

[0121] Step S308, receiving a lock request.

[0122] Step S310, detecting the lock status record of the receivables in the bill.

[0123] Step S312: If the lock status of each account receivable is unlocked, execute the locking process, update the lock status of each account receivable and associate the processing batch number.

[0124] Step S318, returning a successful locking request response to the asset management system.

[0125] Step S324, receiving an unlock notification and performing an unlock operation.

[0126] Step S326, updating the lock status of each receivable in the lock status record table.

[0127] Step S328, check the lock status of all receivables in the bill.

[0128] Step S330, confirm that the lock status of all accounts receivable in the bill is unlocked, and release the lock of the bill.

[0129] Step S332, perform repayment processing to write off each receivable.

[0130] It should be noted that any one of steps S302 to S332 or any combination of multiple steps can be replaced by the corresponding technical means provided in the above steps S402 to S406 according to the needs of implementation and deployment, and will not be described one by one here.

[0131] The first embodiment of a bill processing device based on a distributed lock provided in this specification is as follows: In the above-mentioned embodiment, a first distributed lock-based bill processing method is provided, and correspondingly, a first distributed lock-based bill processing device is also provided, which is described below with reference to the accompanying drawings.

[0132] Reference Figure 5 , which shows a schematic diagram of an embodiment of a bill processing device based on a distributed lock provided in this embodiment.

[0133] Since the device embodiment corresponds to the method embodiment, the description is relatively simple, and the relevant parts can refer to the corresponding description of the method embodiment provided above. The device embodiment described below is only illustrative.

[0134] This embodiment provides a bill processing device based on a distributed lock, the device comprising: The task acquisition module 502 is configured to acquire a task of transferring receivables in a bill allocated to a distributed process; the bill records at least one receivable obtained by payment based on a credit limit; The calling module 504 is configured to call the distributed lock service to add a distributed lock to the bill, transfer each receivable to a third-party institution, and send a lock request to the bill processing system through an interface call, so that the bill processing system locks the bill and updates the lock status of each receivable in the lock status record table; The unlocking module 506 is configured to unlock the distributed lock if the request response returned by the bill processing system indicates that the lock is successful.

[0135] The second embodiment of the bill processing device based on distributed lock provided in this specification is as follows: In the above-mentioned embodiment, a second distributed lock-based bill processing method is provided, and correspondingly, a second distributed lock-based bill processing device is also provided, which is described below with reference to the accompanying drawings.

[0136] Reference Figure 6 , which shows a schematic diagram of an embodiment of a bill processing device based on a distributed lock provided in this embodiment.

[0137] Since the device embodiment corresponds to the method embodiment, the description is relatively simple, and the relevant parts can refer to the corresponding description of the method embodiment provided above. The device embodiment described below is only illustrative.

[0138] This embodiment provides a bill processing device based on a distributed lock, the device comprising: The receiving module 602 is configured to receive a lock request for each receivable in a bill sent by the asset management system through an interface call; the bill records at least one receivable obtained by payment based on a credit limit; the lock request is sent in coordination with the asset management system to transfer the receivables to a third party institution; The locking module 604 is configured to call the distributed lock service to lock the bill if the distributed process detects that the bill has not been added with a distributed lock, and update the lock status of each receivable in the lock status record table; The response module 606 is configured to generate a request response for the lock request and return it to the asset management system.

[0139] The first embodiment of a bill processing device based on a distributed lock provided in this specification is as follows: Corresponding to the first distributed lock-based bill processing method described above, based on the same technical concept, one or more embodiments of this specification further provide a distributed lock-based bill processing device, which is used to execute the first distributed lock-based bill processing method provided above. Figure 7 A schematic diagram of the structure of a bill processing device based on a distributed lock provided in one or more embodiments of this specification.

[0140] This embodiment provides a distributed lock-based bill processing device, including: like Figure 7As shown, the bill processing device based on the distributed lock may have relatively large differences due to different configurations or performances, and may include one or more processors 701 and memory 702, and the memory 702 may store one or more storage applications or data. Among them, the memory 702 may be a short-term storage or a persistent storage. The application stored in the memory 702 may include one or more modules (not shown in the figure), and each module may include a series of computer executable instructions in the bill processing device based on the distributed lock. Furthermore, the processor 701 may be configured to communicate with the memory 702, and execute a series of computer executable instructions in the memory 702 on the bill processing device based on the distributed lock. The bill processing device based on the distributed lock may also include one or more power supplies 703, one or more wired or wireless network interfaces 704, one or more input / output interfaces 705, one or more keyboards 706, etc.

[0141] In a specific embodiment, a bill processing device based on a distributed lock includes a memory and one or more programs, wherein the one or more programs are stored in the memory, and the one or more programs may include one or more modules, and each module may include a series of computer executable instructions in the bill processing device based on a distributed lock, and the one or more programs are configured to be executed by one or more processors, including computer executable instructions for performing the following: Obtaining a task for transferring receivables in a bill assigned to a distributed process; the bill records at least one receivable obtained by payment based on a credit limit; Calling the distributed lock service to add a distributed lock to the bill, transferring each receivable to a third-party institution, and sending a lock request to the bill processing system through an interface call, so that the bill processing system locks the bill and updates the lock status of each receivable in the lock status record table; If the request response returned by the bill processing system indicates that the lock is successful, the distributed lock is unlocked.

[0142] The second embodiment of the bill processing device based on the distributed lock provided in this specification is as follows: Corresponding to the second distributed lock-based bill processing method described above, based on the same technical concept, one or more embodiments of this specification also provide a second distributed lock-based bill processing device, which is used to execute the second distributed lock-based bill processing method provided above. Figure 8 A schematic diagram of the structure of a bill processing device based on a distributed lock provided in one or more embodiments of this specification.

[0143] This embodiment provides a distributed lock-based bill processing device, including: like Figure 8 As shown, the bill processing device based on the distributed lock may have relatively large differences due to different configurations or performances, and may include one or more processors 801 and memory 802, and the memory 802 may store one or more storage applications or data. Among them, the memory 802 may be a short-term storage or a persistent storage. The application stored in the memory 802 may include one or more modules (not shown in the figure), and each module may include a series of computer executable instructions in the bill processing device based on the distributed lock. Furthermore, the processor 801 may be configured to communicate with the memory 802, and execute a series of computer executable instructions in the memory 802 on the bill processing device based on the distributed lock. The bill processing device based on the distributed lock may also include one or more power supplies 803, one or more wired or wireless network interfaces 804, one or more input / output interfaces 805, one or more keyboards 806, etc.

[0144] In a specific embodiment, a bill processing device based on a distributed lock includes a memory and one or more programs, wherein the one or more programs are stored in the memory, and the one or more programs may include one or more modules, and each module may include a series of computer executable instructions in the bill processing device based on a distributed lock, and the one or more programs are configured to be executed by one or more processors, including computer executable instructions for performing the following: Receiving a lock request for each receivable in a bill sent by the asset management system through an interface call; the bill records at least one receivable obtained by payment based on a credit limit; the lock request is sent in coordination with the asset management system to transfer the receivables to a third party institution; If the distributed process detects that the bill has not been added with a distributed lock, it calls the distributed lock service to lock the bill and updates the lock status of each receivable in the lock status record table; A request response for the lock request is generated and returned to the asset management system.

[0145] The first computer-readable storage medium embodiment provided in this specification is as follows: Corresponding to the first distributed lock-based bill processing method described above, based on the same technical concept, one or more embodiments of this specification also provide a first computer-readable storage medium.

[0146] The computer-readable storage medium provided in this embodiment is used to store computer-executable instructions, and the computer-executable instructions implement the following process when executed: Obtaining a task for transferring receivables in a bill assigned to a distributed process; the bill records at least one receivable obtained by payment based on a credit limit; Calling the distributed lock service to add a distributed lock to the bill, transferring each receivable to a third-party institution, and sending a lock request to the bill processing system through an interface call, so that the bill processing system locks the bill and updates the lock status of each receivable in the lock status record table; If the request response returned by the bill processing system indicates that the lock is successful, the distributed lock is unlocked.

[0147] It should be noted that the embodiment of a computer-readable storage medium in this specification and the embodiment of the first bill processing method based on a distributed lock in this specification are based on the same inventive concept. Therefore, the specific implementation of this embodiment can refer to the implementation of the aforementioned corresponding method, and the repeated parts will not be repeated.

[0148] The second computer-readable storage medium embodiment provided in this specification is as follows: Corresponding to the second distributed lock-based bill processing method described above, based on the same technical concept, one or more embodiments of this specification also provide a second computer-readable storage medium.

[0149] The computer-readable storage medium provided in this embodiment is used to store computer-executable instructions, and the computer-executable instructions implement the following process when executed: Receiving a lock request for each receivable in a bill sent by the asset management system through an interface call; the bill records at least one receivable obtained by payment based on a credit limit; the lock request is sent in coordination with the asset management system to transfer the receivables to a third party institution; If the distributed process detects that the bill has not been added with a distributed lock, it calls the distributed lock service to lock the bill and updates the lock status of each receivable in the lock status record table; A request response for the lock request is generated and returned to the asset management system.

[0150] It should be noted that the embodiment of a computer-readable storage medium in this specification and the embodiment of the second bill processing method based on distributed locks in this specification are based on the same inventive concept. Therefore, the specific implementation of this embodiment can refer to the implementation of the aforementioned corresponding method, and the repeated parts will not be repeated.

[0151] Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referenced to each other. Each embodiment focuses on the differences from other embodiments. For example, the device embodiment, equipment embodiment and computer-readable storage medium embodiment are similar to the method embodiment, so the description is relatively simple. To read the relevant contents in the device embodiment, equipment embodiment and computer-readable storage medium embodiment, please refer to the partial description of the method embodiment.

[0152] The above is a description of a specific embodiment of the specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0153] In the 1930s, improvements to a technology could be clearly distinguished as hardware improvements (for example, improvements to circuit structures such as diodes, transistors, switches, etc.) or software improvements (improvements to method flows). However, with the development of technology, many of today's method flow improvements can be regarded as direct improvements to hardware circuit structures. Designers almost always obtain the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that an improvement in a method flow cannot be implemented using hardware entity modules. For example, a programmable logic device (PLD) (such as a field programmable gate array (FPGA)) is such an integrated circuit whose logical function is determined by the user's programming of the device. Designers can "integrate" a digital system on a PLD by programming it themselves, without having to ask chip manufacturers to design and produce dedicated integrated circuit chips. Moreover, nowadays, instead of manually making integrated circuit chips, this kind of programming is mostly implemented by "logic compiler" software, which is similar to the software compiler used when developing and writing programs, and the original code before compilation must also be written in a specific programming language, which is called hardware description language (HDL). There is not only one kind of HDL, but many kinds, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. The most commonly used ones are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also know that it is only necessary to program the method flow slightly in the above-mentioned hardware description languages ​​and program it into the integrated circuit, and then it is easy to obtain the hardware circuit that implements the logic method flow.

[0154] The controller may be implemented in any suitable manner, for example, the controller may take the form of a microprocessor or processor and a computer-readable medium storing a computer-readable program code (e.g., software or firmware) executable by the (micro)processor, a logic gate, a switch, an application-specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller, examples of which include but are not limited to the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320, and the memory controller may also be implemented as part of the control logic of the memory. It is also known to those skilled in the art that, in addition to implementing the controller in a purely computer-readable program code manner, the controller may be implemented in the form of a logic gate, a switch, an application-specific integrated circuit, a programmable logic controller, and an embedded microcontroller by logically programming the method steps. Therefore, such a controller may be considered as a hardware component, and the devices for implementing various functions included therein may also be considered as structures within the hardware component. Or even, the devices for implementing various functions may be considered as both software modules for implementing the method and structures within the hardware component.

[0155] The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0156] For the convenience of description, the above devices are described in terms of functions and are divided into various units. Of course, when implementing the embodiments of this specification, the functions of each unit can be implemented in the same or multiple software and / or hardware.

[0157] It should be understood by those skilled in the art that one or more embodiments of the present specification may be provided as a method, system or computer program product. Therefore, one or more embodiments of the present specification may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present specification may take the form of a computer program product implemented on one or more computer-readable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0158] This specification is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of this specification. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0159] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0160] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0161] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0162] Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0163] Computer-readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer-readable instructions, data structures, program modules or other data. Examples of computer-readable storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory media such as modulated data signals and carrier waves.

[0164] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of further restrictions, the elements defined by the sentence "includes at least one ..." do not exclude the presence of other identical elements in the process, method, commodity or device including the elements.

[0165] One or more embodiments of the present specification may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. One or more embodiments of the present specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules may be located in local and remote computer storage media, including storage devices.

[0166] The above description is only an embodiment of this document and is not intended to limit this document. For those skilled in the art, this document may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this document should be included in the scope of the claims of this document.

Claims

1. A bill processing method based on distributed locks, comprising: Get the task of transferring the receivables in the bill to the distributed process; The bill records at least one receivable obtained by payment based on the credit line; Calling the distributed lock service to add a distributed lock to the bill, transferring each receivable to a third-party institution, and sending a lock request to the bill processing system through an interface call, so that the bill processing system locks the bill and updates the lock status of each receivable in the lock status record table; If the request response returned by the bill processing system indicates that the lock is successful, the distributed lock is unlocked.

2. According to the distributed lock-based bill processing method of claim 1, the transfer task is generated in the following manner: Detecting whether the overdue period after the repayment period of the bill exceeds a preset time threshold; If so, extract each receivable in the bill and create a transfer task for each receivable, or create a transfer task for the bill.

3. According to the distributed lock-based bill processing method of claim 1, the transfer of each receivable to a third-party institution includes: Merge the accounts receivable in the bill, create a transfer task based on the merged amount, and assign the transfer task to a distributed process for ownership transfer processing; or, A respective transfer task is created for each receivable in the bill, and the created transfer task is assigned to a distributed process for ownership transfer processing.

4. According to the distributed lock-based bill processing method of claim 3, after the ownership transfer process is completed, the owner of each receivable is changed from the fund provider corresponding to the credit line to the third-party institution.

5. According to the distributed lock-based bill processing method of claim 1, the step of locking the bill and updating the lock status of each receivable in the lock status record table comprises: Performing lock verification on the bill; If the verification is passed, the distributed lock service is called to add a distributed lock to the bill, and the lock status of each receivable carried by the lock request in the lock status record table is updated to a locked state, and a lock success request response is generated; If the verification fails, a lock failure request response is generated.

6. According to the distributed lock-based bill processing method of claim 5, after the generation of the lock failure request response operation is executed, it also includes: Performing rollback processing of the transferred task; Among them, the rollback processing includes at least one of the following: unlocking the bill for calling the distributed lock service to add a distributed lock, and changing the owner of each receivable from the third-party institution to the funding provider corresponding to the credit line.

7. According to the distributed lock-based bill processing method of claim 1, the updating of the lock status of each receivable in the lock status record table comprises: Read the first identifier associated with each receivable in the lock status record table; If the read result is empty, determining the second identifier carried in the lock request as the first identifier of each receivable; If the read result is not empty, detecting whether the first identifier is consistent with the second identifier; If so, the lock status of each receivable carried in the lock request in the lock status record table is updated to a locked status; If not, a lock request rejection response is returned to the asset management system.

8. According to the bill processing method based on distributed locks according to claim 1, unlocking the distributed lock comprises: Unlock the distributed lock of the bill, and send an unlock request to the bill processing system, so that the bill processing system performs the following operations in response to the unlock request: Determine the receivables to be unlocked according to the second identifier carried in the received unlocking request, and update the lock state of the receivables to be unlocked in the lock state record table to an unlocked state; If it is detected that the lock status of each receivable in at least one receivable recorded in the lock status record table is unlocked, the bill is marked as unlocked.

9. The bill processing method based on distributed locks according to claim 8, after the operation of determining the receivables to be unlocked according to the second identifier carried in the received unlock request is executed, and before the operation of updating the lock state of the receivables to be unlocked in the lock state record table to an unlocked state is executed, it also includes: Detecting whether the first identifier associated with the receivables to be unlocked in the lock status record table is consistent with the second identifier; If so, the operation of updating the lock status of the receivables to be unlocked in the lock status record table to an unlocked state is performed.

10. According to the distributed lock-based bill processing method of claim 1, after the transfer processing operation of each receivable to the third-party institution is performed, it also includes: Querying the lock status of at least one receivable in the bill record in the lock status record table; If the lock status of each receivable in the bill is unlocked, the repayment funds will be transferred to the third-party institution to write off the funds of each receivable in the bill.

11. A bill processing method based on distributed locks, comprising: Receive the lock request for each receivable in the bill sent by the asset management system through the interface call; The bill records at least one receivable obtained by payment based on the credit limit; the lock request is sent to a third party institution in coordination with the asset management system for transfer processing of each receivable; If the distributed process detects that the bill has not been added with a distributed lock, it calls the distributed lock service to lock the bill and updates the lock status of each receivable in the lock status record table; A request response for the lock request is generated and returned to the asset management system.

12. The bill processing method based on distributed lock according to claim 11, if the distributed process detects that the bill has not been added with a distributed lock, the distributed lock service is called to lock the bill, and before the lock status of each receivable is updated in the lock status record table, the method comprises: Performing lock verification on the bill; If the verification passes, it is determined that no distributed lock is added to the bill; If the verification fails, a lock failure request response is generated.

13. According to the distributed lock-based bill processing method of claim 12, after the generation of the lock failure request response operation is executed, it also includes: Performing rollback processing of the transferred task; Among them, the rollback processing includes at least one of the following: unlocking the bill for calling the distributed lock service to add a distributed lock, and changing the owner of each receivable from the third-party institution to the funding provider corresponding to the credit line.

14. The bill processing method based on distributed locks according to claim 11, wherein the updating of the lock status of each receivable in the lock status record table comprises: Read the first identifier associated with each receivable in the lock status record table; If the read result is empty, determining the second identifier carried in the lock request as the first identifier of each receivable; If the read result is not empty, detecting whether the first identifier is consistent with the second identifier; If so, the lock status of each receivable carried in the lock request in the lock status record table is updated to a locked status; If not, a lock request rejection response is returned to the asset management system.

15. According to the distributed lock-based bill processing method of claim 11, after the step of generating a request response to the lock request and returning it to the asset management system is executed, it also includes: Unlocking the distributed lock of the bill; The unlocking of the distributed lock of the bill includes: Determine the receivables to be unlocked according to the second identifier carried in the received unlocking request, and update the lock state of the receivables to be unlocked in the lock state record table to an unlocked state; If it is detected that the lock status of each receivable in at least one receivable recorded in the lock status record table is unlocked, the bill is marked as unlocked.

16. The bill processing method based on distributed locks according to claim 15, after the operation of determining the receivables to be unlocked according to the second identifier carried in the received unlock request is executed, and before the operation of updating the lock state of the receivables to be unlocked in the lock state record table to an unlocked state is executed, it also includes: Detecting whether the first identifier associated with the receivables to be unlocked in the lock status record table is consistent with the second identifier; If so, the operation of updating the lock status of the receivables to be unlocked in the lock status record table to an unlocked state is performed.

17. The bill processing method based on distributed locks according to claim 11, after the transfer of the receivables to the third-party institution, further comprises: Querying the lock status of at least one receivable in the bill record in the lock status record table; If the lock status of each receivable in the bill is unlocked, the repayment funds will be transferred to the third-party institution to write off the funds of each receivable in the bill.

18. A bill processing device based on distributed locks, comprising: A task acquisition module is configured to acquire a task of transferring receivables in a bill allocated to a distributed process; The bill records at least one receivable obtained by payment based on the credit line; A calling module is configured to call a distributed lock service to add a distributed lock to the bill, perform transfer processing of each receivable to a third-party institution, and send a lock request to the bill processing system through an interface call, so that the bill processing system locks the bill and updates the lock status of each receivable in the lock status record table; The unlocking module is configured to unlock the distributed lock if the request response returned by the bill processing system is that the lock is successful.

19. A bill processing device based on a distributed lock, comprising: A receiving module is configured to receive a lock request for each receivable in the bill sent by the asset management system through an interface call; The bill records at least one receivable obtained by payment based on the credit limit; the lock request is sent to a third party institution in coordination with the asset management system for transfer processing of each receivable; The locking module is configured to call the distributed lock service to lock the bill if the distributed process detects that the bill has not been added with a distributed lock, and update the lock status of each receivable in the lock status record table; The response module is configured to generate a request response for the locking request and return it to the asset management system.

20. A bill processing device based on a distributed lock, comprising: processor; and a memory configured to store computer executable instructions that, when executed, cause the processor to: Obtaining a task for transferring receivables in a bill assigned to a distributed process; the bill records at least one receivable obtained by payment based on a credit limit; Calling the distributed lock service to add a distributed lock to the bill, transferring each receivable to a third-party institution, and sending a lock request to the bill processing system through an interface call, so that the bill processing system locks the bill and updates the lock status of each receivable in the lock status record table; If the request response returned by the bill processing system indicates that the lock is successful, the distributed lock is unlocked.

21. A bill processing device based on a distributed lock, comprising: processor; and a memory configured to store computer executable instructions that, when executed, cause the processor to: Receiving a lock request for each receivable in a bill sent by the asset management system through an interface call; the bill records at least one receivable obtained by payment based on a credit limit; the lock request is sent in coordination with the asset management system to transfer the receivables to a third party institution; If the distributed process detects that the bill has not been added with a distributed lock, it calls the distributed lock service to lock the bill and updates the lock status of each receivable in the lock status record table; A request response for the lock request is generated and returned to the asset management system.

22. A computer-readable storage medium for storing computer-executable instructions, wherein the computer-executable instructions implement the steps of the method of claim 1 when executed.

23. A computer-readable storage medium for storing computer-executable instructions, wherein the computer-executable instructions implement the steps of the method of claim 11 when executed.

Images