Fund Management Method, System, Electronic Device and Storage Medium

Abstract

The present application provides a fund management method, system, electronic device and storage medium. The method is applied to a fund management system, which includes a task manager, a database, a message queue, a verification processor, a release-freezing processor, a control center processor and a transaction processor. In this method, the task manager first generates a first fund management message carrying a verification identifier according to the fund management tasks in the database and sends it to the message queue. Then, the verification processor, the release-freezing processor, the control center processor and the transaction processor all identify and consume the messages with a certain specific identifier from the message queue, and return messages with another specific identifier to the message queue after processing, so as to complete the fund management tasks. The present application realizes the high decoupling and asynchronous processing of each processor, and the whole system is simpler, more stable and efficient, and is convenient for maintenance.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular, to a fund management method, system, electronic device, and storage medium. Background Art

[0002] Moving money is a very common operation among many bank operations. The functions of ordinary customers such as transferring money, repaying credit cards, and repaying loans can all be regarded as money moving processes in the system background. The money moving process is a very complex business processing process, and the corresponding system implementation is also relatively complex. There are many intermediate links, and different steps need to be taken in different scenarios. The current management of the money moving process is mainly implemented based on the workflow mode, that is, each link is executed in sequence until all links are completed. However, since there are certain steps in each link that cannot obtain results immediately, or certain steps are prone to exceptions and need to be retried, the workflow-based method often causes subsequent steps to be unable to proceed normally or exceptions to occur, making the current management of the money moving process very complicated and difficult to maintain.

[0003] Therefore, there are technical problems in the current bank money moving business that the process is cumbersome and difficult to maintain, and improvement is needed. Summary of the Invention

[0004] Embodiments of this application provide a fund management method, system, electronic device, and storage medium to alleviate the technical problems of cumbersome process and difficult maintenance in the current bank money moving business.

[0005] To solve the above technical problems, the embodiments of this application provide the following technical solutions:

[0006] This application provides a fund management method for a fund management system. The fund management system includes a task manager, a database, a message queue, a verification processor, a release of stop payment processor, a control center processor, and a transaction processor. The fund management method includes:

[0007] The task manager generates and sends a first fund management message carrying a verification identifier to the message queue according to the fund management tasks in the database. The fund management tasks include at least one fund transfer task, and each fund transfer task includes the transfer of funds between at least two fund cards;

[0008] The verification processor consumes the first fund management message according to the verification identifier, performs a verification operation on the database based on the first fund management message, obtains a verification result, and generates and returns a second fund management message carrying a release of stop payment identifier to the message queue according to the verification result;

[0009] The unlocking and stopping payment processor consumes the second fund management information according to the unlocking and stopping payment identifier, performs an unlocking and stopping payment operation on the database based on the second fund management information, obtains an unlocking and stopping payment result, generates and returns a third fund management message carrying a control identifier to the message queue according to the unlocking and stopping payment result;

[0010] The control center processor consumes the third fund management message according to the control identifier, performs a control operation on the database based on the third fund management information, obtains a control result, and when the control result indicates that the management termination condition is not met, generates and returns a fourth fund management information carrying a transaction processing identifier to the message queue according to the control result;

[0011] The transaction processor consumes the fourth fund management message according to the transaction processing identifier, performs a transaction operation on the database based on the fourth fund management information, obtains a transaction result, and when the transaction result indicates that the transaction is clear, generates and returns a third fund management information carrying a control identifier to the message queue according to the transaction result.

[0012] Meanwhile, an embodiment of the present application further provides a fund management system, which includes a task manager, a database, a message queue, a verification processor, an unlocking and stopping payment processor, a control center processor, and a transaction processor, wherein:

[0013] The task manager is configured to generate and send a first fund management message carrying a verification identifier to the message queue according to the fund management tasks in the database, where the fund management tasks include at least one fund transfer task, and each fund transfer task includes the transfer of funds between at least two fund cards;

[0014] The verification processor is configured to consume the first fund management message according to the verification identifier, perform a verification operation on the database based on the first fund management message, obtain a verification result, and generate and return a second fund management message carrying an unlocking and stopping payment identifier to the message queue according to the verification result;

[0015] The unlocking and stopping payment processor is configured to consume the second fund management information according to the unlocking and stopping payment identifier, perform an unlocking and stopping payment operation on the database based on the second fund management information, obtain an unlocking and stopping payment result, and generate and return a third fund management message carrying a control identifier to the message queue according to the unlocking and stopping payment result;

[0016] The control central processor is configured to consume the third fund management message according to the control identifier, perform a control operation on the database based on the third fund management information, obtain a control result, and when the control result indicates that the management termination condition is not met, generate and return to the message queue a fourth fund management information carrying a transaction processing identifier according to the control result;

[0017] The transaction processor is configured to consume the fourth fund management message according to the transaction processing identifier, perform a transaction operation on the database based on the fourth fund management information, obtain a transaction result, and when the transaction result indicates that the transaction is clear, generate and return to the message queue a third fund management information carrying a control identifier according to the transaction result.

[0018] This application also provides an electronic device, including a memory and a processor; the memory stores an application program, and the processor is configured to run the application program in the memory to execute the steps in the fund management method described in any one of the above.

[0019] An embodiment of this application provides a computer-readable storage medium, which stores multiple instructions, and the instructions are suitable for being loaded by a processor to execute the steps in the above fund management method.

