简析银行核心系统24小时设计思路

银行系统设计中24小时的概念及带来的问题

1. 24小时是个系统可用性的问题，比如晚上出去夜宵用银行卡结账、去KTV凌晨刷卡结账、去国外其他时区旅游刷卡消费等都要求核心系统提供24X7不间断服务。

2. 所有的时段都有交易在发生，客户账户余额24小时不间断更新，在客户账户层面如何计提客户账户利息？，如何进行会计科目的余额与账户余额总分核对？

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

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

1. 可用余额，用户层面查询到的余额，可以24小时不间断发生变化。

2. 账面余额，计提利息用到的余额、会计总分检查用到的余额。在过账程序入账时发生变化，平时静止不变。

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

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

下面简单介绍单表双余额的处理方法。

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

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

其他问题

1. 联机系统日切时的数据库长事务对系统造成的影响

a) 在日切时，sleep一定的时间等待T日的数据库事务提交

b) 超过一定的时间仍然没有提交的，可以放在下一天修改账户的账面余额和入会计账。

c) 考虑对数据库的长事务进行监控和优化，比如对数据库会话进行日期标识，之后再根据条件kill

2. 日终批处理的任务太重，相当于要把白天的所有操作处理一遍

a) 将日终的部分任务移到日间（日切前）处理，提前完成一部分任务，从而缩短日终的处理时间。

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

转自：https://blog.csdn.net/weixin_42306441/article/details/81006562

声明： 此文观点不代表本站立场；转载须要保留原文链接；版权疑问请联系我们。