跨城容灾与异地多活常见的架构设计

1. 同城IDC与跨城IDC
2. 几种不同的部署方式
- 1.1 无复制的异地部署（单地存储）
- 1.2 无复制的异地部署（异地存储）
- 1.3 两地三中心部署（同城同步复制，跨城异步复制）
- 1.4 三地五中心部署（同城同步复制，跨城半同步复制）
- 1.5 跨城异步复制
- 1.6 跨城异步复制（记录日志）
3. 几种不同的部署方式对比
4. 参考文档

现如今，我们开发一个软件系统，对其要求越来越高，如果你了解一些「架构设计」的要求，就知道一个好的软件架构应该遵循以下 3 个原则：

高性能
高可用
易扩展

其中，高性能意味着系统拥有更大流量的处理能力，更低的响应延迟。例如 1 秒可处理 10W 并发请求，接口响应时间 5 ms 等等。

易扩展表示系统在迭代新功能时，能以最小的代价去扩展，系统遇到流量压力时，可以在不改动代码的前提下，去扩容系统。

在此背景下，我调研并对比了几种不同的部署方案，看哪种方案在我们的业务场景下最能够满足异地多活以及跨城容灾的需求。同时，我也将我的思考记录于此，仅供大家在面对同样的问题时进行参考。

1. 同城IDC与跨城IDC

如果要讨论“跨城”以及“异地”，那就不可避免的要讨论下同城部署IDC以及跨城部署IDC的区别。

首先，我们要理解，目前服务器之间基本都是通过光纤进行通信的，虽说光纤的传输速度理论上是光速，也就是3乘以10的八次方米每秒，听起来好像无论两个服务器之间离的有多远，只要是用光纤进行通信，就可以将时延忽略不计。但实际上并非如此，我们用光纤进行通信时，还要考虑光纤并非直线铺设以及中间需要经过很多转换器等种种影响因素。

$延迟(ms) = 两地距离(km) * 1000 / (3*10^8) * 1000$

一般来说，同城部署的IDC之间的时延为1-3ms。而跨城部署的IDC之间的时延约为30ms（以北京到深圳为例）。

因此，当我们考虑异地部署时，同城内的异地部署的时延是可以忽略不计的，而跨城异地部署的时延是我们需要重点考虑的。因为30ms的时延对于时延要求较高的系统可能已经是无法接受的了。比如我们系统对接的有些媒体要求时延为50ms以内，如果仅网络通信时延就占用了30ms，那留给我们推荐系统的计算时间仅有20ms。因此跨城区的网络延迟就变成不得不面对的问题。。

为了规避这个问题，尽可能的缓解跨城网络导致的网络延迟问题，对于延迟非常敏感的系统，通常在访问时采用就近原则，尽可能的将地域相近的区域相互访问，尽量避免跨区域访问，从而减少网络延迟造成的影响。

2. 几种不同的部署方式

1.1 无复制的异地部署（单地存储）

第一种方式是无复制的异地部署，并且真正的数据存储只在一个地方有，其他异地部署的地方没有存储，当然这里的存储指的是可修改的存储，而非Redis或本地缓存。

所谓无复制，指的是不同地方的存储数据没有被互相复制，互相同步。

如下图，表示的是无复制的异地部署（单地存储）方式。我们的MySQL存储仅在深圳有一个实例，这个MySQL存储可能被某个管理端来修改数据，而MySQL存储的数据会被随时或定时刷入到各个不同地方的Redis缓存中。不同地区的用户被依据IP属地分配就近访问不同地区部署好的服务系统。

这种部署方式的优点是可以减少多次部署存储的成本以及工作量，而且由于存储只有一份，在其他地区的IDC出现问题时，也可以依靠切换IDC来快速进行服务恢复，能够基本做到IDC的容灾。但这种部署方式的缺点也很多，比如放置存储的IDC不能够出问题，否则各个地方的系统都会出问题，而且这种部署方式仅能够支持只读操作，如果用户需要写入数据，那就需要跨城访问了，一般来说时延就很难接受了。

在这里插入图片描述

1.2 无复制的异地部署（异地存储）