[0020] Beneficial effects: This application provides a fund management method, system, electronic device and storage medium. This method is applied to a fund management system, which includes a task manager, a database, a message queue, a verification processor, a release of stop payment processor, a control central processor and a transaction processor. In this method, the task manager first generates and sends a first fund management message carrying a verification identifier to the message queue according to the fund management task in the database, and then the verification processor, the release of stop payment processor, the control central processor and the transaction processor all identify and consume the messages with a certain specific identifier from the message queue, and return messages with another specific identifier to the message queue after processing, so as to complete the fund management task. By setting up a message queue and multiple processors, and each processor only needs to identify the message identifier that matches itself from the message queue and consume the corresponding message, each processor does not need to wait for other processors to finish processing all the current messages before performing its own processing. As long as there is a message with a specific identifier in the message queue, it can start its own processing. Therefore, this application realizes the high decoupling and asynchronous processing of each processor, and the whole system is simpler, more stable and efficient, and is convenient for maintenance. Description of the Drawings

[0021] The following will make the technical solutions and other beneficial effects of this application obvious by describing the specific embodiments of this application in detail with reference to the drawings.

[0022] Figure 1 It is a schematic diagram of the application scenario of the fund management method provided by the embodiment of the present application.

[0023] Figure 2 It is a schematic flowchart of the fund management method provided by the embodiment of the present application.

[0024] Figure 3 It is an overall architecture diagram of the fund management system provided by the embodiment of the present application.

[0025] Figure 4 It is a schematic diagram of the application scenario of the fund management task provided by the embodiment of the present application.

[0026] Figure 5 It is a schematic diagram of the flow of each message in the fund management system provided by the embodiment of the present application.

[0027] Figure 6 It is a schematic diagram of the structure of the electronic device provided by the embodiment of the present application. Detailed implementation manners

[0028] Next, the technical solutions in the embodiments of the present application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without creative efforts belong to the scope of protection of the present application.

[0029] The embodiment of the present application provides a fund management method, system, electronic device and computer-readable storage medium. Among them, the fund management system can be integrated in the electronic device, and the electronic device can be a server or a terminal device, etc.

[0030] Please refer to Figure 1 , Figure 1 It is a schematic diagram of the application scenario to which the fund management method provided by the embodiment of the present application is applied. This scenario may include terminals and servers. The terminals, servers, and between terminals and servers are connected and communicate through the Internet composed of various gateways, etc. This application scenario includes database 11 and server 12; among them, database 11 is used to store all data in the fund management process, and server 12 is used to provide a task manager, message queue, verification processor, unlocking processor, control center processor, and transaction processor. Database 11 and server 12 together constitute a fund management system.

[0031] Database 11 and server 12 are located in a wireless network or a wired network to achieve data interaction between the two, where:

[0032] The task manager of server 12 generates a first fund management message carrying a verification identifier according to the fund management tasks in database 11, and sends it to the message queue. The fund management tasks include at least one fund transfer task, and each fund transfer task includes the transfer of funds between at least two fund cards. The verification processor of server 12 consumes the first fund management message according to the verification identifier, performs a verification operation on database 11 based on the first fund management message, obtains a verification result, and generates and returns a second fund management message carrying a release stop payment identifier to the message queue according to the verification result. The release stop payment processor of server 12 consumes the second fund management message according to the release stop payment identifier, performs a release stop payment operation on database 11 based on the second fund management message, obtains a release stop payment result, and generates and returns a third fund management message carrying a control identifier to the message queue according to the release stop payment result. The control center processor of server 12 consumes the third fund management message according to the control identifier, performs a control operation on database 11 based on the third fund management message, obtains a control result, and when the control result indicates that the management termination condition is not met, generates and returns a fourth fund management message carrying a transaction processing identifier to the message queue according to the control result. The transaction processor of server 12 consumes the fourth fund management message according to the transaction processing identifier, performs a transaction operation on database 11 based on the fourth fund management message, obtains a transaction result, and when the transaction result indicates that the transaction is clear, generates and returns a third fund management message carrying a control identifier to the message queue according to the transaction result.

[0033] Through the above process, the verification, release stop payment, control, and transaction of each object in the fund management task are realized, and finally the transfer of funds is completed.

[0034] It should be noted that Figure 1 The schematic diagram of the system scenario shown is only an example. The server and scenario described in the embodiments of the present application are for more clearly explaining the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided by the embodiments of the present application. Those of ordinary skill in the art know that with the evolution of the system and the emergence of new business scenarios, the technical solutions provided by the embodiments of the present application are equally applicable to similar technical problems. The following will be described in detail respectively. It should be noted that the description order of the following embodiments does not constitute a limitation on the preferred order of the embodiments.

[0035] Please refer to Figure 2 , Figure 2 which is a schematic flowchart of the fund management method provided by the embodiments of the present application. The method specifically includes:

[0036] S1: The task manager generates a first fund management message carrying a verification identifier according to the fund management tasks in the database and sends it to the message queue. The fund management tasks include at least one fund transfer task, and each fund transfer task includes the transfer of funds between at least two fund cards.

[0037] As Figure 3 shown, the following is the overall architecture of the fund management system in the embodiment of the present application. The fund management system includes a task manager (not shown in the figure), a database (not shown in the figure), a message queue, a verification processor, an unlocking processor, a control center processor, and a transaction processor. The task manager is used for overall scheduling of the system. The database is used to store various types of data corresponding to management tasks. The message queue is used to store various types of messages in the management process, and each type of message has its own message identifier. When each processor wants to consume a certain type of message in the message queue, it needs to subscribe to the message. Specifically, the verification processor needs to subscribe to verification messages, the unlocking processor needs to subscribe to unlocking messages, the control center processor needs to subscribe to control messages, and the transaction processor needs to subscribe to transaction messages. After subscribing, each processor will only consume messages of the subscribed type and will not consume other types of messages.

