从 0 开始学架构
李运华
网名“华仔”,前阿里资深技术专家(P9)
152573 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 66 讲
结束语 (1讲)
结课测试 (1讲)
从 0 开始学架构
15
15
1.0x
00:00/00:00
登录|注册

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

故障服务器重新分配角色
任务分配器将任务发送给不同服务器
不同服务器角色不同
故障服务器恢复后重新分配任务
故障服务器不再分配任务
任务分配器采取策略分配任务
设计任务管理器,根据执行结果重新分配任务
不做处理,分配到其他非故障服务器
特定服务器(主机)
所有服务器
计算高可用和存储高可用架构复杂度相似
非对称集群
负载均衡集群
人工操作切换主从和增加从机
主机恢复后继续按原有策略分配任务
主机故障时继续发送任务给主机
主机和备机执行不同计算任务
冷备和温备
人工操作切换主备和增加备机
主机恢复后继续发送任务
主机故障时系统不可用
主机执行所有计算任务
任务如何重新执行
哪些服务器可以执行任务
增加更多服务器实现计算高可用
通过冗余规避部分故障风险
部分硬件损坏时任务能够继续正常运行
复杂度比较
集群架构
主从架构
主备架构
任务管理的关键点
计算高可用的设计目标
如何设计计算高可用架构?

该思维导图由 AI 生成,仅供参考

计算高可用的主要设计目标是当出现部分硬件损坏时,计算任务能够继续正常运行。因此计算高可用的本质是通过冗余来规避部分故障的风险,单台服务器是无论如何都达不到这个目标的。所以计算高可用的设计思想很简单:通过增加更多服务器来达到计算高可用。
计算高可用架构的设计复杂度主要体现在任务管理方面,即当任务在某台服务器上执行失败后,如何将任务重新分配到新的服务器进行执行。因此,计算高可用架构设计的关键点有下面两点。
1. 哪些服务器可以执行任务
第一种方式和计算高性能中的集群类似,每个服务器都可以执行任务。例如,常见的访问网站的某个页面。
第二种方式和存储高可用中的集群类似,只有特定服务器(通常叫“主机”)可以执行任务。当执行任务的服务器故障后,系统需要挑选新的服务器来执行任务。例如,ZooKeeper 的 Leader 才能处理写操作请求。
2. 任务如何重新执行
第一种策略是对于已经分配的任务即使执行失败也不做任何处理,系统只需要保证新的任务能够分配到其他非故障服务器上执行即可。
第二种策略是设计一个任务管理器来管理需要执行的计算任务,服务器执行完任务后,需要向任务管理器反馈任务执行结果,任务管理器根据任务执行结果来决定是否需要将任务重新分配到另外的服务器上执行。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

