Shulou(Shulou.com)06/01 Report--

The core of Internet financial system is payment and settlement, and the basis of payment and settlement is account system. The financial account system is characterized by large concurrency, 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 must also have the above characteristics.

I. account system 1.1 account structure

The Yixin payment and settlement account system is a three-tier structure of customers, users and accounts. the document number and document type only determine a customer, and the customer number and organization number determine a user, and a user can open multiple different types of accounts. As shown in the figure:

1.2 account attributes

The account system is based on the account, and all operations are carried out around the account, which contains the following attributes:

Accounting subjects: the changes in the amount of each account should reflect some accounting attributes in order to facilitate accounting. Account category: divided into individual account, enterprise account and platform account. Account details: account details reflect each detail of the changes in the account balance, using double-entry bookkeeping method, including the other party's account number, account and other information, summary, debit amount and balance and other information. Account balance: record the real-time balance of the account. 1.3 Accounting subjects

The account is hung under the bottom account, which determines the meaning of the account and the direction of change in the balance. Some of the attributes of accounting subjects are as follows:

Subject category: asset class, liability category, owner's equity, cost category, profit and loss category, etc. Subject level: the level of accounting subjects, first-level subjects, second-level subjects, third-level subjects, etc. The subordinate subjects belong to the superior subjects. Balance direction: indicate whether the balance is on the debit or credit side. The final balance of the subject: after daily cut, it will summarize the sum of the balance of all the lower accounts of the underlying account on the previous accounting day, and the balance of the superior account will sum up the balance of the subordinate account. 1.4 subject tree

The Credit payment and settlement account system uses the concept of subject tree, and each institution is bound to a subject tree. The root node of the account tree is the first-level account, and the account under the bottom account is structured as follows:

II. Account system architecture

The Credit payment and settlement account system adopts the distributed micro-service framework developed by the company, provides http json interface to the outside, and uses redis to realize message queue communication among the internal services.

2.1 functional architecture of the account system

The credit payment and settlement account system is divided into access module, accounting subsystem, account opening subsystem, asynchronous accounting module, query subsystem, timing task subsystem, day end 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 parsing, signature verification, parameter verification, authority authentication and so on, which is the unified entrance of the account system. Asynchronous log module: asynchronously record business system request messages. Accounting subsystem: the core module of the account system, which handles the accounting requests of the business system. Account opening subsystem: handles account opening requests of the business system. Opening an account for the first time: a default account that opens customers, users, and pre-configured accounts for individuals or enterprises. Designated account opening: after opening an account for the first time, an individual or enterprise may open an account according to the section number. Query subsystem: provide some query functions for account and bookkeeping. Asynchronous accounting module: provides the function of recording account flow asynchronously. Scheduled task subsystem: dealing with scheduled tasks such as failed retries, hot accounts, etc. Day-end subsystem: provides the functions of day-to-day cutting and day-end batch running. 2.1.1 bookkeeping processing

Accounting processing is the core function of the account system, which requires high performance, hot account issues are more prominent under high concurrency, the correctness of funds must also be guaranteed, and according to different businesses, accounting entries are also varied. Yixin payment and settlement account system how to deal with these problems, here focus on the following:

The accounting system uses the concept of accounting service, and each accounting service is a template for accounting entries. According to this template, the business system passes in information such as accounting amount, account number or user number. The account system adopts redis distributed lock to prevent the business system from submitting requests repeatedly. Set up the anti-repetition form of accounting order, and check the accounting request idempotently according to the request order number and organization number. Use double-entry bookkeeping, according to accounting rules according to loan records, there is borrowing, there is loan. During the bookkeeping process, the result is returned to the business system synchronously after updating the account balance, and the accounting pipeline is processed asynchronously. At the same time, set up a compensation mechanism, regularly retry accounting pipeline processing failed orders, retry three failures after the alarm manual intervention. Accounting rules processing, each accounting service can bind some accounting rules, the account system traverses its binding rules according to the accounting service, and processes them sequentially. 2.1.2 Hot account issues

The hot account problem is the sore point of the account system, and it has perplexed us for a long time, which is emphasized here.

-- the entry for top-up is:

Debit: three-party payment pending liquidation account (+)

Credit: personal balance account (+)

When a large number of users recharge, the accounts to be liquidated by the three parties are hot accounts, frequently increasing the balance.

-- the entry at the time of withdrawal is:

Debit: personal balance account (-)

