从0开始学架构
李运华
资深技术专家
立即订阅
38968 人已学习
课程目录
已完结 59 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 照着做,你也能成为架构师!
免费
基础架构 (13讲)
01 | 架构到底是指什么?
02 | 架构设计的历史背景
03 | 架构设计的目的
04 | 复杂度来源:高性能
05 | 复杂度来源:高可用
06 | 复杂度来源:可扩展性
07 | 复杂度来源:低成本、安全、规模
08 | 架构设计三原则
09 | 架构设计原则案例
10 | 架构设计流程:识别复杂度
11 | 架构设计流程:设计备选方案
12 | 架构设计流程:评估和选择备选方案
13 | 架构设计流程:详细方案设计
高性能架构模式 (8讲)
14 | 高性能数据库集群:读写分离
15 | 高性能数据库集群:分库分表
16 | 高性能NoSQL
17 | 高性能缓存架构
18 | 单服务器高性能模式:PPC与TPC
19 | 单服务器高性能模式:Reactor与Proactor
20 | 高性能负载均衡:分类及架构
21 | 高性能负载均衡:算法
高可用架构模式 (10讲)
22 | 想成为架构师,你必须知道CAP理论
23 | 想成为架构师,你必须掌握的CAP细节
24 | FMEA方法,排除架构可用性隐患的利器
25 | 高可用存储架构:双机架构
26 | 高可用存储架构:集群和分区
27 | 如何设计计算高可用架构?
28 | 业务高可用的保障:异地多活架构
29 | 异地多活设计4大技巧
30 | 异地多活设计4步走
31 | 如何应对接口级的故障?
可扩展架构模式 (6讲)
32 | 可扩展架构的基本思想和模式
33 | 传统的可扩展架构模式:分层架构和SOA
34 | 深入理解微服务架构:银弹 or 焦油坑?
35 | 微服务架构最佳实践 - 方法篇
36 | 微服务架构最佳实践 - 基础设施篇
37 | 微内核架构详解
架构实战 (13讲)
38 | 架构师应该如何判断技术演进的方向?
39 | 互联网技术演进的模式
40 | 互联网架构模板:“存储层”技术
41 | 互联网架构模板:“开发层”和“服务层”技术
42 | 互联网架构模板:“网络层”技术
43 | 互联网架构模板:“用户层”和“业务层”技术
44 | 互联网架构模板:“平台”技术
45 | 架构重构内功心法第一式:有的放矢
46 | 架构重构内功心法第二式:合纵连横
47 | 架构重构内功心法第三式:运筹帷幄
48 | 再谈开源项目:如何选择、使用以及二次开发?
49 | 谈谈App架构的演进
50 | 架构实战:架构设计文档模板
特别放送 (7讲)
架构专栏特别放送 | “华仔,放学别走!”第1期
架构专栏特别放送 | “华仔,放学别走!” 第2期
如何高效地学习开源项目 | “华仔,放学别走!” 第3期
架构师成长之路 | “华仔,放学别走!” 第4期
架构师必读书单 | “华仔,放学别走!” 第5期
新书首发 | 《从零开始学架构》
致「从0开始学架构」专栏订阅用户
结束语 (1讲)
结束语 | 坚持,成就你的技术梦想
从0开始学架构
登录|注册

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

