分布式锁服务算法

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

单栋栋，赵东升，樊楷，苏飞

摘要：

我们实现了一个分布式锁服务系统，并能提供可靠的存储服务。系统的接口非常简单，类似普通文件的接口。我们设计的重点在于系统的可靠性与可用性，而系统的性能放在次要位置。同时我们也实现paxos协议，并用它为整个系统提供可靠容错的系统日志。

1.背景介绍

随着计算机网络技术的飞速发展，出现了越来越多的分布式系统，我们利用这些系统已提高现有系统的性能，可用性和稳定性。尽管分布式系统的设计已日趋成熟，但要在分布式系统中进行协调和信息交流仍然不是一件容易的，特别在松耦合的分布式系统中，所有的信息传递只能通过网络来完成，必须面临网络丢包、延迟甚至瘫痪等等复杂的问题。要在这样的系统中都实现可靠的一致性协议来进行信息的交流，对于系统设计而言是非常困难的，而且有一些是在应用中没有办法实现的。因此，我们希望提供一种非侵入式的服务来帮助分布式系统各个成员间的动作协调和信息交流，通过使用这一服务，各个分布式系统的成员可以非常简单的达成同步，而不需要在系统内部加入复杂的协调机制。因此，我们设计并实现了debby分布式锁服务系统，这是一个类似于提供全文件读写的分布式文件系统的结构，它设计的目标并非提供海量数据的存储，而是用于提供具有高可靠性和高可用性的锁服务，同时可以方便高效的信息发布机制。为了保证debby系统的可靠性，我们的系统设定了5个服务器来组成一个debby实例，只有一个服务器用来向外提供服务，而其它服务器都作为备份服务，用来在主服务器崩溃时继续提供服务。为了在5个服务器之间提供一致性保证，我们还在底层实现了Paxos协议，只要有半数以上的debby服务器能够正常运行，就可以提供服务。

利用debby系统，现在分布式系统可以非常便捷的进行同步协调和信息发布。比如当多台服务器提供同一服务时，往往需要选择其中一台服务器来作为主服务器，把其他服务器作为备份服务器，而且当主服务器崩溃时，又要能及时选出新的主服务器来提供服务。如果没有debby系统，在分布式系统内部实现这样的备份机制非常困难，唯一的办法或许就是通过Paxos协议来达到一致性，而有的时候甚至Paxos协议也无法派上用场，比如当只有一个备份服务器的时候。然而利用的debby，实现上述功能变得非常简单，只需要所有的服务器都到debby系统中去获取一个互斥锁，然后获得锁的服务器就自动成为主服务器。只要所有的服务器都遵守这一约定，就保证了系统中只会有一个主服务器。debby提供了非常简单易用的信息发布机制，在获取到互斥锁后，服务器可以通过debby提供的分布式文件服务，在文件写入自己的地址，其他服务器以及客户就可以非常容易的通过读取debby文件内容来得到服务器的地址。如果主服务器崩溃，debby系统会自动释放互斥锁，并且通过事件机制来通知其它服务器来重新选择主服务器。

Google公司已经实现了类似的分布式锁服务系统Chubby，并广泛的应用于内部系统中，他们的经验表明这样的系统具有非常好的可用性和可靠性，能够给其他分布式应用的构建带来非常大的帮助。

2.系统设计

2.1整体设计

Debby结构图

如图所示，一个debby 服务器可以同时为多个客户端提供服务。客户端通过调用debby的client library ，和服务器通信。客户端和服务器的通信建立在ICE远程过程调用的基础上。在服务器端，可以同时有多个debby server，其中一个是leader，另外的是replica（图中有3个server）。每个debby server上面独立运行服务器端的程序，包括文件管理，事件管理，Session管理等。服务器端的操作的一致性通过底层的paxos协议来实现。服务器提交给paxos的操作，都会记录日志信息。

2.2服务器设计