Credit: tripartite payment asset account (-)

When a large number of users withdraw cash, the asset account paid by the three parties is a hot account, frequently reducing the balance.

-- the entry of service charge for business is as follows:

Debit: personal account (-)

Credit: merchant service charge account (+)

When charging a large number of service fees from users, the merchant service charge account is a hot account, which will increase the balance frequently.

-- the entry for payment of business service charges is:

Debit: merchant service charge account (-)

Credit: personal account (+)

When a large number of service charge balances are used to pay users, the merchant service charge account is a hot account, which will frequently reduce the balance.

When keeping accounts, all the account balances involved have to be updated by update. In the case of high concurrency, when the above-mentioned types of hot accounts appear, because of 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 accounting service.

The Credit payment and settlement account system deals with the above problems as follows:

According to the change direction of the amount, we divide the hot accounts into the increased frequency account (the balance increases frequently), the reduced frequency account (the balance deduction is frequent) and the dual frequency account (the balance increases and deducts frequently).

Additional frequency account processing

Update the balance in quasi-real time. First, the amount change is inserted into the temporary table, the scheduled task summarizes the occurrence amount according to a certain frequency, and updates the account balance, and then deletes the temporary record. When the deduction balance of the additional frequency account is insufficient, take the initiative to summarize the occurrence amount. Here, we need to consider the concurrency of active summary and timing task processing. We set a redis lock when the scheduled task is executed to prevent concurrency. Active summary will determine whether the redis lock exists. If there is a proof that the timing task is being executed, there is no need for active summary. There may be a real insufficient balance. Active summarization will also set redis locks, and scheduled tasks will also judge.

Frequency reduction account processing

Split the frequency reduction account into multiple sub-accounts, and set the alarm for the amount of the frequency reduction sub-account. If the alarm is triggered by the insufficient balance of a frequency reduction sub-account, funds will be collected for that sub-account. The balances of other sub-accounts will be collected into the sub-account (each sub-account sets a limit on the amount that can be collected). If the balance of the sub-account is found to be insufficient during the transaction, turn to other sub-accounts for bookkeeping. Due to the dismantling of sub-accounts, the balance of each sub-account needs to be summarized and returned when querying the balance; recording the balance of the main account needs to be recorded after bookkeeping, and the summary needs to be calculated asynchronously here. When the money is added to the frequency reduction account, it needs to be evenly distributed to the impassable sub-accounts.

Dual-frequency account processing

Split the dual-band account into multiple sub-accounts. When adding money, update the balance in quasi-real time, first insert the changes in the amount of the sub-account into the temporary table, summarize the occurrence amount by the scheduled task according to a certain frequency, update the summary occurrence amount to the corresponding sub-account, and delete the record of the amount change; the money reduction shall be carried out in accordance with the logic of the previous frequency reduction account.

2.1.3 bookkeeping deadlock problem

In the case of high concurrency, deadlock problems may occur when multiple accounts are previously transferred to each other.

For example, A balance account-> B balance account (thread 1) and B balance account-> A balance account (thread 2) are concurrent, and the account system updates An and B balances for each transfer request. These two updates need to be in one transaction. Normal process thread 1 updates A first, then updates B, thread 2 updates B first, and then updates A, thread 1 will wait for B's lock after updating A. If the transaction is not committed, thread 2 will wait for A's lock after updating B, without committing the transaction, so that the two threads wait for each other to lock, resulting in a deadlock.

The Yixin payment and settlement account system puts forward a solution to this situation, sorting the account number and then updating the balance, so that each thread updates A first and then B, which solves the deadlock problem.

2.2 Storage layer architecture of account system

Mysql is used in the database of the Credit payment and settlement account system and redis is used in the cache.

Mysql database adopts master-slave architecture, one master and two slaves, and the master database synchronizes the data to the slave database. In view of some tables with a large amount of data, the more representative is the account flow table, which should be queried not only by the account dimension, but also by the time dimension, so in view of this characteristic, a table is redundant, one is divided according to the account, and one is divided according to the date.

Redis takes the form of cluster architecture, and each node in the cluster is in the form of master / slave. 2.3 Network layer architecture of account system

Each service of the account system is deployed in the same computer room, in which the accounting subsystem and asynchronous accounting module are deployed on four different physical machines, and the other subsystems and modules are deployed on two different physical machines. The front end uses nginx to achieve load balancing.

Author: Li Rui Cheng Liuyun

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.