计算高可用架构¶

备注

计算高可用的主要设计目标是当出现部分硬件损坏时，计算任务能够继续正常运行。因此计算高可用的本质是通过冗余来规避部分故障的风险，单台服务器是无论如何都达不到这个目标的。所以计算高可用的设计思想很简单：通过增加更多服务器来达到计算高可用。

备注

计算高可用架构的设计复杂度主要体现在『任务管理』方面，即当任务在某台服务器上执行失败后，如何将任务重新分配到新的服务器进行执行。

计算高可用架构设计的关键点有下面两点:

1. 哪些服务器可以执行任务
    第一种方式和计算高性能中的集群类似，每个服务器都可以执行任务。
    第二种方式和存储高可用中的集群类似，只有特定服务器（通常叫 “主机”）可以执行任务。
2. 任务如何重新执行
    第一种策略是对于已经分配的任务即使执行失败也不做任何处理，
        系统只需要保证新的任务能够分配到其他非故障服务器上执行即可。
    第二种策略是设计一个任务管理器来管理需要执行的计算任务，
        服务器执行完任务后，需要向任务管理器反馈任务执行结果，
        任务管理器根据任务执行结果来决定是否需要将任务重新分配到另外的服务器上执行。

常见的计算高可用架构:

主备
主从
集群

主备¶

根据备机状态的不同，主备架构又可以细分为冷备架构和温备架构。

冷备:

备机上的程序包和配置文件都准备好，但备机上的业务系统没有启动
主机故障后，需要人工手工将备机的业务系统启动，并将任务分配器的任务请求切换发送给备机

温备:

备机上的业务系统已经启动，只是不对外提供服务，
主机故障后，人工只需要将任务分配器的任务请求切换发送到备机即可。
冷备可以节省一定的能源，但温备能够大大减少手工操作时间，因此一般情况下推荐用温备的方式。

主备架构的优缺点:

优点就是简单
缺点是因为人工操作的时间不可控

主从¶

备注

主机和从机执行的任务不同。主机执行 A 任务，从机执行 B 任务。

主从架构与主备架构相比，优缺点有:

优点：主从架构的从机也执行任务，发挥了从机的硬件性能
缺点：主从架构需要将任务分类，任务分配器会复杂一些

集群¶

高可用计算的集群方案根据集群中服务器节点角色的不同，可以分为两类:

1. 对称集群
    即集群中每个服务器的角色都是一样的，都可以执行所有任务
2. 非对称集群
    集群中的服务器分为多个不同的角色，不同的角色执行不同的任务，例如最常见的 Master-Slave 角色

对称集群¶

备注

对称集群更通俗的叫法是负载均衡集群

负载均衡集群详细设计:

正常情况下，任务分配器采取某种策略（随机、轮询等）将计算任务分配给集群中的不同服务器
当集群中的某台服务器故障后，任务分配器不再将任务分配给它，而是将任务分配给其他服务器执行
当故障的服务器恢复后，任务分配器重新将任务分配给它执行

负载均衡集群的设计关键点在于两点:

1. 任务分配器需要选取分配策略
2. 任务分配器需要检测服务器状态

任务分配策略比较简单:

轮询和随机基本就够了

状态检测稍微复杂一些:

既要检测服务器的状态，例如服务器是否宕机、网络是否正常等；
还要检测任务的执行状态，例如任务是否卡死、是否执行时间过长等。

常用的做法是任务分配器和服务器之间通过心跳来传递信息，
包括服务器信息和任务信息，然后根据实际情况来确定状态判断条件。

例如，一个在线页面访问系统
    正常情况下页面平均会在 500 毫秒内返回，那么状态判断条件可以设计为：
    1 分钟内响应时间超过 1 秒（包括超时）的页面数量占了 80% 时，就认为服务器有故障。
例如，一个后台统计任务系统
    正常情况下任务会在 5 分钟内执行完成，那么状态判断条件可以设计为：
    单个任务执行时间超过 10 分钟还没有结束，就认为服务器有故障。

非对称集群¶

备注

非对称集群中不同服务器的角色是不同的，不同角色的服务器承担不同的职责。以 Master-Slave 为例，部分任务是 Master 服务器才能执行，部分任务是 Slave 服务器才能执行。

非对称集群架构详细设计:

1. 集群会通过某种方式来区分不同服务器的角色。
    例如:
    a. 通过 ZAB 算法选举
    b. 简单地取当前存活服务器中节点 ID 最小的服务器作为 Master 服务器
2. 任务分配器将不同任务发送给不同服务器
    例如:
    a. 计算任务 A 发送给 Master 服务器
    b. 计算任务 B 发送给 Slave 服务器
3. 当指定类型的服务器故障时，需要重新分配角色。
    例如:
    a. Master 服务器故障后，需要将剩余的 Slave 服务器中的一个重新指定为 Master 服务器
    b. 如果是 Slave 服务器故障，则并不需要重新分配角色，只需要将故障服务器从集群剔除即可

非对称集群相比负载均衡集群，设计复杂度主要体现在两个方面:

1. 任务分配策略更加复杂
    需要将任务划分为不同类型并分配给不同角色的集群节点
2. 角色分配策略实现比较复杂
    例如，可能需要使用 ZAB、Raft 这类复杂的算法来实现 Leader 的选举

以 ZooKeeper 为例:

1. 任务分配器
    ZooKeeper 中不存在独立的任务分配器节点，
    每个 Server 都是任务分配器:
    Follower 收到请求后会进行判断，如果是写请求就转发给 Leader，如果是读请求就自己处理。
2. 角色指定
    ZooKeeper 通过 ZAB 算法来选举 Leader
    当 Leader 故障后，所有的 Follower 节点会暂停读写操作，
    开始进行选举，直到新的 Leader 选举出来后才继续对 Client 提供服务。