高可用解决方案:同城双活?异地双活?异地多活?
架构之美
共 5094字,需浏览 11分钟
·
2021-05-28 04:47
- 前言 -
- 常见的高可用解决方案 -
冷备
双机热备
同城双活
异地双活
异地多活
- 冷备 -
简单; 快速备份(相对于其他备份方式); 快速恢复。只需要将备份文件拷贝回工作目录即完成恢复过程(亦或者修改数据库的配置,直接将备份的目录修改为数据库工作目录)。更甚,通过两次mv命令就可瞬间完成恢复; 可以按照时间点恢复。比如,几天前发生的拼多多优惠券漏洞被人刷掉很多钱,可以根据前一个时间点进行还原,“挽回损失”。
服务需要停机。n个9肯定无法做到了。然后,以前我们的停机冷备是在凌晨没有人使用的时候进行,但是现在很多的互联网应用已经是面向全球了,所以,任何时候都是有人在使用的。 数据丢失。如果不采取措施,那么在完成了数据恢复后,备份时间点到还原时间内的数据会丢失。传统的做法,是冷备还原以后,通过数据库日志手动恢复数据。比如通过redo日志,更甚者,我还曾经通过业务日志去手动回放请求恢复数据。恢复是极大的体力活,错误率高,恢复时间长。 冷备是全量备份。全量备份会造成磁盘空间浪费,以及容量不足的问题,只能通过将备份拷贝到其他移动设备上解决。所以,整个备份过程的时间其实更长了。想象一下每天拷贝几个T的数据到移动硬盘上,需要多少移动硬盘和时间。并且,全量备份是无法定制化的,比如只备份某一些表,是无法做到的。
- 双机热备 -
Active/Standby模式
- 双机互备 -
- 同城双活 -
- 异地双活 -
对于个别一致性要求很高的应用,我们提供了一种强一致的方案(Global Zone),Globa Zone是一种跨机房的读写分离机制,所有的写操作被定向到一个 Master 机房进行,以保证一致性,读操作可以在每个机房的 Slave库执行,也可以 bind 到 Master 机房进行,这一切都基于我们的数据库访问层(DAL)完成,业务基本无感知。
- 异地多活 -
- 思考 -
假设你在做饿了么的开发,服务按照异地多活方式部署,sharding key根据省市区进行分片。假设买家在多个城市交汇的地方,比如,十字路口的四个位置分别是4个城市,那么如何处理才能让他拉到比较正常的数据? 你们现在的业务模块中,哪些业务是可以做多活的,哪些无法做多活? 所有的业务都要做多活吗?还是只需要核心业务做多活?
作者:Dong GuoChao
来源:https://blog.dogchao.cn/?p=299
评论