[0038] As Figure 4 shown, the following is the specific scenario of the fund management task in the embodiment of the present application. The fund management task includes at least one fund transfer task, and each fund transfer task includes the transfer of funds between at least two fund cards. In Figure 4 it, the fund transfer is from the card on the left to the card on the right. The card on the left is the fund provider card, which may specifically include the bank's salary and wealth management signing card, other bank cards of the bank, and cards of other banks, etc. The card on the right is the fund receipt card, which may specifically include credit cards, loan cards (such as mortgage loans and car loans), other types of repayment cards of the bank / other banks, etc. Between the two, the bank's intelligent repayment signing card is also required as a transfer.

[0039] The bank's salary and wealth management signing card needs to be redeemed in advance. After the funds arrive, they provide funds to the intelligent repayment signing card through in-bank transfer. Other bank cards of the bank directly provide funds to the intelligent repayment signing card through in-bank transfer. Cards of other banks are withheld by the intelligent repayment signing card. Due to the single-transaction limit of cards of other banks, the withholding is carried out in multiple batches. Through this link, the funds in various fund provider cards are aggregated into the intelligent repayment signing card. Then, the credit card gets the transferred funds through the batch deduction repayment of the intelligent repayment signing card, various loan cards get the transferred funds through the in-bank transfer of the intelligent repayment signing card, and other types of repayment cards of the bank / other banks get the transferred funds through in-bank transfer / cross-bank transfer. Through this link, the funds in the intelligent repayment signing card are transferred into various fund receipt cards. The two links together constitute the fund transfer process corresponding to the fund management task.

[0040] In the embodiment of the present application, fund transfer is usually batch transfer. Transferring the funds in a specific fund-providing card to a specific fund-receiving card is a fund transfer task. A fund management task includes at least one fund transfer task. The fund-providing card and the fund-receiving card corresponding to each fund transfer task can be the same or different. All the fund-providing cards form a fund-providing card list, and all the fund-receiving cards form a fund-receiving card list. When there is new information such as a fund-providing card list, a fund-receiving card list, and a fund amount in the database, it indicates that there is a new fund management task. At this time, the task manager generates and sends a first fund management message carrying a verification identifier to the message queue according to the fund management task in the database.

[0041] The first fund management message is used to indicate that pre-verification needs to be performed on each fund transfer task in the fund management task to determine whether it meets the requirements of fund transfer. For example Figure 3 and Figure 5 shown, the first fund management message is also a verification message, which carries a unique verification identifier, and the verification identifier can be "repay_precheck".

[0042] It should be noted that in the embodiment of the present application, the database provides storage space for all the data involved in the execution process of the fund management task. Then, according to different actual scenarios and system design architectures, the database can be a single database, and all the data are stored in the same database. The database can also be multiple different databases, and different data are stored in different databases respectively. Each database can provide functions of adding, deleting, modifying, and querying. The present application does not limit the number, architecture, type, etc. of the databases.

[0043] S2: The verification processor consumes the first fund management message according to the verification identifier, performs a verification operation on the database based on the first fund management message, obtains a verification result, and generates and returns a second fund management message carrying an unlocking identifier to the message queue according to the verification result.

[0044] The verification processor determines the first fund management message with the verification identifier "repay_precheck" from the message queue, and then verifies the relevant data in the database. Specifically, based on the first fund management information, the ID of the current fund management task can be obtained, and information such as the fund-providing card information (type, account number, user name, bank of deposit, etc.), fund-incoming card information (type, account number, user name, bank of deposit, etc.), intelligent repayment signing card information (type, account number, user name, bank of deposit, etc.), the information of each transferred fund (fund currency, fund type, fund amount), transaction type information (deduction, transfer), etc. can be queried from the database, and then some of this information is selected for verification. For example, query the list of fund-providing cards according to the ID of the fund management task, obtain the relevant information of these fund-providing cards from the list, and judge whether these cards have been unbound. If they have been unbound, they cannot participate in this transfer task; judge whether these cards support withholding; judge whether the status of the intelligent repayment signing card is normal; query the ID card numbers and user names bound to each card, and use the latest user name and ID card number as the standard, etc.

[0045] Only several common verification tasks are listed above. In fact, the verification tasks can be set in advance according to needs. After the verification processor determines the first fund management message carrying the verification identifier from the message queue, it can query the relevant information from the database based on the preset verification tasks and call the relevant interfaces to perform the corresponding verification operations.

[0046] After verification, if the verification result is passed, the verification processor generates and returns a second fund management message carrying the stop-payment release identifier to the message queue according to the passed verification result. The second fund management message is used to indicate that stop-payment release processing needs to be performed on some cards involved in the fund management task, unfreeze the funds frozen due to general redemption arrival, so that they can participate in subsequent fund transfers. As Figure 3 and Figure 5 shown, the second fund management message is also the stop-payment release message, which carries a unique stop-payment release identifier, and the stop-payment release identifier can be "stop_payment".

[0047] S3: The stop-payment release processor consumes the second fund management information according to the stop-payment release identifier, performs a stop-payment release operation on the database based on the second fund management information, obtains the stop-payment release result, and generates and returns a third fund management message carrying a control identifier to the message queue according to the stop-payment release result.

