存储解决方案的高可用性通常依赖于将数据在多个存储设备间复制，利用数据冗余来保障可用性。这种方法的复杂性主要在于处理由复制延迟和中断引起的数据不一致问题。因此，分析任何高可用存储方案时，我们应该从以下几个关键点考虑：
数据是如何进行复制的？
各个节点各自承担哪些职责？
复制延迟如何被管理？
面对复制中断，系统如何应对？
高可用存储架构的常见模式包括主备、主从、双主、集群和分区。每种模式都可以根据具体业务需求进行特定的功能定制，从而产生各种变体。考虑到不同业务功能的定制可能不具备普遍适用性，本文将主要分析业界广泛应用的几种双机高可用架构，包括主备、主从、主备/主从切换以及双主架构。
主备复制
1. 基本实现
下面是标准的主备方案结构图：
其整体架构比较简单，主备架构中的“备机”主要还是起到一个备份作用，并不承担实际的业务读写操作，如果要把备机改为主机，需要人工操作。
2. 优缺点分析
主备复制架构以其简洁性著称，具有以下优势：
对客户端透明：客户端无需了解备机的存在。即便在发生灾难后，将原备机手动切换为主机，客户端仅需更新主机地址，无需知晓背后的细节。
数据复制简单：主机和备机间的交互仅限于数据复制，无需复杂的状态判断或主备切换操作。
然而，主备复制架构也存在明显的缺点：
资源利用低：备机仅作为冗余备份存在，不承担读写任务，导致硬件资源浪费。
需要人工干预：系统在故障后不能自动恢复，需人工介入。这种人工处理不仅效率低（寻找可操作人员可能耗时长），而且由于操作不常见，易在恢复过程中出错，可能会在紧急情况下遭遇各种意外问题。
双机切换
主备复制和主从复制方案共同面临的挑战包括：
主机出现故障后，系统无法执行写操作。
如果主机不能恢复，需要手动设定新的主机。
为了解决这些问题，引入了包括主备切换和主从切换在内的双机切换方案。这些方案的核心在于增加自动“切换”功能，使得系统能够自动决定并执行主机角色的转换。虽然主备切换和主从切换在切换机制上类似，接下来我们以主备切换为例来探讨如何实现这种双机切换架构。
实施有效的切换方案需关注以下几个关键点：
状态的判断与传递
传递渠道：是直接在主备之间进行，还是通过第三方仲裁？
检测内容：包括检查机器是否掉电、进程是否运行、系统响应是否缓慢等。
切换的决策制定
切换时机：确定何时应将备机提升为主机。可能的情况包括主机掉电、进程消失、响应时间过长或频繁重启。
切换策略：决定故障主机恢复后的角色是继续作为主机还是变为备机。
自动化程度：切换是否完全自动化，或需要人工确认如点击一个“切换”按钮。
解决数据冲突
当故障的主机恢复后，新旧主机间可能发生数据冲突，例如两个主机上都存在相同ID的数据但内容不同。
每个设计点的处理方案依业务需求而定，因此双机切换方案不仅仅增加了切换功能，其复杂性也大幅提升。比方说，如果复制方案的代码量为1000行，那么加入切换功能后的代码量可能增至10000行。这额外的9000行代码主要用于实现上述三个关键设计点。
2.常见框架
根据状态传递渠道的不同，常见的主备切换架构有三种形式：互连式、中介式和模拟式。
互连式
故名思议，互连式就是指主备机直接建立状态传递的渠道，架构图请注意与主备复制架构对比。
在主备复制架构中，主机与备机之间新增了一个“状态传递”通道，该通道的主要作用是进行状态信息的交换。此通道的实现方法多样化：
可以采用网络连接（如打开特定端口）或非网络连接（例如通过串行端口线）。
状态信息的传递可以由主机向备机发送，也可以由备机主动向主机请求。
此通道既可以与数据复制通道共享，也可以设为独立通道。
状态传递通道可以单一，也可以多重，甚至可以混合不同类型的通道（如网络和串口结合）。
为最大化切换方案自动确定主机的优势，客户端的配置也需作出相应调整，常见的方法包括：
为确保切换不干扰客户端访问，主机和备机可以共享一个对客户端而言唯一的地址，如虚拟IP。在切换时，新的主机将绑定此虚拟IP。
客户端可以同时记录主机和备机的地址，并尝试连接可用的地址。虽然备机能接收到客户端的请求，但会因“备机不提供服务”而拒绝这些请求。
然而，互连式主备切换的主要缺点包括：
如果状态传递通道本身发生故障（如网线意外断开），备机可能误判主机已故障并升级为主机，尽管实际上主机是正常的，这可能导致系统中同时存在两个主机的情况。
虽然可以通过增加更多的通道来提升状态传递的可靠性，这种做法只能降低通道故障的可能性，不能根本解决问题。且随着通道数量的增加，后续的状态决策变得更为复杂，备机可能会从不同的通道接收到互相矛盾的状态信息。
中介式
中介式指的是在主备两者之外引入第三方中介，主备机之间不直接连接，而都去连接中介，并且通过中介来传递状态信息，其架构图如下：
在对比中介式与互连式切换架构时，我们发现主机与备机不再通过直接互联的方式交换状态信息，而是都通过上报状态给一个中间代理—即中介。从表面上看，引入中介似乎使得架构更为复杂，因为需要额外的中介存在以及独立上报状态的步骤。然而，中介式架构实际上简化了状态的传递与决策过程，原因如下：
连接管理简化：在中介式架构中，主备机不需要管理多个状态传递连接，只需维持与中介的连接。这比互连式架构的连接管理要简单，后者可能需要主机和备机开启监听端口，或通过串口连接等多种方式进行状态交换。在中介式架构中，主备机只需向中介发送或从中介接收状态信息，作为中介的客户端进行操作，大大简化了复杂度。
状态决策简化：在中介式架构中，主备机的状态决策过程也被简化。不需要考虑通过多种连接方式获取的状态信息如何处理，只需依据简单的规则作出判断。例如，无论主机还是备机，一旦与中介断开连接，都会自动降级为备机，这可能导致双备机状态。如果主机与中介断连，中介会迅速通知备机升级为主机。如果主机因网络中断而与中介失联，它将自动降级为备机，当网络恢复时，它作为备机重新向中介上报状态。若主机因掉电或进程重启而初始状态为备机，一旦与中介连接恢复，发现已存在主机，就会保持备机状态。只有当连接正常且根据实际状态需要切换时，例如主机响应时间超过规定秒数，才会执行主备切换。
虽然中介式架构在状态传递和决策上提供了简化，但这种简化并非没有成本。其主要挑战在于确保中介自身的高可用性。如果中介宕机，整个系统将转入双备状态，导致写操作暂停，从而使业务受到影响。这导致了一个递归问题：为保障系统的高可用性而引入的中介，本身也需要设计高可用方案，这种需求可能无限循环。
MongoDB 的 Replica Set 采取的就是这种方式，其基本架构如下：
在MongoDB的配置中，MongoDB(M)作为主节点，MongoDB(S)作为备节点，而MongoDB(A)则充当仲裁节点的角色。主备节点负责存储数据，但仲裁节点则不涉及数据存储。客户端应配置为同时连接主节点和备节点，而不连接仲裁节点。
幸运的是，针对中介式架构，已经存在成熟的开源解决方案，如ZooKeeper和Keepalived。ZooKeeper本身已构建了一个高可用集群架构，这为中介的可靠性提供了保障。因此，在实际应用中，建议使用基于ZooKeeper的中介式切换架构来实现高可用性。
模拟式
模拟式指主备机之间并不传递任何状态数据，而是备机模拟成一个客户端，向主机发起模拟的读写操作，根据读写操作的响应情况来判断主机的状态。其基本架构如下：
互连式切换架构中，主备机之间只设有数据复制通道，并不包含专用的状态传递通道。备机通过执行模拟的读写操作来检测主机的状况，并依据这些操作的反应来决定状态。
与互连式切换相比，模拟式切换的主要优点在于其实现的简洁性，因为它免除了创建和维护状态传递通道的需要。
然而，这种简洁性也带来了缺点。模拟式通过读写操作获得的状态信息仅限于响应本身，如HTTP 404错误、请求超时或响应时间超过3秒等，而不像互连式那样可以获取更多样化的信息（例如CPU负载、I/O负载、吞吐量、响应时间等）。因此，基于这些有限的信息进行状态决策可能导致决策偏差。
主主复制
主主复制指的是两台机器都是主机，互相将数据复制给对方，客户端可以任意挑选其中一台机器进行读写操作，下面是基本架构图。
相较于主备切换架构，主主复制架构展现出一些独特的特征：
双主结构意味着两台服务器均作为主机，消除了角色切换的需求。
客户端在进行读写操作时，无需考虑服务器的角色区分，可以任意选择任何一台主机进行数据操作。
从表面上看，主主复制架构似乎更为简洁，因为它不需要进行状态信息的传递、状态决策以及状态切换。然而，实际上，主主复制架构也带来了其特有的复杂性，主要体现在对数据处理的高要求上。具体问题包括：
数据的双向复制问题：某些类型的数据不适宜进行双向复制。例如，用户注册时自动生成的递增用户ID。如果两台主机都分别独立生成ID，可能会导致ID冲突。例如，用户X在主机A上注册时被分配了ID 100，同时用户Y在主机B上也注册，同样被分配了ID 100，从而发生冲突。
库存数据的一致性问题：如果库存数据在两台主机上独立变化，再相互复制可能会导致数据不一致。例如，一件商品的初始库存为100件，主机A减少1件变为99件，而主机B减少2件变为98件。如果主机A将其库存99复制到主机B，将覆盖主机B原有的库存98，导致实际库存出现错误，正确的库存应为97件。
因此，主主复制架构对数据设计提出了严格要求，通常适用于那些临时性的、可被覆盖或可丢失的数据场景，如用户登录时产生的session数据（用户可以重新登录来重新生成）、用户行为日志（允许部分丢失）、或论坛的草稿数据（可被覆盖或丢失）。