运维“冷”思考:一文聊聊高可用的“异地多活”架构设计
共 4763字,需浏览 10分钟
·
2021-03-31 19:20
点击“程序员面试吧”,选择“星标🔝”
点击文末“阅读原文”解锁往期资料合集!
前言
高可用
1、高可用的一些解决方案
冷备 双机热备 同城双活 异地双活 异地多活
冷备
简单
快速备份(相对于其他备份方式)
快速恢复。只需要将备份文件拷贝回工作目录即完成恢复过程(亦或者修改数据库的配置,直接将备份的目录修改为数据库工作目录)。更甚,通过两次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机房整体挂掉的情况(停电,断网等)。
同城双活其实和前文提到的双机热备没有本质的区别,只是“距离”更远了,基本上还是一样(同城专线网速还是很快的)。双机热备提供了灾备能力,双机互备避免了过多的资源浪费。
在程序代码的辅助下,有的业务还可以做到真正的双活,即同一个业务,双主,同时提供读写,只要处理好冲突的问题即可。需要注意的是,并不是所有的业务都能做到。
业界更多采用的是两地三中心的做法。远端的备份机房能更大的提供灾备能力,能更好的抵抗地震,恐袭等情况。双活的机器必须部署到同城,距离更远的城市作为灾备机房。灾备机房是不对外提供服务的,只作为备份使用,发生故障了才切流量到灾备机房;或者是只作为数据备份。原因主要在于:距离太远,网络延迟太大。
![](https://filescdn.proginn.com/5108c4ed865586e29bdaa7feeb0f93e7/44e19e840cea4c0f0f676c58edb08a27.webp)
如上图,用户流量通过负载均衡,将服务A的流量发送到IDC1,服务器集A;将服务B的流量发送到IDC2,服务器B;同时,服务器集a和b分别从A和B进行同城专线的数据同步,并且通过长距离的异地专线往IDC3进行同步。当任何一个IDC当机时,将所有流量切到同城的另一个IDC机房,完成了failover。
当城市1发生大面积故障时,比如发生地震导致IDC1和2同时停止工作,则数据在IDC3得以保全。同时,如果负载均衡仍然有效,也可以将流量全部转发到IDC3中。不过,此时IDC3机房的距离非常远,网络延迟变得很严重,通常用户的体验的会受到严重影响的。
![](https://filescdn.proginn.com/a9a23513a86f78f1c0d4be165c85c846/31ad5f9a9efa3a31079d05123ce7a6cc.webp)
3、异地双活
![](https://filescdn.proginn.com/cd44cda47050dbd9b1a937fbe5b138e3/122f979ead2b11407a91bcbcd82b88b5.webp)
![](https://filescdn.proginn.com/8ff969e129d91709cdc21d1496dd524c/434839e923ab413de6ac8a78559d43ca.webp)
对于个别一致性要求很高的应用,我们提供了一种强一致的方案(Global Zone),Globa Zone是一种跨机房的读写分离机制,所有的写操作被定向到一个 Master 机房进行,以保证一致性,读操作可以在每个机房的 Slave库执行,也可以 bind 到 Master 机房进行,这一切都基于我们的数据库访问层(DAL)完成,业务基本无感知。 ——《饿了么异地多活技术实现(一)总体介绍》
异地多活
![](https://filescdn.proginn.com/b83df475f025e61eac32c4bc48ede7d9/c31ed422d263328ac7772abfcbd67183.webp)
![](https://filescdn.proginn.com/af7fce48be7afaf4609af9419fce3450/3f51495346d755d6c246ff3718e63a51.webp)
![](https://filescdn.proginn.com/901781803c2a5b9acd44edb248bedc3e/fdc0596e672dc40c6e7369b549dfb253.webp)
![](https://filescdn.proginn.com/d9a067d26043bf03474559648c984212/494c848adcabbb50e8a5892cdc2aca54.webp)
来源:https://blog.dogchao.cn/?p=299
![](https://filescdn.proginn.com/753da86f6ee8ab09141db6bcf2b7c57b/958fb7f70fb26eefbc41261728e775ef.webp)
|免费提升专区|
|扫码直达|
点击左下角查看更多