搜索
of56电子工业出版社《云计算(第三版)》配套课件云计算（第三版）CLOUDCOMPUTINGThirdEdition第2章Google云计算原理与应用（二）of56《云计算》第三版配套PPT课件目录目录2.1Google文件系统GFS2.2分布式数据处理MapReduce2.3分布式锁服务Chubby2.4分布式结构化数据表Bigtable2.5分布式存储系统Megastore2.6大规模分布式系统的监控基础架构Dapper2.7海量数据的交互式分析工具Dremel2.8内存大数据分析系统PowerDrill2.9Google应用程序引擎of56《云计算》第三版配套PPT课件初步了解ChubbyChubby是Google设计的提供粗粒度锁服务的一个文件系统，它基于松耦合分布式系统，解决了分布的一致性问题。通过使用Chubby的锁服务，用户可以确保数据操作过程中的一致性Chubby作为一个稳定的存储系统存储包括元数据在内的小数据Google内部还使用Chubby进行名字服务（NameServer）32.3分布式锁服务Chubbyof56《云计算》第三版配套PPT课件2.3分布式锁服务Chubby2.3.1Paxos算法2.3.2Chubby系统设计2.3.3Chubby中的Paxos2.3.4Chubby文件系统2.3.5通信协议2.3.6正确性与性能of56《云计算》第三版配套PPT课件Paxos算法proposersacceptorslearners提出决议批准决议获取并使用已经通过的决议三个节点决议只有在被proposers提出后才能批准每次只批准一个决议只有决议确定被批准后learners才能获取这个决议三个条件52.3分布式锁服务Chubbyof56《云计算》第三版配套PPT课件系统的约束条件p1：每个acceptor只接受它得到的第一个决议。p2：一旦某个决议得到通过，之后通过的决议必须和该决议保持一致。p2a：一旦某个决议v得到通过，之后任何acceptor再批准的决议必须是v。p2b：一旦某个决议v得到通过，之后任何proposer再提出的决议必须是v。p2c：如果一个编号为n的提案具有值v，那么存在一个“多数派”，要么它们中没有谁批准过编号小于n的任何提案，要么它们进行的最近一次批准具有值v。为了保证决议的唯一性，acceptors也要满足一个约束条件：当且仅当acceptors没有收到编号大于n的请求时，acceptors才批准编号为n的提案。62.3分布式锁服务Chubbyof56《云计算》第三版配套PPT课件7一个决议分为两个阶段准备阶段12批准阶段proposers选择一个提案并将它的编号设为n将它发送给acceptors中的一个“多数派”acceptors收到后，如果提案的编号大于它已经回复的所有消息，则acceptors将自己上次的批准回复给proposers，并不再批准小于n的提案。当proposers接收到acceptors中的这个“多数派”的回复后，就向回复请求的acceptors发送accept请求，在符合acceptors一方的约束条件下，acceptors收到accept请求后即批准这个请求。2.3分布式锁服务Chubbyof56《云计算》第三版配套PPT课件2.3分布式锁服务Chubby2.3.1Paxos算法2.3.2Chubby系统设计2.3.3Chubby中的Paxos2.3.4Chubby文件系统2.3.5通信协议2.3.6正确性与性能of56《云计算》第三版配套PPT课件5469Chubby的设计目标主要有以下几点高可用性和高可靠性213高扩展性支持粗粒度的建议性锁服务服务信息的直接存储支持通报机制支持缓存机制2.3分布式锁服务Chubbyof56《云计算》第三版配套PPT课件客户端应用程序客户端应用程序Chubby程序率Chubby程序率…远程过程调用Chubby单元的五个服务器主服务器客户端进程10Chubby的基本架构在客户这一端每个客户应用程序都有一个Chubby程序库（ChubbyLibrary），客户端的所有应用都是通过调用这个库中的相关函数来完成的。服务器一端称为Chubby单元，一般是由五个称为副本（Replica）的服务器组成的，这五个副本在配置上完全一致，并且在系统刚开始时处于对等地位。客户端服务器端2.3分布式锁服务Chubbyof56《云计算》第三版配套PPT课件2.3分布式锁服务Chubby2.3.1Paxos算法2.3.2Chubby系统设计2.3.3Chubby中的Paxos2.3.4Chubby文件系统2.3.5通信协议2.3.6正确性与性能of56《云计算》第三版配套PPT课件副本网络Chubby客户端网络Chubby协议快照互换（Sanpshotexchange）Paxos协议本地文件系统日志文件I/O快照容错的日志（Fault-tolerantLog）容错的数据库（Fault-tolerantDB）ChubbyRPC12单个Chubby副本结构文件传输2.3分布式锁服务Chubbyof56《云计算》第三版配套PPT课件副本1副本2副本3值值值响应响应响应值提交客户端应用程序Paxos构架Paxos协议13容错日志的API2.3分布式锁服务Chubbyof56《云计算》第三版配套PPT课件2.3分布式锁服务Chubby2.3.1Paxos算法2.3.2Chubby系统设计2.3.3Chubby中的Paxos2.3.4Chubby文件系统2.3.5通信协议2.3.6正确性与性能of56《云计算》第三版配套PPT课件15单调递增的64位编号实例号InstanceNumber新节点实例号必定大于旧节点的实例号。1锁生成号LockGenerationNumber锁被用户持有时该号增加。内容生成号ContentGenerationNumber文件内容修改时该号增加。23ACL生成号ACLGenerationNumberACL名被覆写时该号增加。42.3分布式锁服务Chubbyof56《云计算》第三版配套PPT课件函数名称作用Open()打开某个文件或者目录来创建句柄Close()关闭打开的句柄，后续的任何操作都将中止Poison()中止当前未完成及后续的操作，但不关闭句柄GetContentsAndStat()返回文件内容及元数据GetStat()只返回文件元数据ReadDir()返回子目录名称及其元数据SetContents()向文件中写入内容SetACL()设置ACL名称Delete()如果该节点没有子节点的话则执行删除操作Acquire()获取锁Release()释放锁GetSequencer()返回一个sequencerSetSequencer()将sequencer和某个句柄进行关联CheckSequencer()检查某个sequencer是否有效16常用的句柄函数及作用2.3分布式锁服务Chubbyof56《云计算》第三版配套PPT课件2.3分布式锁服务Chubby2.3.1Paxos算法2.3.2Chubby系统设计2.3.3Chubby中的Paxos2.3.4Chubby文件系统2.3.5通信协议2.3.6正确性与性能of56《云计算》第三版配套PPT课件18Chubby客户端与服务器端的通信过程2.3分布式锁服务Chubbyof56《云计算》第三版配套PPT课件19可能出现的两种故障2.3分布式锁服务Chubby客户端租约过期主服务器出错12of56《云计算》第三版配套PPT课件2.3分布式锁服务Chubby2.3.1Paxos算法2.3.2Chubby系统设计2.3.3Chubby中的Paxos2.3.4Chubby文件系统2.3.5通信协议2.3.6正确性与性能of56《云计算》第三版配套PPT课件21一致性2.3分布式锁服务Chubby正确性与性能每个Chubby单元是由五个副本组成的，这五个副本中需要选举产生一个主服务器，这种选举本质上就是一个一致性问题安全性采用的是ACL形式的安全保障措施。只要不被覆写，子节点都是直接继承父节点的ACL名性能优化提高主服务器默认的租约期、使用协议转换服务将Chubby协议转换成较简单的协议、客户端一致性缓存等of56《云计算》第三版配套PPT课件22Chubby的ACL机制2.3分布式锁服务Chubby用户chinacloud提出向文件CLOUD中写入内容的请求。CLOUD首先读取自身的写ACL名fun，接着在fun中查到了chinacloud这一行记录，于是返回信息允许chinacloud对文件进行写操作，此时chinacloud才被允许向CLOUD写入内容。其他的操作和写操作类似。of56《云计算》第三版配套PPT课件目录目录2.1Google文件系统GFS2.2分布式数据处理MapReduce2.3分布式锁服务Chubby2.4分布式结构化数据表Bigtable2.5分布式存储系统Megastore2.6大规模分布式系统的监控基础架构Dapper2.7海量数据的交互式分析工具Dremel2.8内存大数据分析系统PowerDrill2.9Google应用程序引擎23of56《云计算》第三版配套PPT课件2.4分布式结构化数据表Bigtable2.4.1设计动机与目标2.4.2数据模型2.4.3系统架构2.4.4主服务器2.4.5子表服务器2.4.6性能优化of56《云计算》第三版配套PPT课件252.4分布式结构化数据表BigtableBigtable的设计动机123需要存储的数据种类繁多海量的服务请求商用数据库无法满足需求包括URL、网页内容、用户的个性化设置在内的数据都是Google需要经常处理的Google运行着目前世界上最繁忙的系统，它每时每刻处理的客户服务请求数量是普通的系统根本无法承受的一方面现有商用数据库的设计着眼点在于其通用性。另一方面对于底层系统的完全掌控会给后期的系统维护、升级带来极大的便利of56《云计算》第三版配套PPT课件262.4分布式结构化数据表BigtableBigtable应达到的基本目标广泛的适用性很强的可扩展性高可用性简单性Bigtable是为了满足一系列Google产品而并非特定产品的存储要求。根据需要随时可以加入或撤销服务器确保几乎所有的情况下系统都可用底层系统的简单性既可以减少系统出错的概率，也为上层应用的开发带来便利of56《云计算》第三版配套PPT课件2.4分布式结构化数据表Bigtable2.4.1设计动机与目标2.4.2数据模型2.4.3系统架构2.4.4主服务器2.4.5子表服务器2.4.6性能优化of56《云计算》第三版配套PPT课件28Bigtable数据的存储格式2.4分布式结构化数据表BigtableBigtable是一个分布式多维映射表，表中的数据通过一个行关键字（RowKey）、一个列关键字（ColumnKey）以及一个时间戳（TimeStamp）进行索引Bigtable的存储逻辑可以表示为：(row:string,column:string,time:int64)→stringof56《云计算》第三版配套PPT课件292.4分布式结构化数据表Bigtable行列时间戳Bigtable的行关键字可以是任意的字符串，但是大小不能够超过64KB表中数据都是根据行关键字进行排序的，排序使用的是词典序同一地址域的网页会被存储在表中的连续位置倒排便于数据压缩，可以大幅提高压缩率将其组织成所谓的列族（ColumnFamily）族名必须有意义，限定词则可以任意选定组织的数据结构清晰明了，含义也很清楚族同时也是Bigtable中访问控制（AccessControl）的基本单元Bigtable中的时间戳是64位整型数，具体的赋值方式可以用户自行定义Google的很多服务比如网页检索和用户的个性化设置等都需要保存不同时间的数据，这些不同的数据版本必须通过时间戳来区分。of56《云计算》第三版配套PPT课件2.4分布式结构