后台开发必备知识——容灾

关于容灾

后台开发的目标是要提供高可用的后台服务，其中很重要的一点是保证业务连续性（服务不中断，或中断时间在允许范围内）。

要保证业务连续性，系统需要具备容灾能力。

所谓容灾，就是对灾难（disater）的容忍能力，即在灾难袭来时，能够保证信息系统正常运行而采取的措施，以实现业务连续性为目标。

容灾的实现通常都涉及到冗余，比如做最简单的主备。、

容灾的不同层级

根据冗余对象，容灾大致可以分为以下几种层级

容灾的不同层级

• 数据级容灾： 数据备份，如建立异地容灾中心做数据远程备份（只备份数据，没有备用系统可切换）
• 应用级容灾： 在数据容灾基础上构建一套功能相同的系统，可做系统切换。
• 业务级容灾：在应用容灾基础上，增加了IT系统以外的容灾。如备用办公地点，系统相关文档等。

一般系统设计

容灾的评价指标

容灾系统有三个重要的评价指标

• 灾难检测： 具备容灾能力的系统需要能够检测出是哪个子系统、组件发生了灾难，以便决策解决方案（灾难恢复）
• 容灾切换： 系统检测到某个子系统、组件故障后，要具备把流量切换到其它具备相同能力的子系统上去。
• 数据一致性： 同功能的不同子系统（主备）之间的数据要保持一致。灾难恢复后的业务应该不受影响。理论上用户对灾难是无感知的。

容灾评价指标

容灾的解决方案

双活

双活是指在两个生产中心部署相同的两个能力相同的业务系统。两个系统同时工作，地位对等、不分主从。具备在对方系统灾难发生时，接管对方业务的能力。

双活通常需要负载均能技术的支持。

多活与双活区别在生产中心的数量上。

双活有同城双活和异地双活， 主要是地理位置上的区别。

灾备

这里灾备是指具有主从之分的灾备系统。（双活是不分主从的灾备）。

通常是建立一个主业务系统和一个从属（备用）的业务系统（可能只有数据中心），正常情况下仅有主业务系统在工作。在主业务系统故障时，在启用备用系统。

灾备有热备、冷备等方式

• 热备： 备用数据中心对主数据中心的数据实时备份。在容灾切换时，业务不会中断。
• 冷备： 备用数据中心只是对主数据中心的数据进行定期备份（或者异步备份）。在容灾切换时，业务可能会中断。

热备和冷备的成本要考虑是仅做数据中心备份，还是有业务系统的备份。如果仅仅是数据的备份，那么其成本主要是存储设备的成本（硬盘）；如果做了业务系统的备份，则成本与双活差不多，而且由于备用系统长期不工作，会造成资源浪费。

两地三中心

两地三中心是指在同城和异地同时建立灾备中心。

同城灾备中心通常采用热备的方式，并一般会提供业务服务。异步灾备中心知识做数据的备份，且数据的复制是异步的。异步灾备中心平时不提供业务服务。

两地三中心

容灾系统的设计

容灾系统的设计不是一成不变的，不同的应用场景通常会有一些定制化的设计。因为容灾是经常是基于服务冗余实现的，大而全的容灾系统具有较大的成本。

但是容灾有一些比较通用的设计模型。

常见的四层容灾设计

四层容灾设计

• 接入层：负责流量的接入和路由。
• 控制层：负载均衡、节点管理等
• 业务层：处理请求，负责具体的业务逻辑，可能设计数据的读写。
• 落地层：数据的落地存储

灾难检测可以在控制层或业务层。

本文所介绍的容灾主要是业务层以下的容灾

容灾的实现细节

容灾的内部实现是多种多样的，不同的公司可能都有自己的实现技术。下面知识介绍一些案例、或常用的实现。主要是为了阐述可能的实现原理，不一定适用所遇场景。

灾难检测

容灾系统通常是一个集群，集群中有多个节点，通常是一个主节点（Master）和一个以上的从节点（Slave）。

灾难探测可以通过心跳包实现。

主节点和从节点分别向控制层上报心跳，如果控制层收不到某个节点的心跳，则认为其不可用，对主节点降级，并把流量切到从节点。

更为严谨的做法是，节点之间也互相上报心跳，这样可以做孤岛检测。

灾难检测

容灾切换

容灾切换主要是把流量从一个节点切到其他节点。可以通过负载均衡等系统实现。

数据一致性

数据一致性是要保证各个节点的数据一致，这样在主节点故障，切换到其他节点时才能保证业务不中断，不受影响。

在业务处理过程中，可能涉及到频繁的数据读写，有些业务请求需要等待写成功后才能返回给用户。要保证各个节点的数据在存储落地时一致，需要等到所有节点都写成功后在返回，这就涉及到**同步写**。

按上面的逻辑，为保证数据一致性，客户端、主节点和备用节点会发生以下交互。

数据一致性时序图

由于Master和Slave在地理位置上可能相隔较远，因而这种同步写的方式有可能造成一定的延迟，影响系统性能，增加了请求的响应时间。

为了减少延迟（减少容灾对系统性能产生的影响）可以对数据一致性的实现做一些改进。

下面介绍两种改进方式。

1. 数据分级，允许不重要数据少量丢失。
2. 优化设计，变同步为异步。

数据分级的方式，主要是减少需要同步写的对象，对不重要的数据，允许在一定程度内丢失。

然而在很多场景下，数据分级的方式并不适用。

第二种方式是现在常用的保证数据一致性，又降低对系统性能影响的方式。在这种设计下，增加了一个组件（注册中心）用于登记写事件。

Master在存储数据时，先到注册中心登记下，然后再进行写动作，同时通知Slave需要复制数据。Master在写动作完成后即可返回给client，不需要等到Slave写动作完成。也就是Slave是以异步的方式从Master那里复制数据。

那么这种设计如何保证数据一致性呢？

1. Master在注册中心登记了写事件，Slave可以与注册中心校验与Master是否数据一致。
2. 验证结果为数据一致，不需要额外处理。
3. 验证结果为数据不一致，则尝试从Master复制未写的数据。 
4. 尝试复制成功，则数据同步完成。
5. 尝试复制失败，则通知注册中心回滚（做下标志），同时通知客户端上次写事件失败，需要重新发起请求。

时序图：

容灾一致性实现优化

注册中心的登记同样是同步动作，为何能降低性能？ 

1. 注册写事件涉及到的数据内容通常远小于业务数据。
2. 在多节点时，写时间的注册比各节点的数据同步要快很多。