银行业核心系统分布式数据库改造问题求解?

正如此前社区里其他老师所说:”目前金融行业绝大多数核心系统的数据库依旧采用传统的集中式架构(高端小型机+集中式关系型数据库+集中式SAN存储)为主的实现方式。”随着互联网金融产品种类的爆发式增长,银行业为了突破传统盈利模式,增强客户黏性,纷纷推出了互联网类的产品、营...显示全部

正如此前社区里其他老师所说:”目前金融行业绝大多数核心系统的数据库依旧采用传统的集中式架构(高端小型机+集中式关系型数据库+集中式SAN存储)为主的实现方式。”随着互联网金融产品种类的爆发式增长,银行业为了突破传统盈利模式,增强客户黏性,纷纷推出了互联网类的产品、营销活动,如工行、建行自营商城的名酒定时促销。这些产品和活动给传统的集中式关系型数据库带来极大挑战,硬件扩容、分库分表的传统应对手段效果不尽人意,无法适应营销期间海量数据存取及高并发请求响应的场景。为此,各大银行纷纷开始了核心系统分布式数据库改造的前期探索,部分银行已宣称完成核心系统分布式数据库的切换上线(张家港农商行,中信信用卡核心),但是整体效果和改造、使用过程中的问题未见详细描述且有待时间验证。
因此,想请教各位IT同仁,中型商业银行在准备核心分布式数据库选型时,除了必须要考虑的强一致性、高可用性的原则,还应考虑哪些问题?在CAP定律的限制下如何取得最优解?整个改造大致需要历经几个阶段?望各位同仁指点,非常感谢!

收起
参与18

查看其它 4 个回答匿名用户的回答

匿名用户匿名用户

以下纯属个人观点:
1)中型商业银行在准备核心分布式数据库选型时,除了必须要考虑的强一致性、高可用性的原则,还应考虑哪些问题?
业务系统改造成本:需要考虑sql兼容性(mysql or oracle),事务采用悲观锁模型还是乐观锁模型,数据分片是否对业务透明等

产品可靠性和自主可控能力:产品是否真正在金融交易场景尤其是账务系统经过长期验证,核心功能是否基于开源开发还是从零写起

高可用及容灾解决方案:方案是否满足公司实际硬件设施条件

2)在CAP定律的限制下如何取得最优解?
CAP定律适用于多副本之间,实际上现在的分布式数据库多副本更多使用的BASE定律,实现的都还不错

3)整个改造大致需要历经几个阶段?
改造过程还是老套路:先外围系统后核心系统,可以先作为从库,后逐渐切流量上去,最后的形态应该是和专有云融合,提升运维管理效率

证券 · 2019-11-26
浏览3452

回答状态

  • 发布时间:2019-11-26
  • 关注会员:6 人
  • 回答浏览:3452
  • X社区推广