[0048] The unlocking processor determines a second fund management message with the unlocking identifier "stop_payment" from the message queue, and then unlocks the relevant data in the database. Specifically, based on the second fund management information, the ID of the current fund management task can be obtained. Based on this ID, the list of fund-providing cards can be queried from the database, the relevant information of these fund-providing cards can be obtained from the list, and the cards for which the funds to be transferred are the funds arriving from general redemptions are selected, and the frozen funds in these cards are unfrozen.

[0049] After the unlocking is completed, the verification processor generates and returns a third fund management message carrying a control identifier to the message queue according to the unlocking result that has been completed. The third fund management message is used to indicate that the transfer process of each fund in the fund management task needs to be controlled to proceed in an orderly manner. Such as Figure 3 and Figure 5 shown, the third fund management message is also the control message, which carries a unique control identifier, and the control identifier can be "repay_controller".

[0050] S4: The control center processor consumes the third fund management message according to the control identifier, performs a control operation on the database based on the third fund management information, obtains a control result, and when the control result indicates that the management termination condition is not met, generates and returns a fourth fund management information carrying a transaction processing identifier to the message queue according to the control result.

[0051] The control center processor determines the third fund management message with the control center identifier "repay_controller" from the message queue, and then controls the relevant data in the database. Specifically, based on the third fund management information, the ID of the current fund management task can be obtained. Based on this ID, the fund-providing card information, the fund-incoming card information, the intelligent repayment signing card information, the information of each transferred fund, the transaction type information, etc. are queried from the database, and then the specific strategy for each fund transfer is controlled, such as the transfer method of each fund (direct debit or transfer), which specific cards are involved in each fund transfer (fund-providing card, intelligent repayment signing card, and fund-incoming card), and how much is the current fund value to be transferred, etc., and it is judged whether the management termination condition is met. The management termination condition means that the current fund management task has been completed. When this condition is met, the control center processor stops the control work, and when the current fund management task is not completed, the control center processor controls each fund transfer task based on the third fund management message, and generates a control result based on this strategy after determining the specific strategy.

[0052] After the control is completed, if the control result indicates that the management termination condition is not met, the control center processor generates and returns to the message queue the fourth fund management information carrying the transaction processing identifier according to the control result. The fourth fund management message is used to indicate that transaction operations need to be performed on each fund in the fund management task to achieve the transfer of each fund from the fund-providing card to the fund-credited card. As Figure 3 and Figure 5 shown, the fourth fund management message is also the transaction message, which carries a unique transaction identifier, and the transaction identifier can be "commit_transaction".

[0053] S5: The transaction processor consumes the fourth fund management message according to the transaction processing identifier, performs transaction operations on the database based on the fourth fund management information, obtains the transaction result. When the transaction result indicates that the transaction is clear, it generates and returns to the message queue the third fund management information carrying the control identifier according to the transaction result.

[0054] The transaction processor determines the fourth fund management message with the transaction identifier "commit_transaction" from the message queue, and then updates the fund data of the fund-providing card and the fund data of the fund-credited card in the database, thus completing the transaction operation. Specifically, based on the fourth fund management information, the ID of the current fund management task can be obtained, and the corresponding transfer strategy can be obtained based on this ID, and then the relevant data in the database can be updated. After the transaction is completed, if the transaction is successful, a clear transaction result is generated; if the transaction is abnormal, an unclear transaction result is generated.

[0055] After the transaction is completed, if the transaction result is clear, the third fund management information carrying the control identifier is generated and returned to the message queue according to the transaction result. The third fund management message generated here is also the control message, which carries a unique control identifier, and the control identifier can be "repay_cont roller", the same as in step S3 above. At this time, as Figure 5 shown, the control center processor will continue to perform the same control operations as in S3, generate the control result corresponding to each fund transfer task, and determine whether the management termination condition is met. When it is not met, the step of generating the control message is repeated; when it is met, the control work is stopped.

[0056] In one embodiment, the fund management system further includes a backcheck processor. After S5, it further includes: when the transaction result indicates that the transaction is unclear, the transaction processor generates and returns to the message queue the fifth fund management information carrying the backcheck identifier; the backcheck processor consumes the fifth fund management information according to the backcheck identifier and performs a backcheck operation on the database based on the fifth fund management information to obtain the backcheck result.

[0057] As Figure 3 and Figure 5 shown, the fund management system further includes a reverse query processor, which needs to subscribe to reverse query information from the message queue. If the transaction result obtained by the transaction processor is unclear, and a reverse query of the above-mentioned handling process is still required, the transaction processor generates and returns to the message queue the fifth fund management information carrying the reverse query identifier according to the transaction result. The fifth fund management message is used to indicate that a reverse query needs to be performed on the transaction result of the current fund transfer task to determine whether there is a problem and what the problem is. The fifth fund management message is also the reverse query information, which carries a unique reverse query identifier, and the reverse query identifier can be "query_trans_result".

[0058] In one embodiment, after the step where the reverse query processor consumes the fifth fund management information according to the reverse query identifier and performs a reverse query operation on the database based on the fifth fund management information to obtain a reverse query result, the following steps are further included: when the reverse query result indicates that the reverse query is clear, the reverse query processor generates and returns to the message queue the third fund management information carrying the control identifier according to the reverse query result; when the reverse query result indicates that the reverse query is unclear, the reverse query processor generates and returns to the message queue the fifth fund management information carrying the reverse query identifier according to the reverse query result.

