支付系统中热点账户的性能问题
支付系统中热点账户的性能问题
|
热点账户类型 |
账户属性 |
实时需求 |
锁需求 |
处理方式 |
性能 |
|
业务大账户 |
内部账户 |
无实时余额查询 无实时提现 |
无需加锁 |
异步MQ延时处理 |
满足 |
|
大代理商账户
|
对外账户 |
无实时余额查询 无实时提现 |
没有加锁需求 |
异步MQ延时处理 |
满足 |
|
热门商户(推广) |
对外账户 商户账户 |
实时余额查询 实时提现 |
有加锁需求 |
串行化同步 |
亟待提升 |
一、按业务场景尽量拆分热点账户，分散压力
1)账户拆分，拆分主账户
此时解决方法就是再办一张同行的卡，或者其它银行的卡，一起承担存钱和提现的需求
2)新增多个子账户，
向银行申请，为该主卡办理多个子卡，用子卡进行分流
3)按功能进行划分
申请一个专门接收打款的卡
申请一个专门接受提现的卡
二、异步方式
4)异步队列延时处理
先把所有的打款、提现的请求入队列，延时处理账户余额更新
5)实在没招了，合并处理
把某个特征相似的操作进行合并处理。即把别人一万次打款请求合并为一个打款请求，此时最终只需要申请一次打款，其它人的卡逐个扣款
提现就不好解决了，可以增加一个提现缓冲卡，但是迫不得已，可以把多次提现请求，合并为一个请求，先从该账户把钱提到提现缓冲卡，再由提现缓冲卡分发给其它目标账户。
支付结算账户系统针对上述问题做了如下处理：
我们把热点账户按照金额变动方向分为加频账户（余额增加频繁）、减频账户（余额扣减频繁）、双频账户（余额增加扣减均频繁）。
加频账户处理
准实时更新余额。先将金额变动插入临时表中，由定时任务按照一定频率汇总发生额，并更新账户余额，而后删除临时记录。当加频账户减钱余额不足时，主动去汇总发生额。这里需要考虑主动汇总发生额和定时任务处理的并发情况，我们在该定时任务执行时设置redis锁，防止并发，主动汇总时会去判断这个redis锁是否存在，如存在证明定时任务正在执行，无需主动汇总，可能是真的余额不足。主动汇总同样会设置redis锁，定时任务同样会判断。
减频账户处理
将减频账户拆分多个子账户，减频子账户设置金额报警，如果某个减频子账户余额不足触发报警，会对该子账户做资金归集，将其他子账户余额归集到该子账户（每个子账户设置可归集金额限制）。如在交易过程中发现该子账户余额不足，转向使用其他子账户记账。由于拆分子账户，余额查询时需要汇总各个子账户余额返回；记录主账户流水需要记账后余额，这里需要异步计算汇总。当减频账户加钱时，需要平均分配入账到不通的子账户。
双频账户处理
将双频账户拆分多个子账户。加钱时，准实时更新余额，先将子账户金额变动插入临时表中，由定时任务按一定频率汇总发生额，将汇总的发生额更新进对应的子账户，并删除金额变动记录；减钱按照之前减频账户的逻辑执行。
支付宝需要有个账户记账，现在很多业务已经出现了很多热点账户。比如互联网大商家，\\\
账号有余额，主要用于不能扣成负数。 大并发交易下余额快速变化，导致数据库竞争等待。
原则: 不同的业务要求,不同的设计,同时会影响业务需求.
三大需求,是否都容易满足:
1.减款
2.加款
3.读取总金额
最简单设计: 帐户表+流水表. 每次帐户加减款都需要增加流水,和帐户变动.
业务需求: 高并发帐户.
技术选择 1. 悲观锁(高并发帐户), 乐观锁(普通并发帐户). 3. 顺序化 同步转异步,mq 降低峰值.
存储选择: redis 还是 数据库. redis本身并发能力就是比数据库要好. 但是单机支持的数据量不如数据库大. 只存放account的值的话到还好.
账户转账分两个接口，一个可扣成负数,一个不能扣成负数.
1 如何消除余额竞争呢？
方案一：变成两个账户 模仿 担保交易，设置两个账户 1. 扣款账户 2. 加款账户
1.1. 商家都是频繁加款 ,加款账户只记流水,不计算余额. 避免频繁竞争
1.2. 加款帐户的流水定时汇总到扣款帐户上.
1.3 扣款账户用于退款和提现, 因为频率不高. 即保证余额控制,也没有并发问题. 退款有些业务能扣成负数,有些业务不能.
缺点: 进入的钱不一定能时时能用. (对小商家不适用,比较计较)
优点: 这样就避免了热点账户的余额计算。
方案二： 账户分普通账户，加频账户，减频账户，双频账户
类型为加钱频繁账户，加钱不改变余额，定时任务收集改变。 捡钱操作时时进行。
减频账户，拆分子账户。
扣款只账户会有个问题，前面扣掉了，但是最后不够扣。
最佳方案，回滚，即逆操作，加款。
次佳方案， 使用只能扣成一次负数
双频账户：加款依然如此，减款同上。
延迟提现问题：即2天内收入只允许某种业务扣款（内部消费，代驾现金抵扣），但不允许提现扣款。
采用普通账户，但是要满足提现延迟方案？
小商家加的钱必须时时能用. 又要求延迟提现怎么办?
只能通过订单维度,目前这个订单现在有多少钱冻结中(已退款的钱不应该冻结). 展现哪些订单是冻结的,冻结金额是多少.
一旦钱被消费了, 账户余额可能少于订单的冻结的金额,可提现余额可能为负数.
客户可能来投诉, 因为他自己意识不到钱被消费了(抵扣信息费)和提现金额变少有关联.
原文链接：https://blog.csdn.net/xiaohanzuofengzhou/article/details/100938038
