讨论：在应用异地双活的方案中普遍的模式遇到瓶颈
目前一些主流关系数据库（DB2ORACLE)通过purescale、rac仅有在本地或同城实现双活，在跨异地的情况下基本看不到数据库层面的双活应用案例。有些号称实现数据库双活的案例都是在应用层实现库的逻辑分离和数据的集中，底层的数据库还是相互独立的。在应用异地双活的方案中普遍的模式是：应用双活+DB容灾。这种模式通过实际的演练通常会遇到这样一个问题：应用跨广域访问DB效率问题。就这个问题我们银行还特意抓包进行了分析，分析的结果发现应用跟DB交互的延时比本地访问大很多，特别是一些OLTP应用，这种延时会直接导致处理效率下降。后来用过一些广域加速设备，延时有所改进，但效果不明显。
大家都是怎么做的，可以探讨交流下！
大家都是怎么做的，可以探讨交流下！
0同行回答
“答”则兼济天下，请您为题主分忧！
其实，如果要实现异地双活，目前看来靠谱的还是数据库上进行逻辑分离，应用对数据库进行本地访问。因为异地延迟是无论如何都存在的，而且受到广域网线路质量的影响，对于应用与数据库互交这层跨广域站点，还是存在很高风险的。 如果用户没有抱怨说访问异地的应用缓慢的话，那么证明楼主的应用还是优化的较好的。收起
浏览2058
现在的双活到底有多少意义上是能真正实现双活呢？这个表示有点疑问。收起
浏览2057
随着虚拟化的普及，很多的生产环境都已跑在了虚拟化环境之上。当一套系统上线的时候，开发会告诉你需要多少CPU、内存，这时候因为我们的CPU、内存实现了池化，我们可能不会物理上给要求这么多的CPU，你给的值可能是VP值。这种情况就需要考虑整机的切换能否承担负载的问题了（发生这种问题的可能性较小，因为本地都是HA的，但确实值得注意。），特别是容灾端物理机器，因为它上面可能承载了比生产物理机多的多的系统，一旦切换过来肯定过载了。收起
浏览2071
另外在配置方面，一般的纯容灾应用资源配置（CPU、内存）都会比生产略低，双活配置一样。但在实际中要考虑单边运行的性能问题。因为跨了广域，当单边运行的时候可能需要更多的资源。收起
浏览2056
目前还有部分是应用容灾的模式，感觉要达到随时切换的目的还是有些难度。虽然用了一些小工具去做生产和容灾的一致性对比，但还是不够完善，继续摸索中。双活的应用架构大多是F5/ACE+WAS集群的架构，DB异地多采用HADR，DG。DB本地多采用puerscale、RAC等架构。收起
浏览2907
浏览2913