24小时实现方案概略 - 第2页 - 金融行业 - ITPUB论坛－专业的IT技术社区

wangjia

最初由 打死也不说 发布
[B]楼上是联想的吧

，双日期双余额的确是个不错的办法，我没有测试过，但有资料表明这样系统支持批量和柜面同时进行还是有问题，目前银行对pos/atm的24小时支持是比较成熟的. [/B]
对于柜面及批量的同时进行，有两个方面的冲突问题，一个是公共日志文件，一个是对分户帐的操作，对于公共日志文件在我说明的第4条里面，应该可以解决，对于分户帐的控制相对来说冲突的风险性比较小
核心设计不一样，24小时实现起来真是大相径庭，以上各位的系统都是实时更新分户余额的吧？所以会存在更新余额的冲突，甚至想出两个余额的解决办法，搞得贼复杂。
还有一种核心系统，分户只有一个上日余额，并没有当前余额字段。要取当前余额就是上日余额+发生额。当24小时切换后，系统批量日期仍为当日，联机日期跳到次日；批量和24联机同时开跑；批量取余额=上日余额+当日发生额。24小时联机余额=上日余额+当日发生额+次日24小时发生额。批量余额和24小时联机余额不会实时保存，不会存在冲突。还有你们提到的LOG，一般象流水、LOG文件都有日期标志，只要24小时跳次日，也不会存在冲突。
还要考虑一个情况，当批量跑坏后，可能需要数据恢复重跑，但24小时业务已经发生不可能重跑，这个需要特殊处理。
有些24小时方案可能要将系统分两个环境，一个是跑批，一个是24小时联机，跑完批后还需要把24小时联机重过帐。如果两个环境数据不关联，就要注意帐户透支情况：批量扣了帐（比如代收费），24小时那边同时取款。
非常赞同bjalec,//applaud
24小时在切换的时候，关键问题就是余额，那么可以反问，我们为什么在数据设计的时候需要余额呢？目前主流就是表结构里面不保存余额。
联机和批处理其实没有绝对的界限，有些厂商已经在研发联机批处理的核心业务系统了。
数据库备份和错误后恢复其实是个大问题，支持联机备份和恢复的数据库都有哪些版本？
to zlub:
MBI已经是一个支持开放思想的大公司，而且该文档的技术方案在业内已经不是什么秘密了，只是有感于大家敝帚自珍，搞得国内一直在重复的讨论一些问题，比较浪费大家的时间，所以就把这个文档拿出来供大家讨论了，如果有任何问题，可以发邮件给我，呵呵，我将根据情况进行协商处理。
表结构里面不保存余额 [/B]
这个除了可以很容易解决24小时主要问题外，至少还有以下两个好处：
1.解决帐务同时交易同时取余额可能出现帐户记录锁问题
2.交易冲销也不用更新余额而变得很容易。
可能有人会疑问，通过上日余额+当日发生额的方式，因为要统计当日发生而会对系统有很大压力，事实上呢？
其实不会有大影响，因为统计是按帐户键字操作，一个帐务一天做几百笔已经够多了，几百条记录按索引操作算得了什么？
但也有很大交易的帐户，比如象淘宝网的帐户，比如象中国移动的帐户，一天超过1万甚至10万笔交易都有可能。然而，恰恰很有意思的是，这些交易往往是贷记，并不需要去判断其余额。还有一种帐户，内部清算帐户，例如通存通兑帐户，如果是实时清算，交易发生也非常频繁，而这种交易通常也不会去理会清算帐户的余额。
所以，不实时记余额是可行的，甚至去掉余额字段也没问题，请大家不必担心...
如果不记录余额，待查询时实时重新计算可能并不一定合算。上述文档里的24小时是通过其他临时DB将上日余额再计算出来的