0.简介
随着互联网公司的业务规模不断扩大，对于系统的并发能力，流量承载能力和故障恢复能力都有了更高的要求，而最为基本的就是系统的可用性，要做到这点就需要针对故障做容灾设计，其本质是提供冗余以避免单点故障造成系统不可用，本文将从容灾各个发展阶段：单机，主从，同城，两地三中心，异地双活，异地多活来进行详细的分析。
1.单机结构
单机架构就是一台机器就能支撑业务需求，在体量比较小的情况下，可以减少运维的复杂度，其整体结构如下，应用直接读写数据库返回数据即可，但其面对机器故障或者数据的误删是没有容错可言的，一个简单的处理就是下一节的备份。但是其也有自己的缺点，如果只是备份，那么就意味着恢复期间的不可用和数据的不完整（定期备份缺少最新数据）。
2.主从副本
为了解决上述单机结构的问题，可以使用主从副本的方案，也就是不采用数据备份方式，而是在另外机器上部署另一个数据库实例，让其实时同步，这样就能解决上述的恢复时间和数据不全的问题。其在从库也可以去执行读操作，减轻主库压力，同步及访问示意图如下：
这种部署方式已经隔离了单机故障的问题，但是如果其还是在一个机房中，那么就存在一个机房出现问题的可能性。上面提到过，容错性可以通过冗余去做，既然一个机房还是存在环境相似容易一起发生故障的问题，那么可以做更为高级别的处理，也就是下面的同层容灾。
3.同城容灾
同城容灾可以分为两种，一种备份只是作为备份，只在主机房出现问题时提供服务，也就是同层灾备，另外一种是两者同时提供服务，也就是同城双活。
3.1 同城灾备
同城灾备分为冷备和热备，冷备也就是备份数据文件，其也存在数据不完整，恢复需要时间的问题。热备的话只备份不提供服务也存在切换应用服务和部署接入层的问题，也即该方案其实只是处理了存储层的容错。
所以接下来的方案就是对接入层和应用层也进行容错备份，这样可以加快发生问题时的切换操作。
3.2 同城双活
可以看到，上面做了容灾后，机房二只做备用，而不真正提供服务，这会造成资源浪费，同时如果机房一出现问题，机房二能不能正确提供服务也缺少验证，进而衍生出了同城双活，即两者同时对外提供服务，利用读写分离架构去分担主机房的压力。
4.两地三中心
在上面的同城双活架构中，其已经能够解决大部分的问题，但是其还是在一个城市，这样的话就会面临一个城市同时出现问题的场景（自然灾害：如地震，洪水等），在这种场景下需要增加一层保障，也就是两地三中心，三个机房，两个城市，其中两个机房在一个城市同时提供服务，另外一个部署在外地，做冷备。
5.异地双活
上面两地三中心依然存在出问题的可能性，城市出问题后恢复困难，所以异地双活就是来解决这个问题，最简单的异地双活就是直接把原本的同城多机房扩展成异地的多机房，但是这样对于写入流量就不太友好，都要经过长距离传输写到主库，然后再同步到从库，所以需要扩展为多个地区的库都可写，那需要解决的问题就变成了如何去解决冲突，主要有两种方案，一种是冲突解决，双向同步，也就是通过数据同步中间件去解决同时写的冲突，比如按时间去选择（后修改生效）；第二种是规避冲突，利用规则分片两者互为热备，其写的话按照规则去写（比如哈希分片，地理位置分片等，两者图示如下：
6.异地多活
异地多活就是在异地双活的基础上继续扩展，其中有星状架构和网状架构，星形依赖中心机房，网状同步复杂。
更多文章查看：
异地多活架构演进详解