数据库双活方案有哪些局限？有什么可以继续改进的地方呢？

比如双（多）方都在录入数据，那么数据一致性怎么保证？比如唯一主键问题，表间约束问题等等。
还有一个致命问题，数据竞争。
如铁路售票，一个座位不能卖给两个人。
在多活情况，如果网络问题，几个服务器孤立了，一张票就可能卖给多个人。
铁路售票，设计了容灾系统，本质上就是多活，但从来没启用过，也根本没有意义。
最多也就是防止丢失数据。这个对银行有意义。

以上说的是局限性。

数据库双活在我行已经上线三年，期间陆续迁入了6套优先级比较高的系统。整个运行过程算是达到了预期。也经历过网络故障等实际考验，表现都如预期。所以这个高可用性和可维护性都得到了验证。但是这个方案在满足数据0丢失，可用性非常高的情况下，还是牺牲了部分性能。因为距离的原因，写盘和通信都不可避免延长。所以迁入地系统在跑批的时候明显比以前长，这也是没办法的。在这个方案里面，我觉得从技术上还有比较多的地方需要改进。一方面热点数据问题，虽然我们通过分区表随机索引等方式打散热点数据，但是还是需要从数据库技术层面给出更好的改进。另一方面是节点之间的通信，因为延时的缘故，还需要从技术上继续减少交互。同时带宽不是问题，通信的并发性也需要从技术上去解决。相信如果上述几个方面能够得到改进，这个方案将会得到更大的运用空间。