《云计算(第三版)》第2章_Google云计算原理与应用(二)探索.pptVIP

第 2 章 Google云计算原理与应用（二） 目 录 2.1 Google文件系统GFS 2.2 分布式数据处理MapReduce 2.3 分布式锁服务Chubby 2.4 分布式结构化数据表Bigtable 2.5 分布式存储系统Megastore 2.6 大规模分布式系统的监控基础架构Dapper 2.7 海量数据的交互式分析工具Dremel 2.8 内存大数据分析系统PowerDrill 2.9 Google应用程序引擎 初步了解Chubby Chubby是Google设计的提供粗粒度锁服务的一个文件系统，它基于松耦合分布式系统，解决了分布的一致性问题。 通过使用Chubby的锁服务，用户可以确保数据操作过程中的一致性 Chubby作为一个稳定的存储系统存储包括元数据在内的小数据 Google内部还使用Chubby进行名字服务（Name Server） 3 2.3 分布式锁服务Chubby Paxos算法 Paxos算法 ?Leslie Lamport最先提出的一种基于消息传递（Messages Passing）的一致性算法，用于解决分布式系统中的一致性问题 分布式系统一致性问题——就是如何保证系统中初始状态相同的各个节点在执行相同的操作序列时，看到的指令序列是完全一致的，并且最终得到完全一致的结果 一个最简单的方案——在分布式系统中设置一个专门节点，在每次需要进行操作之前，系统的各个部分向它发出请求，告诉该节点接下来系统要做什么。该节点接受第一个到达的请求内容作为接下来的操作，这样就能够保证系统只有一个唯一的操作序列 方案存在什么缺陷？ Paxos算法 缺陷——专门节点失效，整个系统就很可能出现不一致。为了避免这种情况，在系统中必然要设置多个专门节点，由这些节点来共同决定操作序列 Paxos算法 ?proposers提出决议（Value，系统接下来执行的指令） ?acceptors批准决议 ?learners获取并使用已经通过的决议 2.3 分布式锁服务Chubby 2.3.1 Paxos算法 2.3.2 Chubby系统设计 2.3.3 Chubby中的Paxos 2.3.4 Chubby文件系统 2.3.5 通信协议 2.3.6 正确性与性能 Paxos算法 proposers acceptors learners 提出决议 批准决议 获取并使用已经通过的决议 三类节点 决议只有在被proposers提出后才能批准 每次只批准一个决议 只有决议确定被批准后learners才能获取这个决议 三个条件 7 2.3 分布式锁服务Chubby 系统的约束条件 p1：每个acceptor只接受它得到的第一个决议。 p2：一旦某个决议得到通过，之后通过的决议必须和该决议保持一致。 p2a：一旦某个决议v得到通过，之后任何acceptor再批准的决议必须是v。 p2b：一旦某个决议v得到通过，之后任何proposer再提出的决议必须是v。 p2c：如果一个编号为n的提案具有值v，那么存在一个“多数派”，要么它们中没有谁批准过编号小于n的任何提案，要么它们进行的最近一次批准具有值v。 为了保证决议的唯一性，acceptors也要满足一个约束条件：当且仅当 acceptors 没有收到编号大于n的请求时，acceptors 才批准编号为n的提案。 8 2.3 分布式锁服务Chubby 9 一个决议分为两个阶段 准备阶段 1 2 批准阶段 proposers选择一个提案并将它的编号设为n 将它发送给acceptors中的一个“多数派” acceptors 收到后，如果提案的编号大于它已经回复的所有消息，则acceptors将自己上次的批准回复给proposers，并不再批准小于n的提案。 当proposers接收到acceptors 中的这个“多数派”的回复后，就向回复请求的acceptors发送accept请求，在符合acceptors一方的约束条件下，acceptors收到accept请求后即批准这个请求。 2.3 分布式锁服务Chubby 2.3 分布式锁服务Chubby 2.3.1 Paxos算法 2.3.2 Chubby系统设计 2.3.3 Chubby中的Paxos 2.3.4 Chubby文件系统 2.3.5 通信协议 2.3.6 正确性与性能 11 Chubby的设计目标主要有以下几点 高可用性和高可靠性 高扩展性 支持粗粒度的建议性锁服务 服务信息的直接存储 支持通报机制 支持缓存机制 2.3 分布式锁服务Chubby 系统设计目标 Chubby系统设计 高可用性和高可靠性；首要目标，在保证这一目标的基础上再考虑系统的吞吐量和存储能力 高扩展性；将数据存储在价格较