服务器通过向客户端提供接口，并且调用底层的 paxos协议，来实现最终的锁机制，并提供最终的可靠服务。

2.2.1 服务器的通信部分

服务器通过ICE的远程过程调用机制，来和客户端通信。通过服务器为客户端提供的接口，debby的客户端库可以连接到服务器，并且得到一个唯一的连接标识。通过这个标识，客户端库可以关闭连接，创建文件、目录，删除文件、目录，读写文件，注册事件，删除事件，保持心跳，判断文件的类型等等。当某些操作发生错误的时候，服务器端会向客户端抛出一个异常。

2.2.2一致性的保证

服务器端通过调用底层的paxos协议，来保证服务器操作的一致性。每次服务器要进行数据的修改操作的时候，例如创建文件，修改文件，删除文件等，都要把操作提交给paxos协议，paxos会保证每个操作都在服务器上执行，或者都不能执行。也就是是保证操作的一致性。

2.2.3 Session的设计

每个Session是一个客户端和一个debby服务的关系。通过心跳机制，客户端和服务器保持联系。在每个心跳到来的时候，服务器会把发生的事件返回给客户端。

2.2.4文件、目录的设计

对于每个Session，debby提供一个简单的文件系统接口，文件和路径的格式类似于UNIX，例如/ls/foo/dir/file。文件系统向外提供通常的文件系统服务，例如文件、目录的创建，文件、目录的修改、删除等。debby应该向客户端提供对临时文件进行操作的服务。临时文件被客户端创建，在Session失效的时候，临时文件应该被删除。

为了方便，以及提高性能，debby的文件和目录都放在内存中，定期进行snapshot，将文件系统的内容flush到磁盘。在系统恢复的时候，会根据磁盘的内容恢复文件系统。

2.2.5事件机制的设计

对于每个Session， debby提供一个事件管理器，事件管理器会记录客户端已经注册的事件、和已经发生的事件。对于已经发生的事件，服务器会在每个keepAlive的远程过程调用的时候，将客户订阅的事件捎带返回，同时在服务器端删除这些已经发生的事件。2.3客户端设计

利用服务器端提供的接口，我们通过客户端来最终实现锁机制，并向外提供服务。我们希望客户端向外提供尽量易于理解的接口，从而可以让用户可以方便的使用debby系统的服务。

客户端通过ICE库来和服务器进行远程调用，并且通过定期的keepAlive信息保持和服务器的会话。每次客户端与服务器建立会话后，都得到一个独一无二的句柄，并且以后所有的操作都通过这一句柄来完成，从而可以在每次操作时判断用户的身份。尽管在应用程序中，可以有多个对象使用同一个客户端的服务，但在服务器看来，一个客户端只对应唯一的用户。

客户端向外提供的API可以分为两个部分，一部分是实现类似于普通文件系统的目录操作，另外一部分则用来提供全文读写、锁服务以及事件注册。

在提供目录操作的部分，我们的接口与普通文件系统非常类似，具体的操作包括create(),remove(),mkdir(),exist(),isdir(),list()。通过这些操作，用户可以修改系统目录结构，创建和删除文件和目录。与普通的文件系统不同的是，我们在create接口中提供了是否创建临时文件的选项，如果创建的是临时文件，那么当这个客户端与服务器失去连接后，debby服务器会自动删除临时文件。这可以作为一种信息发布的方式，也是我们实现锁机制利用的底层特性。

我们提供了read()和write()操作来进行全文读写，即一次读或者写整个文件的内容。之所以这样设计，是因为debby中的文件其主要作用是为了提供一种信息发布的机制，而不是作为大规模数据的存储。为了防止用户的误用来对debby的整体服务性能造成影响，比如存储非常大的文件，我们对文件的大小进行了限制，目前暂定为1M。这样规模的文件，我们可以很方便的只提供全读和全写的操作，由用户自己来确定文件内容的格式。我们提供了lock()和release()操作来提供锁服务，当多个用户想要获取某个资源时，应当首先获取对那个资源的锁，才可以安全的使用资源。当完成对资源的使用时，用户应当调用release()操作来是释放操作，从而使得其它用户可以使用资源。因为Chubby的使用数据表明几乎所有用户使用的都是互斥锁而非共享锁，因此目前我们只提供互斥锁服务。

