两地三中心及其灾备

       单机房架构

单机房 是指只有一个生产数据中心，当出现自然灾害等原因而发生故障时，应用和数据不具备容灾能力。所以演变出了下面的两地三中心架构

一般两地三中心可以达到4个9的可用性：也就是一年中只有一个小时服务断续不可用

完全独立的三个中心，都可以当生产中心使用

同城双中心 ：是指在同城或邻近城市建立两个可独立承担关键系统运行的数据中心，双中心具备基本等同的业务处理能力并通过高速链路实时同步数据，日常情况下可同时分担业务及管理系统的运行，并可切换运行；        

异地灾备中心： 是指在异地的城市建立一个备份的灾备中心，用于双中心的数据备份，当双中心出现自然灾害等原因而发生故障时，异地灾备中心可以用备份数据进行业务的恢复。

问题：这样的话 切换到灾备能不能正常用还是不知道的，毕竟没有流量就木有办法做监控，所以切换时间完全不可用  （一活2冷）   ，所以出现了升级版的双活或多活的架构

双活架构

 双活 ” 或 “ 多 活 ” 数据中心: 区别于 传统 数据中心 和 灾备中心的模式，前者 多个 或两个数据中心都处于运行当中， 运行相同的应用，具备同样的数据，能够提供跨中心业务负载均衡运行能力，实现持续的应用可用性和灾难备份能力， 所以称为 “双活 ” 和 “ 多 活 ” ；后者是 生产 数据中心投入运行， 灾备 数据中心处在不工作状态，只有当灾难发生时，生产数据中心瘫痪，灾备中心才启动。

“ 双活 ” 数据中心特点 ：

一、充分利用资源，避免了一个数据中心常年处于闲置状态而造成浪费 ， 通过资源整合， “ 双活 ” 数据中心的服务能力是 翻 倍的

； 二 、“ 双活 ” 数据中心如果断了一个数据中心， 其 业务可以 迅速 切换到另外一个 正在 运行的数据中心， 切换 过程对用户来说是不可感知的。

双活都是随机的流量（轮询的那种），所以必须是无状态的，有状态不能用。

这里拓展下db的同步三种方式：

主备同步：冷备，可能按照天同步，时效性差一些

主从同步：时效性高一些，从一般支持读业务，主支持写，读写分离

主主同步： 双向同步，缺点就是存在数据覆盖的问题（相同id的数据），数据一致性要求不高，可以容忍丢失，如日志类的数据

电商双活架构实践

 

中间件是横向的，跨机房的。因为机房1和机房2的服务都要互相知道所以zk这样都是横向部署。

mq在逻辑层面是独立的，逻辑集群  主从模式  mq支持半主原则（大于二分之一）

中间件就是逻辑集群

先大体介绍下容灾的思路：

机房层面容灾：  机房1不可用那就吧流量全部切换到机房2

服务层面容灾：正常的调用如下图所示

但是比如b出问题的话那么a就需要调用机房2的B1了

那就用zk  如下所示，b1 服务注册到机房1的zk1，这样a就可以调用机房2的b1了

这就是应用层面的容灾

数据库的容灾：

左边是主库，右边是从库，主库挂了那么新的写要切到右边

 那么这种要允许数据丢失，因为ogg可能有三秒数据延迟，比如日志那种数据可以这么存

要是强一致的话，需要事务型mq，启用双写：（也就是业务层写入主库的同时，写入mq中一份数据，保证同时成功的事务消息。）

正常情况下主库和mq都会写一份数据如下所示 

如下所示从库消费完mq里面的堆积消息，然后才能切换成从库写，不然会有数据不一致的问题

 这种方案存在的问题：

容灾切换的时效性不可用，比如mq延迟，不可用，消息积压太多

这里就升级下：

不过这里mq下面接入了缓存redis

也还是获取黑名单，拉取到mq积压之类的消息，然后和灾备库对比出一个黑名单

故障瞬间数据还是写入mq了，只是写1没了而已 ，瞬间切换，那就需要快速产生黑名单，实现分钟级切换，

流量发过来请求 先看mq里面数据里面有没有积压，有积压就全部放入黑名单，然后开始比对，发现流量不在黑名单里面就可以进入灾备库，这可以做到分钟级切换，对时效性要求高的可以用这种。

对灾备的难点就在于数据一致性，光靠数据库很难实现强一致除非像OceanBase实现了paxos，二阶段的。

成熟的容灾方式：

mysql自带的同步功能也存在问题：

比如左边主，右边从

 主挂了以后，如果有强一致要求的话，挂的时候会有数据丢失，你也不知道丢了多少（那些数据），所以不能切主的

那么就采用半同步的形式：

先写从节点，然后再写主节点，可以保证数据一致性，然后切换 

但是极端情况存在丢失的情况：

比如主节点写失败，从节点写成功，那么从节点就多一条数据，需要措施去发现多余的数据

但是同样的这样性能就有损失了。

这种适合在一个机房里面的情况

但是如果整个机房都挂了那就没用了，所以是实例级容灾，不是跨机房的容灾

跨机房级容灾，核心点是跨机房

 

主节点和镜像库  跨机房半同步方式 （上面讲的），一定要有个镜像库

然后异步同步到容灾库

也就是做流量切换之前保证 容灾库和镜像库产出一个黑名单（用对比工具对比），黑名单数据不能写入的，因为挂掉了那时候肯定有数据丢失的。 黑名单产出之后，切换从库写入的时候，如果发现写有黑名单数据那么是不能写入的，否则 容灾库和镜像库数据不一致写入有风险。

redis容灾：

同理，机房1的主发生数据故障，机房2的从上升为主，那么主从同步可能存在数据丢失的，存在秒级的同步延迟

redis原理是 主机写，从同步 ，架构就是容易丢失，因为是缓存所以丢失可以接受

利用广播特性自己同步。

和数据库同步，很难做到强一致，毕竟不是事务型的。