谈谈24小时办业务你们都是怎么实现滴

dlms

我觉得没有绝对的24小时不间断,作日终的时候肯定会停滞一会的,然后日起来之后在去处理.
我以前接触的业务都是这样的,作日终的时候需要大量的处理数据,为了防止帐务丢失,是把系统状态该为不接收外来交易的状态,但是对于渠道交易要求24小时的业务,是采取暂时把那笔交易的数据记录在前置上,日启后来个批量发包,给客户的感觉是24小时.

好像我了解没有真的24小时的系统,但是今天听高人说os390上有算法可以实现,具体是怎么样的呢?
这个群太冷了大家都来讨论下哈

dlms

同时会计日期和系统日期不一样的,这样作也是为了避免帐务上的麻烦

zengjin8310

多进程不就可以了, 你说的"日终"我不知道啥意思, 不过我想这个操作之前把会计日期改到下一天,  然后"日终"用上一天的日期,只处理上一天的数据不就行了,"日终"开始执行后的帐务到下一天的日终开始执行前就是下一天的了,  那里需要什么高深的算法.

zengjin8310

银行金融软件大多数很白痴, 没一点技术含量, 别把他想复杂了.
国内几乎没有做金融工程, 相应的数学建模这些稍微有点技术含量的东西就更没有了

FH

想问问楼上啥有技术含量

胖有型

这个问题，以前我和同事们讨论过，从技术上来说，理论上是可以实现真正不间断的24小时，不过首先改动的程序比较关键，要组织人员大量测试，最后就减少那么几分钟，客户的需求不是很迫切；而且不间断的24小时，还有备份的时间点的问题要确定，还有一个什么问题我忘记了。总之就是技术上可以实现，但是从安全稳定的角度考虑，还是维护现状，停个几分钟比较理想。

dlms

原帖由 zengjin8310 于 2007-2-10 22:03 发表
多进程不就可以了, 你说的"日终"我不知道啥意思, 不过我想这个操作之前把会计日期改到下一天,  然后"日终"用上一天的日期,只处理上一天的数据不就行了,"日终"开始执行后的帐务到下 ...

这个观点我不同意,多进程你日切的那几10秒怎么处理啊,这个时候很容易丢帐的或者错记帐的,跟几个进程是米有关系的
标题好像是讨论真正的实现24小时作业,不是怎么来处理.其实假的24小时有很多处理方法滴.
1.日终的时候将任务交给备机,然后日启后在切回来.
2.日终的时候,不管来多少笔业务(都先把业务数据保存,日启后作个批量发包,这些帐算第二天的帐务,对于客户来说米有什么影响),其实帐务机的日切时间也就几10秒的,而且设计的时候都会考虑交易量的情况把日终放到交易量最小的时候来作.

其实实现24小时主要是为了电子银行部服务的,大多都是面向渠道业务.

至于什么是日终.这个还要我回答吗?

dlms

原帖由 zengjin8310 于 2007-2-10 22:10 发表
银行金融软件大多数很白痴, 没一点技术含量, 别把他想复杂了.
国内几乎没有做金融工程, 相应的数学建模这些稍微有点技术含量的东西就更没有了

不要这么说,技术什么是技术,含量什么又是含量呢,国内没有金融工程,我请问金融工程又是什么呢,每个行业都有每个行业的特点.

dlms

原帖由 胖有型 于 2007-2-10 22:59 发表
这个问题，以前我和同事们讨论过，从技术上来说，理论上是可以实现真正不间断的24小时，不过首先改动的程序比较关键，要组织人员大量测试，最后就减少那么几分钟，客户的需求不是很迫切；而且不间断的24小时，还有 ...

哈哈,我以前也考虑很多次这个问题,24小时针对的是渠道业务,实际上0点后,渠道业务就很少了,但是作国际业务,交易量大的时候还是有必要的,美国的客户很难对付的,哈哈

胖有型

原来楼上的做米国的单啊，佩服。我的客户只有国内的。
说来说去还是客户的需求，其实我想我们这边，如果客户真有这个要求，在现有系统架构不变的情况下，也是可以做得到的，我刚数了一下，还是有几个技术亮点的喔。只是不知道会不会有什么隐患，可能要多搞几次压力测试才看得出来。
不过要是客户没这个需求，觉得只要稳定，每天停个几分钟也无所谓，那我们自然就搞不起来了。