我们还提供了事件机制，通过事件机制，用户只需要在某个事件上注册好回调，当事件发生时，就会自动调用用户注册的回调函数。通过这一机制，用户不需要通过轮询来获得信息，大大减轻了服务器的负担，使其具有更好的可扩展性。目前我们提供的事件包括EventCreated, EventRemoved, EventChanged, EventLockChanged, EventArbitrary五种。前三个事件分别代表目录或文件的创建、删除和改变，这里目录的内容改变指的是目

录内文件的创建或删除。第四个事件是指在某个路径上的锁发生改变，包括锁被获取或释放。第五个事件则是指在一个路径上的所有事件，包括创建、删除、改变以及锁的改变。

2.4 snapshot机制设计

Debby的paxos框架保证了各个replica存放数据的一致性。也支持备份在crush掉之后恢复。到目前为止，所有的故障恢复均基于log，log存放在稳定存储器（硬盘）中。但由此引发了新问题：随着系统运行，日志将会越来越多。这有两方面问题：log的存储需要无限量的磁盘空间，并且更糟的是，这也可能会导致恢复时间越来越长。

这里介绍的snapshot（快照）机制想法很简单。就是要将文件系统的数据结构直接序列化到磁盘上，这样之前的日志就不再需要了。于是可通知paxos部分将log删除。当然，paxos部分并不知道任何有关的数据结构，因此，application进程必须负责snapshot的执行。

debby提供了snapshot机制，允许客户端应用程序通知文件系统执行snpsoht操作。用户应用程序可在任何时间发起snapshot命令。当snapshot操作完成，snapshot部分应通知paxos部分以删除其过时的snapshot存储和log。当某台服务器crush掉之后恢复时，snapshot类将负责为其从磁盘中导入最新的文件数据结构，然后重放截断日志，以重建服务器的服务环境。

当然snapshot机制也增加了一些复杂性：在实现snapshot机制之前，crush掉的服务器在恢复时只需从其他机器获得最近的log即可进行更新。而实现snapshot机制之后，如需保持状态的一致性，得包括进最近的log和snapshot复本。

2.5容错日志设计

Debby系统的主要设计目标是高可靠性与高可用性，这主要依靠多台服务器一起运行来实现。一台机器坏悼都有备份机接替工作，但如果保证系统中的机器数据的一致性是一个非常大的问题。我们主要用paxos一致性协议[][]，它保证每一时刻，系统中的大部分机器的状态都是一致的，状态不一致的机器可以通过一定方法恢复到一致的状态。

paxos保证系统的一致性主要靠容错日志，系统的每次操作paxos都会把这个操作记录在日志中，通过这个日志就能过从错误中恢复。我们的系统中，要写入日志的值就可要对数据库进行操作的值。

基本的paxos主要分为三个步骤[4]：

一.有多少机器中通过一些算法选出一个leader

二.选出的leader可以提交决议到系统中，leader发送消息给其它机器，其它机器回复leader

三.当leader收至半数以上的应答，就发消息给其它机器，表明可以记日志。

基础的paxos协议没有对那个状态不一致的系统进行处理，在我们的容错日志设计中，有第一与第二步中间加了一步准备阶段。当leader被选出来已后，向其它机器发一个消息，表明自己是leader，并把当前的系统状态发给大家。其它机器根据leader发过的状态信息，判断自己的信息是不是最新，返回给leader自己的状态，leader根据这些信息来决定自己是否需要进行catch up操作，其它机器可以与leader通信，更新状态。

