目前可实施的双活方案中,数据库层解决方案也罢,存储层解决方案也好,大多实现的是伪双活,即A-S模式,或A-Q模式,做不到真正意义上的双活,即A-A模式。
1、在CAP不可突破的情况下,能否实现RPO=0&RTO=0的真正意义的双活?
2、如果单纯依赖系统层(数据库,存储,网络)无法实现的话,应用层有需要做哪些改造?
3、阿里的异地多活在金融系统如何借鉴?
我认为银行在现有技术架构和业务模式下,不可能实现真正的业务级别AA双活。想要实现真正的双活,数据必须能够切片分区,这将不是一个简单的数据库要实现的技术问题,更多的是应用层面以及网络层面导流等多方面的综合改革,这是一个系统工程。单靠任何一项新技术都很难实现真正意义的双活。
但是话又说回来,有必要实现真正的双活么,那么大的代价。金融监管的要求也没有把RTP和RPO都定义为0啊。双活只不过是厂家们为了卖东西而刻意迎合的一种宣传。
收起1. 真正意义上的AA双活确实是已经有技术并且实现了。但是双活环境的RTO=0这也是不可能的,只能说广义上是接近0了。现在即便不是双中心,也没见过哪个架构敢说自己的RTO完全是0的。现在交行,民生等都已经上线了双活架构,底层存储复制,上层数据库集群,实现了AA双活。
2. 应用的双活其实是最终解决方案。这要求应用能够分库分表,应用负载也能够分开。所以对于特定应用,是可以做到的,但不太具备通用性。其他系统用不上,限制太多。
本地的双活,从数据库双机,多节点等,底层存储分布式,完全是可以实现的。本地到异地,就是距离的变化,只要“速度和距离”矛盾问题解决了就可以,或者降低对远程数据传输和应答耗时带来的效率期望,但估计没有一个业务可以答应的。毕竟不是某个网页,看到404就刷新再试就好了。
收起换个思路,如果抛开数据的实时一致性,只保证最终一致性,能否实现业务层面AA双活?
数据的一致性问题可以通过其他方式补偿,例如通过日志补帐。。。。。。
另,监管部门没有RTO/RPO等于零的要求,是因为目前实现不了,如果做得到,说不定就写到监管要求里了(^_^)
收起