说起容灾，很多同学脑子冒出来熟悉字眼，”同城双活”，“两地三中心”，“单元化”，“set化”等等。其实这些名词背后均隐射一层含义，面对一些灾难时候，业务如何做冗余来快速恢复业务。

本文从容灾概念，决策因素，典型案例和方案对比进行说明，希望容灾方案的选择有所帮助。

1.容灾概念

将容灾这个词，分开来看“容”和“灾”。“灾“可大可小，某种意义上来讲就是"单点"问题，例如核心业务部署单台服务器上，这台服务器宕机起不来了，对业务来讲就是一场灾难；而“容”，是解决各种"单点"问题。以资源部署粒度来看，一直在解决单点问题路上，如下图：

3.2.2 同城双活（双写）

同城双活核心特征：

1）容灾范围：可用区粒度容灾

2）流量分布：每个可用区均承载流量业务；数据库采用分区模式，将数据分为两个可用区，az间的网络延时对业务影响较小

3）数据存储：数据库和存储跨az部署，其中数据库双向同步，读写均在各自可用区；存储cos本身具备多az容灾

4）常见场景：数据一致性强依赖于业务，同时业务不能接受跨az延时；相比单写方案，对业务改造较大，相当于单元化和set的业务改造级别。

以下是云上某saas厂家同城双活案例：

云上的存储业务均采用虚拟机或者黑石机器进行自建，业务以账户单双号进行set化部署；A区的数据库存双号，B区的数据库存双号；数据库同步使用双向方式；每个AZ数据库均存在全量数据；当一个可用区故障，业务通过DNS以及业务调用配置下发能力，将业务切换到另外一个可用区，同时取消同步能力。

3.3 异地多活

异地多活核心特征：

1）容灾范围：地域粒度容灾

2）流量分布：每个地域均承载流量业务；数据库读写均在同一个地域

3）数据存储：每个地域均存储本地数据和全局数据

4）常见场景：业务已经完成set改造，每个地域为独立一个或者多个set，全局数据进行地域之间复制同步。

以下为某生活巨头异地多活的场景：

业务流量统一调度，通过路由层进行set路由，将流量分发到各个set；各个set业务流量相互独立；数据容灾各个set之间两两互备，同时set和中心互备形成三副本。某个set故障后，流量入口切换set路由保障服务。

4.方案对比

关于以上四种容灾方案，分别从成本，可用性以及可扩展性做横向对比总结。