架构之异地多活

软件架构设计通常遵循：高性能、高可用以及易扩展原则
多活

架构进化

1. 单机：单点故障
2. 备份：恢复时间长，影响业务；定期备份数据可能不完整
3. 主从： 实时同步，数据完整性高；抗故障能力强，主从切换；读性能提升
   从部署细节上看，这些机器的的分布可能在相同的环境下，为应对机房级别的故障，其解决方案包括同城灾备方案，即为了避免A机房故障导致数据丢失，所以我们需要把数据在B机房也存一份。最简单的方案还是和前面提到的一样：备份。这样的方案称之为冷备，因为B机房只做备份，不提供实时服务，它是冷的，只会在A机房故障时才会启用，所以仍然需要在A、B之间做实时同步，为了减少业务恢复时间，需要提前在B机房部署好接入层、业务应用，这种方案叫做热备

同城双活

为保证A机房发生故障，B机房能承担对应的业务流量，我们需要让B机房也接入流量，实时提供服务。
一是保证B机房能有和A机房相同的业务处理性能；二是B机房可以承担A机房的流量压力。同时还要对B机房的业务应用层做改造，实现两个机房的「读」流量，可以读任意机房的存储，但「写」流量，只允许写 A 机房，因为主库在 A 机房。业务改造完成后，B机房可以接入流量，并对出现的问题及时修复。

两地三中心

两地是指2个城市，三中心是指3个机房，其中2个机房在同一个城市，并且同时提供服务，第3个机房部署在异地，只做数据灾备

伪异地双活

只是简单利用同城双活的架构模型，把机房部署在异地，存在很大的问题：网络延迟

真正的异地双活

为减少延迟，就需要考虑读写就近，则必须在存储层做改造，那么B机房就不能再是从库，而应该成为主库，只有两个机房都拥有「全量数据」，才能支持任意切换机房，持续提供服务。但问题是数据同步，对同一个数据极短时间内的数据修改如何解决，因为地域不同，时钟必须保持严格一致。
配置路由规则：

• 按业务类型分片
• 直接哈希分片
• 按地理位置分片
  在最上层接入流量时，就不要让冲突的情况发生。具体来讲就是，要在最上层就把用户「区分」开，部分用户请求固定A机房，其它用户请求固定B机房，避免跨机房

异地多活

在异地双活的基础上，部署多个机房即可