27 | 如何设计计算高可用架构？

2018-06-28 李运华

《从 0 开始学架构》

课程介绍



讲述：黄洲君

时长:大小4.98M



计算高可用的主要设计目标是当出现部分硬件损坏时，计算任务能够继续正常运行。因此计算高可用的本质是通过冗余来规避部分故障的风险，单台服务器是无论如何都达不到这个目标的。所以计算高可用的设计思想很简单：通过增加更多服务器来达到计算高可用。
计算高可用架构的设计复杂度主要体现在任务管理方面，即当任务在某台服务器上执行失败后，如何将任务重新分配到新的服务器进行执行。因此，计算高可用架构设计的关键点有下面两点。
1. 哪些服务器可以执行任务
第一种方式和计算高性能中的集群类似，每个服务器都可以执行任务。例如，常见的访问网站的某个页面。
第二种方式和存储高可用中的集群类似，只有特定服务器（通常叫“主机”）可以执行任务。当执行任务的服务器故障后，系统需要挑选新的服务器来执行任务。例如，ZooKeeper 的 Leader 才能处理写操作请求。
2. 任务如何重新执行
第一种策略是对于已经分配的任务即使执行失败也不做任何处理，系统只需要保证新的任务能够分配到其他非故障服务器上执行即可。
...



展开全文

精选留言

feifei
2018-06-28
计算高可用架构，主要解决当单点发生故障后，原本发送到故障节点的任务，任务如何分发给非故障节点，根据业务特点选择分发和重试机制即可，不存在数据一致性问题，只需要保证任务计算完成即可
存储高可用架构，解决的问题是当单点发生故障了，任务如何分发给其他非故障节点，以及如何保障数据的一致性问题。
所以存储的高可用比计算的高可用的设计更为复杂。
作者回复: 分析正确👍
共 5 条评论
124
孙振超
2018-08-17
在学习课程的过程中，发现作者是把很多的学习方法给融合到自身之中，变成了自己的东西，从知道变成了成为。比如本次的习题，通过对计算高可用和存储高可用的对比，就是很好的一个例子。

要想高可用就离不开冗余，无论是计算高可用还是存储高可用都会面对机器状态检测、切换以及机器选择的问题，在这几个方面二者复杂度差别不大。

