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

分布式锁服务--debby的设计与实现 Ifox小组：单栋栋，赵东升， 樊 楷，苏 飞 主要内容 Debby系统整体设计 服务器端设计与实现 数据存储的设计与实现 客户端设计与实现 容错日志 paxos 的设计与实现 系统的整体结构 Debby server实现 服务器和客户端的通信 一致性的保证 文件、目录的实现 Session的实现 事件（Event）管理的实现 SnapShot 服务器和客户端的通信 用户调用客户端库于服务器通信 通过ICE远程过程调用实现 提供的接口connect, close, keepAlive,addEventgetData, setData, create, mkdir, remove, isDir, exists ... 服务器一致性的保证 调用底层Paxos协议 对文件的操作时，把操作提交给Paxos Paxos保证在3台服务器上操作的一致性 Paxos提供的接口sendProposal ? Session 的实现 服务器维护一个Debby管理器 Session通过KeepAlive来保证 每个KeepAlive会捎带事件信息 KeepAlive:客户端等待，服务器受到请求立即返回 文件、目录的实现 文件、目录放在内存 常规文件系统和临时文件系统 常规文件系统map path, debbyfile MemDir 用tree.hh实现 临时文件系统map handle, path list 事件管理的实现 Debby维护了一个事件管理器 已注册的事件和已发生的事件 对于已注册的事件，系统维护一个事件到handle列表的map 当心跳发生时，将发生的事件返回给订阅的客户 SnapShot 只用log恢复服务器带来的问题： 日志将会越来越多 恢复时间越来越长 本系统采用snapshot 快照 机制解决此问题 SnapShot 将内存中的文件系统数据结构直接序列化到磁盘上 Snapshot过程执行成功后，比snapshot备份时间早的log信息不再需要，可通知paxos将log删除。 SnapShot SnapShot方法增加了额外的复杂性 实现SnapShot之前，crush掉的服务器只需从其他机器获得最近的log即可进行恢复。 实现SnapShot之后，需同时考虑log和snapshot信息。 SnapShot class SnapShot private static string DIR_PATH; public static void serialize MemDir md ; public MemDir void Unserialize ; Paxos Framework Implementfor fault-tolerance log 单栋栋网络实验室 系统结构 Api for fault-tolerant log Paxos normal-case operation Paxos消息类型 ViewChangeMessage 选leader HeartBeatMessage leader租约 PrepareMessage 成leader前的内容同步 PrepareOKMessage ProposalMessage 提议 AcceptMessage LeaderElection 何时选leader 系统启动时 检测到当前leader宕机，并已过leader的租约 每次选leader都要提交一个全序的view号 View号的产生 两种选leader的方法 每台服务器只提自己当leader 可以提别的服务器为leader 我们的实现 PreparePhare Leader被选出后，由leader执行，并只执行一次 保证系统安全的过渡 Leader catch up ProposalPhare 由leader发起Proposal 两种proposal 同步proposal，客户提交决议后一直等待，直到决定被完成 有可以失败 异步proposal，客户提交决议后马上返回，paxos执行完决议后再通知客户 Proposal的限时,重发 消息的发送与接收 使用boost的asio库进行网络通讯 采用多播的方式 点对点的catch up使用TCP连接 接受消息使用异步socket 采用多线程 多类型的消息传输 实验 向paxos不停的提交proposal，让paxos到保证每台服务器数据的一致性 log 每台服务器都记log，并且同步写磁盘 对于一个proposal有1秒来还没答成一致，作提交失败处理 总共4组实验，每组各进行3次，每次5000个proposal 在单台机器上模拟