视频笔记一:绪论

课程背景

构建分布式系统的原因:

  1. Parallelism,资源并行(提高效率)。
  2. Fault tolerance,容错。
  3. Physical,系统内在的物理分散。
  4. Security,不可信对端(区块链)。

分布式系统面临的挑战:

  1. Concurrency,系统构件很多,并行繁杂,交互复杂。
  2. Partial failure,存在部分失败,而不是像单机一样要么正常运行,要么完全宕机。
  3. Performance,精巧设计才能获取与机器数量线性相关的性能。

课程组成

  1. Lectures,授课,一些案例学习。

  2. Papers,论文。

    • 包括一些经典的和前沿的、学术的和工业界的。
    • 看其观点,学其实现,断其性能。
    • 抓重要部分,略次要部分。
    • 课程主页有所有论文链接。
  3. Exams,期中期末两次考试。

  4. Labs:四个实验

    • lab1: MapReduce
    • lab2: Raft 容错
    • lab3: K/V server use Raft
    • lab4: Shared K/V based on lab3

    分布式系统巨难调试,做好心理准备,早点开做。

  5. Project,可以自选相关题目,组队完成,用来替代 lab4。

课程内容

本课程旨在学习支撑应用的基础设施抽象(abstraction),包括

  1. Storage,存储,一个很直接并常用的抽象;如何构建多副本、容错、高性能分布式存储系统。
  2. Communication,通信,如何可靠的通信。
  3. Computation,现代的大规模计算,如 MapReduce

最终理想是提供能够屏蔽分布式细节的、类似于单机的通用接口,同时能兼具容错性能

对于上述抽象,我们有哪些实现呢?

  1. RPC:像在本机调用一样跨节点通信
  2. Concurrency,Threads:并发载体
  3. Concurrency,Lock:并发控制。

Performance 性能

scalability,可扩展性

  • 可以线性的集结计算机资源:使用两倍的机器获取两倍的吞吐。
  • 意味着遇到瓶颈你只需要花少量的钱买机器,而不用付很多的工资找程序员重构。
  • 但这个特点很难实现。通常你将一个组件扩展后,瓶颈就转移到了另一个组件,全组件的无限扩展很难。

Fault Tolerance 容错

单机虽好,作为上千台机器组成的集群来说,故障却是常态。比如说:

  • 主机宕机
  • 网络抖动
  • 交换机故障

Availability 可用性
Recoverbility 可恢复性,无干预 、不影响正确性的可恢复

手段:
NV storage:持久化
Replication:多副本

Consistency 一致性

分布式系统产生不一致的因素:

  1. 缓存
  2. 多副本

不同程度的一致性:

  1. 强一致性:每个客户端每次都能读到(自己 or 他人)之前所写数据。在多副本系统实现强一致性代价十分高昂,需要进行大量的通信。简单说两种方法:

    • 每次更改同时写到所有副本
    • 每次读取都去读所有副本,使用具有最新时间戳的数据。
  2. 弱一致性,为了性能,工业级系统通常选择弱一致性。

MapReduce

背景

Google (2003 年左右)面对巨量(数十 T)的索引数据和全网结构的数据,需要找到最重要的网页。可以简化为一个排序问题,但如此数量级的排序,单机不是一个可选项。而又不是所有工程师都有手撸分布式系统的能力,因此产生了做一个分布式框架的需求,以对应用程序员屏蔽分布式环境细节:

  1. 如何将工作高效分配到上千台机器上。
  2. 如何控制数据流动。
  3. 如何进行容错。

工作原理

以 WordCount 为例:

Map: document -> (word, 1)

Shuffle:group by word in Map machine,send each key Range to the corresponding Reduce Machine。

Reduce: List(word, 1) -> (word, count)

术语体系

任务:Job

工作:Task,分为 Map Task 和 Reduce Task。

工作节点:worker server

工作进程:worker process

主节点:master server

存储配合

为了更好的并行读写,需要一个网络文件系统来配合输入和输出,这就是 GFS(谷歌文件系统)。

GFS 可以简单理解为,一个将大文件拆为一个个小的 64M 的块分散到不同机器上网络文件系统。

网络开销

为了尽量绕开当时的主要瓶颈(网络传输),Google 做了一系列优化,包括 GFS 和 MR 跑在一个集群上,以减少读取和写入数据的网络传输。具体做法是让 Map 任务(Map Task)去找数据(Block)—— 将 Task 调度到其输入所在的机器上。但对于 Reduce 任务,无论如何都会存在大量网络开销:GFS 对数据都进行了冗余备份,意味着每个结果都要写多次。

不过,时下的数据中心可以通过很多手段使得网络传输的速度大大提高,比如使用多个根路由器进行分摊流量,意味着在设计时可以有更多灵活性,不用太为网络传输而优化。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 219,635评论 6 508
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 93,628评论 3 396
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 165,971评论 0 356
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,986评论 1 295
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 68,006评论 6 394
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,784评论 1 307
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,475评论 3 420
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,364评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,860评论 1 317
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 38,008评论 3 338
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 40,152评论 1 351
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,829评论 5 346
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,490评论 3 331
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 32,035评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 33,156评论 1 272
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,428评论 3 373
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 45,127评论 2 356