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的原子写入操作可解决