对于突发性巨量事务性类需求，如何实现？ - 金融行业 - ITPUB论坛－专业的IT技术社区

wangjia

但是实际上如同上班中早高峰和晚高峰一样的，就那么一小段紧张，而其他时段都比较空闲
如果系统，特别是数据库，按照峰值时段（现在设计多是如此）来应对，不可避免的造成了投资的浪费
从技术角度上，对于数据库部分，如何从设计上进行部分或者全部的解决？
ps：纯从网银网站和银行网点的每月或者每天特定的高峰时段情况想到的
肯定要留有余量啊。要是觉得浪费，可以在空闲的时候拿来干的别的计算。IBM的动态分区就是这么搞的。
不过我认为不是太有必要，完全分开更省心。
首先看设计，能否告知后来者还需要多长时间能够处理，就象交通广播一下，可以告知后来者提早或晚点，让其有知情权和自主决策权。
其次看能否开辟类似付费的绿色或紧急通道，充分发挥相关资源的潜力，比如开通直升机通道，只要价码合理会有客户选用的。
最后是开发并开放替换性选择，不仅缓解当前业务处理压力，也给替换性选择有新的机会与客户接触。
当然，对于流失的具名客户或者投诉应该积极处理，尽量做好沟通，获得有用的信息。
最后要反过头来看看技术上的能力规划是否是恰当的，要做好分析。
事务尽量从数据库前移到中间层，中间件服务器可以根据流量水平扩展；
引入内存数据库技术；
freesearcher 发表于 2012-1-30 09:07

事务尽量从数据库前移到中间层，中间件服务器可以根据流量水平扩展；
引入内存数据库技术；
事务前移会导致事务一致性问题。内存数据库有丢失数据的危险。
bazookapb 发表于 2012-1-30 11:17

用云计算啊，google什么的不都是可以动态伸缩的么
问题google的应用不是事务性的啊！
pacman2000 发表于 2012-1-30 17:05

事务前移会导致事务一致性问题。内存数据库有丢失数据的危险。
中间层上也有事务控制的，对单个数据库不会导致事务一致性问题，跨多个数据库时就多对一下账了。
引入内存数据库的意思也是尽量在前置的内存上完成，主要是读数据，写数据还是及时刷硬盘缓存，那个有电池保护的吧。据说oracle有times ten产品，应该有数据保障的吧。
freesearcher 发表于 2012-1-30 17:22

中间层上也有事务控制的，对单个数据库不会导致事务一致性问题，跨多个数据库时就多对一下账了。
引入内 ...
你说的中间层，是指非存储过程的数据库应用程序运行的机器吧。这个一般就直接叫应用后台了。银行系统里的中间层，往往是说综合前置，ESB之类。现在银行独立的系统越来越多，例如建行现在就有200多个系统，相互的对账很快会成为下一个麻烦。
供电保护，其实一般的银行都有，包括备用线路和发电机。但是，银行的事务要求很高，包括系统崩溃都要考虑进去。读数据在内存进行，这个在普通的数据库里，都已经用缓存实现了，内存数据库主要的区别还是在写数据上面。