|
|
我的理解是，做到真正的7 X 24小时是不可能的，至少目前是，这就好比我们了解到的操作系统或DBMS，不管它体现在宏观上进程或任务是如何并行或并发达，在底层的原子操作看来，其实还是串行的；
我的意思是7 X 24小时，在系统实现上一定有一个停顿点，只不过
设计的好的系统，可能这个停顿时间比较短；
其实上面所说的双日志，双主档来实现，个人觉得与操作系统
平台的关系应该不是联系的很紧，大机上可以，UNIX上也可以，
关键是看应用系统或业务平台的设计，比如UNIX，我以前一个公司
也做金融，绝大多数项目都是在UNIX上，也有7 X 24的解决方案，
一种方案是：
用两套中间件平台（公司有自已的中间件平台产品），做主备切换
；
另一种方案是使用另外一个版本的平台，运行时有三种状态：
online,batch,onbatch（可能是我们自已的叫法，就是online和batch同时run ,但基本上这时batch量很少），这种方案与应用（AP）的耦合
较紧；
两种方案在数据库层面都有双日志及双主档的设计。
我们有一个重入的概念，就是系统自动把临时档上发生的联机交易（此时系统已经跑完当日批量）追到主档上，然后系统自动切换运行模式，这个切换在宏观上看是一个点，可以说做到了7×24不间断。在我们公司，其实对于这个特性，我们做应用开发的不需要考虑，公司的前辈和几位平台架构师替应用层做好了一切，应用层只要按照规范开发，系统会自动调度。
因为我真正了解的大型核心系统只有我们公司这一套，所以也不知道具体哪个7×24方案更好一些，就象啊哩说的那样，没有具体环境空谈实现没有实际意义。还有，啊哩也别对纯粹讨论概念生气，我们处于食物链下游，很多事情都是要等人家卖完概念、卖完平台、卖完产品，我们才有机会，毕竟，行业的带头人不是我们～
如果不考虑数据备份的问题，单从应用系统方面来考虑，可以使用双余额法：即日间做业务时同时修改2个余额，日终轧账时修改一个标志使其只修改一个余额，同时切换日期轧账，轧账完毕再修改标志同步更新2个余额，在修改标志和同步余额时会有停顿
真正完全24×7很难做到，但应该不是不可能－－看你愿意为此投入多少了。举个例子，一年停机10小时的水平，你的投入费用水平可能是1M USD级的，但停5小时，投入可能是10M USD级的，只停1小时，可能需要100M USD……也许只停一分钟需要1B USD，甚至可以为你的业务做到真正的24×7，但是这时候你自己会问，我真的需要24×7吗？为此我付出那么多的USD值得吗？
答案你自己决定……
要进行日切时,修改一个标志位.
然后将这个时间点上的帐务状况进行复制.复制完成后,复原标志位.
在此时间段内发生的交易信息,记录到另外的临时表(多个)中,该临时表和帐务信息表结构完全相同..
复制表和临时表的内容相加,就是前一日的全部帐务信息.
24小时也不是很复杂,想清楚了就是那么回事.楼主好好考虑一下,我们这个方案已经实施很久了. |
|
发表于 2022-9-11 08:32:05
发表于 2025-7-7 02:44:12
