分布式锁服务-debby的设计与实现

1、分布式锁服务-debby的设计与实现Ifox小组：单栋栋，赵东升， 樊 楷，苏 飞主要内容 Debby系统整体设计 服务器端设计与实现 数据存储的设计与实现 客户端设计与实现 容错日志(paxos)的设计与实现系统的整体结构Debby server实现 服务器和客户端的通信 一致性的保证 文件、目录的实现 Session的实现 事件（Event）管理的实现 SnapShot服务器和客户端的通信 用户调用客户端库于服务器通信 通过ICE远程过程调用实现 提供的接口connect, close, keepAlive,addEventgetData, setData, create, mkdir,

2、remove, isDir, exists .服务器一致性的保证 调用底层Paxos协议 对文件的操作时，把操作提交给Paxos Paxos保证在3台服务器上操作的一致性 Paxos提供的接口sendProposal() Session 的实现 服务器维护一个Debby管理器 Session通过KeepAlive来保证 每个KeepAlive会捎带事件信息 KeepAlive:客户端等待，服务器受到请求立即返回文件、目录的实现 文件、目录放在内存 常规文件系统和临时文件系统 常规文件系统map MemDir 用tree.hh实现 临时文件系统map 事件管理的实现 Debby维护了一个事件管理

3、器 已注册的事件和已发生的事件 对于已注册的事件，系统维护一个事件到handle列表的map 当心跳发生时，将发生的事件返回给订阅的客户SnapShot 只用log恢复服务器带来的问题：日志将会越来越多恢复时间越来越长 本系统采用snapshot(快照)机制解决此问题SnapShot 将内存中的文件系统数据结构直接序列化到磁盘上 Snapshot过程执行成功后，比snapshot备份时间早的log信息不再需要，可通知paxos将log删除。SnapShot SnapShot方法增加了额外的复杂性实现SnapShot之前，crush掉的服务器只需从其他机器获得最近的log即可进行恢复。 实现Sn

4、apShot之后，需同时考虑log和snapshot信息。SnapShot class SnapShot private static string DIR_PATH; public static void serialize(MemDir& md); public MemDir& void Unserialize(); Debby Client00448161APIvoid create(const string &path, bool ephemeral)void mkdir(const string &path)void remove(const stri

5、ng &path)bool exists(const string &path)bool isdir(const string &path)vector list(const string &path)bool lock(const string &path, bool share)void release(const string &path)string read(const string &path)void write(const string &path, const string &content)void r

6、egcb(const string &path, EventType e, shared_ptr cb)void clearcb(const string &path)Lock Server dont support lock directly, client use ephemeral file to implement lock service. When client obtain a lock on file, create filename.lck ephemeral file. If file already exists, server would throw a

7、 exception, and client returns failure. When client release the lock, simply delete the file.Lock(2) When client lose connection with server, ephemeral file is deleted, including those indicate locks, thus locks is released. To prevent ambiguity, user file is not allowed to end with “”, so they are

8、easy to be differentiated from files used to implement locks.Events EventType EventCreated EventRemoved EventChanged EventLockChanged EventArbitrary All event would apply on both directories and filesEvents(2) All callbacks are managed by client, when a callback is first registered on a event, the c

9、lient registers the event on master. When a client receives a event, it invoke all callbacks registered on the event. User could cancel all callbacks on a certain path, and client would unregister events on server.Event(3) Client supply a Callback class to implement use callback, it contains a pure

10、virtual function run(). User implement their own class based on Callback, and implement the run() function. User could save any necessary information in the class. When client invoke a Callback, it create a thread to invoke the run() function.Choose Server There a 5 server in a debby cell, while onl

11、y one of them is the master. Client use ICE multi-endpoints mechanism to find the only master. Client register the address of all 5 servers to ICE, and ICE will try all 5 addresses to automatically find the right server, as long as there is only one master at one time.Grace Period When the master el

12、ection is going on, no service is available, and client must wait for new master to be elected. Use ICE retry mechanism to enable this function, use indicate a retry time series in which ICE will retry connection, for example, 3, 5, 10. We retry connection in 10, 30, 60Paxos Framework Implementfor f

13、ault-tolerance log单栋栋 10748200网络实验室系统结构 Api for fault-tolerant logFrom Paxos made livePaxos normal-case operationclientrequetproposalacceptreply012相当于leader客户的两种提交方式： 1.只能由leader接受请求并提交(我们的做法,chubby) 2.所有服务器都可以接受请求，并把这些请求转给leader，由leader提交。(zookeeper)Paxos消息类型 ViewChangeMessage(选leader) HeartBeatMes

14、sage(leader租约) PrepareMessage(成leader前的内容同步) PrepareOKMessage ProposalMessage(提议) AcceptMessageLeaderElection 何时选leader 系统启动时 检测到当前leader宕机，并已过leader的租约 每次选leader都要提交一个全序的view号 View号的产生 两种选leader的方法 每台服务器只提自己当leader 可以提别的服务器为leader(我们的实现)PreparePhare Leader被选出后，由leader执行，并只执行一次 保证系统安全的过渡 Leader catc

15、h upProposalPhare 由leader发起Proposal 两种proposal 同步proposal，客户提交决议后一直等待，直到决定被完成(有可以失败) 异步proposal，客户提交决议后马上返回，paxos执行完决议后再通知客户 Proposal的限时,重发消息的发送与接收 使用boost的asio库进行网络通讯 采用多播的方式 点对点的catch up使用TCP连接 接受消息使用异步socket 采用多线程 多类型的消息传输实验 向paxos不停的提交proposal，让paxos到保证每台服务器数据的一致性(log) 每台服务器都记log，并且同步写磁盘 对于一个proposal有1秒来还没答成一致，作提交失败处理 总共4组实验，每组各进行3次，每次5000个proposal(在单台机器上模拟) 3台 (运行2台，运行3台) 5台 (运行3台，运行5台)结果1-3台机器机器数(3台)运行时间提交失败数(5000次提交)平均每秒提交数每100失败率只运行2台 99.133050.7次/秒0.02795.1260101.8564运行3台126.893038.95次