2014年《云计算(第二版)》—第二章 Google云计算原理与应用(2.pptVIP

电子工业出版社《云计算(第二版)》配套课件解放军理工大学刘鹏教授主编华东交通大学刘鹏制作第2章Google云计算原理与应用《云计算（第二版）》购买网址：当当网京东商城姊妹力作《实战Hadoop》购买网址：当当网京东商城提纲Google文件系统GFS分布式数据处理MapReduce分布式锁服务Chubby分布式结构化数据表Bigtable分布式存储系统Megastore大规模分布式系统的监控基础架构DapperGoogle应用程序引擎分布式结构化数据表Bigtable设计动机与目标数据模型系统架构主服务器子表服务器性能优化主服务器当一个新子表产生时，主服务器通过一个加载命令将其分配给一个空间足够的子表服务器。创建新表、表合并以及较大子表的分裂都会产生一个或多个新子表。对于前面两种，主服务器会自动检测到，而较大子表的分裂是由子服务发起并完成的，所以主服务器并不能自动检测到，因此在分割完成之后子服务器需要向主服务发出一个通知由于系统设计之初就要求能达到良好的扩展性，所以主服务器必须对子表服务器的状态进行监控，以便及时检测到服务器的加入或撤销Bigtable中主服务器对子表服务器的监控是通过Chubby完成的——子表服务器在初始化时都会从Chubby中得到一个独占锁。通过这种方式所有子表服务器基本信息被保存在Chubby中一个称为服务器目录（ServerDirectory）的特殊目录之中主服务器主服务器会定期向其询问独占锁的状态。如果子表服务器的锁丢失或没有回应，则此时可能有两种情况要么是Chubby出现了问题（虽然这种概率很小，但的确存在，Google自己也做过相关测试）要么是子表服务器自身出现了问题。对此主服务器首先自己尝试获取这个独占锁，如果失败说明Chubby服务出现问题，需等待恢复；如果成功则说明Chubby服务良好而子表服务器本身出现了问题当在状态监测时发现某个子表服务器上负载过重时，主服务器会自动对其进行负载均衡操作主服务器基于系统出现故障是一种常态的设计理念，每个主服务器被设定了一个会话时间的限制。当某个主服务器到时退出后，管理系统就会指定一个新的主服务器，这个主服务器的启动需要经历以下四个步骤：（1）从Chubby中获取一个独占锁，确保同一时间只有一个主服务器（2）扫描服务器目录，发现目前活跃的子表服务器（3）与所有的活跃子表服务器取得联系以便了解所有子表的分配情况（4）扫描元数据表，发现未分配的子表并将其分配到合适子表服务器如果元数据表未分配，则首先需要将根子表（RootTablet）加入未分配的子表中。由于根子表保存了其他所有元数据子表的信息，确保了扫描能够发现所有未分配的子表分布式结构化数据表Bigtable设计动机与目标数据模型系统架构主服务器子表服务器性能优化SSTable及子表基本结构SSTable是Google为Bigtable设计的内部数据存储格式。所有的SSTable文件都存储在GFS上SSTable中数据被划分成一个个的块（Block），每个块的大小是可以设置的，一般为64KB在SSTable的结尾有一个索引（Index），这个索引保存了块的位置信息，在SSTable打开时这个索引会被加载进内存，用户在查找某个块时首先在内存中查找块的位置信息，然后在硬盘上直接找到这个块由于每个SSTable一般都不是很大，用户还可以选择将其整体加载进内存，这样查找起来会更快SSTable结构子表实际组成每个子表都是由多个SSTable以及日志（Log）文件构成不同子表的SSTable可以共享Bigtable中的日志文件是一种共享日志，每个子表服务器上仅保存一个日志文件，某个子表日志只是这个共享日志的一个片段。这样会节省大量的空间，但在恢复时却有一定的难度Google为了避免这种情况出现，对日志做了一些改进。Bigtable规定将日志的内容按照键值进行排序，这样不同的子表服务器都可以连续读取日志文件了一般来说每个子表的大小在100MB到200MB之间。每个子表服务器上保存的子表数量可以从几十到上千不等，通常情况下是100个左右子表地址结构子表地址的查询是经常碰到的操作。在Bigtable系统的内部采用的是一种类似B+树的三层查询体系所有子表地址都被记录在元数据表中，元数据表也是由一个个的元数据子表（Metadatatablet）组成根子表是元数据表中一个比较特殊的子表，它既是元数据表的第一条记录，也包含了其他元数据子表的地址，同时Chubby中的一个文件也存储了这个根子表的信息。查询时，首先从Chubby中提取这个根子表的地址，进而读取所需的元数据子表的位置，最后就可以从元数据子表中找到待查询的子表。除了这些子表的元数据之外，元数据表中还保存了