第二种方式也是无复制的异地部署，但与第一种不同之处在于存储是分别放在不同地方的。换句话说，就是每个地方都是分别独立部署的，存储也是互不相通的。

如下图所示，深圳与北京分别部署了一套服务系统，并且独立部署了MySQL存储。各自不同地方的用户访问各自的服务，比如北方用户访问北京的系统，南方用户访问深圳的系统。由于存储都是在同城部署的，因此用户不仅可以读数据，也可以很方便的写入数据。

这种部署方式的优点是可以做到异地多活，让不同地方的用户访问不同地方的系统，减少了跨城的网络时延。但缺点也很明显，就是没有办法做到容灾。在某个地区的IDC出现问题时，不能靠切换到其他IDC来进行快速恢复服务，因为不同地区的存储内容是完全不同的。

在这里插入图片描述

1.3 两地三中心部署（同城同步复制，跨城异步复制）

该部署叫两地三中心部署，所谓两地，指的是两个不同的城市，所谓三中心，指的是三个不同的IDC。并且该部署方式是要在同城部署两个不同的IDC，且这两个IDC要能够做到同步复制。而跨城也要部署一个IDC，此IDC要做到异步复制。如下图所示。

这种部署方式的优点是，同城之间的IDC可以做到容灾备份，当其中一个IDC出现问题时，能够通过切换到另一个IDC来实现快速恢复。而且也能够基本做到跨城的容灾备份，比如当深圳的IDC都出现问题时，也能够通过切换到北京的IDC来使服务得到恢复。但这种部署方式也有缺点，首先，北京这个地区的IDC算是一个冷备份，如果用户对存储有写操作，那我们就只能让所有用户访问深圳的IDC，就算用户对服务只有只读操作，北京的数据也相对于深圳的数据稍有延迟。另外，依然是冷备份带来的问题，当我们需要将用户从深圳切换至北京进行访问时，由于他们之间是异步同步的，所以可能会出现丢失部分数据的问题。

在这里插入图片描述

1.4 三地五中心部署（同城同步复制，跨城半同步复制）

该部署方式是三地五中心的部署方式。三地指的是三个不同的城市，五中心指的是五个IDC集群。同城间的IDC采用的是同步复制的方式，而跨城间采用的是半同步复制的方式。所谓半同步复制，这里是指ACK=2，也就是说，当有两个IDC被成功同步复制了，那就算完成了。这样，用户每次请求，至少会有一个异地城市有了及时的数据备份。

如图所示，该部署方式优点是有了跨城容灾的能力，且数据不易丢失，因为当某个IDC出现问题时，我们总能切换到一个有着全量数据的IDC。缺点是它不能做到异地多活，而且跨城同步复制数据会导致用户的每次请求都会有很高的时延，因此它不适合对时延要求较高的服务。

在这里插入图片描述

1.5 跨城异步复制

一般来说，想要做到跨城同步复制一定是会牺牲掉部分性能的，因为跨城就意味着较高的网络时延。因此，我们可以思考下如何做到跨城异步复制的同时也做到容灾切换时尽量不丢或少丢数据。

下图展示了一个最简单的跨城异步复制方案。该方案的优点在于能够做到异地多活，并且当某个IDC出现故障时，能够做到及时切换。缺点是由于是跨城异步复制，可能会出现切换后部分数据丢失的问题，对一致性要求较高的系统来说肯定是不能接受的，如支付系统。

在这里插入图片描述

1.6 跨城异步复制（记录日志）

由此之故，我们可以对上述方案五进行优化，让两个IDC在异步复制给对方的同时将日志数据写入到一个第三方IDC，这个IDC用于记录日志数据以及不一致的操作ID。当深圳或北京的IDC发生故障时，查询下第三方IDC中存储的日志数据，看哪些操作ID还没有复制给对方，让这一部分的操作ID只能读不能写，虽然这部分操作ID读到的数据会有些延迟，但不会影响系统基本盘，等到故障IDC恢复后，再进行数据同步，然后清除日志，允许这一部分操作ID进行写操作即可。由于没来得及复制的一定是少部分数据，因此，该方案基本能够解决跨城异步复制所带来的数据不一致问题。见下图。

在这里插入图片描述