[0059] When it is determined through reverse query that there is a problem with the current transaction and what the specific problem is, the reverse query result is clear. The reverse query processor generates and returns to the message queue the third fund management information carrying the control identifier "repay_controller" according to the reverse query result, which is the same as in step S3 above. At this time, as Figure 5 shown, the control center processor will continue to perform the same control operations as in S3, generate the control result corresponding to each fund transfer task, and determine whether the management termination condition is met. When it is not met, the step of generating control messages is repeated. When it is met, the control work is stopped. When it is not determined through reverse query what specific problem the current transaction has, the reverse query result is unclear. The reverse query processor generates and returns to the message queue the fifth fund management information carrying the reverse query identifier "query_tr ans_result" according to the reverse query result. Then the reverse query processor continues to repeat the above process, consumes this type of message again and performs a reverse query again until a clear reverse query result is obtained.

[0060] In one embodiment, S5 specifically includes: the transaction processor inserts initial transaction data into the database and generates a primary key for the initial transaction data based on a preset transaction rule; the transaction processor consumes the fourth fund management message according to the transaction processing identifier, obtains target transaction data based on the fourth fund management information, and generates a primary key for the target transaction data based on the preset transaction rule; the transaction processor determines whether there is a primary key conflict between the historical transaction data and the target transaction data in the database. When no primary key conflict occurs, the target transaction data is written into the database, and a transaction result is obtained.

[0061] The transaction processor performs a transaction operation on the database, that is, updates the data involved in the fund transfer process between the fund-providing card and the fund-credited card, so that the funds flow from the fund-providing card to the fund-credited card. To avoid repeated withholding or transfer of a certain card, a unique primary key constraint is set on the database. Before the transaction, the transaction processor first inserts the initial transaction data into the database and generates a primary key for it based on a preset transaction rule. Specifically, the preset transaction rule may include the transaction batch corresponding to each transaction data, the transaction date, the fund management task ID, the order of the current fund-providing card in the fund-providing card list, the order of the deduction policy in the entire policy table, the execution table record ID corresponding to the fund management task, and the number of transactions, etc. Then the formed primary key can be: batch (normal batch is 00, supplementary deduction batch is 11, 12...)+transaction date of the day (YYYYMMDD)+fund management task ID+card order (2 digits, filled with 0 on the left if insufficient, starting from 1)+policy order (1 digit, starting from 0)+execution table record ID+number of transactions (2 digits, filled with 0 on the left if insufficient, starting from 1). After setting the primary key, each piece of target transaction data obtained by the transaction processor consuming the fourth fund management message according to the transaction processing identifier will also generate a unique primary key in an auto-increment manner according to the same preset transaction rule. Since values such as card order and number of transactions in the preset transaction rule are different for each transaction, normally the primary keys of different transaction data are different.

[0062] Before writing the target transaction data, the transaction processor will first determine whether there is a primary key conflict between the historical transaction data and the target transaction data in the database. When writing for the first time, the historical transaction data only includes the initial transaction data. When writing non-first time, the historical transaction data also includes the target transaction data that has been written. In each judgment, if no primary key conflict occurs, the current target transaction data is directly written into the database to obtain a transaction result indicating a successful transaction. If a conflict occurs, that is, the primary keys of the two transaction data are the same, it means that they are the same transaction, and the transaction processor will not write the target transaction data to avoid overwriting the historical transaction data and causing repeated withholding / transfer.

[0063] In one embodiment, the fund management method further includes: when each processor consumes a message, it monitors the invocation of the associated interface; when there is a case where the invocation of the target associated interface by the target processor fails, the target processor generates and returns a delayed message to the message queue, and sends a re-invocation request to the target associated interface after a preset time period; when the target processor receives an allow-retry response returned by the target associated interface, it re-invokes the target associated interface.

[0064] In the embodiment of the present application, the fund management system also sets up a retry mechanism. When each processor consumes the messages it subscribes to, it will call the associated interface to perform operations such as adding, deleting, modifying, and querying in the database, such as querying positions and balances. During this process, it will monitor its own invocation of the associated interface. If the invocation of a certain associated interface by a certain processor fails, then this processor is used as the target processor, and this associated interface is used as the target associated interface. The target processor will return a delayed message to the message queue to promptly inform the management of its current situation. At the same time, after a preset time period such as 3 seconds, it will send a re-invocation request to the target associated interface again. If the target associated interface allows retry, it will return an allow-retry response, and then the target associated interface can be re-invoked to complete the current processing work of the target processor. Through the above method, the administrator can promptly obtain the processing situation of each processor for better management. The processor can also re-attempt to invoke when a call fails, rather than just reporting an error and waiting for external processing for a long time, thereby improving work efficiency.

[0065] In one embodiment, the fund management method further includes: when each processor consumes a message, the message queue monitors the consumption situation of each message; when there is a case where the consumption of the target message by the target processor fails, the message queue generates and sends a consumption failure message to the database; according to the consumption failure message in the database, the task manager re-provides the target message to the target processor through the message queue after a preset time period.

[0066] When each processor consumes the messages it subscribes to, the message queue can monitor the consumption situation of each message. If the consumption of a certain message by a certain processor fails, then this processor is used as the target processor, and this message is used as the target message. The message queue will generate a message failure message and send it to the database. The task manager can promptly obtain the situation of the target message consumption failure from the database, and after a preset time period such as 3 seconds, re-schedule to provide the target message to the target processor through the message queue. By adopting this method, since the message queue can promptly report the problem to the task manager, even if there is a problem with the message queue, it will not cause the loss of messages. Subsequently, the task manager can perform message scheduling and retry, thereby improving the stability of the system.

[0067] In one embodiment, the fund management system further includes a monitoring processor, and the fund management method further includes: the monitoring processor monitors in real time the processing status of each message by other processors; when it is monitored that the processing status of a target processor for a target message is abnormal, the associated message corresponding to the target message is determined from the above message queue, and the associated processor is determined according to the associated message; the monitoring processor generates and returns a warning message to the message queue, and the warning message carries a stop flag matching the associated processor; the associated processor consumes the warning message according to the stop flag and stops consuming the associated message based on the warning information.

