精华内容
下载资源
问答
  • 账户系统和会计系统的设计是整个支付系统的底层基础,对外,为支付系统提供资金的充、提、转、管等服务,对内,为财务和资金方提供完整的内部记账凭证。 一、交易模型 账户的变动基于交易而发生,对于账户的处理...

    账户系统和会计系统的设计是整个支付系统的底层基础,对外,为支付系统提供资金的充、提、转、管等服务,对内,为财务和资金方提供完整的内部记账凭证。

     

    一、交易模型

    账户的变动基于交易而发生,对于账户的处理,需要根据不同的业务规则,结合产品的规划,建立完整的交易模型。

     

    • 收银台

    资金入口,提供B2C网银、B2B网银、快捷支付、协议支付、身份验证等

    • 交易系统

    提供业务层的原子化接口,比如快捷支付,协议支付,出金、提现等,处理组合不同的业务,包括组合支付、拆单支付、多次支付等

    • 资产交换

    基于渠道层的接口提供原子化服务,动态编排组合账户指令和渠道指令,清结算指令等。

    • 账户系统

    基于交易发生的账户变动,比如C1转账100元给C2账户。

    • 会计分录

    根据不同的记账事务指令会产生不同的会计分录事件,一般需要支持一借一贷和一借多贷,即每笔交易都会至少生成一组会计分录。

    下面以快捷支付收单为列

    假设条件:

    1、用户使用招商银行做快捷支付向企业商户下单购买产品。

    2、支付公司结算至商户余额账户。

    产品简称 交易阶段 账户变动 会计分录
    快捷支付 收单 银行应收至商户待结算户 借:应收账款-待结算-招商银行
       贷:应付账款-待结算-企业商户
      结算 商户待结算户转账至商户基本户 借:应付账款-待结算-企业商户
       贷:应付账款-基本户-企业商户

     

    二、账户体系

    账户按照所有权可以分为个人账户、企业账户、内部账户。个人账户是面向个人开设的电子账户,比如余额记录用户在支付平台的余额,企业账户是面向商户开立的账户,比如待结算户,基本户,手续费户。内部账户是支付公司为自身业务开展而设立的账户,比如在央行开立的ACS 账户、长款户、短款户。除此之外,支付系统还可以根据自身业务的需要设立各种不同的账户类型。

    所有的账户都记录着两方面的信息。

    1、账户基本信息:账户号、账户类型、余额、币种、余额方向、账户状态、开户时间、还有些权限控制(是否允许余额为负数、是否允许充值、是否允许提现等)

    2、账户流水信息:自开户以来账户所有余额变动信息。何时存入资金,何时取出资金、何时资金冻结解冻。

    名词说明:

    开户:开设个人账户、企业账户、内部账户。

    变更账户信息:变更账户状态、变更账户信息。

    记账:实时记账、定时批量记账。

    查询:查询账户变动流水。

    账户用例(记录商户侧)

    1)开户

    • 商户A是一家电商平台,接入支付系统快捷支付、支持借记卡和贷记卡;

    对于手续费征收,采取收支两线,并预存手续费10000元,及交易手续费为1%;同时因为该商户资质较好,交易时采取D+0实时结算。这里涉及到了垫资。

    • 商户开户,根据交易特点,需要开通以下账户:

    待结算户:用户在商户交易完成后,资金进入该账户。

    基本户:商户的余额户,可体现。结算后资金进入该账户。

    手续费账户:专门用来存放手续费的账户。

     

    阶段 待结算户 基本户 手续费户
    开户 0 0 10000

    2)收单交易

    用户上午9点在A电商平台上使用快捷支付购买1000元的商品,交易完成后,A商户结算户增加1000元。

    手续费按照1%标准收取,有商户支出,该笔交易手续费为1000*1%=10元,计入手续费账户,手续费剩余9990.

    支付公司设置D0结算时间为每天下午4点,下午4点后,待结算资金结转至基本户。

    账户变动如下:

    阶段 时间节点 待结算户 基本户 手续费户
    开户   0 0 10000
    收单 9:00 1000 0 9990
    结算 16:00 0 1000 9990

    3)提现

    A商户在下午16:30提现600,商户提现手续费按笔征收,每笔2元。

    商户提现600元后,基本户剩余400,手续费账户剩余9988。

    账户变动如下:

    阶段 时间节点 待结算户 基本户 手续费户
    开户   0 0 10000
    收单 9:00 1000 0 9990
    结算 16:00 0 1000 9990
    提现 16:30 0 400 9988

    三、会计核算体系

    按会计科目所反映经济内容的不同一般可分为资产类科目,负债类科目、资产负债类共同科目、所有者权益科目,损益类科目。

    资产类科目余额在借方,借贷类科目余额在贷方,资产负债共同科目类根据实际情况可借可贷。

    会计科目分为总账科目和明细科目。总账科目又称一级科目,是总括反映会计要素的科目,比如银行存款,应收账款。

    明细科目是对总账科目的细化的科目,在明细科目中。根据需要设计二级科目,三级科目。其中,没有下级科目称之为叶子科目。

    常见会计科目

    1.资产科目类

    银行存款

    应收账款

    在途调拨

    2.负债类科目

    个人账户余额

    公司账户余额

    应付账户

    3.共同类

    待清算充值款项

    待清算提现款项

    待清算支付款项

    科目账户层级

    四、业务流程

    基于消费类型的记账流程

    • 交易系统(收单)

    基于商户模式的收单交易,针对购买商品消费类型,异步请求清结算系统。

    • 清结算系统

    A-交易清分,算出给每个账户打多少钱,同时从每个账户收多少钱;

    B-交易结算出款:调用银行/通道代付接口,自动出款。

    C-对账:核算通道与支付系统的应收应付。注:对账业务流程最好不要跟清算、结算勾连在一起,跟上游通道对账与给商户付多少钱最好不要业务先后关系。

    • 账户系统

    记录每笔交易的收付记录。

    • 会计系统

    按照企业会计分录流水记账,记账采用复式记账法。

     

    账户、会计处理流程

    一笔交易至少在账务系统中产生一条账户流水记录(明细账),同时会在会计系统中根据业务规则产生一套或者多套会计分录流水,账户余额与会计余额想对应。账务系统是对外客户提供账户支持,客户的查询余额,明细都是来源于此;会计系统是为了内部核算管理的需求设定的,所有银行资金清算与结转都需要会计系统的支撑,内部户与外部户的资金核算管理也需要会计系统,两个系统相互依赖,账户系统是会计系统的前置。

    交易流水达到账户系统后,账户系统为每笔交易分配账务流水,账务前置调用计费系统统计商户手续费。账户流水形成后,若是非实时记账,则直接通知业务系统记账完成,待定时任务跑批执行缓冲记账,若是实时记账,则系统开始记录分户账流水和更新分户账余额,余额更新完成后通知业务系统记账完成。账户系统记账完毕后,将定时或者准实时以批量接口发送至会计系统,会计系统会为每笔交易记录会计分录流水。对于会计记账,需要支持一借一贷,一借多贷模式,会计记账也分为记分户明细账和更新会计余额。

    会计记账完毕后,每日日终,进入批处理流程,日终处理是对日间没有处理完毕,以及不需要在日间处理的任务进行批处理的过程,在记账中日终处理主要是指业会核对,即账户系统余额与会计系统余额间的核对。

    展开全文
  • Meteor 添加账户系统

    千次阅读 2015-03-13 11:40:27
    Meteor 添加账户系统我们给meteor添加一个账户系统 导入包 meteor add ian:accounts-ui-bootstrap-3 meteor add accounts-password在界面添加登陆按钮 {{> loginButtons}}result

    Meteor 添加账户系统


    我们给meteor添加一个账户系统

    • 导入包

      meteor add ian:accounts-ui-bootstrap-3
      meteor add accounts-password

    • 在界面添加登陆按钮

      {{> loginButtons}}

    • result
      登陆
      登陆后效果

    展开全文
  • 互联网金融系统的核心是支付结算,而支付结算的基础又是账户系统。互金账户系统的特点是并发量大、响应快、交易金额大,热点账户问题突出。一个合格的账户系统既要解决上述问题,又必须绝对保证资金安全。作为这家...

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

    一、账户体系

    1.1 账户结构

    支付结算账户体系是客户、用户、账户三层结构,证件号和证件类型唯一确定一个客户,客户号和机构号确定一个用户,一个用户下可开多个不同类型的账户。如图:

    1.2 账户属性

    账户系统的基础是账户,所有的操作都围绕着账户进行,账户包含以下一些属性:

    • 会计科目:每个账户金额的变动要体现一些会计的属性,以便会计核算。
    • 账户类别:分为个人账户、企业账户、平台类账户。
    • 账户明细:账户的明细是反映账户余额变动的每笔详情,采用复式记账法,包含本对方账号、账户等信息、摘要、借方的发生额及余额等信息。
    • 账户余额:记录账户的实时余额。

    1.3 会计科目

    账户下挂在最底层的会计科目下,会计科目决定了账户的含义及余额变动方向。会计科目的一些属性如下:

    • 科目类别:资产类、负债类、所有者权益、成本类、损益类等。
    • 科目级别:会计科目的级别,一级科目、二级科目、三级科目等。下级科目归属上级科目。
    • 余额方向:标示余额是在借方还是贷方。
    • 科目的期末余额:每日日切后会汇总底层科目所有下挂账户在上一会计日的余额总和,上级科目汇总下级科目的余额总和。

    1.4 科目树

    支付结算账户系统采用科目树的概念,每个机构都会绑定一个科目树。科目树的根节点是一级科目,底层的科目下挂账户,结构如下:

    二、账户系统架构

    支付结算账户系统采用公司自研的分布式微服务框架,对外提供http json接口,内部各服务间采用redis实现的消息队列通讯。

    2.1 账户系统功能架构

    支付结算账户系统分为接入模块、记账子系统、开户子系统、异步记账模块、查询子系统、定时任务子系统、日终子系统、异步日志模块,下图是账务系统功能模块图:

    • 接入模块:提供报文解析、验签、参数校验、权限认证等公共服务,是账户系统的统一入口。
    • 异步日志模块:异步记录业务系统请求报文。
    • 记账子系统:账户系统的核心模块,处理业务系统的记账请求。
    • 开户子系统:处理业务系统的开户请求。
      • 首次开立账户:为个人或企业开立客户、用户及提前配置的默认开通的账户。
      • 指定开立账户:个人或企业在首次开立账户后,可按科目号指定开立账户。
    • 查询子系统:提供账户、记账的一些查询功能。
    • 异步记账模块:提供异步记录账户流水的功能。
    • 定时任务子系统:处理失败重试、热点账户等的定时任务。
    • 日终子系统:提供日切以及日终跑批的功能。

    2.1.1 记账处理

    记账处理是账户系统的核心功能,该功能对性能的要求比较高,高并发下热点账户问题比较突出,资金的正确性也必须保证,并且根据业务不同,记账的分录也是五花八门,支付结算账户系统如何应对这些问题,这里重点介绍下:

    • 账户系统记账采用记账服务的概念,每个记账服务就是一个记账分录的模板,业务系统按照这个模板传入记账金额、账户号或者用户号等信息。
    • 账户系统采用redis分布式锁,防止业务系统重复提交请求。设置记账订单防重表,按照请求单号和机构号对记账请求做幂等性校验。
    • 采用复式记账法,按照会计规则按照借贷记录流水,有借必有贷。
    • 记账处理时,更新账户余额后同步返回结果给业务系统,异步的处理记账流水。同时设置补偿机制,定时重试记账流水处理失败的订单,重试三次失败后报警人工介入。
    • 记账规则处理,每个记账服务可以绑定一些记账规则,账户系统根据记账服务遍历其绑定的规则,顺序处理。

    2.1.2 热点账户问题

    热点账户问题是账户系统的痛点,也困扰了我们很久,这里着重说下。

    -- 充值时的记账分录是:

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

    贷方:个人余额账户(+)

    当大量用户充值时,三方支付的待清算账户就是热点账户,频繁的增加余额。

    -- 提现时的记账分录是:

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

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

    当大量用户提现时,三方支付的资产账户就是热点账户,频繁的减少余额。

    --业务收服务费的记账分录是:

    借方:个人账户(-)

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

    当大量向用户收取服务费时,商户服务费账户就是热点账户,会频繁增加余额。

    --业务服务费付款的记账分录是:

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

    贷方:个人账户(+)

    当大量用服务费余额向用户付款时,商户服务费账户就是热点账户,会频繁减少余额。

    记账时,所有涉及的账户余额都要做update更新,高并发情况下,当出现上述类型的热点账户时,由于数据库的行级锁,对同一账户的更新余额操作由并行变成串行,单个请求的响应时间变长,从而拖垮整个记账服务。

    支付结算账户系统针对上述问题做了如下处理:

    我们把热点账户按照金额变动方向分为加频账户(余额增加频繁)、减频账户(余额扣减频繁)、双频账户(余额增加扣减均频繁)。

    • 加频账户处理

    准实时更新余额。先将金额变动插入临时表中,由定时任务按照一定频率汇总发生额,并更新账户余额,而后删除临时记录。当加频账户减钱余额不足时,主动去汇总发生额。这里需要考虑主动汇总发生额和定时任务处理的并发情况,我们在该定时任务执行时设置redis锁,防止并发,主动汇总时会去判断这个redis锁是否存在,如存在证明定时任务正在执行,无需主动汇总,可能是真的余额不足。主动汇总同样会设置redis锁,定时任务同样会判断。

    • 减频账户处理

    将减频账户拆分多个子账户,减频子账户设置金额报警,如果某个减频子账户余额不足触发报警,会对该子账户做资金归集,将其他子账户余额归集到该子账户(每个子账户设置可归集金额限制)。如在交易过程中发现该子账户余额不足,转向使用其他子账户记账。由于拆分子账户,余额查询时需要汇总各个子账户余额返回;记录主账户流水需要记账后余额,这里需要异步计算汇总。当减频账户加钱时,需要平均分配入账到不通的子账户。

    • 双频账户处理

    将双频账户拆分多个子账户。加钱时,准实时更新余额,先将子账户金额变动插入临时表中,由定时任务按一定频率汇总发生额,将汇总的发生额更新进对应的子账户,并删除金额变动记录;减钱按照之前减频账户的逻辑执行。

    2.1.3 记账死锁问题

    高并发情况下,当多个账户之前互相转账时,可能会出现死锁问题。

    例如:A余额账户 —> B余额账户(线程1) 和 B余额账户—>A余额账户(线程2) 两个转账请求并发,账户系统对每个转账请求都会更新A、B余额,这两个更新需要在一个事务里,正常流程线程1先更新A,再更新B,线程2先更新B,再更新A,线程1更新完A后会等待B的锁,不提交事务,线程2更新完B后会等待A的锁,不提交事务,这样两个线程互相等待锁,造成死锁。

    支付结算账户系统针对这种情况提出了解决办法,对账户号进行排序后再更新余额,这样每个线程都是先更新A再更新B,解决了死锁问题。

    2.2 账户系统存储层架构

    支付结算账户系统数据库采用Mysql,缓存采用redis。

    • Mysql数据库采用主从架构,一主二从,主库向从库同步数据。针对一些数据量大的表进行分表,比较有代表性的是账户流水表,既要按账户维度查询,又要按时间维度汇总,所以针对这个特点,冗余了一张表,一张按照账户分表,一张按照日期分表。

    • Redis采取集群架构,集群中每个点主备的形式。

    2.3 账户系统的网络层架构

    账户系统各个服务部署在同一机房,其中记账子系统和异步记账模块部署在4个不同的物理机上,其他子系统和模块部署在2个不同物理机上。最前端采用nginx实现负载均衡。

    展开全文
  • 账户系统的具体实现

    2019-05-16 17:47:53
    在上一篇文章中我们通过场景举例的方式,讨论了一套相对通用的互联网业务账户系统,从业务模型上应该如何定义。那么除了从业务模型上进行定义外,在具体系统实现上又该如何设计?又有哪些需要注意的地方呢?在本篇...

    在上一篇文章中我们通过场景举例的方式,讨论了一套相对通用的互联网业务账户系统,从业务模型上应该如何定义。那么除了从业务模型上进行定义外,在具体系统实现上又该如何设计?又有哪些需要注意的地方呢?在本篇内容中小码农就和大家一起讨论下账户系统的实现细节,希望可以和大家一起交流进步。

    事实上账户系统的业务逻辑是比较复杂的,对数据的一致性要求很高,特别是记账动作涉及强事务特性;另外,性能问题也是常常制约账户系统稳定性的一个比较突出的方面。在这种情况下,我们还需要考虑统的业务通用性设计问题,而这必然也会涉及很多配置项的设计,增加系统的逻辑复杂度。但是,也只有处理好了这些问题,账户系统才能保证业务的持续扩张,否则再好的理念也只是空中楼阁。然而,处理好这些复杂的问题,事实上并不只是某一点的设计就可以达成的,既需要逻辑流程设计上的优化,也需要采用合适的技术方案,更需要一个合理的系统结构。

    下面我们就从系统结构、整体流程、数据模型、记账规则,以及日终对账这几个方面与大家探讨从系统层面应该如何设计。另外对于账户系统中制约性能最常见的热点账户问题,也会和大家一起探讨。

    系统结构

    在之前的内容中,我们提到要设计一套可以满足互联网业务扩展的账户系统,所以账户是这套系统的基础,为了更好地支持不同业务、或同一业务不同账户的开户,我们需要将开户逻辑设计成独立的子系统,独立地提供包括开户、账户信息查询、余额查询在内的服务,以便逻辑复杂到一定阶段后可以更容易的扩展。在完成开账户动作后,就需要根据业务规则,设计好逻辑体系下不同交易类型的记账规则了,而这种规则配置是否智能,则是账户系统是否通用的关键;配置完规则后账户系统就可以接收业务发起的交易请求,并根据规则的配置完成业务资金流的处理了,所以,从系统结构层面也需要将记账核心服务设计成独立的子系统;此外,为了适配业务层不同的交易类型,主要是隔离记账逻辑与交易逻辑,还需要前置账户交易系统。

    最后,为了确保账户余额与流水之间的平衡,我们还需要在日终时对主要资金账户进行对账核算,确保账户流水发生额与账户余额的一致性。所以从系统结构层面,整个系统主要可以分为四个部分:

    之所以在账户系统、核心记账系统之上设置一层账户层交易系统,是为了将多变的业务交易逻辑与相对通用的记账逻辑进行隔离,避免在核心记账系统中冗余过多的业务逻辑导致后续出现臃肿的情况。例如业务层的交易类型可能是复杂多变的,如车费充值、押金支付之类,而这样的逻辑是没有必要让记账系统感知的,记账系统只需要根据交易系统传递的记账规则,根据会计分录完成资金流处理即可。

     

    整体流程

    为了确保系统能够正常Run起来,需要对系统整体的流程进行规划,这部分流程即包括线下流程,也包括线上流程,它是确保整个系统闭环的基础。例如,以账户系统需要支撑A公司打车业务为例,假设账户系统已经存在的情况下,那么它需要支撑这个业务应该经历以下两个阶段的流程:

    (一)、线下规划配置流程

     

    按照正常的流程设计,在业务开展之前,需要根据实际的业务资金流设计好具体的账户及交易资金逻辑,这部分逻辑一般是由PM与资金部门线下确认后形成正式的产品规格文档。之后,由具有权限的运营人员通过后台,或者前期在没有完善配置系统的情况下,由技术人员初始化到系统中,由于这部分配置关系到交易核心流程,所以在流程及操作规范的制定上要严格把控,避免配置错误导致的严重系统逻辑错乱问题。

    在这部分流程中我们首先需要配置业务主体,这里需要为A公司配置客户开户信息,之后需要按照之前业务模型定义的结构,在客户下为其开通表示打车业务线网约车用户,至此在系统中就完成了“谁?要干什么?”的定义。而具体“怎么干?”,则是在后面我们要重点配置的内容。

    那么具体需要配置什么内容呢?

    因为,账户系统本身是为交易逻辑服务的,所以我们需要明确业务中涉及账户逻辑的交易有哪些类型,例如在约车业务中主要涉及到司机端开户乘客开户、现金支付车费、余额充值、余额支付车费、司机提现等这些交易类型,所以我们需要为这些交易类型定义交易编码(tradeCode),并将其与之前开通的网约车业务用户进行关联,这样在后续的系统交易流程中,就可以进行交易权限控制,各业务线逻辑各自关联自身的交易类型,以免互相干扰了。

    而定义了这些交易类型以后,账户层交易系统具体接收到这样的交易请求后应该怎样执行逻辑呢?在互联网公司早期业务发展的过程中,很多都是将账户逻辑与交易逻辑耦合在一起的,这样会导致各个业务账户逻辑陷入要么继续耦合,要么各自定制、重复开发的怪圈。

    而要让这种逻辑变得通用,就需要将其规则化,即账户层交易系统接收到指定的交易请求类型后,会根据系统用户交易规则配置,获取开户、记账交易规则信息,然后记账系统和开户系统就会按照规则指定的逻辑执行了,这种执行逻辑识别规则,不感知具体业务逻辑。在上述流程中,我们将“平台层开户”也设计成了规则,只是这种开户动作接口并不对实时交易接口开放,一般是通过后台设置,即通过后台调用开户系统机构(平台)开户接口,开户逻辑根据网约车平台层开户规则,自动开立“服务费账户”、“代收付平台账户”、“结算账户”、“市场营销账户”这类开展网约车业务所需的平台层账户体系。

    其他开户交易类型,如司机端开户、乘客开户由于需要在具体用户注册、司机入驻时通过实时交易接口自动调用Api开通,所以这里需要配置好开户规则即可;至于,各个涉及资金变动的交易类型,如车费支付、余额充值之类,涉及到具体的记账规则的逻辑,也需要通过配置相应的交易记账规则,关于记账规则的配置设计涉及一点会计知识的细节,会在后面的内容中介绍到。

    (二)、线上系统交易流程

    完成系统级的数据定义及规则配置后,整个账户系统就会通过开放Api,为各个业务交易系统提供线上账户交易接口服务了。

     

    业务层交易系统向账户层交易系统发起交易请求后,系统会首先根据传递的客户、用户ID对请求权限进行识别,只有在(一)流程中设置了客户、用户主体信息的交易请求才被允许,之后账户层交易系统会根据传递的交易编码(tradeCode)识别交易数据开户交易类型,还是交易记账类型。开户交易类型则被转发至开户子系统进行开户处理,开户子系统根据tradeCode设置的开户规则,完成注册用户账户体系的开通,如:乘客张三,会依次为其开通客户身份、打车用户身份、以及打车用户涉及的余额账户,余额返现账户,押金账户的开通。

    而如果为交易记账类型,假设这里为乘客使用现金支付车费,则请求被转发至记账子系统,记账子系统根据业务线客户、用户ID、乘客业务用户ID以及tradeCode获取记账规则,完成资金逻辑记账处理。

    规则涉及的账户逻辑如下:

     

    记账规则

    在账户系统中,记账规则逻辑的设计是最为复杂的一项设计,需要在兼顾会计逻辑的情况下,还需要将其设计成较为通用的规则,以上面用户支付车费的账户资金逻辑为例,如何将其设计成规则配置呢?

     

    在以上记账规则表中,定义了业务线用户ID(merchUserId),表示该业务模式在系统中的唯一编码;记账交易类型(tradeCode)由具体的业务线交易模式定义,例如打车业务用户现金支付车费。这两个字段由定义客户用户信息、用户交易类型,可根据实际业务定义。

    后面的字段主要定义了账户交易逻辑的情况,例如changeType中定义的记账,表示按照规则正常的借贷方向进行余额更新,而冻结、解冻则是对账户余额进行冻结、解冻操作,增加、减少是根据规则直接对账户进行增加及减少操作,之所以定义上述不同类型,主要是为了适应不同账户操作逻辑,具体定义及含义,大家也可以根据自身公司的实际业务情况进行定义。

    可能这么解释大家会有比较大的疑问,我们以线上交易流程中涉及的网约车用户现金支付车费的资金逻辑为例:

    根据规则表的设计,以上规则描述了各账户资金流的变动逻辑,其中涉及账户类型、借贷方向、资金类型、记账科目以及记账步骤。当业务层交易发起至账户层交易系统后,账户层交易系统会获取以上记账规则,并根据规则描述的账户类型,找到普通消费用户、平台层用户、普通服务用户对应的账户信息,并按照规则逐条进行记账逻辑执行。

    通用数据模型

    在上面的流程及规则涉及中,以网约车业务为例,通过两个流程说明了账户系统应该如何支撑着项业务,虽然,看着并不是特别复杂,但是从系统设计上看却是涉及了很多实体信息,接下来我们从数据建模的角度,看看如何设计系统的数据模型。

    在模型中我们根据逻辑,抽象了客户、用户、账户相关实体,同时也抽象了账户流水、科目信息、记账规则、开户规则,交易类型等信息。系统通过这些实体设计相关表结构,系统就初步具备了运转能力了,大家可以根据实际情况增加其他实体信息。

    会计科目

    会计科目是账户系统中比较基础的概念,它的定义决定了账户的一些属性特征,例如是否可透支,属于资产类or负债类,可以根据不同公司财务的需求进行设计。

    记账策略

    大家知道记账动作是强事务的,按照正常记账逻辑以上规则执行过程中涉及的4个账户更新需要具有原子性,要么都执行成功,要么全部回滚,而对于普通消费账户、普通服务账户,这些账户都属于个人账户,在线上实时交易中的并发度是有限的。而对于平台层账户,包括代收付账户、服务费账户等,平台所有的交易都涉及这些账户的资金变动,所以如果在某一个交易过程中对其加锁,会导致该账户记录的加锁-更新动作非常频繁,成为热点账户,影响系统性能。

    所以在规则中我们加入了是否缓冲记账的配置,一旦配置为缓冲记账,则在执行该规则时,只是把该记账逻辑放入缓冲队列的逻辑与其他规则在一个事务中,而具体账户更新逻辑则是由缓冲记账系统完成,该逻辑可设置为日间完成,或日终完成。

    从而缓解热点账户问题导致系统性能瓶颈,但是需要注意,这种方案也对缓冲记账逻辑提出了比较高的要求,需要缓冲记账系统尽量保证记账动作执行成功,一旦执行失败前面同步执行成功的记账逻辑回滚起来会比较麻烦;另外,如果之前的同步记账逻辑在发送缓冲队列成功后,自身逻辑又失败了,则需要及时发送冲正机制,取消该缓冲记账动作。

    日终对账

    为了确保账户余额始终处于相对正确地状态,需要对日终账户流水进行各种试算核对,确保所有流水发生额累加后的余额+期初余额能够与当前余额匹配,这里会涉及到比较复杂的对账逻辑,需要大家在实际系统研发实践中加以考虑。

    技术点拓展

    在账户系统的研发设计过程中,还会涉及很多其他问题,例如账户流水数据量非常大,同时数据的留存时间又要求比较长,所以需要考虑数据的分布式存储,目前小码农所在公司,采用了TIDB这种分布式数据库,大家可在实践中根据自身情况进行选择。

    另外,账户的频繁更新,在系统并发量非常高的情况下,还会遇到性能瓶颈,如何在保证用户体验及数据正确性的情况下,采取更多的技术手段,如采用Redis/Codis进行缓存记账,也需要在实践应用场景中进行探索。

    后记

    由于账户系统逻辑相对比较复杂,涉及很多会计知识及细节逻辑,本文只是描述了一种理念与思路,真正做好这套账户系统还需要大家根据自身场景进行取舍与裁剪。由于作者水平有限,不足之处,还请多多包涵!

    转摘于:http://www.sohu.com/a/253132589_684445

    展开全文
  • TCC分布式事务是效率最高的分布式事务解决方案之一,本高阶实战教程使用亿级金融账户系统为案例,详细的讲解了TCC分布式事务的概念、建模、异常与调优。
  • 互联网金融-资金账户系统设计

    千次阅读 2019-09-16 15:06:13
    互联网金融-资金账户系统设计 支付系统设计 互联网账户系统如何设计(上篇)? 互联网账户系统如何设计(下篇)? 支付对账系统怎么设计? 移动端支付系统如何设计有效地防重失效机制? 如何做一个对账系统 聊聊对账...
  • 转载自 互联网账户系统如何设计 在很多互联网公司业务发展的早期,业务模式比较单一的情况下,涉及用户账户资金交易相关的逻辑也比较简单,但是随着公司业务模式的不断创新及类型的多元化发展,会渐渐发现现有系统...
  • 使用AccountManager和AbstractAccountAuthenticator建立账户系统使用AccountManager和AbstractAccountAuthenticator建立账户系统 为什么要使用AccountManager和AccountAuthenticatr AccountManager和Authenticator...
  • )我们通过场景举例的方式,讨论了一套相对通用的互联网业务账户系统,从业务模型上应该如何定义。那么除了从业务模型上进行定义外,在具体系统实现上又该如何设计?又有哪些需要注意的地方呢?在本篇内容中小码农就...
  • 导读在上一篇文章中(互联网账户系统如何设计(上篇)?)我们通过场景举例的方式,讨论了一套相对通用的互联网业务账户系统,从业务模型上应该如何定义。那么除了从业务模型上进行定...
  • 现要设计一网站账户系统,可以支持手机邮箱注册登陆,同时支持腾讯QQ微信及新浪微博等第三方账号绑定登陆,该如何设计网站的账户系统数据库?之前没有相关经验,不知道有哪些需要休息的地方,求高手指教!
  • 我们需要给所有前台业务提供统一的账户系统,用来支撑所有前台产品线的用户资产管理,统一提供支持大并发万级TPS、亿级流水、数据强一致、风控安全、日切对账、财务核算、审计等能力,在万级TPS下保证绝对的数据准确...
  • 基于成熟的聚合支付云服务,Ping++ 正式推出「账户系统」和「多级商户系统」。
  • 账户系统设计(上)

    千次阅读 2019-05-16 09:19:54
    在很多互联网公司业务发展的早期,业务模式比较单一的情况下,涉及用户账户资金交易相关的逻辑也比较简单,但是随着公司业务模式的不断创新及类型的多元化发展,会渐渐发现现有系统账户逻辑越来越雍肿,不仅难以支持...
  • meteor 自定义账户系统

    千次阅读 2015-04-08 15:18:21
    当前版本Meteor默认安装bootstrap2,使用bootstrap3需要安装Meteorite,同时需要安装Meteor的最基本的账户管理代码包。 npm install -g meteorite mrt add bootstrap-3 mrt add font-awesome meteor add accountss-...
  •  博易鑫管家,即博易鑫(分账户系统)期货资管风控交易软件,“澎博资产管理系统可以将一个或多个真实账户(主账号)中的资金,分配给任意个子账号,每个子账号使用分配给自己的资金额度进行投资。系统可为每个子...
  • 1.问题背景:我们大学里面的数据库课程的上机课程的上机作业中,一般要求我们学生利用“PL/SQL”的“Scott账户系统自带的数据库表格”来编写数据库题目要求的SQL查询语句。但是我们学生总是会忘记如何登陆PL/SQL的...
  • [提炼&总结]账户系统的设计

    千次阅读 2018-07-30 16:05:00
    一般而言,系统内都会有用户模块,如果涉及到钱、积分、兑换券之类的,那么最好搞一套账户模块。 简单的账户模块分为两部分,账户和流水记录。 最简单的账户模块 在这种简单的模块内,典型的场景是用户做了...
  • 互联网账户系统如何设计(上篇)

    千次阅读 2019-01-04 11:10:15
    在很多互联网公司业务发展的早期,业务模式比较单一的情况下,涉及用户账户资金交易相关的逻辑也比较简单,但是随着公司业务模式的不断创新及类型的多元化发展,会渐渐发现现有系统账户逻辑越来越雍肿,不仅难以支持...
  • 在很多互联网公司业务发展的早期,业务模式比较单一的情况下,涉及用户账户资金交易相关的逻辑也比较简单,但是随着公司业务模式的不断创新及类型的多元化发展,会渐渐发现现有系统账...
  • 有了用户账户系统,就能够增加用户的黏性,能够根据用户的日常使用习惯提供更贴心的服务,并且,有了这个平台,就可以加入更多更有趣的元素,可以把学术搜索打造成研究人员的一站式服务中心。 功能具体的特色...
  • JAVA项目:简单的银行账户系统1

    千次阅读 2017-08-07 19:43:31
    这是我在初学Java的第一个实战项目,在很多视频也有相关的介绍, 这是非常适合新手的一个简单的代码,后续也有提升版本。 这里就不赘述,直接上代码!...//账户余额 public Account(double init_balance)

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 23,657
精华内容 9,462
关键字:

账户系统