Chinaunix首页 | 论坛 | 博客
  • 博客访问: 304677
  • 博文数量: 40
  • 博客积分: 1
  • 博客等级: 民兵
  • 技术积分: 670
  • 用 户 组: 普通用户
  • 注册时间: 2011-07-31 11:19
个人简介

从事银行核心系统设计开发的程序猿

文章存档

2019年(1)

2018年(4)

2017年(11)

2016年(6)

2015年(18)

分类: 信息化

2018-03-30 23:58:00

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

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

 

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

 

首先是分户账的改造。

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

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

 

其次是序号表的改造。

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

 

然后是明细类的改造。

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

 

最后是冲正交易的改造。

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

 

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

 

 

 

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

 

程序版本更新时的处理。

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

 

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

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

 

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

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

 

 

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

 

阅读(7916) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~