分布式技术原理与算法解析
聂鹏程
智载云帆CTO,前华为分布式Lab资深技术专家
立即订阅
5969 人已学习
课程目录
已更新 36 讲 / 共 34 讲
0/4登录后,你可以任选4讲全文学习。
课前必读 (3讲)
开篇词 | 四纵四横,带你透彻理解分布式技术
免费
01 | 分布式缘何而起:从单兵,到游击队,到集团军
02 | 分布式系统的指标:啥是分布式的三围
第一站:分布式协调与同步 (6讲)
03 | 分布式互斥:有你没我,有我没你
04 | 分布式选举:国不可一日无君
05 | 分布式共识:存异求同
06 | 分布式事务:All or nothing
07 | 分布式锁:关键重地,非请勿入
08 | 分布式技术是如何引爆人工智能的?
第二站:分布式资源管理与负载调度 (6讲)
09 | 分布式体系结构之集中式结构:一人在上,万人在下
10 | 分布式体系结构之非集中式结构:众生平等
11 | 分布式调度架构之单体调度:物质文明、精神文明一手抓
12 | 分布式调度架构之两层调度:物质文明、精神文明两手抓
13 | 分布式调度架构之共享状态调度:物质文明、精神文明多手协商抓
14 | 答疑篇:分布式事务与分布式锁相关问题
第三站:分布式计算技术 (4讲)
15 | 分布式计算模式之MR:一门同流合污的艺术
16 | 分布式计算模式之Stream:一门背锅的艺术
17 | 分布式计算模式之Actor:一门甩锅的艺术
18 | 分布式计算模式之流水线:你方唱罢我登场
第四站:分布式通信技术 (4讲)
19 | 分布式通信之远程调用:我是你的千里眼
20 | 分布式通信之发布订阅:送货上门
21 | 分布式通信之消息队列:货物自取
22 | 答疑篇:分布式体系架构与分布式计算相关问题
第五站:分布式数据存储 (5讲)
23 | CAP理论:这顶帽子我不想要
24 | 分布式数据存储系统之三要素:顾客、导购与货架
25 | 数据分布方式之哈希与一致性哈希:“掐指一算”与“掐指两算”的事
26 | 分布式数据复制技术:分身有术
27 | 分布式数据之缓存技术:“身手钥钱”随身带
特别放送 (3讲)
特别放送 | 分布式下的一致性杂谈
特别放送 | 徐志强:学习这件事儿,不到长城非好汉
特别放送 | 那些你不能错过的分布式系统论文
第六站:分布式高可靠 (5讲)
28 | 分布式高可靠之负载均衡:不患寡,而患不均
29 | 分布式高可靠之流量控制:大禹治水,在疏不在堵
30 | 分布式高可用之故障隔离:当断不断,反受其乱
31 | 分布式高可用之故障恢复:知错能改,善莫大焉
32 | 答疑篇:如何判断并解决网络分区问题?
分布式技术原理与算法解析
登录|注册

22 | 答疑篇:分布式体系架构与分布式计算相关问题

聂鹏程 2019-11-13
你好,我是聂鹏程。今天,我来继续带你打卡分布式核心技术。
到目前为止,“分布式技术原理与算法解析”专栏已经更新 21 篇文章了,我已经为你介绍了分布式技术四纵四横知识体系中的三横,即“布式资源管理”“分布式计算技术”和“分布式通信”,以及四纵中的“分布式协同”和“分布式调度”。
在这里,我首先要感谢你们坚持学习每一篇文章,以及对每一道思考题的积极思考与讨论,并且还在此基础上对类似问题进行了扩展。
比如,@1024、@每天晒白牙、@游弋云端、@Jackey 和 @Dale 等同学,对双主问题展开了激烈的讨论;再比如,@xj_zh、@mt11912、@小白啊、@随心而至等同学,对 Master 如何判断 Slave 是否存活的问题进行了讨论,特别是 @小白啊还专门查询了 Kubernetes 的方法,在留言区进行了回复。
这样的同学还有很多,我就不再一一点名了。今天,我就针对前面文章涉及的与思考题有关的留言,做一次进一步地梳理与分析,以帮助你夯实前面所学的知识点。
留言涉及的问题有很多,但我经过进一步地分析和总结后,发现大家特别感兴趣和有疑惑的思考题主要分为两类:
分布式体系架构中,如何判断节点存活的问题;
分布式计算技术中,离线计算、批量计算、实时计算和流式计算的区别。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《分布式技术原理与算法解析》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(9)

  • 花儿少年
    如何避免出现”双主“呢
    https://www.iteye.com/blog/1316478764-2206068
    这篇博客 给了一个一种颁发有效期的机制。
    其实都会依赖一个高可用的监控系统来监控应用系统主节点的状态,根据其状态做判断
    2019-11-20
    2
  • simon
    对于 Slave 所在服务器故障的情况,由于服务器宕机或重启,那么系统环境等均不工作了,这种情况 TCP 长连接也无法进行探测了,也就是说 TCP 长连接方法在这种场景下无法判断节点是否故障。
    为什么???难道重启或岩机,还能tcp长连接?反过来,心跳也能检查进程退出吧,因为如果进程退出也不会有心跳吧
    2019-11-14
    2
  • Dylan
    那假设出现双主的场景,一般是通过什么有效策略去解决呢,或者有没有好的办法尽量去避免这种情况
    2019-11-16
    1
  • 随心而至
    非集中式的心跳机制好多是基于Gossip协议做的,比如consul,redis。
    2019-11-13
    1
  • Jackey
    关于检测存活还是有些疑问。长连接为什么不能检测机器故障呢?服务器宕机时长连接也会断开的吧。
    另外非集中式的下线条件是过半数以上机器标记为不可达才会认为机器下线对吗?下线后监控的顺序会发生改变吗?
    2019-11-13
    5
    1
  • tt
    判断节点是否存活的方法中,基于长链接的方法是利用了TCP层本身的机制;而基于心跳的方式是基于应用层自己的方法去实现。

    如果用OSI模型来描述,就是前者是四层的存活检测,后者是七层的存活检测。
    2019-11-13
    1
  • 张先生
    我以为就我看不到心跳检测,原来大家都有疑问。为什么TCP断开就判断是程序挂了,心跳就是服务器挂了??不明白
    2019-11-15
    1
  • 安排
    tcp长连接和心跳那块儿不是很理解,我觉得探测slave进程故障才应该用心跳,探测机器故障长连接是可以的。
    slave进程如果还活着但是死锁卡住了,其实长连接是探测不到的,内核协议栈会正常回复探测报文。slave进程如果异常退出,但是操作系统没死,这时socket关闭时有机会发fin,master会收到fin(不考虑网络丢失),所以可以很快知道slave进程死了。如果slave所在机器宕机来不及发fin,master长连接不停探测,最终是会发现机器死了的。
    我认为心跳就是探测slave进程是否死锁卡死等这种场景的,slave进程死了就认为机器也挂了,不管物理机器是否宕机了。
    2019-11-13
    1
  • 忆水寒
    收获满满
    2019-11-13
收起评论
9
返回
顶部