异地多活架构梳理演变（九）异地双活

上文《异地多活架构梳理演变（八）两地三中心》我们介绍了两地三中心的部署实施方案保证系统的高可用。但是这种虽然同城发生故障的概率非常低，但是还是有发生故障的可能性，所以基于此，业界提出了异地双活的概念。

整体异地双活的方式大体的部署方式和同城双活是差不多的，示例图如下：

但是上面我们为什么要说是差不多的呢？因为主要从形式上来看差不多。但是从实现上来说就差很多。

首先我们设想一下，如果同时部署成都机房和北京机房，那么北京机房肯定有专线连接成都机房，如果北京机房直接通过专线访问成都机房的存储的话，那么这个延迟还是很大的，至少一次又10ms的延迟，那么再考虑一来一回的延迟，再考虑网络抖动的延迟，再考虑高并发的延迟。此时系统的可用性是不是大大降低？

所以真正的要实现异地双活的话，我们要保证北京的数据只能读写到北京的数据存储中，成都的数据只能读写到成都的数据存储中，不能出现成都机房和北京机房的跨机房读写数据的情况出现。

那么这种方案如何实现呢？

其实主要就是数据中间件同步工具的使用。一旦涉及到异地双活的话，一定会使用到这种工具。所以设计到的整体部署形式是：

1、通过dns进行分流，一部分流量访问到北京的机房，一部分流量访问到成都的机房。
2、北京和成都的机房各自实现内部的高可用。
3、通过数据中间件同步工具在专线之间实现异地数据的同步，例如在成都机房写入的A用户数据，必须要同步到北京机房保存一份，在北京机房写入的B用户数据，必须要同步到成都机房保存一份。这样子成都机房和北京机房就同时有A和B用户的数据。

这里的数据中间件同步工具的话，不仅仅是同步mysql的工具，还包括redis，mongodb，mq，elasticsearch，数仓等等。反正除了无状态的web，api等这种服务型不需要做同步之外，其他涉及到持久化，涉及到数据的相关组件都需要涉及到同步。

目前市面上对于上诉数据中间件的同步工具有一些是开源的，例如：

1、mysql的同步工具canal
2、redis的同步工具RedisShake
3、mongodb的同步工具MongoShake
4、doris的同步工具ccr
5、等等

但是说实话，一般要做异地双活的话，几乎都是大厂的布局了，对此他们其实很少会用到这种市面上的开源工具，大部分都是自研或者针对上诉开源工具做二开。