云计算的原理
并行计算模式
Master-Slave worker
把编程分为两部分
- Worker部分来实行对数据的处理
- Master负责其余工作，包含对数据对切分、对worker对拷贝，然后分配worker的参数，接收返回参数
GFS设计思路
- 将文件划分为若干Chunk存储
- 通过冗余提高可靠性
- 通过单个master来协调数据访问、元数据存储
-
GFS架构
单一Master，若干ChunkServer（单一Master意味着集中式，不存在元数据的一致性问题）
GFS容错机制
Chunk Server容错
每个Chunk有多个存储副本。
每个Chunk划分为若干Block，用校验码保证正确，若错误则转移至其他Chunk副本。
Master容错（影子节点热备份）
采用多个影子Master节点进行热备份，一旦主节点损坏，立即选举一个新的主节点服务
三类元数据：命名空间、Chunk与文件名的映射以及Chunk副本的位置信息
- 前两类通过日志提供容错，Chunk副本信息存储于Chunk Server，Master出现故障时可恢复。
MapReduce
MapReduce处理流程中各类文件的存储位置在哪里？
源文件：GFS
Map处理结果：本地存储
Reduce处理结果：GFS
日志：GFS
MapReduce的容错方法？
Worker故障
- Master周期性的ping每个worker。如果master在一个确定的时间段内没有收到worker返回的信息，则将该worker标记为失效
- 重新执行该节点上已经执行或尚未执行的Map任务（因Map处理结果存在本地，看不到）
重新执行该节点上未完成的Reduce任务，已完成的不必再执行（Reduce结果存在GFS，全都能看到）
Master故障
任务备份机制
慢的worker会严重拖延整个执行完成的时间
- 解决方案：临近结束的时候，启动多个进程来执行尚未完成的任务（谁先完成，就算谁）
-
MapReduce的处理优化方法？
本地处理
Master调度策略：
向GFS询问获得输入文件blocks副本的位置信息
- Map tasks的输入数据通常按64MB来划分（GFS Block大小）
- 按照blocks所在的机器或机器所在的机架的范围进行调度
效果：
-
跳过有问题的记录
一些特定的输入数据常导致Map/Reduce无法运行
- 最好的解决方法是调试或者修改
- 在每个Worker里运行一个信号处理程序，捕获map或reduce任务崩溃时发出的信号，一旦捕获，就会向master报告，同时报告输入记录的编号信息。如果master看到一条记录有两次崩溃信息，那么就会对该记录进行标记，下次运行的时候，跳过该记录。
MapReduce仅能对GFS之上的文件进行处理吗？
Chubby
粗粒度的分布式锁服务
- Chubby是Google为解决分布式一致性问题而设计的提供粗颗粒锁服务的文件系统
- 其他分布式系统可以使用它对共享资源的访问进行同步
-
如何解决分布式一致性问题
在一个分布式系统中，有一组Process，它们需要确定一个Value。于是每个Process都提出一个Value。
- 一致性就是指：只有其中的一个Value能够被选中作为最后确定的值，并且当这个值被选出来以后，所有的Process都需要被通知到
Chubby的设计目标
需要实现的特性
Chubby文件系统
Chubby系统本质上就是一个分布式的、存储大量小文件的文件系统
- Chubby中的锁就是文件
- 在GFS的例子中，创建文件就是进行“加锁”操作，创建文件成功的那个Server其实就是抢占到了“锁”
用户通过打开、关闭和存取文件，获取共享锁或独占锁；并且通过通信机制，向用户发送更新信息
Chubby的应用
主节点选举
- 独占锁
- 共享锁
- 数据存取应用（获取GFS Chunk Server信息和元数据存储）
BigTable（GFS的上层封装）
基于GFS和Chubby的分布式存储系统
若有收获，就点个赞吧
0 人点赞
