找回密码
 会员注册
查看: 10|回复: 0

财务记账系统中高频热点账户的研究

[复制链接]

4

主题

0

回帖

13

积分

新手上路

积分
13
发表于 2024-10-9 09:19:31 | 显示全部楼层 |阅读模式
点击「百度外卖技术团队」快速关注1. 摘要本文在结算系统升级到了2.0,搭建了一个基于账户余额的财务系统的基础上,讨论了财务系统中较为常见的高频热点账户的现象,研究并给出了一些解决方案,并对不同的解决方案进行对比,给出不同业务场景下适用的解决方案。2. 何为热点账户2.1?基于账户余额体系的财务记账系统结算系统升级到了2.0时代,在账户余额体系上搭建起了更为完善的财务记账系统。新的财务记账系统与现实中的银行账户类似,简单来说由两种数据构成:账户余额和交易流水,账户余额反映某账户当前实时的余额,交易流水则反映账户余额的增减过程,描述了账户所发生的所有变更过程。而新系统,目的是能将外卖各个环节所产生的经济行为转为财务上的账户流水变更,便于各个结算主体实时查看自己的交易流水,便于财务核算各种资金科目。2.2 热点账户的定义简单的定义:在整个系统中,某种账户产生的流水占整个记账系统中产生总流失的大部分、或者在某时刻出现对于某账户的高频余额变更。该账户则认为是一个热点账户。常见的热点账户则是一些财务账户。3. 热点账户为何是难题3.1 某个账户的变更操作记账系统中,每一次的账户余额变更,需要记录当时的余额、变更后的余额、变更值。因此,每次的余额变更简单来说可以分解为如下几步操作:获取账户当前余额记录流水更新账户当前余额+变更值注:由于某些操作(例如提现)需要校验余额不能为负,并且流水中要记录变更后的账户余额,所以第一步不能省去。对于最简单情况下,使用简单的乐观锁控制并发,反应到数据库操作,可以变为如下sql语句例如给某账户A加10元(乐观锁版,数据库事务隔离级别为可重复读)start transaction;select amount,version from account where account_id=A; (返回值 AM, V)insert into trade(trade_id,account_id,income_amount,account_amount) valus(xxx,A,10,AM+10);update account set amount=AM+10, version=V+1 where account_id=A and version = V; (判断影响行数)commit;3.2 使用锁串行化财务记账系统需要符合财务上的一些基本要求,例如基本所有操作都有入有出(双边账),所有操作入金额一定要等于出金额。因此,所有的操作都不止变更一个账户,在外卖的财务记账系统中,复杂情况下某步操作可能需要对近10个账户变更余额。如果简单的用乐观锁或悲观锁串行化处理,当有业务逻辑出现需要会对某个账户做大量高频的并发余额变更,会导致一批操作串行化,系统整体吞吐量急速降低。4. 解决方案的研究4.1 异步化、延迟入账?使用异步队列的方式。在线业务操作只增加交易流水,不更新余额,交易流水入队列。通过离线脚本扫描队列,批量计算余额,更新余额并增加交易流水。系统架构如图:优点:不会出现锁问题,并发问题基本解决,并发能力较强缺点:不能做需要校验余额的操作(如提现),离线脚本的处理性能影响延迟时间,不过可以通过分离为多个脚本解决。4.2 账户拆分主体思想其实是将锁一条账户余额数据分散为多条,将并发锁的情况分散。共通缺点:提现会需要特殊处理对于用户来说是不需要知道账户拆分的,并且实时生成的流水只能知晓子账户的余额,所以处理流水中的实时账户余额是个比较麻烦的问题,可以通过异步更新账户余额解决。??4.2.1 拆分为加款账户与扣款账户加款账户通过上述异步化入账或拆分为多个加款账户实时入账,定时将加款账户流水同步到扣款账户,扣款账户只允许做提现等扣款操作。优点:加款入账逻辑基本无阻塞,扣款操作可以通过业务控制频率,可以做到实时操作缺点:系统逻辑更为复杂,可提现的金额会有一定延迟??4.2.2 拆分为多个子账户将总账户拆分为多个子账户,子账户的余额为总账户的余额,所有的加款减款操作都操作子账户,子账户越多,加款并发能力越强,但对于提现操作则耗时会越长。优点:加款扣款都可以做到实时操作,并发能力与子账户个数相关,但提现操作性能则与子账户个数成反比缺点:系统逻辑比较复杂,需要做好负载均衡,一般业务上提现都会全提现,提现操作太多也会影响系统性能5. 不同业务账户的最合适方案脱离业务谈技术方案都是耍流氓,对于不同的业务情况,应该选择最合适的方案,不一定需要将系统做到极强的通用性。另外,可以发现各个方案其实中对于提现操作的并发性与实时性做了不断的博弈与妥协,提现操作其实需要跟业务结合,需要现实情况下业务和财务等支持才能在整体上做到时效性较高,通常情况下,系统造成的提现延迟比银行实际将资金打款到某实体银行账户的延迟要小很多。5.1 各个方案的对比5.2 外卖业务场景下的选择结合外卖目前的业务场景来说,包含的账户有如下几种:1.?骑士账户:特点:骑士接单完成等情况都会记账,基本没有并发,一天的流水量相对来说很小,业务上要支持实时提现。方案:比较适用于方案1。2. 财务账户&分账大账户特点:有业务发生则会记账,一天的流水量占总量的大部分,并发量很高,不提现。方案:很适用于方案2。3. 商户账户特点:用于给商户记账和结算,比个人账户的流水量并发量要高,结算给商户的代收付款都会在账户中体现。目前业务限制每天系统自动提现一次。方案:比较适用于方案2,方案1也可以考虑。当然如果以后要支持手动提现,可以考虑使用方案3.1或3.2。4. 代理商账户特点:是某个城市的管理者账户,某城市下商户佣金都会返给代理商,并发量流水量较高,目前限制每天系统自动提现一次。方案:适用于方案2。如果以后要支持手动提现,可以考虑使用方案3.1或3.2。作 者 介 绍ccy,百度外卖商业平台部结算方向负责人,负责团队内系统架构设计与优化,项目把控,技术规划等。主导设计研发新账务系统,致力于描述与监控外卖线上资金流转,支撑外卖健康发展。点击查看往期热门文章:1运营监控从无到有实战总结2针对新用户复购概率预测模型3Favicon,让你的网站更具个性欢迎关注百度外卖技术团队?点击【阅读原文】加入百度外卖技术团队!
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 会员注册

本版积分规则

QQ|手机版|心飞设计-版权所有:微度网络信息技术服务中心 ( 鲁ICP备17032091号-12 )|网站地图

GMT+8, 2025-1-5 09:08 , Processed in 0.434462 second(s), 25 queries .

Powered by Discuz! X3.5

© 2001-2025 Discuz! Team.

快速回复 返回顶部 返回列表