[0068] The fund management system of the present application can also set a monitoring processor, which can monitor the processing status of all processors in real time. When it is monitored that a certain processor has abnormal processing of a certain message, that processor is taken as the target processor and that message is taken as the target message. Then, according to the target message, it is determined which fund transfer task it belongs to, and further, the unconsumed fund management messages of other fund transfer tasks that belong to the same fund management task and are after this one are determined as associated messages, and the processor that consumes this associated message is determined as the associated processor. For example, the target message is a control message for a certain transaction. There are two fund transfer tasks after this one. Among them, for one task, there is a first fund management message to be consumed in the message queue currently, then this first fund management message is the associated message, and the verification processor is the associated processor. For the other task, there is a second fund management message to be consumed, then this second fund management message is the associated message, and the release stop payment processor is the associated processor.

[0069] After determining the associated processor, the monitoring processor generates and returns a warning message to the message queue, and the warning message carries a stop flag matching the associated processor. In this embodiment, since each processor may be the associated processor, each processor also needs to subscribe to the warning message in advance. The warning message has a stop flag, and the stop flags of the warning messages subscribed by different processors are different, so different processors will only process the warning messages corresponding to the stop flags that match themselves. The associated processor consumes the warning message according to the stop flag, and then stops consuming the associated message based on the warning information. Since the target processor has an abnormality when processing the target message, this abnormality may be caused by itself or by the previous processor. Therefore, after detecting the abnormality, by sending warning information, it is possible to timely control the unconsumed messages of all subsequent fund transfer tasks from being consumed, thereby avoiding the generation of more abnormalities and reducing losses. After the management personnel investigate the abnormal situation, consumption can be resumed.

[0070] As can be seen from the above embodiments, in the fund management method of the present application, the task manager first generates a first fund management message carrying a verification identifier according to the fund management tasks in the database and sends it to the message queue. Then, the verification processor, the unlocking processor, the control center processor, and the transaction processor all identify and consume the messages with a certain specific identifier from the message queue, and return messages with another specific identifier to the message queue after processing, so as to complete the fund management task. By setting up a message queue and multiple processors in the present application, and each processor only needs to identify the message identifier that matches itself from the message queue and consume the corresponding message, each processor does not need to wait for other processors to complete the processing of all current messages before starting its own processing. As long as there is a message with a specific identifier in the message queue, it can start its own processing. Therefore, the present application realizes the high decoupling and asynchronous processing of each processor, and the entire system is simpler, more stable and efficient, and is convenient for maintenance.

[0071] In the present application, the multi-task repeatable processing fund management system based on the message queue can effectively decouple multiple links in the money transfer process, and can arbitrarily expand the links. Just use the same message queue to transfer messages to connect all links for circulation. In addition, when each processor consumes the messages in the message queue, if the processing is abnormal, the message can be resent and consumed repeatedly, and multiple levels of delayed messages can be supported until the processing of this link is completed and then transferred to the next link. The code implementation is simple and easy to maintain. Finally, based on the message consumption of the message queue, the number of consumption threads can be dynamically adjusted to improve the performance of message processing, and the message consumption server can be horizontally expanded arbitrarily, thereby improving the throughput of the entire system.

[0072] Based on the method described in the above embodiments, this embodiment further provides a fund management system, which is the fund management system described in any of the above embodiments. Different from the prior art, the fund management system provided by the present application realizes the high decoupling and asynchronous processing of each processor by setting up a message queue and multiple processors, and each processor only needs to identify the message identifier that matches itself from the message queue and consume the corresponding message. Each processor does not need to wait for other processors to complete the processing of all current messages before starting its own processing. As long as there is a message with a specific identifier in the message queue, it can start its own processing. Therefore, the present application realizes the high decoupling and asynchronous processing of each processor, and the entire system is simpler, more stable and efficient, and is convenient for maintenance.

[0073] Correspondingly, the embodiments of the present application further provide an electronic device, such as Figure 6As shown in the figure, the electronic device may include a radio frequency (RF) circuit 601, a memory 602 including one or more computer-readable storage media, an input unit 603, a display unit 604, a sensor 605, an audio circuit 606, a WiFi module 607, a processor 608 including one or more processing cores, and a power supply 609, etc. Those skilled in the art can understand that Figure 6 the structure of the electronic device shown in

[0074] does not limit the electronic device, and it may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements. Among them:

[0075] The RF circuit 601 can be used for receiving and transmitting signals during information reception or call processes. Specifically, after receiving the downlink information from the base station, it is handed over to one or more processors 608 for processing; in addition, the data related to the uplink is sent to the base station. The memory 602 can be used to store software programs and modules, and the processor 608 executes various functional applications and fund management by running the software programs and modules stored in the memory 602. The input unit 603 can be used to receive input digital or character information, and generate keyboard, mouse, joystick, optical or trackball signal inputs related to customer settings and function controls.

[0076] The electronic device may further include at least one sensor 605, such as a light sensor, a motion sensor, and other sensors. The audio circuit 606 includes a speaker, and the speaker can provide an audio interface between the customer and the electronic device.

[0077] WiFi belongs to short-distance wireless transmission technology. The electronic device can help customers send and receive emails, browse the web, and follow up on streaming media through the WiFi module 607. It provides customers with wireless broadband Internet follow-up. Although Figure 6 the WiFi module 607 is shown, it can be understood that it does not belong to an essential component of the electronic device and can be omitted completely within the scope of not changing the essence of the application as needed.

