MySQL（从库）
应用层
应用3
应用2
读
Nginx
应用1
MySQL（主库）
机房A
两地三中心
存储层
同城灾备
keepalived
跨城专线
异地多活在异地双活的基础上进一步改善，每个城市的机房之间并不是直接两两复制数据，而是选择一个机房作为中心节点，其他机房向中心机房同步数据，再由中心机房统一向其他机房同步其他机房的数据，当中心机房不可用时，可以提升其他机房为中心节点机房，多活的优势在于，可以任意扩展机房就近部署。任意机房发生故障，可以完成快速切换，大大提高了系统的可用性。
专线
复制
接入层
MySQL
城市A
云机房
城市B机房
应用
主备
机房C
主从架构通常是在同一个机房下通过服务器集群进行冗余部署，从而达到高可用的效果，但从部署区域粒度来看，如果机房断点，那么即使采用主从架构，系统对外仍然是不可用。同城灾备方案是在不同的机房（机房B）再部署一套系统，而这套系统正常情况下不对外提供服务，只有当机房A出现故障时，才切换到机房B，同城灾备最大的缺点就是大材小用，因此机房A出现故障不可用的概率还是非常低的，那么绝大部分时间机房B可能处于空闲状态，从而导致资源浪费。
DNS
同城双活架构是在同城灾备的方案基础上进行优化，充分利用备用机房（机房B）的资源，对外提供服务，同城双活需要把两个机房（机房A和机房B）的入口IP配置到DNS上，那么用户接入时，通过DNS解析到任意机房，同城双活需要控制存储层的写入，通常只在机房A写入数据，机房B只提供读数据权限。但同城双活也是有缺点的，由于同城，也就是两个机房在同一个城市，当发生自然灾害，比如地震、水灾时，也会导致系统不可用。
读、写
异地双活
主从架构
写
主主复制
城市A机房
异地多活
华丽的分割线
城市B（中心节点）
同城双活
机房B
路由层（地理位置路由）
同步
城市B
单机架构是最简单的一种架构方式，接入层、应用层和存储层都只有一个节点，实际部署可以部署在同一个服务器上，但是缺点也比较突出，其中一个节点宕机，整个系统不可用。
单机架构
两地三中心跟同城灾备有一个类似的地方，就是备用机房没有业务接入，只有出现灾难时才会切入，但是这个概率又极低，因此通常处于空闲状态而导致资源浪费。由于异地双活方案两个机房的距离通常在1000公里以上，因此机房之间数据同步往往延迟比较高，网络传输成为了性能瓶颈，因此只在一个机房写入，另外一个机房读取，这种方式是不可取的，所以需要增加路由层，可以根据用户请求IP判断地理位置，然后进行路由到最近机房，每个机房的存储层都是可以写入和读取的，数据通过主主复制的方式同步，所以业务应用在设计主键ID时需要采用分布式ID（雪花ID）的方式，保证数据同步时不会出现主键冲突。
由于同城双活方案当城市发生自然灾害时导致系统不可能，因此有些银行、政企等公司产品会采用两地三中心方案进行部署，该方案是在同城双活的基础上进行改进，通常会选择距离1000公里以上的城市部署备份机房，比如主机房在上海，则备份机房通常选择北京等，备用机房通常不对外提供服务，只是用于备份数据，防止主机房所在城市出现灾难而导致系统不可用。
主从架构除了数据库MySQL有状态外，其他都是无状态的节点（应用节点的状态数据可以存放在Redis等缓存上），其中Nginx和MySQL可以通过虚拟IP的方式对外提供服务，当Nginx和MySQL对外服务的节点宕机时，keepalived自动把VIP切换到另外一个节点，继续对外提供服务，从而达到高可用的效果。
城市C
