双机架构

存储高可用方案的本质都是通过将数据复制到多个存储设备，通过数据冗余的方式来实现高可用，其复杂性主要体现在如何应对复制延迟和中断导致的数据不一致问题。因此，对任何一个高可用存储方案，我们需要从以下几个方面去进行思考和分析：
数据如何复制？
各个节点的职责是什么？
如何应对复制延迟？
如何应对复制中断？
常见的高可用存储架构有主备、主从、主主、集群、分区。

主备复制

主备复制是最常见也是最简单的一种存储高可用方案，几乎所有的存储系统都提供了主备复制的功能，例如 MySQL、Redis、MongoDB 等。

基本实现

下面是标准的主备方案结构图：
在这里插入图片描述

优缺点分析

优点：
1、无须感知备机存在；
2、对于主备，双方只需要进行数据复制即可，无须进行状态判断和主备切换操作；
缺点：
1、备机仅仅只为备份，并没有提供读写操作；
2、故障后需要人工干预，无法自动恢复；
使用场景：
内部的后台管理系统使用主备复制架构的情况会比较多，例如学生管理系统、员工管理系统、假期管理系统等，因为这类系统的数据变更频率低，即使在某些场景下丢失数据，也可以通过人工的方式补全

主从复制

主机负责读写操作，从机只负责读操作，不负责写操作。

基本实现

下面是标准的主从复制架构：
在这里插入图片描述

优缺点分析

优点：
1、主从复制在主机故障时，读操作相关的业务可以继续运行；
2、主从复制架构的从机提供读操作，发挥了硬件的性能；
缺点：
1、客户端需要感知主从关系，并将不同的操作发给不同的机器进行处理；
2、如果主从复制延迟比较大，业务会因为数据不一致出现问题；
3、故障时需要人工干预；
使用场景：
写少读多的业务场景使用主从复制架构较多。如，论坛，BBS、新闻网站等，读操作数量是写操作数量的10倍甚至100倍以上。

双机切换

主备复制和主从复制方案存在两个共性的问题：

1、主机故障后，无法进行写操作；
2、如果主机无法恢复，需要人工指定新的主机角色；

双机切换就是为了解决这两个问题而产生的，包括主备切换和主从切换两种方案。简单来说，这两个方案就是在原有方案的基础上增加“切换”功能，即系统自动决定主机角色，并完成角色切换。

要实现一个完善的切换方案，必须考虑这几个关键的设计点：

主备间状态判断

状态传递的渠道：是相互间互相连接，还是第三方仲裁？
状态检测的内容：例如机器是否掉电、进程是否存在、响应是否缓慢等。

切换决策

切换时机：什么情况下备机应该升级为主机？是机器掉电后备机才升级，还是主机上的进程不存在就升级，还是主机响应时间超过2秒就升级，还是3分钟内主机连续重启3次就升级等。
切换策略：原来的主机故障恢复后，要再次切换，确保原来的主机继续做主机，还是原来的主机故障恢复后自动成为新的备机？
自动程度：切换是完全自动还是半自动的？

数据冲突解决
当原有故障的主机恢复后，新旧主机之间可能存在数据冲突。例如，用户在旧主机上新增了一条ID为100的数据，这个数据还没有复制到旧的备机，此时发生切换，用户又在新的主机新增了一条ID为100的数据，当旧的故障主机恢复后，这两条ID重复的数据如何处理。

根据状态传递渠道的不同，常见的主备切换架构有三种形式：互连式、中介式和模拟式。

互连式

互连式是指主备机直接建立状态传递的渠道，存在状态传递通道故障的问题
在这里插入图片描述
可以是主机发送状态给备机，也可以是备机到主机来获取状态信息。
可以和数据复制通道共用，也可以独立一条通道。
为了充分利用切换方案能够自动决定主机这个优势，客户端也会有一些相应的改变，常见方式如下：
1、为了切换后不影响客户端的访问，主机和备机之间共享一个对客户端来说唯一的地址。例如虚拟 IP，主机需要绑定这个虚拟的 IP。
2、客户端同时记录主备机的地址；
3、备机虽然能收到客户端的操作请求，但是会直接拒绝，拒绝的原因就是“备机不对外提供服务”；

互连式缺点：
1、状态传递的通道故障时，可能导致备机也认为主机故障了从而升级为主机，导致出现两个主机；
2、如果增加多个通道增强状态传递的可靠性，只是降低通道故障概率，不能根本解决这个缺点，并且通道越多状态决策越复杂。

中介式

中介式指的是在主备两者之外引入第三方中介，主备机之间不直接连接，而都去连接中介，并且通过中介来传递状态信息
在这里插入图片描述

虽然中介式在状态传递和状态决策上更加简单，但存在如何保证中介本身的高可用问题。如果中介自己宕机了，整个系统就进入了双备的状态，写操作相关的业务就不可用了。

MongoDB的Replica Set采取的就是中介式，架构图如下，
在这里插入图片描述

MongoDB（M），主节点：存储数据
MongoDB（S）：备节点：存储数据
MongoDB（A）：仲裁节点：不存储数据
客户端连接主备节点。

开源方案已经有比较成熟的中介式解决方案，例如 ZooKeeper 和 Keepalived。ZooKeeper 本身已经实现了高可用集群架构，因此已经帮我们解决了中介本身的可靠性问题，在工程实践中推荐基于 ZooKeeper 搭建中介式切换架构。

模拟式

模拟式指主备机之间并不传递任何状态数据，而是备机模拟成一个客户端，向主机发起模拟的读写操作，根据读写操作的响应情况来判断主机的状态。
在这里插入图片描述

模拟式切换与互连式切换相比，优点是实现更加简单，因为省去了状态传递通道的建立和管理工作。

简单既是优点，同时也是缺点。因为模拟式读写操作获取的状态信息只有响应信息（例如，HTTP 404，超时、响应时间超过 3 秒等），没有互连式那样多样（除了响应信息，还可以包含 CPU 负载、I/O 负载、吞吐量、响应时间等），基于有限的状态来做状态决策，可能出现偏差。

主主复制

主主复制指的是两台机器都是主机，互相将数据复制给对方，客户端可以任意挑选其中一台机器进行读写操作

在这里插入图片描述

主主复制从总体上来看要简单很多，无须状态信息传递，也无须状态决策和状态切换，但是其对使用场景有限制，如果采取主主复制架构，必须保证数据能够双向复制，而很多数据是不能双向复制的。例如：

用户注册后生成的用户 ID，如果按照数字增长，那就不能双向复制，否则就会出现多台主机出现同一ID;
库存不能双向复制，一台主机减了，另一台主机也减了，复制后被覆盖掉；
因此，主主复制架构对数据的设计有严格的要求，一般适合于那些临时性、可丢失、可覆盖的数据场景。例如，用户登录产生的 session 数据（可以重新登录生成）、用户行为的日志数据（可以丢失）、论坛的草稿数据（可以丢失）等。