支付结算系统如何处理高并发性和热点账户等问题

互联网金融系统的核心是支付和结算，支付和结算的基础是账户系统。金融账户系统具有并发量大、响应快、交易量大、热点账户问题突出的特点。一个合格的账户体系不仅要解决上述问题，还要绝对保证资金的安全。作为互联网金融公司宜信的支付结算中心，其账户系统也必须具备上述特征。

1、账户系统

1.1账户结构

宜信支付结算账户系统是一个客户、用户和账户三层结构。证书编号和证书类型唯一地标识客户，客户编号和机构编号标识用户，并且用户可以开立不同类型的多个账户。如图所示:

1.2科目属性

科目体系是以科目为基础的，所有的操作都是围绕着科目进行的，并且该科目包含以下属性:

会计科目:每个科目的金额变化都应该反映一些会计属性，以便于核算账户类别:分为个人账户、企业账户和平台账户账户明细:账户明细是账户余额每次变化的明细，采用复式记账，包括对方账号、账户、汇总、借方金额、余额等信息。账户余额:记录账户的实时余额

1.3账户

挂在最低账户下，这决定了账户的含义和余额的变化方向。会计科目的一些属性如下:

-4科目类别:资产类别、负债类别、所有者权益、成本类别、损益类别等科目等级:会计科目等级、一级科目、二级科目、三级科目等。下级账户属于上级账户余额方向:指示余额是借方还是贷方账户期末余额:每日日切后，汇总上一会计日所有基础账户余额之和，下级账户余额之和由上级账户汇总。

1.4主体树

益新支付结算账户系统采用主体树概念，每个机构绑定一个主体树。账户树的根节点是一级账户，账户链接在底层账户下。结构如下:

2。账户系统架构

宜信支付结算账户系统采用公司开发的分布式微服务框架，提供http json对外接口，内部服务之间采用redis实现的消息队列通信

2.1账户系统功能框架

宜信支付结算账户系统分为接入模块、账务子系统、开户子系统、异步账务模块、查询子系统、计时任务子系统、日终子系统和异步日志模块。下图是会计系统的功能模块图:

会计子系统:会计系统的核心模块，处理业务系统的会计请求开户子系统:处理业务系统的开户请求首次开户:为个人或企业的客户、用户和预配置账户开立默认的开户账户。指定账户开户:个人或企业首次开户后，可根据账号指定账户。查询子系统:提供一些账户和记账的查询功能。异步记账模块:提供异步记录账户流量的功能定时任务子系统:处理定时任务，如失败的重试和热点帐户日终子系统:提供日切、日终运行和批量功能。

2.1.1记账处理

记账处理是账户系统的核心功能。该功能要求高性能。在高并发情况下，热账户问题非常突出，资金的正确性也必须得到保证。根据不同的业务，簿记分录也各不相同。宜信支付结算系统如何应对这些问题？这里，重点是:

账户系统记账采用记账服务的概念。每个记账服务都是记账条目的模板。业务系统根据此模板传递记账金额、账号或用户号等信息账户系统使用redis分布式锁来防止业务系统重复提交请求。建立簿记订单的反重复表，并根据请求号和组织号对簿记请求进行幂等性验证。采用复式记账法。根据会计规则和借款记录，贷款必须在贷款时发放。记账过程中，账户余额更新后，结果同步返回业务系统，记账流程异步处理同时，建立补偿机制，定期重试未能通过簿记流程处理的订单，并在重试三次失败后报警手动干预。会计规则处理:每个会计服务可以绑定一些会计规则，会计系统根据会计服务遍历的绑定规则顺序处理它们

2.1.2热点账户问题

热点账户问题是账户体系的痛点，长期困扰着我们。在这里，让我们关注以下内容

-充值时，记账分录为:

借方:待清算三方支付账户()

贷方:个人余额账户()

当大量用户充值时，待清算三方支付账户是热点账户，经常增加余额

-当前簿记分录是

