Google云计算原理-分布式锁服务Chubby综述.ppt

分布式锁服务Chubby;*;试图由以下三点来保证数据的一致性: （1）决议只有被proposers提出后才能批准 （2）每次只批准一个决议 （3）只有决议确定被批准后learners才能获取这个决议;决议通过的两个阶段： 准备阶段：proposers选择一个提案并将它的编号设为n，然后将它发送给acceptors中的一个“多数派”。Acceptors收到后，如果提案的编号大于它已经回复的所有消息，则acceptors将自己上次的批准回复给proposers，并不再批准小于n的提案? 批准阶段：当proposers接收到acceptors 中的这个“多数派”的回复后，就向回复请求的acceptors发送accept请求，在符合acceptors一方的约束条件下，acceptors收到accept请求后即批准这个请求? 解决一致性问题算法：为了减少决议发布过程中的消息量，acceptors将这个通过的决议发送给learners的一个子集，然后由这个子集中的learners去通知所有其他的learners； 特殊情况：如果两个proposer在这种情况下都转而提出一个编号更大的提案，那么就可能陷入活锁。此时需要选举出一个president，仅允许 president提出提案;Chubby中还添加了一些新的功能特性；这种设计主要是考虑到以下几个问题: 1、开发者初期很少考虑系统的一致性，但随着开发进行，问题会变得越来越严重。单独的锁服务可以保证原有系统架构不会发生改变，而使用函数库很可能需要对系统架构做出大幅度的改动 2、系统中很多事件发生是需要告知其他用户和服务器，使用一个基于文件系统的锁服务可以将这些变动写入文件中。有需要的用户和服务器直接访问这些文件即可，避免因大量系统组件之间事件通信带来系统性能下降 3、基于锁的开发接口容易被开发者接受。虽然在分布式系统中锁的使用会有很大的不同，但是和一致性算法相比，锁显然被更多的开发者所熟知 ;Paxos算法实现过程中需要一个“多数派”就某个值达成一致，本质上就是分布式系统中常见的quorum机制；为保证系统高可用性，需要若干台机器，但使用单独锁服务的话一台机器也能保证这种高可用性 Chubby设计过程中一些细节问题值得关注： 在Chubby系统中采用了建议性的锁而没有采用强制性的锁。两者的根本区别在于用户访问某个被锁定的文件时，建议性的锁不会阻止访问，而强制性的锁则会阻止访问，实际上这是为了方便系统组件之间的信息交互 另外，Chubby还采用了粗粒度（Coarse-Grained）锁服务而没有采用细粒度（Fine-Grained）锁服务，两者的差异在于持有锁的时间，细粒度的锁持有时间很短 ;Chubby系统本质上就是一个分布式的、存储大量小文件的文件系统，它所有的操作都是在文件的基础上完成 ?Chubby最常用的锁服务中，每一个文件就代表一个锁，用户通过打开、关闭和读取文件，获取共享（Shared）锁或独占（Exclusive）锁 ?选举主服务器过程中，符合条件的服务器都同时申请打开某个文件并请求锁住该文件 ?成功获得锁的服务器自动成为主服务器并将其地址写入这个文件夹，以便其他服务器和用户可以获知主服务器的地址信息 ;;;?每个Chubby单元是由五个副本组成的，这五个副本中需要选举产生一个主服务器，这种选举本质上就是一个一致性问题。实际执行过程中，Chubby使用Paxos算法来解决 ?? ? ?主服务器产生后客户端的所有读写操作都是由主服务器来完成的 ?a读操作很简单，客户直接从主服务器上读取所需数据即可 ?a写操作就会涉及数据一致性的问题；为了保证客户的写操作能够同步到所有的服???器上，系统再次利用了Paxos算法;;需要实现的特性 高可用性 高可靠性 支持粗粒度的建议性锁服务 支持小规模文件直接存储 不作考虑的特性 高性能 存储能力;;;Chubby系统本质上就是一个分布式的、存储大量小文件的文件系统 Chubby中的锁就是文件 在GFS的例子中，创建文件就是进行“加锁”操作，创建文件成功的那个server其实就是抢占到了“锁” 用户通过打开、关闭和存取文件，获取共享锁或者独占锁；并且通过通信机制，向用户发送更新信息 ;;主节点选举 独占锁 共享锁 数据存取应用 获取GFS ChunkServer信息 元数据存储 ……