计算高可用架构设计是保证计算任务在部分硬件损坏时仍能正常运行的关键目标。为实现高可用性,需要通过冗余来规避部分故障的风险,因此简单的单台服务器无法满足这一目标。文章介绍了计算高可用架构设计的复杂性,主要集中在任务管理方面。关键设计点包括确定哪些服务器可以执行任务以及如何重新执行任务。文章详细阐述了主备、主从和集群等常见的计算高可用架构。主备架构是最简单的,但需要人工操作,适合使用人数不多、使用频率不高的业务;主从架构需要将任务分类,任务分配器复杂一些,但能充分发挥从机的硬件性能。总的来说,计算高可用架构设计需要综合考虑系统的复杂性和可维护性,选择合适的架构方案来满足业务需求。 文章还介绍了高可用计算的集群方案,包括对称集群和非对称集群。对称集群采用负载均衡集群设计,通过任务分配器选取分配策略和检测服务器状态来实现高可用性。而非对称集群中不同服务器的角色是不同的,需要更复杂的任务分配策略和角色分配策略实现。文章还以ZooKeeper为例详细介绍了非对称集群的设计。 总的来说,本文详细介绍了计算高可用架构设计的复杂性和关键设计点,以及对称集群和非对称集群的设计方案。读者可以通过本文了解不同架构方案的特点和适用场景,以便根据业务需求选择合适的高可用架构设计方案。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《从 0 开始学架构》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(49)

  • 最新
  • 精选
  • feifei
    计算高可用架构,主要解决当单点发生故障后,原本发送到故障节点的任务,任务如何分发给非故障节点,根据业务特点选择分发和重试机制即可,不存在数据一致性问题,只需要保证任务计算完成即可 存储高可用架构,解决的问题是当单点发生故障了,任务如何分发给其他非故障节点,以及如何保障数据的一致性问题。 所以存储的高可用比计算的高可用的设计更为复杂。

    作者回复: 分析正确👍

    2018-06-28
    5
    164
  • 孙振超
    在学习课程的过程中,发现作者是把很多的学习方法给融合到自身之中,变成了自己的东西,从知道变成了成为。比如本次的习题,通过对计算高可用和存储高可用的对比,就是很好的一个例子。 要想高可用就离不开冗余,无论是计算高可用还是存储高可用都会面对机器状态检测、切换以及机器选择的问题,在这几个方面二者复杂度差别不大。 但对于计算而言,集群中的机器间之间基本上是无交互的,对于需要重试的计算任务,是有任务管理器来维护处理;而存储高可用还会涉及到机器之间数据的同步和一致性问题,在同步时还需要考虑性能、稳定性、同步中断、个别失败、重复同步等问题,这一块就会复杂许多。 因而,总体来看,存储高可用更为复杂。

    作者回复: 你的理解比我的理解还要深刻了👍👍👍😄

    2018-08-17
    5
    78
  • yungoo
    计算高可用系统需考虑safety和liveness,而存储高可用除了需考虑safety和liveness,还受CAP约束

    作者回复: 你已经融会贯通👍

    2018-06-28
    2
    42
  • @
    计算无状态,存储有状态

    作者回复: 一针见血👍

    2019-07-12
    2
    27
  • oddrock
    存储高可用比计算高可用要复杂的多,存储高可用是有状态的,计算高可用一般解决的都是无状态问题,有状态就存在着如何保存状态、同步状态的问题了

    作者回复: 分析正确

    2018-06-28
    26
  • Johnny.Z
    任务分配器挂了是不是高可用计算就没办法保证了,任务分配器是否也要弄成集群呢?

    作者回复: 是的,全流程的高可用要求任务分配器也高可用

    2018-06-28
    9
  • 李同杰
    存储高可用需要考虑数据复制的问题,复杂度高于计算高可用架构。

    作者回复: 👍👍👍

    2018-06-28
    8
  • 空档滑行
    计算高可用复杂在选择算法,随着集群规模的扩大,复杂性增加的不明显。比如负载均衡如何判断节点可用,如何判断任务失败还是只是时间较长。 存储高可用除了面临计算高可用同样的问题在,还要考虑数据的同步,异地备灾也比计算高可用复杂,而且随着集群数量增加,整个策略都要做相应的改变

    作者回复: 分析正确👍

    2018-06-28
    5
  • 一步两步
    结合我的负责的项目,计算高可用更像是我平时开发的业务系统(包含了我平时写的curd),当然这个理解台浅显了,希望有更好的举例或者我后面再想想,而存储高可用是我平时业务系统调用的mysql、mongodb、redis、elasticsearch等,平时开发对存储高可用其实考虑的较少,因为有基础架构部门和DBA团队支持,也比较放心使用,只需要分析好数据规模,以及未来增长趋势即可,对于计算高可用,我负责的业务系统大概是北京、南京等三个机房、每个机房有几个集群,我的服务大概100来台机器,我的上游流控系统把流量分发到我这里,采用的是nginx的轮训做的负载均衡。

    作者回复: 你的理解是正确的,但不能因为有基础架构部门负责自己就不去关注和学习,面试的时候你要是这样说很大概率会挂😂

    2021-01-06
    3
  • Geek_Littlelolo
    老师你好,我们现在的业务是开发C-V2X设备的CA系统,系统运行中包含了大量的加解密,签名,验签,计算密集型操作,目前我们设计的是加入一台高性能的加密机,如果实现计算高可用,是不是应该引入多台加密机?

    作者回复: 是的,这是最常见的做法,同时建议用多台价格一般的加密机来代替一台价格特别贵的加密机,因为这样可以同时实现高可用

    2020-12-23
    2
收起评论
显示
设置
留言
49
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部