mit分布式系统学习笔记01

Leture01

为什么分布式：

• 连接不同物理实体
• 通过隔离实现安全
• 通过复制实现容错
• 并行的cpu、mem、disk、net实现扩展

4个实验：

Lab 1: MapReduce

Lab 2: replication for fault-tolerance using Raft

Lab 3: fault-tolerant key/value store

Lab 4: sharded key/value store

实现：

RPC、多线程、并发控制

性能

理想情况，可扩展N

随着N增加带来的问题：

负载均衡

不可并行化的代码，如初始化，交互

容错

隐藏错误

需满足错误发生时的可用性，错误修复后的持久性；

复制服务器

一致性

难点：复制服务器需完全相同、客户端和服务端崩溃、网络分区

一致性和性能是对立的

MapReduce

简述：

map/shuffle/reduce

master给workers分配任务，输入被分成M份（M个map task，M比worker多），每份有3个备份；对每份输入调用Map()，产出(k2,v2)的中间结果，在本地Hash成R份，传递给R个Reduce()，每个Reduce task写一个结果文件

隐藏的细节：

跟踪task的完成情况、数据移动、错误恢复

好的负载均衡：

tasks比workers多，workers完成task后master继续给它分配

容错：

某个服务器在运行MR任务时崩溃，只需重新运行相应的Map和Reduce而不用整个任务重新运行；

这依赖Map和Reduce是纯函数，即：

不保存状态、

不读写额外的文件、

没有task间隐藏的通信

崩溃恢复：

Map worker崩溃：

重新给包含该输入的副本的worker分配该task（可能一些Reduce worker已经读取了该Map的部分输入，不要紧，Map是纯函数）；

如果该Map的中间结果都已被读取，则不用重新运行

Reduce worker崩溃：

该worker已运行完的task不用重新运行（结果已存到GFS）

只需重新运行未完成的task

如果Reduce worker写数据中途崩溃，不要紧，GFS会在写入完成时才重命名文件，所以相当于原子操作，未写入完成可重新运行

其他问题：

给两个worker分配了同样的Map task — 只会告诉Reduce worker其中的一个；

给两个worker分配了同意的Reduce task — GFS的原子写入操作可解决