27 如何设计计算高可用架构？
计算高可用的主要设计目标是当出现部分硬件损坏时，计算任务能够继续正常运行。因此计算高可用的本质是通过冗余来规避部分故障的风险，单台服务器是无论如何都达不到这个目标的。所以计算高可用的设计思想很简单：通过增加更多服务器来达到计算高可用。
计算高可用架构的设计复杂度主要体现在任务管理方面，即当任务在某台服务器上执行失败后，如何将任务重新分配到新的服务器进行执行。因此，计算高可用架构设计的关键点有下面两点。
1.哪些服务器可以执行任务
第一种方式和计算高性能中的集群类似，每个服务器都可以执行任务。例如，常见的访问网站的某个页面。
第二种方式和存储高可用中的集群类似，只有特定服务器（通常叫“主机”）可以执行任务。当执行任务的服务器故障后，系统需要挑选新的服务器来执行任务。例如，ZooKeeper的Leader才能处理写操作请求。
2.任务如何重新执行
第一种策略是对于已经分配的任务即使执行失败也不做任何处理，系统只需要保证新的任务能够分配到其他非故障服务器上执行即可。
第二种策略是设计一个任务管理器来管理需要执行的计算任务，服务器执行完任务后，需要向任务管理器反馈任务执行结果，任务管理器根据任务执行结果来决定是否需要将任务重新分配到另外的服务器上执行。
需要注意的是：“任务分配器”是一个逻辑的概念，并不一定要求系统存在一个独立的任务分配器模块。例如：
- Nginx将页面请求发送给Web服务器，而CSS/JS等静态文件直接读取本地缓存。这里的Nginx角色是反向代理系统，但是承担了任务分配器的职责，而不需要Nginx做反向代理，后面再来一个任务分配器。
- 对于一些后台批量运算的任务，可以设计一个独立的任务分配系统来管理这些批处理任务的执行和分配。
- ZooKeeper中的Follower节点，当接收到写请求时会将请求转发给Leader节点处理，当接收到读请求时就自己处理，这里的Follower就相当于一个逻辑上的任务分配器。
接下来，我将详细阐述常见的计算高可用架构：主备、主从和集群。
主备
主备架构是计算高可用最简单的架构，和存储高可用的主备复制架构类似，但是要更简单一些，因为计算高可用的主备架构无须数据复制，其基本的架构示意图如下：
主备方案的详细设计：
- 主机执行所有计算任务。例如，读写数据、执行操作等。
- 当主机故障（例如，主机宕机）时，任务分配器不会自动将计算任务发送给备机，此时系统处于不可用状态。
- 如果主机能够恢复（不管是人工恢复还是自动恢复），任务分配器继续将任务发送给主机。
- 如果主机不能够恢复（例如，机器硬盘损坏，短时间内无法恢复），则需要人工操作，将备机升为主机，然后让任务分配器将任务发送给新的主机（即原来的备机）；同时，为了继续保持主备架构，需要人工增加新的机器作为备机。
根据备机状态的不同，主备架构又可以细分为冷备架构和温备架构。
冷备：备机上的程序包和配置文件都准备好，但备机上的业务系统没有启动（注意：备机的服务器是启动的），主机故障后，需要人工手工将备机的业务系统启动，并将任务分配器的任务请求切换发送给备机。
温备：备机上的业务系统已经启动，只是不对外提供服务，主机故障后，人工只需要将任务分配器的任务请求切换发送到备机即可。冷备可以节省一定的能源，但温备能够大大减少手工操作时间，因此一般情况下推荐用温备的方式。
主备架构的优点就是简单，主备机之间不需要进行交互，状态判断和切换操作由人工执行，系统实现很简单。而缺点正好也体现在“人工操作”这点上，因为人工操作的时间不可控，可能系统已经发生问题了，但维护人员还没发现，等了1个小时才发现。发现后人工切换的操作效率也比较低，可能需要半个小时才完成切换操作，而且手工操作过程中容易出错。例如，修改配置文件改错了、启动了错误的程序等。
和存储高可用中的主备复制架构类似，计算高可用的主备架构也比较适合与内部管理系统、后台管理系统这类使用人数不多、使用频率不高的业务，不太适合在线的业务。
主从
和存储高可用中的主从复制架构类似，计算高可用的主从架构中的从机也是要执行任务的。任务分配器需要将任务进行分类，确定哪些任务可以发送给主机执行，哪些任务可以发送给备机执行，其基本的架构示意图如下：
主从方案详细设计：
- 正常情况下，主机执行部分计算任务（如图中的“计算任务A”），备机执行部分计算任务（如图中的“计算任务B”）。
- 当主机故障（例如，主机宕机）时，任务分配器不会自动将原本发送给主机的任务发送给从机，而是继续发送给主机，不管这些任务执行是否成功。
- 如果主机能够恢复（不管是人工恢复还是自动恢复），任务分配器继续按照原有的设计策略分配任务，即计算任务A发送给主机，计算任务B发送给从机。
- 如果主机不能够恢复（例如，机器硬盘损坏，短时间内无法恢复），则需要人工操作，将原来的从机升级为主机（一般只是修改配置即可），增加新的机器作为从机，新的从机准备就绪后，任务分配器继续按照原有的设计策略分配任务。
主从架构与主备架构相比，优缺点有：
- 优点：主从架构的从机也执行任务，发挥了从机的硬件性能。
- 缺点：主从架构需要将任务分类，任务分配器会复杂一些。
集群
主备架构和主从架构通过冗余一台服务器来提升可用性，且需要人工来切换主备或者主从。这样的架构虽然简单，但存在一个主要的问题：人工操作效率低、容易出错、不能及时处理故障。因此在可用性要求更加严格的场景中，我们需要系统能够自动完成切换操作，这就是高可用集群方案。
高可用计算的集群方案根据集群中服务器节点角色的不同，可以分为两类：一类是对称集群，即集群中每个服务器的角色都是一样的，都可以执行所有任务；另一类是非对称集群，集群中的服务器分为多个不同的角色，不同的角色执行不同的任务，例如最常见的Master-Slave角色。
需要注意的是，计算高可用集群包含2台服务器的集群，这点和存储高可用集群不太一样。存储高可用集群把双机架构和集群架构进行了区分；而在计算高可用集群架构中，2台服务器的集群和多台服务器的集群，在设计上没有本质区别，因此不需要进行区分。
对称集群
对称集群更通俗的叫法是负载均衡集群，因此接下来我使用“负载均衡集群”这个通俗的说法，架构示意图如下：
负载均衡集群详细设计：
- 正常情况下，任务分配器采取某种策略（随机、轮询等）将计算任务分配给集群中的不同服务器。
- 当集群中的某台服务器故障后，任务分配器不再将任务分配给它，而是将任务分配给其他服务器执行。
- 当故障的服务器恢复后，任务分配器重新将任务分配给它执行。
负载均衡集群的设计关键点在于两点：
- 任务分配器需要选取分配策略。
- 任务分配器需要检测服务器状态。
任务分配策略比较简单，轮询和随机基本就够了。状态检测稍微复杂一些，既要检测服务器的状态，例如服务器是否宕机、网络是否正常等；同时还要检测任务的执行状态，例如任务是否卡死、是否执行时间过长等。常用的做法是任务分配器和服务器之间通过心跳来传递信息，包括服务器信息和任务信息，然后根据实际情况来确定状态判断条件。
例如，一个在线页面访问系统，正常情况下页面平均会在500毫秒内返回，那么状态判断条件可以设计为：1分钟内响应时间超过1秒（包括超时）的页面数量占了80%时，就认为服务器有故障。
例如，一个后台统计任务系统，正常情况下任务会在5分钟内执行完成，那么状态判断条件可以设计为：单个任务执行时间超过10分钟还没有结束，就认为服务器有故障。
通过上面两个案例可以看出，不同业务场景的状态判断条件差异很大，实际设计时要根据业务需求来进行设计和调优。
非对称集群
非对称集群中不同服务器的角色是不同的，不同角色的服务器承担不同的职责。以Master-Slave为例，部分任务是Master服务器才能执行，部分任务是Slave服务器才能执行。非对称集群的基本架构示意图如下：
非对称集群架构详细设计：
- 集群会通过某种方式来区分不同服务器的角色。例如，通过ZAB算法选举，或者简单地取当前存活服务器中节点ID最小的服务器作为Master服务器。
- 任务分配器将不同任务发送给不同服务器。例如，图中的计算任务A发送给Master服务器，计算任务B发送给Slave服务器。
- 当指定类型的服务器故障时，需要重新分配角色。例如，Master服务器故障后，需要将剩余的Slave服务器中的一个重新指定为Master服务器；如果是Slave服务器故障，则并不需要重新分配角色，只需要将故障服务器从集群剔除即可。
非对称集群相比负载均衡集群，设计复杂度主要体现在两个方面：
- 任务分配策略更加复杂：需要将任务划分为不同类型并分配给不同角色的集群节点。
- 角色分配策略实现比较复杂：例如，可能需要使用ZAB、Raft这类复杂的算法来实现Leader的选举。
我以ZooKeeper为例：
- 任务分配器：ZooKeeper中不存在独立的任务分配器节点，每个Server都是任务分配器，Follower收到请求后会进行判断，如果是写请求就转发给Leader，如果是读请求就自己处理。
- 角色指定：ZooKeeper通过ZAB算法来选举Leader，当Leader故障后，所有的Follower节点会暂停读写操作，开始进行选举，直到新的Leader选举出来后才继续对Client提供服务。
小结
今天我为你讲了几种常见的计算高可用架构，并分析了不同方案的详细设计，希望对你有所帮助。
这就是今天的全部内容，留一道思考题给你吧，计算高可用架构从形式上和存储高可用架构看上去几乎一样，它们的复杂度是一样的么？谈谈你的理解。
欢迎你把答案写到留言区，和我一起讨论。相信经过深度思考的回答，也会让你对知识的理解更加深刻。（编辑乱入：精彩的留言有机会获得丰厚福利哦！）
- feifei 👍（169） 💬（5）
计算高可用架构，主要解决当单点发生故障后，原本发送到故障节点的任务，任务如何分发给非故障节点，根据业务特点选择分发和重试机制即可，不存在数据一致性问题，只需要保证任务计算完成即可 存储高可用架构，解决的问题是当单点发生故障了，任务如何分发给其他非故障节点，以及如何保障数据的一致性问题。 所以存储的高可用比计算的高可用的设计更为复杂。
2018-06-28 - 孙振超 👍（82） 💬（5）
在学习课程的过程中，发现作者是把很多的学习方法给融合到自身之中，变成了自己的东西，从知道变成了成为。比如本次的习题，通过对计算高可用和存储高可用的对比，就是很好的一个例子。 要想高可用就离不开冗余，无论是计算高可用还是存储高可用都会面对机器状态检测、切换以及机器选择的问题，在这几个方面二者复杂度差别不大。 但对于计算而言，集群中的机器间之间基本上是无交互的，对于需要重试的计算任务，是有任务管理器来维护处理；而存储高可用还会涉及到机器之间数据的同步和一致性问题，在同步时还需要考虑性能、稳定性、同步中断、个别失败、重复同步等问题，这一块就会复杂许多。 因而，总体来看，存储高可用更为复杂。
2018-08-17 - yungoo 👍（42） 💬（2）
计算高可用系统需考虑safety和liveness，而存储高可用除了需考虑safety和liveness，还受CAP约束
2018-06-28 - @ 👍（28） 💬（2）
计算无状态，存储有状态
2019-07-12 - oddrock 👍（27） 💬（1）
存储高可用比计算高可用要复杂的多，存储高可用是有状态的，计算高可用一般解决的都是无状态问题，有状态就存在着如何保存状态、同步状态的问题了
2018-06-28 - Johnny.Z 👍（10） 💬（1）
任务分配器挂了是不是高可用计算就没办法保证了，任务分配器是否也要弄成集群呢？
2018-06-28 - 李同杰 👍（8） 💬（1）
存储高可用需要考虑数据复制的问题，复杂度高于计算高可用架构。
2018-06-28 - 空档滑行 👍（5） 💬（1）
计算高可用复杂在选择算法，随着集群规模的扩大，复杂性增加的不明显。比如负载均衡如何判断节点可用，如何判断任务失败还是只是时间较长。 存储高可用除了面临计算高可用同样的问题在，还要考虑数据的同步，异地备灾也比计算高可用复杂，而且随着集群数量增加，整个策略都要做相应的改变
2018-06-28 - 一步两步 👍（4） 💬（1）
结合我的负责的项目，计算高可用更像是我平时开发的业务系统（包含了我平时写的curd），当然这个理解台浅显了，希望有更好的举例或者我后面再想想，而存储高可用是我平时业务系统调用的mysql、mongodb、redis、elasticsearch等，平时开发对存储高可用其实考虑的较少，因为有基础架构部门和DBA团队支持，也比较放心使用，只需要分析好数据规模，以及未来增长趋势即可，对于计算高可用，我负责的业务系统大概是北京、南京等三个机房、每个机房有几个集群，我的服务大概100来台机器，我的上游流控系统把流量分发到我这里，采用的是nginx的轮训做的负载均衡。
2021-01-06 - 脱缰的野马__ 👍（3） 💬（1）
老师，@yungoo同学说的：存储高可用还受到CAP约束 这句话，应该需要更明确一些吧？存储高可用也是通过冗余的方式来实现，但是有不同的方案和不同的使用场景，比如是主从主备这类的集群还是切片集群。结合CAP的讲解内容，切片集群并不共享数据，切片集群存储的目的是因为数据体量非常大，只能通过某个切分规则将数据分开来存储，减少单个实例的存储压力，不涉及到集群节点之间的数据同步，最多只是扩容和缩容时的数据重分配，所以CAP应该是约束在存储高可用的主从主备种类的集群方案中吧？请教老师
2020-09-25 - Geek_Littlelolo 👍（2） 💬（1）
老师你好,我们现在的业务是开发C-V2X设备的CA系统,系统运行中包含了大量的加解密,签名,验签,计算密集型操作,目前我们设计的是加入一台高性能的加密机,如果实现计算高可用,是不是应该引入多台加密机?
2020-12-23 - gt 👍（2） 💬（1）
老师，我有一个问题，对于那种已经分配给某台服务器处理的任务，如果处理任务的服务挂了，这些未处理完的任务要怎么处理，有些什么方案
2019-08-02 - 天明 👍（2） 💬（1）
请求转发面临着重复计算幂等性问题？如何解决这个问题呢？
2019-07-26 - 旭东(Frank) 👍（2） 💬（1）
请问有哪些指标表征架构的高可用，高性能？
2019-05-31 - 星火燎原 👍（2） 💬（1）
存储高可用架构的复杂度在于节点数据的一致性上，计算高可用架构复杂度在于主从节点的选举上 不知对不对
2018-06-28