技术思路分享｜我认为应该这样设计双活架构，你觉得呢？

作者：haizdl　城商银行系统架构师

所谓双活数据中心的架构，我认为有数据中心级别的双活、应用级别的双活、业务级别的双活之分。

1）数据中心级别的双活，相对容易实现，只要不同的业务跑在不同的数据中心就可以了。

2）应用级别的双活，只要业务能读写分离，同样的业务系统，写操作单中心做，读操作双数据中心做，需要应用系统的高度逻辑隔离。

3）业务级别的双活，就是指同一笔业务既可以在A中心写入，也可以在B中心写入。这种双活就相对困难了。

对于业务级别的双活来讲，他的关键制约条件是什么呢？我们从上到下来看：

一、网络层面：双数据中心2层打通，GTM+LTM很容易做到分流控制。

二、应用层面：只要是短连接应用，挂载负载均衡设备上，无论是虚拟化还是实体机，也非常容易做到。

三、数据层面：要完成三个功能：一是两边都能写入，二是两边都要保留数据的副本，三是两边的数据库节点能快速接管彼此的业务。那就是数据库AA集群+数据复制技术。

• 首先来看AA集群技术，典型的ORACLE RAC，可是有一个致命的问题是关系型数据库的AA集群会有数据热点问题，在双中心之间的链路延时和不稳定情况下，这么做是非常危险的，不出问题是侥幸，出问题是时间的问题。

• 再说数据复制技术，存储层面的复制技术有很多，但是没有一个能解决逻辑校验的，也就是说存储的块数据同步过去了，但是有可能在危急时刻，数据库还是拉不起来。而且还有一个关键问题就是数据库的仲裁和存储的仲裁再加上光纤链路的远距离不可控，危急时刻做出正确的仲裁，很难。不要简单听信仲裁时间的先后以及第三点仲裁中心的说法，那是理论上不是实践。血淋淋的案例摆在面前。

• 再看数据库层面的复制技术，典型的就是ADG，现在做的也是越来越好了，只要日志复制过去，那就不会有数据丢失的危险，但是这个ADG切换就不是1分两分钟能搞定的事情了。

　

因此我认为，在既有关系型数据库的前提下，双活最稳妥的做法就是：

网络层： 大二层、GTM

应用层：虚拟化 + LTM

数据层：单中心集群数据库 + 数据库复制技术

管理层：开发脚本减少切换浪费掉不必要的时间

社区网友补充观点：

• wangj0923 工行 技术经理：

根据我们的实施的经验补充几点：

1，网络大二层必要性不大，双中心耦合度太高，用DNS搞定。

2，虚拟化不是必须的，但虚拟化对缩短恢复时间有好处。

3，跨中心数据库复制技术，同步模式对主库影响太大，异步模式会有数据丢失，需要补偿措施。

• 孙杰 cnpc 系统架构师：

同城双活，网络层面可以大二层。异地的双活，大二层代价较高，可使用全局负载均衡+DNS进行流量导引。数据层面使用数据库自身的高可用解决方案，比如ADG、Oracle Extended RAC，这些比存储阵列的双活效果要好。

• sxtycxx 山西光远科技 售前技术支持：

补充网络的大二层是为虚拟化环境中，虚拟机跨数据中心飘移的，在双活数据中心模式确实必要性不大。另外说到双活无法解决逻辑，建议在保障业务连续性的同时增加CDP，对业务系统的逻辑错误、操作系统、病毒等进行有效的保护。

• anikikong 中国民生银行 数据库运维工程师：

其实在双活搭建的最难点也就是如何保证数据库的双活。数据库的双活不是为了提高系统利用率，而是在于灾难发生的时候，应用能更快的恢复响应。在数据层，单中心集群加数据复制就不太满足发生灾难时快速恢复的要求。这也是为什么要做数据库双活。数据库双活不可避免会有很多的热点数据，这在RAC和DB2 GDPC集群里面都是常见的问题。这些问题也是有调优办法的，主要的思路是分散热点数据。解决了性能问题后，双活环境才算真正达到效果。

光纤抖动确实会影响数据库的交易。主要是存储复制的IO请求如果正好在这个光纤上，可能会丢失，只能等到超时。这个影响比较大。现在在光纤交换机上配置了一些策略来抵抗抖动，同时还有DCP保护。

• haizdl 城商银行 系统架构师

没错。ORACLE数据库也是有分区技术的。但是这就需要应用做大的调整了，数据库模型得重新设计。而且应用系统能否改造还得看它的业务特点。 而且这仅仅是一个缓解问题的手段，不是科学合理的解决方案，我是这样认为的，您觉得呢？

　

对于以上思路和观点，您怎么看？欢迎点击“阅读原文”发表您的见解看法。

本内容来自于在线交流活动：金融行业数据中心的双活实现方式应该如何选择？ （地址http://www./activity/?id=127