银行核心系统24小时机制实现总结

         在核心系统的设计实现中，24小时机制向来是一个重点难点。早期的银行只有柜面一个业务办理渠道，因此当时的综合业务系统，跟随网点的营业时间，分为日起，营业，日结，日终批量这几个阶段。所有网点日结后，才开始日终批量，这时是不办理联机业务的。随着科技发展，银行逐渐开展了自助设备，网上银行，手机银行等多种电子渠道，接入了支付系统，银联系统等第三方接口。这时，对核心系统就提出了的24小时支持的要求。

24小时实现机制有准24小时和真24小时之分。准24小时是核心系统在日切时停止联机交易一小段时间，待日切完成后再启动联机，通常时间控制在几分钟内，这段时间内未完成的联机交易被强行中断，不接收新的交易请求。真24小时是不停联机，在任意时间联机交易都可以正常发送处理，不会中断。下面总结的就是真24小时的实现方案。

 

要做到真24小时，需从以下几个方面解决。

 

首先是分户账的改造。

分户账处理主要有两种情况。一是交易的记账日期可以先发生次日，再发生前日。例如，日切后先发生过次日的联机交易，再执行日终批处理记上日账。又比如，在日切点交易并发时，日切后的交易先被调度到执行完毕，日切前的交易后被调度执行。二是日终批处理中能获取上日结束的准确余额。

主要的解决方法有AB表法，追账法，双字段法等几种，其中最优的当属双字段法。在分户账表中设置当前余额，上次更新日期，上日余额。发生交易时，用交易日期与上次更新日期比较。如果交易日期大，说明进入新的一天，将当前余额搬入上日余额，再更新当前余额，记录上次更新日期为交易日期。如果相等，说明是当天的后续交易，只更新当前余额，上日余额和上次更新日期不变。如果交易日期小，说明先发生了次日交易，这时同时更新上日余额和当前余额，上次更新日期不变。在日终批处理获取上日余额进行统计时，同样先判断上次更新日期，如果上次更新日期小于或等于上日，说明新的一天没发生过交易，取当前余额，否则说明新的一天已发生交易，取上日余额。

 

其次是序号表的改造。

核心系统有很多序号，是按周期设置的，最常见的是日序号，每天从1重新开始。原先常见的做法是，通过日切后一个序号初始化批处理，批量清零。24小时情况下就不能如此了，同样也要考虑两个日期以及先后顺序的问题。与分户账类似，使用双字段法给序号表设置当前序号，上次更新日期，上日序号，解决不同日期交易取用的问题。

 

然后是明细类的改造。

明细类包含有账户明细，记账传票流水等这类带日期的记录表。以往的系统，在日切过程中进行当前表删除并导入历史表的操作，导出期间会影响按日期的查询结果，这也是24小时需要避免出现的。解决方法是，将这类表按日期分表或分区，操作时根据日期就可算出应该操作的表名或分区名，免除了数据的搬移。这样在任意时间均可支持正确的写入和查询。

 

最后是冲正交易的改造。

外围发起冲正时，无法判断何时日切，因此核心应只提供统一的冲正交易，后台根据原交易记账日期和当前日期判断是当日冲正还是隔日冲正，并支持隔日冲正的处理。

 

特别提一点，批处理中，日切这一任务应等待1个联机交易超时时间，以防批处理过快，前日的交易未处理完就在后续批处理任务中获取上日余额。

 

 

 

此外，系统在版本更新时，也需要考虑如何尽量支持不停止联机服务。更新时还需注意一定要保证同一笔交易内不同程序版本的一致性，不能出现部分旧版本部分新版本的情况。

 

程序版本更新时的处理。

如果应用系统支持运行中动态加载卸载库和名称绑定，例如Unix环境的动态链接库，则可以通过控制交易结束后开始前进行动态库的卸载加载，来保证交易内程序版本的一致性。这种方式对于普通修复是可以了，但有时会严格要求新旧版本不能并存，切换时间点后必须全部执行新版本，这时候就要用额外的方法了，即暂挂请求交易的处理。在每个并发进程上一交易结束后，接收完新的连接请求，下一交易开始前，通过标志控制暂停处理，可以保持连接。当所有并发进程都处于暂停状态时，说明原有交易均已处理完成。版本更新后，修改标志放开处理，这时原先暂挂的交易会继续处理，对外感觉仅仅是这笔交易响应时间变长了，并未发生服务的中断。

 

参数表内容更新时的处理。

通常参数表是加载至缓存的，因此只要控制缓存更新的时机即可。参数表不会太大，缓存更新很快能完成，因此放在交易结束后开始前加载更新。同样，如果严格要求新旧不能并存，也仍需要暂挂请求交易处理。

 

数据库表结构更新时的处理。

表结构的变动分为新增表，删除表，新增字段，修改删除字段这几类。新增表和删除表时通过操作顺序很容易做到不停止联机服务。新增表时先建表，后更新程序，删除表时先更新程序，后删表。新增字段，修改删除字段可以通过SQL语句进行，执行期间会锁表，因此需要预先评估SQL执行时间长短，如果表数据量较大则需要用以下的方式实现切换：首先暂挂交易的接收请求处理，将原表rename为旧表，并以新的结构建立空的新表。修改访问这个表的所有程序，改为访问新表和旧表的合集的版本。随后开放交易处理，并以后台进程的方式，逐渐将旧表的记录一点一点搬移至新表，直到旧表为空。最后修改访问这个表的所有程序，恢复成仅访问新表的版本即可。

 

 

         随着银行对服务可用性要求越来越高，核心系统的设计也应当充分考虑，尽可能实现完全不停机的连续运行，这也是设计人员对优秀核心系统的追求目标。