目前,大多数机构实现的同城双活都只在应用部署及运行层面上,而数据库的访问基本是访问一个中心的数据库,无法做到各数据中心访问各自中心的数据库。
多活数据面临多个写入点,极有可能会错乱、会冲突、循环复制、数据环路环路等问题,这些情况下怎么保障数据一致性成为极大的挑战。因此,多数机构都采用了只使用生产中心的数据库,将生产中心的数据实时向同城中心同步的方法,一旦生产中心数据库故障,再切换至同城中心的数据库,同时将交易比例向同城中心倾斜。
请有经验的专家分享一下经验。
做双活的目的是提升业务连续性运作能力,如果为了双活连正常业务都受影响了,那就本末倒置了。
按银行业务系统的要求,技术架构首先要保证数据一致性,其次是RPO=0,最后才是RTO=0。所谓双活,本质上就是满足前两条的前提下看如何才能做到第三条。这也是绝大多数机构的双活只是AS模式或AQ模式的原因。
在双站点距离较近的情况下,采用Oracle Extended RAC加存储双活技术是可以做到双活的,但是对距离、网络质量有非常严苛的要求,方案好设计,后期运维的坑较大。
对于业务连续性要求非常高(必须要双活)的应用,建议从应用架构层面解决。
时间换空间,空间换时间,这是一个有争议的命题,想保证性能,一定程度上牺牲可靠性,想保证可靠性,一定程度上会损失性能,主要看业务场景的重要性。
目前闪存的趋势越来越明显,对于性能和可靠性都有要求的账务系统,可以采用全闪存阵列双活或同步解决方案,来实同城双活的架构。
安全性和性能,就像是鱼和熊掌。
数据实时性要求极高,可以考虑选择类似跨数据中心的Oracle RAC技术,既能够实现数据库的双活,也能实现严格同步。缺点是,对链路质量要求极高!(参考oracle最佳实践)
基于存储层的双活技术,是有很多技术来避免错乱和冲突的。EMC VPLEX是分布式Cache,华为是分布式锁。这些技术都是解决这类问题的。