The core of Internet financial system is payment and settlement, and the basis of payment and settlement is account system. Mutual fund account system is characterized by large concurrent amount, fast response, large transaction amount and prominent hot account problems. A qualified account system must not only solve the above problems, but also absolutely ensure the safety of funds. As the payment and settlement center of Yixin, an Internet finance company, its account system also has the above characteristics.
1. Account System
1. Account structure
Yixin’s payment and settlement account system is a three-tier structure of customers, users and accounts. The ID number and ID type uniquely identify a customer, the customer number and institution number identify a user, and a user can open multiple accounts of different types. As shown in the figure:
2. Account Attributes
The foundation of the account system is the account. All operations are carried out around the account. The account contains the following attributes:
Accounting subjects: changes in the amount of each account should reflect some accounting attributes so as to facilitate accounting.
Account category: divided into personal account, enterprise account and platform account.
Account Details: Account details are each detail reflecting changes in the balance of the account, using double-entry bookkeeping method, including information such as the opposite party’s account number, account, lending direction, summary, amount of debits and credits and balance.
Account Balance: Record the real-time balance of the account.
3. Accounting subjects
The account is hung under the lowest accounting item, which determines the meaning of the account and the change direction of the balance. Some attributes of accounting subjects are as follows:
Account category: asset category, liability category, owner’s equity, cost category, profit and loss category, etc.
Subject level: the level of accounting subjects, level 1 subjects, level 2 subjects, level 3 subjects, etc. The subordinate account belongs to the superior account.
Balance Direction: Indicates whether the balance is debit or credit.
Closing Balance of Account: after daily daily daily cutting, the sum of the balances of all underlying accounts on the previous accounting day will be summarized, and the sum of the balances of lower accounts will be summarized for higher accounts.
4. Subject tree
Yixin’s payment and settlement account system adopts the concept of an account tree, and each institution will bind to an account tree. The root node of the account tree is a first-level account, and accounts are linked under the bottom account. The structure is as follows:
2. Account System Architecture
Yixin payment and settlement account system adopts the distributed micro-service framework developed by the company, exposes the http json interface to the outside, and adopts the message queue communication implemented by redis among internal services.
1. Functional Architecture of Account System
Yixin payment and settlement account system is divided into access module, accounting subsystem, account opening subsystem, asynchronous accounting module, inquiry subsystem, timing task subsystem, end-of-day subsystem and asynchronous log module. The following figure is the functional module diagram of the accounting system:
Access module: provides public services such as message analysis, signature verification, parameter verification, authority authentication, etc. It is the unified entrance of the account system.
Asynchronous log module: asynchronously records service system request messages.
Bookkeeping subsystem: the core module of the account system, which handles the bookkeeping requests of the business system.
Account Opening Subsystem: Handles account opening requests from business systems.
Opening an account for the first time: opening a default opening account for individuals or enterprises for customers, users and pre-configured accounts.
Designated Account Opening: After opening an account for the first time, an individual or enterprise may designate an account according to the account number.
Query subsystem: provides some query functions for account and bookkeeping.
Asynchronous bookkeeping module: provides the function of asynchronously recording account flow.
Timed task subsystem: handles timed tasks such as failed retries and hot-spot accounts.
End-of-day subsystem: provides the functions of daily cut and end-of-day run and batch.
Bookkeeping processing is the core function of the account system. This function requires high performance. Hot account problems are prominent under high concurrency. The correctness of funds must also be guaranteed. According to different businesses, bookkeeping entries are also multifarious. How should Yixin’s payment and settlement account system deal with these problems? Here are the highlights:
Account system bookkeeping uses the concept of bookkeeping service. Each bookkeeping service is a template for bookkeeping entries. The business system passes in information such as bookkeeping amount, account number or user number according to this template.
The account system uses redis distributed locks to prevent the business system from submitting requests repeatedly. Set up an anti-duplication table for bookkeeping orders, and perform idempotent verification on bookkeeping requests according to the request number and organization number.
Double-entry bookkeeping method is adopted. According to accounting rules and borrowing records, loans must be made whenever loans are made.
During the bookkeeping process, the results will be returned to the business system synchronously after the account balance is updated, and the bookkeeping flow will be processed asynchronously. At the same time, a compensation mechanism is set up to retry orders that fail bookkeeping flow processing regularly, and alarm manual intervention after three retries.
Accounting rules processing: each accounting service can bind some accounting rules, and the account system processes them sequentially according to the binding rules traversed by the accounting service.
2) Hot Account Issues
The hot account problem is the pain point of the account system and has troubled us for a long time. Here, I’d like to focus on it.
When recharging, the bookkeeping entry is,
Debit: tripartite payment account to be cleared (+)
Credit: Personal Balance Account (+)
When a large number of users recharge, the account to be cleared for tripartite payment is the hot account, increasing the balance frequently.
Referring to the current bookkeeping entry,
Debit: Personal Balance Account (-)
Credit: tripartite payment asset account (-)
When a large number of users mention the current situation, the asset accounts paid by the three parties are hot accounts, frequently reducing the balance.
The entry for P2P service charge is,
Debit: Personal p2p Account (-)
Credit: merchant service fee account (+)
When a large amount of service fees are collected from users, the merchant service fee account is a hot account, which frequently increases the balance.
The entry for P2P service fee payment is,
Debit: merchant service fee account (-)
Credit: Personal p2p Account (+)
When a large number of users are paid with the service fee balance, the merchant service fee account is a hot account, which will frequently reduce the balance.
During bookkeeping, all the account balances involved must be update. In case of high concurrency, when hot accounts of the above type occur, due to the row-level lock of the database, the operation of updating the balance of the same account changes from parallel to serial, and the response time of a single request becomes longer, thus dragging down the entire bookkeeping service.
Yixin payment and settlement account system has dealt with the above problems as follows:
We divide hot account into frequency increasing account (frequent balance increase), frequency decreasing account (frequent balance deduction) and dual frequency account (frequent balance increase and deduction) according to the change direction of amount.
Processing of frequency-added accounts: quasi-real-time update of balance. First, the amount change is inserted into the temporary table, and the regular task summarizes the amount according to a certain frequency, updates the account balance, and then deletes the temporary record. When the balance of the increased frequency account minus the money is insufficient, it will voluntarily summarize the amount incurred. Here, we need to consider the concurrent situation of active summary occurrence amount and scheduled task processing. We set the redis lock during the execution of the scheduled task to prevent concurrency. During active summary, we will judge whether the redis lock exists. If the existence proves that the scheduled task is being executed, there is no need for active summary, and the balance may be really insufficient. Redis lock will also be set for active summary, and scheduled tasks will also be judged.
Frequency reduction account processing: divide the frequency reduction account into multiple sub-accounts, and set an amount alarm for the frequency reduction sub-account. if an alarm is triggered due to insufficient balance in a certain frequency reduction sub-account, fund collection will be carried out for the sub-account and other sub-account balances will be collected into the sub-account (each sub-account sets a limit on the amount that can be collected). If the balance of this sub-account is found to be insufficient during the transaction, the bank will switch to other sub-accounts for bookkeeping. Due to the dismantling of molecular accounts, the balance of each sub-account needs to be summarized and returned during balance query. To record the balance of the main account after bookkeeping, asynchronous calculation and summary are required here. When adding money to the frequency reduction account, it is necessary to evenly distribute the money to the sub-accounts that are not available.
Dual-frequency account processing: split the dual-frequency account into multiple sub-accounts. When adding money, the balance will be updated in real time. First, the sub-account amount change will be inserted into the temporary table. The regular task will summarize the amount of occurrence according to a certain frequency, update the summarized amount of occurrence into the corresponding sub-account and delete the amount change record. The money reduction shall be carried out according to the logic of the previous frequency reduction account.
3) Deadlock Problem of Bookkeeping
In case of high concurrency, deadlock may occur when multiple accounts transfer money to each other before.
For example: a balance account-—> B balance account (thread 1)
B balance account-> a balance account (thread 2)
The two transfer requests are concurrent, and the account system will update the balances of A and B for each transfer request. The two updates need to be in one transaction. In normal process, Thread 1 updates A first, then updates B, Thread 2 updates B first, then updates A. Thread 1 will wait for the lock of B after updating A, and will not commit the transaction. Thread 2 will wait for the lock of A after updating B, and will not commit the transaction. Thus, the two threads wait for the lock with each other, causing deadlock.
Yixin payment and settlement account system proposed a solution to this situation, ordering the account numbers and updating the balance, so that each thread updates A and B first, thus solving the deadlock problem.
2. Account System Storage Layer Architecture
The database of Yixin payment and settlement account system adopts Mysql and the cache adopts redis.
MySQL database adopts a master-slave architecture, with one master and two slaves. The master database synchronizes data with the slave database. For some tables with a large amount of data, the representative one is the account flow chart, which needs to be queried according to the account dimension and summarized according to the time dimension. Therefore, according to this feature, one table is redundant, one by the account and one by the date.
Redis takes the form of cluster architecture, with each point in the cluster being the master and standby.
3. Network layer architecture of account system
Each service of the account system is deployed in the same computer room, wherein the accounting subsystem and asynchronous accounting module are deployed on 4 different physical machines, and other subsystems and modules are deployed on 2 different physical machines. Nginx is used at the front end to realize load balancing.
Source:Yixin Institute of TechnologyAuthor: Li Rui cheng liuyun