核心系统的24小时问题 - 金融行业 - ITPUB论坛－专业的IT技术社区

wangjia

这个问题也许不在成为问题了，各家银行都宣称自己已经实现了24小时服务，但确实如此吗？
据我所知，工行已经实现了真正意义上的24小时服务，切换日期时间小于0.1S，对客户基本没有影响，不会出现暂时停止联机服务的情况，也没有切换系统运行模式
有些行，如交行等，是通过建立临时表，把在批量运行时的联机交易放在临时表中，等批量运行完后，在根据临时表进行补账处理，这样也算实现了24小时服务，系统需要切换运行模式，所需的时间大概在分钟这个级别吧
各路高手讨论一下，还有哪些行采用什么样的设计方法实现24小时的？
何为翻牌式？呵呵
其实24小时实现的难点我认为主要在两个方面：1、帐户昨日信息的保存，所以很多系统是通过建临时表来存储日切前的帐户数据；2、联机和批量的冲突，通过临时表和原表来分别处理批量和联机从这个角度倒是不错
有没有知道工行24小时实现的细节？
我所知道的24小时的模式都是跟交行实现的思路差不多。
都是在批量时，联机交易写临时表，然后进行追账或者补账。
To mackednice：从系统架构设计上说，设置双余额、帐户初笔是关键；从数据结构设计来说，双日志、批量联机用表尽量分开、相关工作表有工作日期减少批量联机的冲突；从程序设计上，程序支持断点再续或无条件重提。
To binss：谢谢，原来这么多高手讨论过了，学习ing。
To 看热闹的好人：您说的很对，没有最完美的方案，只有接近的方案。个人认为，在联机事务正常反应时间内（3s）完成日切可以算是比较接近的方案。
最初由 游侠老KING 发布
[B]To mackednice：从系统架构设计上说，设置双余额、帐户初笔是关键；从数据结构设计来说，双日志、批量联机用表尽量分开、相关工作表有工作日期减少批量联机的冲突；从程序设计上，程序支持断点再续或无条件重提。
To binss：谢谢，原来这么多高手讨论过了，学习ing。
To 看热闹的好人：您说的很对，没有最完美的方案，只有接近的方案。个人认为，在联机事务正常反应时间内（3s）完成日切可以算是比较接近的方案。 [/B]
欢迎多讨论!