李运华 2018-06-28
计算高可用的主要设计目标是当出现部分硬件损坏时,计算任务能够继续正常运行。因此计算高可用的本质是通过冗余来规避部分故障的风险,单台服务器是无论如何都达不到这个目标的。所以计算高可用的设计思想很简单:通过增加更多服务器来达到计算高可用。
计算高可用架构的设计复杂度主要体现在任务管理方面,即当任务在某台服务器上执行失败后,如何将任务重新分配到新的服务器进行执行。因此,计算高可用架构设计的关键点有下面两点。
1. 哪些服务器可以执行任务
第一种方式和计算高性能中的集群类似,每个服务器都可以执行任务。例如,常见的访问网站的某个页面。
第二种方式和存储高可用中的集群类似,只有特定服务器(通常叫“主机”)可以执行任务。当执行任务的服务器故障后,系统需要挑选新的服务器来执行任务。例如,ZooKeeper 的 Leader 才能处理写操作请求。
2. 任务如何重新执行
第一种策略是对于已经分配的任务即使执行失败也不做任何处理,系统只需要保证新的任务能够分配到其他非故障服务器上执行即可。
第二种策略是设计一个任务管理器来管理需要执行的计算任务,服务器执行完任务后,需要向任务管理器反馈任务执行结果,任务管理器根据任务执行结果来决定是否需要将任务重新分配到另外的服务器上执行。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《从0开始学架构》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(29)

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

    作者回复: 分析正确👍

    2018-06-28
    55
  • 孙振超
    在学习课程的过程中,发现作者是把很多的学习方法给融合到自身之中,变成了自己的东西,从知道变成了成为。比如本次的习题,通过对计算高可用和存储高可用的对比,就是很好的一个例子。

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

    但对于计算而言,集群中的机器间之间基本上是无交互的,对于需要重试的计算任务,是有任务管理器来维护处理;而存储高可用还会涉及到机器之间数据的同步和一致性问题,在同步时还需要考虑性能、稳定性、同步中断、个别失败、重复同步等问题,这一块就会复杂许多。
    因而,总体来看,存储高可用更为复杂。

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

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

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

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

    作者回复: 分析正确

    2018-06-28
    11
  • 看评论人人都是架构师的感觉,老师讲的好,各位学友更是青出于蓝而胜于蓝!佩服
    2018-06-28
    9
  • 李同杰
    存储高可用需要考虑数据复制的问题,复杂度高于计算高可用架构。

    作者回复: 👍👍👍

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

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

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

    作者回复: 分析正确👍

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

    作者回复: 一针见血👍

    2019-07-12
    2
  • 星火燎原
    存储高可用架构的复杂度在于节点数据的一致性上,计算高可用架构复杂度在于主从节点的选举上 不知对不对

    作者回复: 基本正确,存储高可用选举也比较复杂

    2018-06-28
    2
  • 成功
    存储任务要考虑CAP三个方面,肯定比计算任务复杂
    2018-07-01
    1
  • 布小丫学编程
    感谢老师的分享,让我系统性地学习了高可用。原来高可用分存储高可用和计算高可用的。
    那Zookeeper本身属于计算高可用还是存储高可用呢?首先它们都是有保存了其他节点状态的,但是它们又需要实现计算高可用的。我个人观点觉得是计算高可用多一些,不知道老师觉得怎么样?

    课后问题:存储高可用肯定更复杂一些,有状态信息的需要保证数据一致性,比如网络原因造成同步延迟问题,这种问题不但难定位而且难解决。计算高可用可以通过重试来解决,比如dubbo分布式框架有负载均衡算法解决计算高可用。
    2019-11-27
  • Minbo
    计算无状态,存储有状态(CAP)

    两个问题:
    1. 那热备和温备的区别是?
    2.这里主备切换,是可以做成自动切换的吧?

    作者回复: 1. 热备随时可以接管业务,温备是系统都启动了
    2. 自动切换可以做,但做好也不那么容易

    2019-11-15
  • 在分布式架构中,往往计算节点会保存中间状态,那么这种属于存储高可用还是计算高可用呢?系统又如何设计呢?

    作者回复: 计算节点保存高可用当然是为了计算,因为节点一重启中间状态就没有了

    2019-08-17
  • (╯‵□′)╯︵┻━┻
    先不考虑架构,说存储和计算本身。

    储存相当于一种时序数据结构,当前由过去决定,需要在当前保证过去储存的数据。由于需要定时执行存储或备份操作,复杂度的上限可以简化为冗余度n乘以已运营时间的长度t。由于存储量是是随着时间累计的,所以可以简化为t/2。那么存储的总复杂度就是O(n*t*t/2),当前时间执行存储的复杂度是其微分,O(n*t)。

    计算结果不取决于过去。所以总复杂度仅为O(n*t),n是计算规模。其当前复杂度为其微分O(n)。

    架构的意义在于当前时间,那么存储架构中关系到增加冗余度的部分,相当于上面的O(n*t)复杂度,其余部分由于不需要在乎过去的数据,复杂度都为O(n)。而计算架构中的任何部分复杂度都是O(n)。

    作者回复: 角度新奇,不过我没看懂😂

    2019-08-09
  • gt
    老师,我有一个问题,对于那种已经分配给某台服务器处理的任务,如果处理任务的服务挂了,这些未处理完的任务要怎么处理,有些什么方案

    作者回复: 重试

    2019-08-02
  • 天明
    请求转发面临着重复计算幂等性问题?如何解决这个问题呢?

    作者回复: 业务方自己解决

    2019-07-26
  • 海罗沃德
    zookeeper在没有选出新的leader之前,整个系统是否处于downtime中?

    作者回复: 是的

    2019-07-15
  • 旭东
    请问有哪些指标表征架构的高可用,高性能?

    作者回复: 都是通用的呀,高可用就是故障时间占比,性能就是吞吐量和时延

    2019-05-31
  • Dylan
    计算高可用集群和存储高可用集群如果是同一个集群呢,也就是同一个集群既要考虑计算高可用又要考虑存储高可用,那么这个复杂度是不是把两者分别的复杂度都要考虑上?那感觉这个复杂度会远远超过单个的复杂度。

    作者回复: 是的,同时设计复杂度更高

    2018-11-03
收起评论
29
返回
顶部