在基本的paxos中，如果每台机器都给其它机器返回信息，第三步可以省略。基本的paxos做每一次决议都要选leader，比较费时，我们通过给leader一个租约时间，在这个时间中，其它机器保证不会同意选出新的leader。leader在租约时间内可经续租约，从而保证leader长间的成为leader。下图是我们使用paxos对容错日志系统的设计[]。

3.系统实现

3.1服务器端实现

在服务器端实现了向客户端提供的接口，并且调用底层的 paxos协议的接口，来实现最终的锁机制，并提供最终的可靠服务。debby的服务器实现了Session管理，心跳机制，文件、目录的管理，事件管理，以及和客户端、paxos协议的通信。

3.1.1Session机制的实现

对于客户端和服务器建立的每一个连接，服务器都会保存一个的pair，当客户端显示结束连接，或者没有心跳的时候，服务器会删除对应的Session。每个Session都会保存对应的临时文件信息，以及相应的注册事件信息。注册的事件发生时，Session会在心跳的基础上，将事件返回，通知客户端。

3.1.2文件、目录的实现

考虑到实现的方便和高效，debby的文件和目录是放在内存中的。debby的文件系统分为常规的文件系统，和临时的文件系统。常规文件系统和临时文件系统是分开实现的，他们的命名空间也是相互独立的。

在常规文件目录中，对于文件和目录的管理，提供了通常意义下的操作，包括文件、目录的创建，文件、目录的修改、删除等。系统实现了两个版本的文件、目录系统。第一个是用STL的map实现，整个文件系统只有一个map，map的每一个元素是<路径，debby文件>的pair。这个实现版本效率比较差，并且操作起来非常不方便，实现起来比较麻烦。考虑到文件系统的组织结构，debby提供了文件系统的第二个实现版本，用树来实现。在开源的tree.hh基础上，debby用模板实现了通用的内存目录MemDir。通过MemDir，用户可以定义自己的inode类型，在inode中，用户应该提供相应的方法，这些方法在MemDir 中被调用。

对于临时文件系统，系统维护了一个从handle到路径名称的map，当一个Session失效的时候，系统会释放一个handle所对应的文件。

3.1.3事件机制的实现

debby维护了一个事件管理器，事件管理器会记录客户端已经注册的事件、和已经发生的事件。对于已注册的事件，系统维护一个事件到handle列表的map，如果某一个事件发生了，则会通知列表里面记录的每一个连接。

3.2客户端实现

当用户启动客户端时，就会启动一个心跳线程，专门用于向debby服务器发送keepAlive 信息以维持会话。在客户端的大部分操作都通过服务器提供的远程调用服务来实现，比如文件和目录的创建、删除等操作。

对于互斥锁的获取和释放操作，debby并不提供直接的支持，而是通过客户端通过创建和删除临时文件来完成。比如当客户获取"/ls/printer"的互斥锁，客户端就会试图创建"/ls/ printer.lck~"文件，如果这个文件已经存在，说明互斥锁已经被其他用户获得，服务器向客户端抛出异常，客户端获取异常后返回失败。如果成功了创建了那个文件，就表明客户成功获取了该互斥锁。当用户要释放锁时，客户端就会删除"/ls/printer.lck~"文件，来表明用户已经释放锁。为了防止这样的文件和用户的普通文件重名，我们规定用户不能创建以"~"结尾的文件名。对于锁服务，我们最需要处理的问题是当客户端崩溃时，需要自动的释放锁，临时文件的机制使得我们可以实现这个功能，因为如果客户端和服务器失去连接，服务器就会删除用于所服务的临时文件，也就是释放了该用户拥有的所有锁。

在实现事件机制时，尽管客户可以在事件上注册回调，但服务器并不需要管理回调函数，只是通知客户端事件的发生，对回调的管理有客户端完成。用户可以在一个路径的一个事件上注册多个回调，只有在注册第一个回调是需要由客户端向服务器注册，后续的操

作就完全由客户端来完成。当客户端收到一个事件时，它会调用注册到这个事件的所有回调。用户也可以取消在一个路径上注册的所有回调。

