tickcount()修改成小时分钟_银行核心系统24小时机制实现总结

本文共2268字 | 建议阅读时间：5分钟

作者：张广

在核心系统的设计实现中，24小时机制向来是一个重点难点。早期的银行只有柜面一个业务办理渠道，因此当时的综合业务系统，跟随网点的营业时间，分为日起，营业，日结，日终批量这几个阶段。所有网点日结后，才开始日终批量，这时是不办理联机业务的。

随着科技发展，银行逐渐开展了自助设备，网上银行，手机银行等多种电子渠道，接入了支付系统，银联系统等第三方接口。这时，对核心系统就提出了的24小时支持的要求。

24小时实现机制有准24小时和真24小时之分。

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

下面总结的就是真24小时的实现方案。要做到真24小时，需从以下几个方面解决。

1、分户账的改造

分户账处理主要有两种情况。

一是交易的记账日期可以先发生次日，再发生前日。例如，日切后先发生过次日的联机交易，再执行日终批处理记上日账。又比如，在日切点交易并发时，日切后的交易先被调度到执行完毕，日切前的交易后被调度执行。

二是日终批处理中能获取上日结束的准确余额。

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

核心系统有很多序号，是按周期设置的，最常见的是日序号，每天从1重新开始。原先常见的做法是，通过日切后一个序号初始化批处理，批量清零。

24小时情况下就不能如此了，同样也要考虑两个日期以及先后顺序的问题。与分户账类似，使用双字段法给序号表设置当前序号，上次更新日期，上日序号，解决不同日期交易取用的问题。

3、明细类的改造

明细类包含有账户明细，记账传票流水等这类带日期的记录表。

以往的系统，在日切过程中进行当前表删除并导入历史表的操作，导出期间会影响按日期的查询结果，这也是24小时需要避免出现的。

解决方法是，将这类表按日期分表或分区，操作时根据日期就可算出应该操作的表名或分区名，免除了数据的搬移。这样在任意时间均可支持正确的写入和查询。

4、冲正交易的改造

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

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

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

5、程序版本更新时的处理

如果应用系统支持运行中动态加载卸载库和名称绑定，例如Unix环境的动态链接库，则可以通过控制交易结束后开始前进行动态库的卸载加载，来保证交易内程序版本的一致性。