《基于分布式系统的粗粒度锁服务chubby》由会员分享，可在线阅读，更多相关《基于分布式系统的粗粒度锁服务chubby（29页珍藏版）》请在金锄头文库上搜索。
1、基于分布式系统的粗粒度锁服务ChubbyCNDS小组2008-5-26 目录o系统简介n系统介绍n系统目标n系统结构o系统实现o系统例子系统介绍o提供粗粒度的锁服务o基于松耦合分布式系统设计可靠的存储o建议性的锁，具有更大的灵活性o软件开发者不需要使用复杂的同步协议，而 是直接在程序中调用chubby的锁服务，来 保证数据操作的一致性。系统目标o支持粗粒度的锁服务n基于松耦合分布式系统的可靠存储，提供粗粒度锁服务o高可用性和高可靠性n保证锁服务的高可用性和高可靠性n提供基本的可用性、吞吐量和存储能力o直接存储服务信息n提供档案文件，存储服务的参数及相关信息n不需要建立并维护另一个服务o高扩展性
2、n在RAM中存储数据，支持大规模用户访问文件 系统目标o通报机制n通过通报机制，定期向客户端发送更新消息o缓存机制n利用缓存保存文件，避免频繁访问主服务器n使用一致性缓存，避免数据出错系统结构目录o系统简介o系统实现n“文件系统”n基于ICE的Chubby通信机制n客户端与主服务器通信n锁机制n服务器间的一致性操作n系统现状o系统例子“文件系统”o负责提供底层的文件操作函数o支持文件读写等操作o类似于UNIX文件系统结构o由Node构成，代表文件或目录oBerkeley DB保存Node数据基本操作日志操作（未使用）基于ICE的Chubby通信机制oICE Core包括客户端与服务器端的一些远
3、程过程调用的运 行时刻支持。o代理代码(proxy code)是根据ICE的Specification Language for ICE (slice)文件生成代码的扩展。o客户端的Proxy code和服务器端的adapter code是相互对 应的：前者负责发送，后者负责接收。AMIo一种ICE提供给客户端的异步编程模型o调用RPC之后，客户端无需等待服务器端的 返回就可以继续执行后续语句；操作结果通 过Callback机制实现oChubby系统通过AMI方法实现：n锁操作与文件操作的非互斥性n系统底层大量使用非阻塞性的RPCAMD o一种ICE提供给服务器端的异步编程模型o服务器端先将R
4、PC的callback函数挂起o经过一段时间延时(运行需求)后才被取出处 理并返回o主要应用于Chubby系统的服务器端n这种RPC往往不是立刻需要服务器端返回n等进行必要的处理后才返回结果客户端与主服务器通信 oChubby 会话用来保持主服务器与客户端之 间的联系o每段会话持续一段时间，通过keep alive的 握手机制维持o除非chubby客户端通知主服务器，否则在 会话有效期间，客户端的句柄，锁服务和缓 存数据一直维持有效o保持有效和出错回调是客户端和主服务器通 信的重点 客户端与主服务器通信 o正常情况o客户端租约过期o主服务器租约过期o主服务器出错客户端与主服务器通信o数据结构n
5、Session和lease维持客户端与服务器端通信nLease通过定期的发送keep-alive RPC来保持 Client和Master的连接nSession在两端的作用规则并不同oClient端的CSessionoMaster端的SSessionCSession类o处理Master发送过来的KeepAlive消息o使用KeepAlive的Callback函数处理消息n普通的KeepAlive消息n普通的KeepAlive消息以外的事件通知o文件内容被修改o添加、删除、修改子节点nMaster Fail-over后重建立与Master的连接SSession类 o为每个连接的Client设置一
6、个session并且 保存client打开的文件handleoSSession处理client的keep-alive消息： 如果client超时，则调用Master的处理函数 ；同时也支持对事件机制提供支持o将client打开的handle保存在session，根 据client很容易定位到其打开的handle锁机制 oChubby系统使用锁是建议性而非强制性o因此，即使一个进程对一个File Node”上了 锁“，也无法阻止其他进程（假设没有权限 问题）对该文件进行操作。oChubby中的锁对应于一个File Node，但 File Node只相当于这个锁的名字。事实上 ，如果没有保存信息的
7、需求，完全可以不需 要File Node。o目前只实现了互斥锁锁机制o对每个file node，可以有多个进程同时进 行锁请求o如果有多个锁请求，后到达的请求将会被加 入到该文件的锁等待队列中等待。o直到当前锁被释放，才可以从等待队列取出 最先到达的请求，replicate到副本服务器 上，并根据replicate的结果决定是否同意 锁请求，转换文件的锁状态 锁机制o应用程序采用分布式锁编程，需参考以下场 景：n锁请求在服务器端被序列化n有一个锁请求先到达并且占用File Noden当File Node被某个进程锁住o其他进程的锁请求会被阻塞，可以读File Node已 获得当前锁进程的信息o
8、等锁被释放，新进程可以获得锁o在File Node中添加自己的信息选举Master，建立视图使用Paxos made practical中的方法，不 再赘述。主要的工程量是如何使 用ICE的AMI和AMD机 制来实现一些定时与回 调函数。负责各replica之间数据的一致性o采用简单的两阶段提交策略oMaster把改变系统硬数据状态的请求replicate到 副本服务器上，副本服务器对请求进行回复oMaster在收到majority的回复后，发送commit 消息；或者超时后仍然没有达到majority的回复 ，则发送de-commit消息o如果副本服务器lagged，需要在收到master的
9、请 求时，先必须从master获得缺少的请求系统现状o提供ClientStub类，用来支持应用层编程o支持基本的文件及锁请求接口o在client超时后删除临时文件、释放锁o在master fail-over后能还原锁状态（不支持锁请 求队列复制）o支持事件机制o工程代码共有13700多行代码n由ICE自动生成的代码6400余行n手动编写代码8000多行 (?)系统现状o没有经过大量的测试，存在系统或进程突然崩溃和 系统不一致性的风险o功能上只有互斥锁，但共享锁实现起来应该不难o没有复制锁请求到副本服务器上（受ICE Callback 机制限制）o没有实现系统快照的功能，暂时不能将系统状态保 存
10、o使用起来还是有很多不方便的地方目录o系统简介o系统实现o系统例子n选举主服务器n进程监控选举主服务器o每个服务器(进程)都试图打开同一个文件，并且在 该文件中记录自己的服务信息。o任何时刻，只有一个服务器能通过锁请求获得该文 件控制权o获得该文件控制权的服务器就成为主服务器o其他服务器的锁请求被添加到等待队列，可以读取 当前主服务器的信息o如果chubby检测当前主服务器超时死亡，则会释 放锁，并让下一个进程获得锁，成为新的主服务器进程监控 o各个进程都把自己的状态信息记录都指定目 录下的临时文件o监控的进程则通过阅读该目录下的文件信息 来获得进程状态o由于各个进程随时可能死亡，因此该指定目 录的数据状态就会发生变化o通过事件机制通知监控进程，通过事件处理 函数读取该目录下的内容，从而获得新的进 程状态信息 Q & AThank You！
