《云计算》学习笔记3——Google的云计算原理与应用(分布式锁服务——Chubby).pdf

一、分布式锁服务 今天，要接触有些难理解的知识点了，这也许就是涉及到当时赵致琢老 师强调的在中国没人能有资格讲和讲得清的一块—分布式算法。说实话， 这块看了两遍了，到现在还不敢说自己人懂了一半啊·！ Chubby ØGoogle 设计的提供粗粒度锁服务(???)的一个文件系统，它基于松耦 合分布式系统，解决了分布的一致性问题 ——一种建议性的锁(相信看过《UNIX 环境下高级编程》的人对建议性 的锁这个名词不会陌生)，而不是一种强制性的锁：具有更大的灵活性 ØGFS 使用Chubby 选取一个GFS 主服务器 ØBigtable 使用Chubby 指定一个主服务器并发现、控制与其相关的子 表服务器 ØChubby 还可以作为一个稳定的存储系统存储包括元数据在内的小数 据 ØGoogle 内部还使用Chubby 进行名字服务（Name Server） 想像一下，要在大规模集群的条件下，保证所有指令和数据的一致性（即： 在初始状态相同情况下，要求各结点接收到同样相同指令，且最终状态 一致）会遇到什么样的困难？——这也许正是分布式算法要发挥作用的 境地，很多时候设计的算法根本不可能会是十全十美。Chubby 中即要 用到Paxos 算法 1、Paxos 算法 试想想：该方案存在什么缺陷？？？？ 试图由以下三点来保证数据的一致性: （1）决议只有被proposers 提出后才能批准 （2 ）每次只批准一个决议 （3 ）只有决议确定被批准后learners 才能获取这个决议 系统的约束条件： p1:每个acceptor 只接受它得到的第一个决议 p1 表明每个可以接收到多个决议，为区分，对每个决议进行编号，后得到的决议编号要大 于先到的编号；p1 不是很完备!!(??一个问题可能是：对于每个结点，其收到的所谓第一个 编号是否都是一样？？) P2：一旦某个决议通过，之后通过的决议必须和该决议保持一致 P1+P2——P2a:一旦某个决议V 得到通过，之后任何acceptor 再批准的决议必须是V P2a 和P1 是有矛盾的!(我的理解是：有可能这个V 不是某个结点收到的第一个决议) P2a——》P2b:一旦某个决议V 得到通过，之后任何proposer 再提出的 决议必须是V P1 和P2b 保证条件（2 ），彼此之间不存在矛盾。但是P2b 很难通过 一种技术手段来实现它，因此提出了一个蕴涵P2b 的约束P2c P2b——》P2c:如果一个编号为n 的提案具有值v，那么存在一个“多 数派”，要么它们中没有谁批准过编号小于n 的任何提案，要么它们进 行的最近一次批准具有值v 决议通过的两个阶段： 准备阶段：proposers 选择一个提案并将它的编号设为n，然后将它发送给acceptors 中的 一个―多数派‖。Acceptors 收到后，如果提案的编号大于它已经回复的所有消息，则acceptors 将自己上次的批准回复给proposers，并不再批准小于n 的提案 （那么，可以问问：如果 小于它已经回复的所有消息呢？这个思考之后，对算法的流程就有个印象——但似乎这样 一想，这中间的延迟倒很是个问题，看来，这个算法还是未弄懂！！） 批准阶段：当proposers 接收到acceptors 中的这个―多数派‖的回复后，就向回复请求的 acceptors 发送accept 请求，在符合acceptors 一方的约束条件下，acceptors 收到accept 请求后即批准这个请求 解决一致性问题算法：为了减少决议发布过程中的消息量，acceptors 将这个通过的决议发 送给learners 的一个子集，然后由这个子集中的learners 去通知所有其他的learners； 特殊情况：如果两个proposer 在这种情况下都转而提出一个编号更大的提案，那么就可能 陷入活锁。此时需要选举出一个president，仅允许 president 提出提案 2、Chubby 的系统设计 Chubby 中还添加了一些新的功能特性；这种设计主要是考虑到以下几个问题: 1、开发者初期很少考虑系统的一致性，但随着开发进行，问题会变得越来越严重。单独的 锁服务可以保证原有系统架构不会发生改变，而使用函数库很可能需要对系统架构做出大 幅度的改动 2、系统中很多事件发生是需要告知其他用户和服务器，使用一个基于文件系统的锁服务可 以将这些变动写入文件中。有需要的用户和服务器直接访问这些文件即可，避免因大量系统 组件之间事件通信带来系统性能下降 3、基于锁的开发接口容易被开发者接受。虽然在分布式系统中锁的使用会有很大的不同，