回调的实现，我们通过一个类Callback来实现，这个类有一个纯虚函数run()，用户要定义自己的回调时，需要首先创建一个Callback的子类，并实现其run()函数作为回调函数。当客户端要收到事件时，对于每一个注册的Callback，都会创建一个线程来调用其run()函数。在用户的子类中，可以把任何用户的回调函数需要的数据作为其Callback子类的成员，从而使得其回调函数可以实现几乎任意强大的功能。

客户端另外一个需要处理的问题是当debby服务器发生改变时如何能转换到适当的服务器，并且能够处理由于改变服务器导致的一段时间内服务失效问题。我们通过ICE的多终端功能和重试功能来解决这个问题。当ICE进行初始化的时候，我们会把debby的5个服务器地址都传给ICE，这样ICE会自动尝试所有5个服务器，只要有一个服务器提供服务，就可以建立其连接并进行远程调用。因此我们只要保证debby服务器端同一时间内只有一个服务器在提供服务，就能够保证debby客户端能够找到master。但在改变服务器期间，回出现没有任何一个服务器提供服务的情况，此时我们需要利用ICE的重试机制，即我们可以给ICE提供一个重试时间的序列，比如(1 3 5)表示如果ICE客户端无法与服务器建立连接，会在接下来的第1秒，第3秒和第5秒进行重试，只要在重试中能连上服务器就可正常工作，否则认为连接失效抛出异常。我们也给我们的客户端ICE提供了重试时间序列，为(10 30 60)，这样只要服务器端能够在60秒内恢复，我们就可以向用户提供连续的服务。

3.3snapshot机制实现

对于Google公司的Chubby，其文件系统以数据库的形式采用Berkeley DB实现。Berkeley DB采用B-树结构，可以提供高效率的Key-value查找。在我们的版本里进一步做了简化。文件系统采用自定义的tree实现，于是在序列化时只需对 MemDir中的文件树做遍历，记下相应节点（INode）的信息和其父节点即可。由于Debby系统采用C++编写，standard library中未提供序列化功能，只能自己编码完成（考虑过用boost库实现，由于使用起来不方便而作罢）。

Snapshot类主要实现两个函数：

public static void serialize(MemDir& md);

public MemDir& void Unserialize();

其中，属性DIR_PATH为序列化后的文件系统数据结构的存放路径； Serialize方法将传入的文件系统数据结构MemDir序列化后存入路径为DIR_PATH的文件中， Unserialize 方法在服务器恢复时调用，其从路径为DIR_PATH的文件中恢复数据结构MemDir并返回之。

3.4容错日志实现

我们主要实现了一个paxos框架，用paxos框架来产生容错日志。对2.5小节的设计，我们的机器共有三种角色，LOOKING表示当前机器正在寻找leader。LEADERG表示当前机器为leader。FOLLOWER表示当前机器为非leader。paxos过程如下：

1.通过leader选举算法，得到一个leader。每台机器要参与leader的选举，必须提交一个veiw号，这个号要保证是递增的。在我们的实现中，每台机器即可以推举自己当leader，也可以推举别的机器当leader。所以在我们的实现中，每台机器都有自己的编号例如0~N-1,当前被达成一致的view对应的leader就是view%N对应的机器[5]，如果该机器没有起启动，则再次选leader，如何得到leader没有启动，可以通过心跳机制来保证。在我们的实现中，当一台机器被选成leader，马上就得给其它机器发心跳，而leader也是通过心跳来续约租约时间的。这里所涉及到的消息包括viewchange消息，与heartbeat消息

2.当一台机器被选为leader后，向大家发送一个准备信息，包括当前的view与系统的状态，向大家来同步。其它机器对这个消息进行应答并通过自己的状态信息。leader汇总这些信息，判断自己的状态是否为最新，如果不是最新，刚向收到回复消息的机器中选择一个状态最新的机器，向那台机器请求数据，以恢复来最新状态。系统中必定有一台机器的状态是最新的，这个可以由paxos的性质来保证。其它服务器如果状态不是最近，可以向leader发请求来恢复最新状态。这里所涉及到的消息包括prepare消息，prepareok消息，catch up消息

