【分布式】异地多活

  常见的多活方案有同城双活、两地三中心、三地五中心、异地多活等，异地多活是目前比较普遍的一种。作为一种分布式系统架构，其核心目的是维护系统的的高可用性。那既然要提高容灾，一定涉及到冗余。

两地三中心

• 两地：本地 + 异地
• 三中心：本地主数据中心 + 本地数据备份中心 + 异地数据备份中心

  两地三中心是一种成熟的服务器灾备解决方案，可以视为同城双活+异地多活。数据中心间存在三种备份方式，前两种统称为主备模式（Active-Standby）：

1. 热备：服务器A1作为主服务器承担业务，服务器A2作为备份服务器，实时从A1中获取数据保持数据一致。一旦A1熄火，A2立即接手保持服务正常不间断运行。由于时刻有一个A2空转作为备份，因此开销巨大。
2. 冷备：依旧只有A1承担业务，只不过A2不再时刻保持数据一致，而是周期性地同步A1数据，即异步数据复制。实际上是在A1完成所有服务、离开工作状态、数据库关闭后进行复制，这确实可以避免复制过程中写入数据导致的一致性问题，并且直接用系统的指令去复制，很简单。A1瘫痪，来不及拷贝的业务直接中断，在业务层上判断和处理故障。但是冷备的问题是，在异地采取冷备，一旦遇到故障，很难决定是否要切换备份中心。因为连接到备份中心的时间未知（不知道能不能切换过去），备份中心接管服务的时间未知，接管后功能是否正常也未知。并且冷备基本上就是备份全站，成本并没有比热备低很多。
3. 双活（Active-Active）：这种方式对服务器的利用率最高。A1和A2同时承担业务，作为主服务器的A1负载相对高一点（可能达到总体服务量的六成到七成）。并且A1和A2互相备份，且实时备份。双活分为两种，同城双活和异地双活。

  两地三中心的优势很明显，服务同城双活，数据通城灾备，通信便捷，很多异地多活里棘手的问题（时延、同步、一致性）在同城双活中根本不叫问题。但是同城双活的问题就是数据库写数据存在跨机房调用。
  同城双活+异地双活的架构解决了同城双活无法解决的跨地区容灾问题。异地的备份中心可以是冷的，也可以是活的，但是也解决不了跨机房调用，并且异地的话没有骨干网，延迟是很大的，因此很多情况下是冷的。并且这也带来冷备的问题：出了问题很难决定要不要把流量切刀备份中心。

异地多活

  说到底，这个架构仍旧是一个分布式架构，那就不可避免地需要面临分布式架构的三大问题：计算、存储、通信。而实际案例中，往往更关注存储和通信两部分。解决整个系统的问题，其实主要涉及两个部分：业务划分和数据划分。所谓业务划分，就是把一套核心业务包装成一个单元，单元内部需要保证高度的一致性。而数据划分则是对所有的数据进行维度上的划分，去选择一个维度作为我们所设计的单元的输入。
  因此，双活架构在两个机房的调用是各自封闭的，不存在跨机调用的情况