双活数据中心如何减少距离带来的影响？

双活要求两个站点数据完全同步，最关键的就是要解决链路延迟的问题，否则会影响整体性能，距离越长延迟越大，这是硬伤，除非有新技术解决这个问题。

距离是双活环境最大的挑战。部署双活环境最关键的就是如何减少距离所带来的影响。在我的实践经验里，距离的影响主要在两方面：

一，存储实时复制比较慢。这个是没有办法克服的，光就那么快，不可能更快。那么先分析数据库里面使用存储的主要是数据和日志。数据因为不是实时写，所以问题不大。问题是日志。双活环境的每个数据库节点都有自己的日志。日志是实时写的。适当增加日志缓存，提高groupcommit的效率。每次IO写的内容更多，平均下来单个事务耗在日志上的就比较小。还有个几乎用不上的终极方案，如果正式写日志成了很大瓶颈，多建立几个数据库逻辑节点，多写几份日志，呵呵。

二， 跨中心的通信比较慢。例如外围系统到应用服务器的通信；应用服务器到数据库节点的通信，数据库member节点和主CF的通信等。所以最关键是本地化访问。其次是将写操作比较多的业务放在主CF所在的中心。

总结就是距离是问题，带宽不是问题。解决方案一是提高并发，二是本地通信。

谈如何减少距离带来的影响前我想首先需要分析距离具体有哪些影响。

以db2集群为例，距离主要造成以下影响：

1、db2节点与两个中心cf的通讯时间增加了，造成sql语录require lock时间增加了，commit时将page写入cf中的gbp的时间也增加了；

2、双中心磁盘同步造成db2写active log的时间增加了。主机上的解决方法是在a中心部署2个同步的cf，在b中心部署一个闲置的cf，这样a中心的交易就只受第二点影响从而性能不会太差，然后把重要的交易路由至a中心即可，b中心只负责处理一些对性能要求不高的交易，当a中心挂了b中心可以做db2  crash recover启用b中心的cf，这过程大概需要5分钟。对于开放上的db2 purescale目前好像不支持这种做法，不过我想这点ibm也迟早会解决的吧。