20180623_193041

一、24小时的概念及带来的问题

  1. 24小时是个系统可用性的问题,比如晚上出去夜宵用银行卡结账、去KTV凌晨刷卡结账、去国外其他时区旅游刷卡消费等都要求核心系统提供24X7不间断服务。
  2. 所有的时段都有交易在发生,客户账户余额24小时不间断更新,在客户账户层面如何计提客户账户利息?,如何进行会计科目的余额与账户余额总分核对?

客户交易用到了账户余额(读写)、利息计提也用到了账户余额(读)、会计科目总分核对也用到了账户余额(读),但是由于24小时不间断服务带来了账户余额不间断发生更新变化,无法得到一个静止状态的余额(数据量小的银行可以考虑使用oralce数据库的flashback功能得到一个静止状态的余额),故24小时要解决这一矛盾,将客户账户余额解耦,将实时交易用到的余额与计提账户利息用到的余额、会计科目用到的余额进行解耦(将对客户账户余额的读和写解耦)。

所以我们要把账户余额分成两个概念,姑且定义成可用余额和账面余额。

由于每笔交易都包含有日期、会计科目报表也包含日期,因此系统日期也要根据使用的场景解耦成 1. 联机系统交易日期 2.批量处理日期。

上述思路是对账户余额在空间上的解耦,即使用两个字段来分离存储(单表双余额)。还有一种思路是对余额在时间上解耦(多表单余额),即日终时段客户发起的交易不实时修改余额,而是登记到另外的表,事后再追账去更新账户的余额。

二、单表双余额的处理方法及存在问题

2.1单表双余额的处理方法

在包含余额的账户主表里面有账号、上笔发生日期、可用余额、账面余额,平时客户查询、存取款等操作的都是可用余额,每一笔操作都会有唯一(每日唯一,甚至是系统生命周期内唯一)的流水号对应,系统逐笔记录形成业务流水,以供后续生成会计流水用(从业务流水到会计流水可以作为另一话题展开)。流水信息里面包含了流水号、业务日期、账号、交易场景(交易码)、发生额等。

日终批处理开始之前系统日期(联机交易日期和批处理日期都为T日),先对联机系统的交易日期切换到下一天(T+1日),这样系统在此之后收到的交易都是下一天(T+1日)的,因此T日的交易不会有变动了,这样批量处理系统根据T日的业务流水信息逐笔修改账户的账面余额,待T日所有的业务流水处理完毕后,就得到了账户在T日的日终余额,批量系统可以后续对账户根据日终余额进行利息计提,也可以对T日的会计报表和分户账余额进行总分核对,在T日的全行总账生成完毕后,批量处理系统在T日的工作也就完成了,此时批量处理系统的日期切换到T+1日。

2.2单表双余额设计存在的问题:

  1. 联机系统日切时的数据库长事务对系统造成的影响
    a. 在日切时,sleep一定的时间等待T日的数据库事务提交
    b. 超过一定的时间仍然没有提交的,可以放在下一天修改账户的账面余额和入会计账。
    c. 考虑对数据库的长事务进行监控和优化,比如对数据库会话进行日期标识,之后再根据条件kill
  2. 日终批处理的任务太重,相当于要把白天的所有操作处理一遍
    a. 将日终的部分任务移到日间(日切前)处理,提前完成一部分任务,从而缩短日终的处理时间。
  3. 由于数据库是行级锁,存在一定的几率发生日终过账程序与联机程序处理到同一条记录的情况,这种情况下,一般导致日终过账中断或者联机交易中断。联机交易中断后,客户可以再次发起记账;日终过账程序中断可以考虑出错时保存断点,之后从断点开始继续处理。

需要24小时运行又需要按日出报表的系统都会遇到类似的问题,可能各家有不同的设计,上述是我所了解的一种,各位老师也可以讲讲你们的设计。

三、Q&A

Q:日切是什么意思?

A:就是营业系统切换营业日期,特别银行日期敏感的业务,营业日期是独立于自然日期、机器日期的你发生业务的利息不一样了


Q:你们的批处理用的什么技术?

A:这些技术都是连着一串的,批处理就是主要解决并行分流和重启的问题,什么技术都可以。


由于数据库是行级锁,存在一定的几率发生日终过账程序与联机程序处理到同一条记录的情况,这种情况下,一般导致日终过账中断或者联机交易中断。联机交易中断后,客户可以再次发起记账;日终过账程序中断可以考虑出错时保存断点,之后从断点开始继续处理。

Q:这里为什么会处理到同一条记录?日终过账不是处理的是从上个日切到这个日切中的交易吗?

A:某个账号在批处理时段发生交易,而恰好批处理作业也在处理这个账号(比如利息计提) 就会有锁的冲突。


Q: 现在银行这块核心用的什么数据库?

A:我了解的都是oracle,毕竟非常依赖数据库。

Q:ibm大型机,小型机?

A:数据库都是部署在ibm P系列小型机上,应用一般是C 或者java 我认为可以集群部署到linux上的,不过银行也是把这个部分部署在ibm服务器上

Q:存储呢?

A:存储都ibm或者emc

Q:传统方案的标配

A:24小时营业的系统如果技术力量不够,做不到高可用高可靠,很难有动力做出改变,一些边缘的系统创新会多点吧


Q:这个核心系统是指贷记卡和借记卡系统吗

A:没做过贷记卡系统,不了解,我了解的是常规的存款账户、贷款账户的系统。业务流水到会计流水通过 会计场景(交易代码)+ 账户类别 关联出来处理

Q:是根据每笔交易(交易代码) 会 配置一个会计分录是吧?

A:每类交易


Q:你们的业务流水号是如何生成的 sequence 吗?流水号是随机的吗?

A:外围系统给的,服务调用方给的。


Q:请问一下数据库主键使用流水号么?没有id的概念了?

A:自增,UUID,存储过程模仿ORACLE序列,时间戳+机器码+递增序列,这几个都见过。这是偏向技术这块的(主要技术点:唯一性,路由),偏向业务的比如订单号这块可能会有一些标识,微信订单号,支付宝交易号28位,淘宝订单号18位。对于业务这块的做法,我很喜欢类似科目段的设计方式,加标识在里面。对于技术这块的做法参考snawflak。


本文档来自支付产品技术交流群的聊天记录整理,由志愿者整理并发布到本网站。如需要及时收到来自支付产品技术交流群的最新消息,请扫码关注“凤凰牌老熊”的微信公众号。 本群面向支付行业的有经验(2年以上)的产品经理、软件工程师、架构师等,提供交流平台。如想加入本群,请在本文评论中留言(不公开),说明所在的公司、负责的工作、入群分享的主题和时间。