分布式技术原理与算法解析
聂鹏程
智载云帆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 | 答疑篇:如何判断并解决网络分区问题?
分布式技术原理与算法解析
登录|注册

13 | 分布式调度架构之共享状态调度:物质文明、精神文明多手协商抓

聂鹏程 2019-10-21
你好,我是聂鹏程。今天,我来继续带你打卡分布式核心技术。
在上一篇文章中,我们一起学习了两层调度。在两层调度架构中,第二层调度只知道集群中的部分资源,无法进行全局最优调度。那么,是否有办法解决全局最优调度的问题呢?
答案是肯定的,解决办法就是我今天要带你打卡的共享状态调度。
接下来,我们就一起看看共享状态调度到底是什么,以及它的架构和工作原理吧。

什么是共享状态调度?

通过我们前两篇文章的讲述,不难发现,集群中需要管理的对象主要包括两种:
一是,资源的分配和使用状态;
二是,任务的调度和执行状态;
在单体调度中,这两种对象都是由单体调度器管理的,因此可以比较容易地保证全局状态的一致性,但问题是可扩展性较差(支持业务类型受限),且存在单点瓶颈问题。
而在两层调度中,这两种对象分别由第一层中央调度器和第二层 Framework 调度器管理,由于 Framwork 调度器只能看到部分资源,因此不能保证全局状态的一致性,也不容易实现全局最优的调度。
为了解决这些问题,一种新的调度器架构被设计了出来。这种架构基本上沿袭了单体调度器的模式,通过将单体调度器分解为多个调度器,每个调度器都有全局的资源状态信息,从而实现最优的任务调度,提供了更好的可扩展性。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《分布式技术原理与算法解析》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(7)

  • Eternal
    感觉这一节超级棒,老师通过事务的例子来解释共享状态的调度很深刻。
    我对老师的问题关于共享状态调度的核心解决并发冲突的思考:
    一个job由多个task组成,一个job要么全都执行,要么全都不执行,就像老师说的理解成一个事务;
    1.job执行执行的时候如果阻塞等待资源,我们可以将阻塞加上超时时间,超时后还不能获取到资源,当前job主动释放自己已经占有的资源,这可以叫做等待超时时间;
    2.如果一个job占有了一些资源,正在执行,我们可以给当前job设置一个超时时间,如果job在超时时间内还没把资源执行完,自己主动释放占有的资源,回滚job的所有task,这可以理解成作业超时时间
    3.多个job的多个task在抢资源的时候,我们可以设计一个公平和非公平的抢占队列
    4.共享状态下的调度有一个特点是每个调度器都有全局的资源,这个可以这样改进一下:每个调度器的资源分为两部分组成,一部分独占,一部分由共享抢占获取,这样减少并发的程度;这让我想到了操作系统的内存模型,一个核心占用一部分固定内存,然后其它的内存是共享的,也就是可以抢占的

    2019-10-30
    2
  • 波波安
    解决并发冲突的方法就是加锁,在分布式架构中可以采用分布式锁,具体有前面讲到的三种,基于数据库的,基于redis的,基于zookeeper的分布式锁。
    2019-10-21
    1
  • 阿卡牛
    不同的体系结构是否对选择不同的调试结构有影响?
    2019-10-29
  • 天天向善
    很抽像,能不能描述一下调度器做了哪些事情,任务举几个例子,共享状态调度的资源状态和任务状态有哪些
    2019-10-22
  • leslie
    关于并发其实数据系统中一直很早就在处理这种问题:从早期单机RMDB->读写分离->一主多从->内存库【虽然市面上各种分类众多,可是个人还是偏向这种说法,各种关系太复杂了】。
        谈不上什么特别好的解决方案:就谈谈老师课程中提到的Google对此的做法吧MVCC,其实这确实是一条解决的方式和思路,就像内存库就无法做到ACID特性,只能牺牲部分。目前主流其实就是老师文中所说的先锁或者后验证。
        前段时间和本地的同行交流发现其实随着现在系统的越来越复杂:操作系统都开始特性化的时代确实感觉定制化的东西已经越来越多的出现在计算机的各个方面,如何从中获得一个相对中立的方案才是关键吧。
    2019-10-21
  • Jackey
    能想到的解决冲突的方法就是加锁了,乐观锁或是悲观锁,本质上都是让并行变串行。当然也有一些可以优化的点,比如读读并行。
    2019-10-21
  • 随心而至
    1.同步
    给资源编号,按照一定的顺序加锁,释放锁,以免出现死锁
    2.CAS compare and swap
    可能还有其他方式,可以参考维基百科的Synchronization条目
    2019-10-21
收起评论
7
返回
顶部