异地多活高可用架构设计.docx

? ? ? ? ? ? ? ? 异地多活高可用架构设计 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  导读：异地多活，作为一种高可用部署架构，成为大中型互联网公司的选择。像大家熟知的大型互联网公司，如阿里、腾讯、百度、网易、新浪等等都已经完成了异地多活的技术重构。 可以说，异地多活是互联网公司业务规模扩大后所必然要经历的阶段。那么如何解决高可用异地多活呢？ 有状态服务 后台服务可以划分为两类，有状态和无状态。高可用对于无状态的应用来说是比较简单的，无状态的应用，只需要通过 F5 或者任何代理的方式就可以很好的解决。 后文描述的主要是针对有状态的服务进行分析。服务端进行状态维护主要是通过磁盘或内存进行保存，比如 MySQL 数据库，Redis 等内存数据库。 除了这两种类型的维护方式，还有 JVM 的内存的状态维持，但 JVM 的状态生命周期通常很短。 高可用的一些解决方案 高可用，从发展来看，大致经过了这几个过程： 冷备 双机热备 同城双活 异地双活 异地多活 在聊异地多活的时候，还是先看一些其他的方案，这有利于我们理解很多设计的缘由。 冷备 冷备，通过停止数据库对外服务的能力，通过文件拷贝的方式将数据快速进行备份归档的操作方式。 简而言之，冷备，就是复制粘贴，在 Linux 上通过 cp 命令就可以很快完成。可以通过人为操作，或者定时脚本进行。 有如下好处： 简单 快速备份（相对于其他备份方式） 快速恢复。只需要将备份文件拷贝回工作目录即完成恢复过程（亦或者修改数据库的配置，直接将备份的目录修改为数据库工作目录）。更甚，通过两次 mv 命令就可瞬间完成恢复。 可以按照时间点恢复。比如，几天前发生的拼多多优惠券漏洞被人刷掉很多钱，可以根据前一个时间点进行还原，“挽回损失”。 以上的好处，对于以前的软件来说，是很好的方式。但是对于现如今的很多场景，已经不好用了，因为： 服务需要停机。N 个 9 肯定无法做到了。然后，以前我们的停机冷备是在凌晨没有人使用的时候进行，但是现在很多的互联网应用已经是面向全球了，所以，任何时候都是有人在使用的。 数据丢失。如果不采取措施，那么在完成了数据恢复后，备份时间点到还原时间内的数据会丢失。 传统的做法，是冷备还原以后，通过数据库日志手动恢复数据。比如通过 redo 日志，更甚者，我还曾经通过业务日志去手动回放请求恢复数据。恢复是极大的体力活，错误率高，恢复时间长。 冷备是全量备份。全量备份会造成磁盘空间浪费，以及容量不足的问题，只能通过将备份拷贝到其他移动设备上解决。 所以，整个备份过程的时间其实更长了。想象一下每天拷贝几个T的数据到移动硬盘上，需要多少移动硬盘和时间。并且，全量备份是无法定制化的，比如只备份某一些表，是无法做到的。 如何权衡冷备的利弊，是每个业务需要考虑的。 双机热备 热备，和冷备比起来，主要的差别是不用停机，一边备份一边提供服务。但还原的时候还是需要停机的。由于我们讨论的是和存储相关的，所以不将共享磁盘的方式看作双机热备。 ①Active/Standby 模式 相当于 1 主 1 从，主节点对外提供服务，从节点作为 backup。通过一些手段将数据从主节点同步到从节点，当故障发生时，将从节点设置为工作节点。数据同步的方式可以是偏软件层面，也可以是偏硬件层面的。 偏软件层面的，比如 MySQL 的 master/slave 方式，通过同步 binlog 的方式；sqlserver 的订阅复制方式。 偏硬件层面，通过扇区和磁盘的拦截等镜像技术，将数据拷贝到另外的磁盘。偏硬件的方式，也被叫做数据级灾备；偏软件的，被叫做应用级灾备。后文谈得更多的是应用级灾备。 ②双机互备 本质上还是 Active/Standby，只是互为主从而已。双机互备并不能工作于同一个业务，只是在服务器角度来看，更好的压榨了可用的资源。 比如，两个业务分别有库 A 和 B，通过两个机器 P 和 Q 进行部署。那么对于 A 业务，P 主 Q 从，对于 B 业务，Q 主 P 从。 整体上看起来是两个机器互为主备。这种架构下，读写分离是很好的，单写多读，减少冲突又提高了效率。 其他的高可用方案还可以参考各类数据库的多种部署模式，比如 MySQL 的主从、双主多从、MHA；Redis 的主从，哨兵，Cluster 等等。 同城双活 前面讲到的几种方案，基本都是在一个局域网内进行的。业务发展到后面，有了同城多活的方案。 和前面比起来，不信任的粒度从机器转为了机房。这种方案可以解决某个 IDC 机房整体挂掉的情况（停电，断网等）。 同城双活其实和前文提到的双机热备没有本质的区别，只是“距离”更远了，基本上还是一样（同城专线网速还是很快的）。双机热备提供了灾备能力，双机互备避免了