《云计算(第二版)》教材配套课件3—第二章Google云计算原理与应用(2).ppt

压缩 ?压缩 ?压缩可以有效地节省空间，Bigtable中的压缩被应用于很多场合 ?首先压缩可以被用在构成局部性群组的SSTable中，可以选择是否对个人的局部性群组的SSTable进行压缩。这种压缩是对每个局部性群组独立进行，虽然会浪费一些空间，但是在需要读时解压速度非常快 ?通常情况下，用户可以采用两步压缩的方式： ?第一步利用Bentley McIlroy方式（BMDiff）在大的扫描窗口将常见的长串进行压缩；第二步采取Zippy技术进行快速压缩，它在一个16KB大小的扫描窗口内寻找重复数据，这个过程非常快 ?压缩技术还可以提高子表的恢复速度，当某个子表服务器停止使用后，需要将上面所有的子表移至另一个子表服务器。转移前两次压缩：第一次压缩减少了提交日志中未压缩状态；文件正式转移前还要进行一次压缩，主要是将第一次压缩后遗留的未压缩空间进行压缩 布隆过滤器（Bloom Filter） ?布隆过滤器（Bloom Filter） ?巴顿·布隆在1970年提出的，实际上它是一个很长的二进制向量和一系列随机映射函数，在读操作中确定子表的位置时非常有用 ?优势：速度快，省空间。而且它有一个最大的好处是它绝不会将一个存在的子表判定为不存在 ?缺点：在某些情况下它会将不存在的子表判断为存在。不过这种情况出现的概率非常小，跟它带来的巨大好处相比这个缺点是可以忍受的 目前包括Google Analytics、Google Earth、个性化搜索、Orkut和RRS阅读器在内几十个项目都使用Bigtable。这些应用对Bigtable的要求以及使用的集群机器数量都各不相同，但从实际运行来看，Bigtable完全可以满足这些不同需求的应用，而这一切都得益于其优良的构架以及恰当的技术选择 《云计算（第二版）》购买网址： 当当网：/product.aspx?product_id京东商城：html * * 故障处理 客户端租约过期 ?客户端向主服务器发出一个KeepAlive请求（上图1） ?如果有需要通知的事件时则主服务器会立刻做出回应，否则等到客户端的租约期C1快结束的时候才做出回应（图2），并更新主服务器租约期为M2 ?客户端接到回应后认为该主服务器仍处于活跃状态，于是将租约期更新为C2并立刻发出新的KeepAlive请求（图3） ?宽限期内，客户端不会立刻断开其与服务器端的联系，而是不断地做探询，当它接到客户端的第一个KeepAlive请求（图4）时会拒绝（图5） ?客户端在主服务器拒绝后使用新纪元号来发送KeepAlive请求（图6） ?新的主服务器接受这个请求并立刻做出回应（图7） 如果客户端接收到这个回应的时间仍处于宽限期内，系统会恢复到安全状态，租约期更新为C3。如果在宽限期未接到主服务器的相关回应，客户端终止当前的会话 故障处理 主服务器出错 正常情况下旧的主服务器出现故障后系统会很快地选举出新的主服务器，新选举需要经历以下九个步骤： （1）产生一个新的纪元号以便今后客户端通信时使用，这能保证当前的主服务器不必处理针对旧的主服务器的请求 （2）只处理主服务器位置相关的信息，不处理会话相关的信息 （3）构建处理会话和锁所需的内部数据结构 （4）允许客户端发送KeepAlive请求，不处理其他会话相关的信息 （5）向每个会话发送一个故障事件，促使所有的客户端清空缓存 （6）等待直到所有的会话都收到故障事件或会话终止 （7）开始允许执行所有的操作 （8）如果客户端使用了旧的句柄则需要为其重新构建新的句柄 （9）一定时间段后（1分钟），删除没有被打开过的临时文件夹 如果这一过程在宽限期内顺利完成，则用户不会感觉到任何故障的发生，也就是说新旧主服务器的替换对于用户来说是透明的，用户感觉到的仅仅是一个延迟 ?系统实现时，Chubby还使用了一致性客户端缓存（Consistent Client-Side Caching）技术，这样做的目的是减少通信压力，降低通信频率 ?在客户端保存一个和单元上数据一致的本地缓存，需要时客户可以直接从缓存中取出数据而不用再和主服务器通信 ?当某个文件数据或者元数据需要修改时，主服务器首先将这个修改阻塞；然后通过查询主服务器自身维护的一个缓存表，向对修改的数据进行了缓存的所有客户端发送一个无效标志（Invalidation） ?客户端收到这个无效标志后会返回一个确认（Acknowledge），主服务器在收到所有的确认后才解除阻塞并完成这次修改 这个过程的执行效率非常高，仅仅需要发送一次无效标志即可，因为对于没有返回确认的节点，主服务器直接认为其是未缓存 分布