[0078] The processor 608 is the control center of the electronic device, connecting various parts of the entire mobile phone through various interfaces and lines. By running or executing the software programs and / or modules stored in the memory 602, and calling the data stored in the memory 602, it executes various functions of the electronic device and processes data, thereby monitoring the mobile phone as a whole.

[0079] The electronic device further includes a power source 609 (such as a battery) for supplying power to each component. Preferably, the power source can be logically connected to the processor 608 through a power management system, so as to implement functions such as management of charging, discharging, and power consumption management through the power management system.

[0080] Although not shown, the electronic device may further include a camera, a Bluetooth module, etc., which will not be elaborated here. Specifically, in this embodiment, the processor 608 in the server will load the executable files corresponding to the processes of one or more application programs into the memory 602 according to the following instructions, and the processor 608 will run the application programs stored in the memory 602. The application programs are applied to the fund management system. The fund management system includes a task manager, a database, a message queue, a verification processor, an unlocking processor, a control center processor, and a transaction processor. The processor 608 runs the application programs to implement the following functions:

[0081] The task manager generates and sends a first fund management message carrying a verification identifier to the message queue according to the fund management tasks in the database. The fund management tasks include at least one fund transfer task, and each fund transfer task includes the transfer of funds between at least two fund cards;

[0082] The verification processor consumes the first fund management message according to the verification identifier, performs a verification operation on the database based on the first fund management message, obtains a verification result, and generates and returns a second fund management message carrying an unlocking identifier to the message queue according to the verification result;

[0083] The unlocking processor consumes the second fund management information according to the unlocking identifier, performs an unlocking operation on the database based on the second fund management information, obtains an unlocking result, and generates and returns a third fund management message carrying a control identifier to the message queue according to the unlocking result;

[0084] The control center processor consumes the third fund management message according to the control identifier, performs a control operation on the database based on the third fund management information, obtains a control result, and when the control result indicates that the management termination condition is not met, generates and returns a fourth fund management information carrying a transaction processing identifier to the message queue according to the control result;

[0085] The transaction processor consumes the fourth fund management message according to the transaction processing identifier, performs a transaction operation on the database based on the fourth fund management information, obtains a transaction result, and when the transaction result indicates that the transaction is clear, generates and returns a third fund management information carrying a control identifier to the message queue according to the transaction result.

[0086] In the above embodiments, the descriptions of the respective embodiments have their own emphases. For parts not detailed in a certain embodiment, reference may be made to the detailed description above, and details will not be repeated here.

[0087] Those of ordinary skill in the art can understand that all or part of the steps in the various methods of the above embodiments can be completed by instructions or by controlling relevant hardware through instructions. The instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0088] To this end, an embodiment of the present application provides a computer-readable storage medium storing multiple instructions. The instructions are applied to a fund management system, which includes a task manager, a database, a message queue, a verification processor, a release-freezing processor, a control center processor, and a transaction processor. The instructions can be loaded by a processor to implement the following functions:

[0089] The task manager generates and sends a first fund management message carrying a verification identifier to the message queue according to the fund management tasks in the database. The fund management tasks include at least one fund transfer task, and each fund transfer task includes the transfer of funds between at least two fund cards;

[0090] The verification processor consumes the first fund management message according to the verification identifier, performs a verification operation on the database based on the first fund management message, obtains a verification result, and generates and returns a second fund management message carrying a release-freezing identifier to the message queue according to the verification result;

[0091] The release-freezing processor consumes the second fund management information according to the release-freezing identifier, performs a release-freezing operation on the database based on the second fund management information, obtains a release-freezing result, and generates and returns a third fund management message carrying a control identifier to the message queue according to the release-freezing result;

[0092] The control center processor consumes the third fund management message according to the control identifier, performs a control operation on the database based on the third fund management information, obtains a control result, and when the control result indicates that the management termination condition is not met, generates and returns a fourth fund management information carrying a transaction processing identifier to the message queue according to the control result;

[0093] The transaction processor consumes the fourth fund management message according to the transaction processing identifier, performs a transaction operation on the database based on the fourth fund management information, obtains a transaction result, and when the transaction result indicates that the transaction is clear, generates and returns third fund management information carrying a control identifier to the message queue according to the transaction result.

[0094] The above has introduced in detail a fund management method, system, electronic device, and computer-readable storage medium provided by an embodiment of the present application. Specific examples are used herein to elaborate on the principle and implementation manner of the present application. The description of the above embodiments is only used to help understand the technical solution and its core idea of the present application; those of ordinary skill in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments, or perform equivalent replacements on some of the technical features; and these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A fund management method, characterized in that, Applied to a fund management system, the fund management system includes a task manager, a database, a message queue, a verification processor, an unlocking and blocking processor, a control center processor, and a transaction processor. The fund management method includes: The task manager generates a first fund management message carrying a verification identifier according to the fund management tasks in the database, and sends the first fund management message to the message queue. The fund management tasks include at least one fund transfer task, and each fund transfer task includes the transfer of funds between at least two fund cards; The verification processor consumes the first fund management message according to the verification identifier, performs a verification operation on the database based on the first fund management message, obtains a verification result, and generates and returns a second fund management message carrying an unlocking and blocking identifier to the message queue according to the verification result; The unlocking and blocking processor consumes the second fund management message according to the unlocking and blocking identifier, performs an unlocking and blocking operation on the database based on the second fund management message, obtains an unlocking and blocking result, and generates and returns a third fund management message carrying a control identifier to the message queue according to the unlocking and blocking result; The control center processor consumes the third fund management message according to the control identifier, performs a control operation on the database based on the third fund management message, obtains a control result, and when the control result indicates that the management termination condition is not met, generates and returns a fourth fund management message carrying a transaction processing identifier to the message queue according to the control result; The transaction processor inserts initial transaction data into the database and generates a primary key for the initial transaction data based on a preset transaction rule; The transaction processor consumes the fourth fund management message according to the transaction processing identifier, obtains target transaction data based on the fourth fund management message, and generates a primary key for the target transaction data based on the preset transaction rule; The transaction processor judges the primary key conflict between the historical transaction data and the target transaction data in the database. When there is no primary key conflict, the target transaction data is written into the database, and a transaction result is obtained. When the transaction result indicates that the transaction is clear, a third fund management message carrying a control identifier is generated and returned to the message queue according to the transaction result.

