知识卡片
存储高可用的四个分析维度,及主备复制的简单与代价
内容
存储高可用方案的本质都是把数据复制到多个存储设备、靠数据冗余来实现高可用,真正的复杂性集中在如何应对复制延迟和复制中断带来的数据不一致。因此分析任何一个高可用存储方案,都要回答四个问题:数据如何复制?各个节点的职责是什么?如何应对复制延迟?如何应对复制中断?主备复制是其中最常见也最简单的一种——几乎所有存储系统(MySQL、Redis、MongoDB等)都原生支持,架构上主机负责读写,备机只做数据备份、不承担实际业务的读写操作,如果要把备机切换成主机需要人工操作。它的优点是”简单”:客户端完全不需要感知备机的存在,即使灾难恢复后原来的备机被人工改成了主机,对客户端来说也只是”主机地址换了”这一件小事;主备双方之间只需要做数据复制,不涉及状态判断和主备切换这类复杂操作。它的缺点也很直接:备机只用来备份不承担读写,硬件资源上是一种浪费;故障恢复必须靠人工干预,无法自动化——人工响应的效率往往很低(光是打电话找到能操作的人可能就要花掉10分钟,如果是深夜出故障甚至可能没人及时发现),而且这类恢复操作本身并不常见(可能一年只发生两三次),真正操作时反而更容易踩到各种没预料到的坑。综合看,主备复制适合数据变更频率低、即使偶尔丢一点数据也能靠人工补全的场景,典型代表是学生管理系统、员工管理系统、假期管理系统这类内部后台管理系统。
参考来源
- 位置:《从零开始学架构》第25讲《高可用存储架构:双机架构》"主备复制"(源文件:_epub-src/OEBPS/text00002.html)
- 结论依据:原文说明存储高可用方案需要从"数据如何复制?各个节点的职责是什么?如何应对复制延迟?如何应对复制中断?"四方面分析,并说明主备复制"对于客户端来说,不需要感知备机的存在……备机仅仅只为备份,并没有提供读写操作,硬件成本上有浪费……故障后需要人工干预,无法自动恢复……内部的后台管理系统使用主备复制架构的情况会比较多",直接支撑本卡片结论。
- 原始内容:存储高可用方案的本质都是通过将数据复制到多个存储设备,通过数据冗余的方式来实现高可用……对于客户端来说,不需要感知备机的存在……故障后需要人工干预,无法自动恢复……内部的后台管理系统使用主备复制架构的情况会比较多。