但对于计算而言，集群中的机器间之间基本上是无交互的，对于需要重试的计算任务，是有任务管理器来维护处理；而存储高可用还会涉及到机器之间数据的同步和一致性问题，在同步时还需要考虑性能、稳定性、同步中断、个别失败、重复同步等问题，这一块就会复杂许多。
因而，总体来看，存储高可用更为复杂。
展开
作者回复: 你的理解比我的理解还要深刻了👍👍👍😄
共 5 条评论
58
yungoo
2018-06-28
计算高可用系统需考虑safety和liveness，而存储高可用除了需考虑safety和liveness，还受CAP约束
作者回复: 你已经融会贯通👍
共 2 条评论
31
oddrock
2018-06-28
存储高可用比计算高可用要复杂的多，存储高可用是有状态的，计算高可用一般解决的都是无状态问题，有状态就存在着如何保存状态、同步状态的问题了
作者回复: 分析正确
22
林
2018-06-28
看评论人人都是架构师的感觉，老师讲的好，各位学友更是青出于蓝而胜于蓝！佩服
20
@
2019-07-12
计算无状态，存储有状态
作者回复: 一针见血👍
共 2 条评论
14
李同杰
2018-06-28
存储高可用需要考虑数据复制的问题，复杂度高于计算高可用架构。
作者回复: 👍👍👍
8
Johnny.Z
2018-06-28
任务分配器挂了是不是高可用计算就没办法保证了，任务分配器是否也要弄成集群呢？
作者回复: 是的，全流程的高可用要求任务分配器也高可用
7
空档滑行
2018-06-28
计算高可用复杂在选择算法，随着集群规模的扩大，复杂性增加的不明显。比如负载均衡如何判断节点可用，如何判断任务失败还是只是时间较长。
存储高可用除了面临计算高可用同样的问题在，还要考虑数据的同步，异地备灾也比计算高可用复杂，而且随着集群数量增加，整个策略都要做相应的改变
作者回复: 分析正确👍
4
一步两步
2021-01-06
结合我的负责的项目，计算高可用更像是我平时开发的业务系统（包含了我平时写的curd），当然这个理解台浅显了，希望有更好的举例或者我后面再想想，而存储高可用是我平时业务系统调用的mysql、mongodb、redis、elasticsearch等，平时开发对存储高可用其实考虑的较少，因为有基础架构部门和DBA团队支持，也比较放心使用，只需要分析好数据规模，以及未来增长趋势即可，对于计算高可用，我负责的业务系统大概是北京、南京等三个机房、每个机房有几个集群，我的服务大概100来台机器，我的上游流控系统把流量分发到我这里，采用的是nginx的轮训做的负载均衡。
作者回复: 你的理解是正确的，但不能因为有基础架构部门负责自己就不去关注和学习，面试的时候你要是这样说很大概率会挂😂
2
Leon Wong
2018-07-03
往往AP设计倾向的系统，大多数是对称集群;而往往CP设计倾向的系统，大多数都是非对称集群
2
星火燎原
2018-06-28
存储高可用架构的复杂度在于节点数据的一致性上，计算高可用架构复杂度在于主从节点的选举上不知对不对
作者回复: 基本正确，存储高可用选举也比较复杂
2
小神david
2020-12-28
计算高可用和存储高可用架构单从图中看确实有类似之处，但是复杂度的对比不在同样的维度上。首先，计算高可用可以认为是无状态的，而存储高可用是有状态的，这是最主要的区别；其次，存储高可用要解决节点间通信的问题，而计算高可用架构不是必须的。
作者回复: 正解，数据有状态的时候如何保证分布式多节点状态一致性非常难，FLP和CAP都是关于这方面的定理。
1
Geek_Littlelolo
2020-12-23
老师你好,我们现在的业务是开发C-V2X设备的CA系统,系统运行中包含了大量的加解密,签名,验签,计算密集型操作,目前我们设计的是加入一台高性能的加密机,如果实现计算高可用,是不是应该引入多台加密机?
作者回复: 是的，这是最常见的做法，同时建议用多台价格一般的加密机来代替一台价格特别贵的加密机，因为这样可以同时实现高可用
1
脱缰的野马__
2020-09-25
老师，@yungoo同学说的：存储高可用还受到CAP约束这句话，应该需要更明确一些吧？存储高可用也是通过冗余的方式来实现，但是有不同的方案和不同的使用场景，比如是主从主备这类的集群还是切片集群。结合CAP的讲解内容，切片集群并不共享数据，切片集群存储的目的是因为数据体量非常大，只能通过某个切分规则将数据分开来存储，减少单个实例的存储压力，不涉及到集群节点之间的数据同步，最多只是扩容和缩容时的数据重分配，所以CAP应该是约束在存储高可用的主从主备种类的集群方案中吧？请教老师
作者回复: 是的，CAP约束的是有数据复制的集群，数据分片集群不涉及数据复制
1
贺敏Minbo
2019-11-15
计算无状态，存储有状态（CAP）

两个问题：
1. 那热备和温备的区别是？
2.这里主备切换，是可以做成自动切换的吧？
作者回复: 1. 热备随时可以接管业务，温备是系统都启动了
2. 自动切换可以做，但做好也不那么容易
1
gt
2019-08-02
老师，我有一个问题，对于那种已经分配给某台服务器处理的任务，如果处理任务的服务挂了，这些未处理完的任务要怎么处理，有些什么方案
作者回复: 重试
1
天明
2019-07-26
请求转发面临着重复计算幂等性问题？如何解决这个问题呢？
作者回复: 业务方自己解决
1
旭东(Frank)
2019-05-31
请问有哪些指标表征架构的高可用，高性能？
作者回复: 都是通用的呀，高可用就是故障时间占比，性能就是吞吐量和时延
1
成功
2018-07-01
存储任务要考虑CAP三个方面，肯定比计算任务复杂
1