2. The fund management method according to claim 1, characterized in that The fund management system further includes a reverse query processor. After the step that the transaction processor judges the primary key conflict between the historical transaction data and the target transaction data in the database, and when there is no primary key conflict, the target transaction data is written into the database, and a transaction result is obtained, it further includes: When the transaction result indicates that the transaction is not clear, the transaction processor generates and returns a fifth fund management message carrying a reverse query identifier to the message queue according to the transaction result; The reverse query processor consumes the fifth fund management message according to the reverse query identifier, performs a reverse query operation on the database based on the fifth fund management message, and obtains a reverse query result.

3. The fund management method according to claim 2, characterized in that After the step that the reverse lookup processor consumes the fifth fund management message according to the reverse lookup identifier and performs a reverse lookup operation on the database based on the fifth fund management message to obtain a reverse lookup result, the method further includes: When the reverse lookup result indicates that the reverse lookup is clear, the reverse lookup processor generates and returns a third fund management message carrying a control identifier to the message queue according to the reverse lookup result; When the reverse lookup result indicates that the reverse lookup is unclear, the reverse lookup processor generates and returns a fifth fund management message carrying a reverse lookup identifier to the message queue according to the reverse lookup result.

4. The fund management method according to claim 2, characterized in that The fund management method further includes: When each processor consumes a message, it monitors the call situation of the associated interface; When there is a situation where the call of a target processor to a target associated interface fails, the target processor generates and returns a delay message to the message queue, and sends a re-call request to the target associated interface after a preset time period; When the target processor receives an allow-retry response returned by the target associated interface, it re-calls the target associated interface.

5. The fund management method according to claim 2, characterized in that, The fund management method further includes: When each processor consumes a message, the message queue monitors the consumption situation of each message; When there is a situation where the consumption message of a target processor for a target message fails, the message queue generates and sends a consumption failure message to the database; The task manager re-provides the target message to the target processor through the message queue after a preset time period according to the consumption failure message in the database.

6. The fund management method according to claim 2, characterized in that The fund management system further includes a monitoring processor, and the fund management method further includes: The monitoring processor monitors the processing situation of other processors for each message in real time; When it is monitored that there is a situation where the processing of a target processor for a target message is abnormal, it determines the associated message corresponding to the target message from the above message queue, and determines the associated processor according to the associated message; The monitoring processor generates and returns a warning message to the message queue, and the warning message carries a stop identifier matching the associated processor; The associated processor consumes the warning message according to the stop identifier, and stops consuming the associated message based on the warning information.

7. A fund management system, characterized in that, The fund management system includes a task manager, a database, a message queue, a verification processor, a release-freezing processor, a control center processor, and a transaction processor, where: The task manager is configured to generate and send a first fund management message carrying a verification identifier to the message queue according to the fund management task in the database, the fund management task includes at least one fund transfer task, and each fund transfer task includes the transfer of funds between at least two fund cards; The verification processor is configured to consume the first fund management message according to the verification identifier, perform a verification operation on the database based on the first fund management message to obtain a verification result, and generate and return a second fund management message carrying a release-freezing identifier to the message queue according to the verification result; The unlocking and stop payment processor is configured to consume the second fund management message according to the unlocking and stop payment identifier, perform an unlocking and stop payment operation on the database based on the second fund management message to obtain an unlocking and stop payment result, and generate and return a third fund management message carrying a control identifier to the message queue according to the unlocking and stop payment result; The control center processor is configured to consume the third fund management message according to the control identifier, perform a control operation on the database based on the third fund management message to obtain a control result, and when the control result indicates that the management termination condition is not met, generate and return a fourth fund management message carrying a transaction processing identifier to the message queue according to the control result; The transaction processor is configured to insert initial transaction data into the database and generate a primary key for the initial transaction data based on a preset transaction rule. The transaction processor consumes the fourth fund management message according to the transaction processing identifier, obtains target transaction data based on the fourth fund management message, and generates a primary key for the target transaction data based on the preset transaction rule. The transaction processor determines whether there is a primary key conflict between the historical transaction data and the target transaction data in the database. When there is no primary key conflict, the transaction processor writes the target transaction data into the database and obtains a transaction result. When the transaction result indicates that the transaction is clear, the transaction processor generates and returns a third fund management message carrying a control identifier to the message queue according to the transaction result.

8. An electronic device, characterized in that, It includes a memory and a processor; the memory stores an application program, and the processor is configured to run the application program in the memory to execute the steps in the fund management method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, A computer program is stored on the computer-readable storage medium, and the computer program is executed by a processor to implement the steps in the fund management method according to any one of claims 1 to 6.

Images