借方:个人余额账户(-)

贷方:三方支付资产账户(-)

当大量用户提到当前资产账户时，三方支付是一个热门账户，经常减少余额

-服务费的记账分录为:

借方:个人账户(-)

贷方:商户服务费账户()

当向用户收取大量服务费时，商户服务费账户是一个热门账户，余额会频繁增加

-服务费支付的记账分录为:

借方:商户服务费账户(-)

贷方:个人账户()

当大量服务费余额用于支付用户时，商户服务费账户是一个热门账户，余额会频繁减少在

记账期间，所有涉及的账户余额都需要更新。在高并发情况下，由于数据库的行级锁定，更新同一帐户余额的操作从并行变为串行，单个请求的响应时间变长，从而拖累了整个簿记服务。

宜信支付结算账户系统对上述问题的处理如下:

我们将热点账户分为频率增加账户(频繁余额增加)、频率减少账户(频繁余额扣除)和双频账户(频繁余额增加和扣除)

频率增加帐户处理

准实时更新余额首先，将金额更改插入临时表中，常规任务按照一定的频率汇总金额，更新帐户余额，然后删除临时记录当增加频率账户的余额减去资金不足时，它将自动汇总发生的金额。这里，我们需要考虑活动摘要数量和计划任务处理的并发情况。我们在执行计划任务期间设置redis锁，以防止并发。在活动摘要期间，我们将判断redis锁是否存在。如果存在证明计划的任务正在执行，并且不需要活动的摘要，则可能是平衡真的不够。还将为活动摘要设置Redis锁，并对计划任务进行判断。

降频账户处理

将降频账户分成多个子账户，降频子账户将设置金额告警。如果某个降频子账户余额不足时触发报警，则该子账户将被收回，其他子账户的余额将被收回到该子账户中(每个子账户将设置一个可收回金额的限额)如果在交易过程中发现该子账户余额不足，银行将切换到其他子账户记账。由于分子账户被拆除，余额查询时需要汇总并返回每个子账户的余额。为了记录记账后主账户的余额，这里需要异步计算和汇总。向频率降低帐户添加货币时，必须将货币平均分配到不可用的子帐户。

双频账户处理

将双频账户分成多个子账户添加货币时，余额将实时更新。首先，将子账户金额变更插入到临时表中。常规任务将按照一定的频率汇总发生额，并将汇总的发生额更新到相应的子账户中，并删除金额变动记录。应根据之前频率降低账户的逻辑执行货币降低。

2.1.3簿记中的死锁问题

高并发性，当多个帐户以前相互转账时，可能会出现死锁问题

例如:一个余额账户--> B余额账户(线程1)和B余额账户--> a余额账户(线程2)两个转账请求是并发的。账户系统更新每个转账请求的a和b余额。这两个更新需要在一个事务中。正常进程线程1首先更新a，然后更新b，线程2首先更新b，然后更新a。线程1在更新a之后等待锁，不提交事务，线程2在更新b之后等待锁，不提交事务，从而导致两个线程之间的死锁

宜信支付结算账户系统针对这种情况提出了一种解决方案，对账号进行排序，然后更新余额，这样每个线程更新a，然后更新b，从而解决了死锁问题

2.2账户系统存储层架构

宜信支付结算账户系统数据库采用Mysql，缓存采用redis

Mysql数据库采用主从架构，一个主机和两个从机。主数据库与从数据库同步数据对于一些数据量大的表，更有代表性的是账户流程图，需要按账户维度查询，按时间维度汇总。因此，根据这一特性，一个表是多余的，一个按帐户，一个按日期。Redis采用集群架构的形式，集群中的每个点都是主节点和备用节点

2.3

帐务系统的网络层架构，帐务系统的每一项服务都部署在同一个机房内，其中帐务子系统和异步帐务模块部署在4台不同的物理机上，其他子系统和模块部署在2台不同的物理机上前端采用Nginx实现负载均衡。