3.当第2步完成时，leader状态是最新的，并且系统中的大部分机器的状态都是最新的，即一半以上的机器状态一致。leader就可以响应其它程序向paxos系统提交决议，其它机器收到决议并向leader与其它机器应答消息，当应答的消息过半时，表示协议已经达成，每台机器把这协议记录在本地的日志中。如果协议没有达成，leader可以自动重新提交协议，直到达成协议，也可直接返回协议没有答成给调用者，由调用都重新提交协议,在paxos系统中，这次提交的协议号与上次失败的协议号是相同的。这里涉及到的消息包括proposal消息,accept消息

在系统的运行过程中，如果有一台宕掉的机器起来，它首先通过一定时间侦听当前leader发送的心跳消息，如果没有收到心跳消息，由进入选leader状态。如果收到消息，向leader更新自己的状态信息到最新。在一个已有leader的系统中，如果有别的新的机器发选leader的消息，大家都会把它拒绝，当新的机器收到心跳消息时，自动转变角色。4.实验

4.1paxos实验

我们的实验环境主要是在单台机器下(PM1.5GHz 512MB)，通过多个终端来模拟多台机器对paxos的系统测试实验。在针对paxos系统的一致性进行测试实验，我们主要采用同步提交的方法，即下一次提交的协议必需等上一次提交后并且已经得到结果了才能提交。这些实验我们都默认系统已经把leader选出，所有的决议都leader提交。在实验中leader提交的策略如下：如果一次提交，再1秒钟内paxos系统还没有对该协议达成一致，则返回提交失败而paxos系统对本次操作不记日志，否则则提交成功，paxos对这次操作记下日志。paxos记日志的方式是把提交的内容与协议号写入磁盘。系统中的通过主要用多播实现，系统之间的catch up通过单点tcp连接进行通讯。

我们总共做了四组实验，在这四组实验中也可以分成两组，一组用3个终端，另一组用5个终端完成。3个终端表示我们paxos系统中有3台机器中,我们模拟系统中只剩2台机器，与3台机器都存在的情况。5个终端的实验中模拟了3台机器与5台机器的情况。表一,是3台机器的模拟结果，表二，是5台机器的模拟结果。

在实验的结果中，我们可以看出，系统中机器数比较少时，达成协议的速度比较快。在同一个系统中，也就是系统中的机器数量一定时，宕掉的机器越多出现提交失败的比例也越高，而整个系统特别在有许多机器的，其运行速度也越慢。

表一 3个终端模拟1台机器宕机与没有机器宕机的情况

表二 5个终端模拟2台机器宕机与没有机器宕机的情况

5.总结

在本文中，我们实现了类似于chubby系统的分布式锁服务系统Debby。此锁服务系统采用C++实现，由多台服务器共同维护一个类似文件系统的数据结构，并保证此数据结构在多个服务器进程之间的一致性。整个系统具有容错性能（fault tolerance），能够保证在复杂的网络情况中（丢包、传送延迟，机器瘫痪等）稳定运行。多个进程通过paxos算法保持各自维护的数据间的一致性。系统的运行日志（log）和快照（snapshot）将被备份到硬盘上，服务器在宕机后可依此自动恢复。客户端与服务器之间的通信采用ICE远端过程调用。Debby系统可用于分布式环境中的leader选举，名字服务（name service）以及共享资源的并发控制等。

通过这次课程项目，我们深入了解了分布式系统如何保持各个备份间的一致性和容错性，并亲自开发了一个真实的分布式系统，加深了对课程内容的理解，也锻炼了动手能力，在此感谢老师给我们提供的机会，也感谢助教师兄的工作。

参考文献