基于存储区域网络SAN的集群分布式锁管理方法

摘要

基于存储区域网络SAN的分布式锁管理方法属于网络存储领域，其特征在于：集群各节点服务器构成多重主从式子集群，即Quorum，子集群中一个节点作为主服务器，其他均为从属服务器；多重子集群包括一个State Quorum和若干个Lock Quorum，分别负责系统节点生灭状态的管理和名字空间中读写访问锁的管理；State Quorum由所有节点构成，Lock Quorum可由任意数量的节点构成，其大小及构成可由用户灵活配置；不论是State Quorum，还是Lock Quorum，都遵循子集群侦测协议，通过该协议，各节点能够选举Quorum中的唯一主服务器，构建正常态的Quorum；各个Lock Quorum分管名字空间的不同分段且互不交叠，按照服务能力分别被赋予不同的权值。各Lock Quorum独立统计自己的负载情况，当一个Lock Quorum所负担的锁管理任务过于繁重时，触发负载平衡过程，将本Lock Quorum的部分任务分流给其他Lock Quorum。本发明易于灵活配置，具有良好的性能、高可扩展性以及高可靠性。

说明书

技术领域

基于存储区域网络SAN的集群分布式锁管理方法属于网络存储系统领域，锁的管理对于维护系统一致性，保证并发访问的正确性非常重要，该方法尤其涉及集群系统名字空间的访问权限管理、存储网络中的负载调度、集群全局数据快照备份等领域。

背景技术

分布式锁管理系统用来控制对共享资源的并发性访问，提高并发访问的效率，同时保证对共享资源修改操作的原子性，从而也保证了系统的一致性状态。传统的锁管理系统依赖中心锁管理服务器提供对整个数据资源名字空间的访问权限控制，这种方案中，中心锁管理服务器容易成为系统瓶颈，整个系统的可扩展性较差，同时，中心锁管理服务器的单节点故障问题也会影响系统的可靠性；以集群并行文件系统Lustre为代表的面向对象分布式文件系统中采用了分布式锁管理系统，将对象存储服务器OSD名字空间的访问权限控制分布到若干台元数据管理服务器MDS中，这样大大减轻了单台服务器的负担，但这种方案中，名字空间在元数据管理服务器MDS中的分布是静态的，缺乏灵活性，不能适应负载的动态变化，同时，该类锁管理系统采用了热备standby服务器的方案，在一定程度上提高了系统可靠性；以全局文件系统Gloable FS为代表的集群系统采用了基于子集群Quorum的锁管理系统，其好处在于大大提高了系统可靠性，通过Quorum内部的锁更新协议Quorum内的所有服务器保持严格同步，当其中一台或多台出现故障，其他服务器按照协议依然能够形成新的Quorum继续提供服务，但该系统中Quorum内部只有一台节点，称为主服务器Master，能真正对外提供服务，所以存在性能瓶颈。

基于SAN的集群分布式锁管理方法提出了一种应用于大规模存储区域网络系统，能够协同工作的多Quorum锁管理系统结构，设计了子集群Quorum侦测协议来实现各个Quorum的建立、Quorum中领袖的选举，同时，设计了该多Quorum环境下的动态负载平衡机制，基于此方法实现的分布式锁管理系统易于灵活配置，具有良好的性能，高可扩展性以及高可靠性。

发明内容

本发明的目的在于设计一个性能好、可扩展性好并且高可靠的分布式锁服务系统，在存储区域网络环境下，实现对共享数据并发访问的权限管理，并能实现对分布式全局快照的支持。本发明的重点在于：可配置的主从式锁服务器子集群Quorum，锁服务器子集群Quorum的探测流程，锁服务器子集群Quorum的负载均衡。

本发明的特征在于：

所述方法是在集群的各节点服务器上依次按以下步骤实现的：

步骤(1).集群初始化

步骤(1.1).集群的设定初始化

在集群的各节点上设立一个状态服务器State Server，负责包括监测各节点的生灭状态、屏蔽故障节点、维护整个集群在内的各项正常工作，形成一个状态侦测集群State Quorum，负责节点生灭状态的管理；

在所述集群各节点上有选择地选择若干节点，各自设立一个锁服务器Lock Server，负责包括对共享数据资源并发访问的控制、保障集群卷管理系统、文件系统或数据库读写查询在内的各项操作的正确执行，维护共享存储系统的一致性并且按照锁更新协议构成每个锁服务子集群Lock Quorum，负责名字空间中读写访问锁的管理，各个与所述锁服务的节点必须安装锁代理Lock Agent作为客户端，只有通过锁代理才能申请读写访问锁；

所述包括状态侦测集群和锁服务子集群在内的各个集群Quorum是由设定数量的服务器构成的一个服务单元，所述集群内的各服务器按照功能不同被分为主服务器Master、仲裁服务器Arbitrator，以及从属服务器Slave，其中：

主服务器仅存在于原先由设定数量的服务器构成的集群中，是随机选择的，仅有一个，负责提供相关服务；

仲裁服务器仅在所述集群未达到设定数量时存在，由此时的所有服务器按照选举协议临时选举出来作管理者用的，当接收该服务器加入后，使服务器总数超过设定阈值时，所选仲裁服务器便转换为主服务器，所在的集群转入正常状态，即Quorate状态，提供正常服务；

从属服务器，为所选主服务器的热备，存储重要数据的副本，参与集群中的投票与决策，在当前的主服务器失败后，新的主服务器由各从属服务器投票选出；

所述锁更新协议是指：各个锁服务子集群分管名字空间的不同分段且互不交叠，独立统计本锁服务子集群的负载情况，并按照服务分别被赋予不同权重值条件下，当一个锁服务子集群所负担的锁管理任务过于繁重时，则向其他锁服务子集群分流即更新名字空间的分段；

步骤(1.2)配置初始化

步骤(1.2.1)配置节点的IP地址、主机名，以及相应的XML配置文件，其中，包括版本、根元素的版本等，所述根元素代表整个锁集群，其版本及其名称，用<cluster_version>及<name>表示，其中包括：

<cluster_nodes>标签，包括：

集群中每个节点的标签及其内容，其中包括节点名name、节点优先级rank、节点投票时的权重votes，所述各节点的权重必须满足以下条件：对于进入正常状态，即Quorate状态的集群，已经加入其中的所有节点的权重和必须大于整个集群系统中所有节点权重和的一半，在缺省情况下，设各节点的权重为1，则Quorate状态成立的条件为当前已加入集群的节点必须多于半数；

<thudlm_dom>标签，包括：

构成锁服务子集群的所有节点，其属性为：权重weight，描述该锁服务子集群的锁处理能力；代表该锁服务子集群中一个节点的标签<lock_server>，以及每个节点的名称name；

步骤(1.2.2).把配置文件分发到集群中的各个节点；

步骤(1.3).状态初始化，按以下步骤建立状态侦测集群：

步骤(1.3.1).对集群内各节点同时运行以下操作：

步骤(1.3.1.1).读取并分析配置文件，脚本参数，初始化各内存的数据结构，包括：节点当前状态、状态侦测集群和锁服务子集群的链表；

步骤(1.3.1.2).开放本节点的服务端口，侦听集群内其他节点的消息；

步骤(1.3.1.3).按以下步骤执行集群探测流程：

步骤(1.3.1.3.1).定义节点在本集群中的四种状态为：初始化状态Beginner，仲裁服务器状态Arbitrator，主服务器状态Master，以及从属服务器状态Slave；

步骤(1.3.1.3.2).把本集群中的所有节点读入节点链表，并设定一个游标指针指向该链表的首节点；

步骤(1.3.1.3.3).若本节点的当前状态为开始状态或仲裁服务器状态，则把游标指针指向节点链表的首节点，并发起探测游标所指向的首节点的操作，发起连接申请，侦听本节点在本集群中的服务端口，持续侦听，直到有事件到来；

步骤(1.3.1.3.4).若被探测节点发出同意连接的响应，则登录所探测节点，向所探测发出本节点的基本信息，并根据不同情况，作以下处理：

若：锁探测节点当前处于初始状态，且本节点的优先级低于被探测节点，则退出在所探测节点上的登录，重置游标指针，重新探测，转步骤(1.3.1.3.5)；

若：锁探测节点为从属服务器则推出在所探测节点上的登录，转步骤(1.3.1.3.5)；

若：锁探测节点当前为仲裁服务器状态，且本节点也为仲裁服务器状态，则根据优先级确定最终候选者，一旦本节点候选失败，则遣散所有本节点上的登录者并勒令登录者转换为初始状态，而本节点转为从属服务器；

若：所探测节点当前为主服务器状态，则遣散所有在本节点上的登录者，并勒令所有登录者转为初始状态重新探测，而本节点则转为从属服务器状态；

若：所探测的节点其状态为未知，则退出在所探测节点上的登录；

步骤(1.3.1.3.5).

若：本节点收到其他节点的探测请求，则建立连接，发回同意连接的消息；

若：本节点处于初始状态或从属服务器状态下，收到其他节点的登录信息，则向对方节点发回本节点的具体信息；

若：本节点处于仲裁服务器状态，且本集群中的权重已足够使本集群转为Quorate时收到其他节点的登录信息，则记录对方节点在本集群中的权重，本节点转为主服务器状态；

步骤(1.3.1.3.6).把事件内容记录入日志，转步骤(1.3.1.3.3)；

步骤(1.3.1.3.7).确定各节点在状态侦测集群中是主服务器，还是从属服务器状态的最终形式，由全部或多数存活节点构成状态侦测集群；

步骤(1.3.1.4).作为主服务器的节点轮询检测集群中各节点的心跳信息，确认节点生灭状态，若有新节点加入，则更新本地状态侦测集群的节点链表，同时发送广播消息通知状态侦测集群中其他节点同步更新，若有节点出现故障，则主动屏蔽故障节点；

步骤(1.3.1.5).各节点启动锁代理进程，通过作为锁服务子集群的客户端的锁代理把本地锁请求发送到对应的所服务子集群；

步骤(1.4).锁服务初始化，建立锁服务子集群，其步骤如下：

步骤(1.4.1).根据所述初始化时读入内存的配置文件信息、节点生灭状态，建立各个锁服务子集群的节点链表；

步骤(1.4.2).查询本节点是否在锁服务子集群中，若属于某个锁服务子集群，则按步骤(1.3.1.3)所述的探测流程，确定本节点是主服务器还是从属服务器，若不属于任何一个锁服务子集群，则退出；

步骤(1.4.3).按以下步骤初始化一个资源表RT：

步骤(1.4.3.1).在锁服务子集群中，把整个名字空间映射到一个水平的哈希地址空间，设哈希值有n位，把整个哈希地址空间表示为{i|0≤i≤2ⁿ}；

步骤(1.4.3.2).把各个锁服务子集群锁管理的名字空间分段信息都记录在各个锁服务子集群自己的资源表RT中，其表项为：哈希地址hash_addr，对应名字空间某数据资源；锁服务子集群标识lqid，取值为1、2、3......m，共有m个锁服务子集群，令RT_i表示隶属于第i个锁服务子集群LQ_i的表项组成的集合，用RT_i＝{p|p∈RT∧p.lqid＝i}表示，则整个集群系统包含m个锁服务子集群，用LQ₁、LQ₂、......、LQ_m表示，各自的权重分别为w₁、w₂、......、w_m；

步骤(2).状态侦测集群按以下步骤在各个锁服务子集群中进行负载均衡：

步骤(2.1).各锁服务器子集群中的主服务器每隔间隔T为每个锁服务子集群LQ_i对应的资源表RT_i的每一项按下式计算负载load_p：load_p(T)＝(1-α)×ar_p+α×load_p(T-1)；

其中：

p为RT_i中的某个表项；

ar_p为当前间隔T计算得到的单位时间内接收的锁请求数；

a为历史因子，表示(T-1)周期的负载值load_p(T-1)在T周期中新计算得到的负载load_p(T)中的比例；

步骤(2.2).状态侦测集群的主服务器通过锁代理收集各个锁服务子集群在同期T内的负载量，进而求出各锁服务子集群按各自权重所应负担的理论负载量，同时，求出各锁服务子集群的过载负载量，该过载负载量为现实负载量与理论负载量之差；

步骤(2.3).根据所述过载负载量的正负，把各个锁服务子集群分别划分到过载集合和轻载集合；

步骤(2.4).按以下步骤使负载量近似均衡分布：

步骤(2.4.1).结束条件判断：当过载集合或轻载集合中其中任何一个为空，或最大过载量低于设定的阈值时则转步骤(2.4.5)，否则，执行步骤(2.4.2)；

步骤(2.4.2).对于过载集合中的每一个元素，在轻载集合中寻求最佳分流匹配，把已匹配成对的从相应集合中去除，并把要分流的负载量记录到相应的过载集合的元素上；

步骤(2.4.3).对于轻载集合中的每一个元素，在过载集合中寻求最佳负载与分流匹配，并把已匹配的从相应集合中去除，把要分流的负载量仍然记录在过载集合的元素上；

步骤(2.4.4).结束一轮匹配，转步骤(2.4.1)；

步骤(2.4.5).负载分流，遍历过载集合中的每个节点，根据记录的分流信息把相应的流量分流到相应的轻载集合中。

对于所述状态侦测集群，初始化时，应选择集群中一个不属于任何锁服务子集群的服务器为主服务器。

本发明的优点如下：

(1)多Quorum架构，一个State Quorum用来探测所有存活节点，维护集群的结构，检测各节点状态，多个Lock Quorum负责维护读写访问锁信息，是系统核心服务单元，各个Quorum的结构、节点构成都通过xml配置文件配置，维护和修改灵活；

(2)各Quorum采用主从结构，从服务器作为主服务器的热备，提供高可靠的服务，主服务器的选举、从服务的数量等都可以灵活配置；

(3)各Quorum中节点独立发起探测，根据预设的rank级别确定本节点的优先顺序，因为Quorum中级别的唯一性，Quorum中各节点能够选举出唯一的Master，即当前存活的具有最高级别的节点；

(4)各Quorum采用投票机制确立Quorum的合法地位，当目前加入Quorum的节点投票数超过理论总票数的一半时，Quorum才被宣布为合法且能正常对外提供服务，通过该机制，避免了由于多个子Quorum同时成立而对共享数据管理带来的混乱以及对数据一致性的破坏；

(5)多Lock Quorum，彼此协同处理，各个Quorum分管全局名字空间的一部分且互不交叠，各节点在访问相应资源全会查询资源表，按照表中记录的Quorum id值向相应Lock Quorum发送锁申请，无中心瓶颈；

(6)各个Lock Quorum间的负载能够实现动态平衡，通过配置文件中的数据确定各Lock Quorum的权重，并以此为根据均分负载，负责平衡首先将各Lock Quorum归入两个集合，过载集合和轻载集合，通过两个集合间寻求最优匹配的算法进行负载分流，当最大过载Quorum的过载量低于指定阈值时负责平衡流程结束。

本发明在清华大学计算机系高性能计算技术研究所进行了模拟与测试。测试环境如图2所示，测试首先对比了不使用锁管理系统的单机卷管理软件与依赖锁管理系统的集群卷管理软件在执行相同操作时的性能差异，其次，通过在本所实际使用依赖于该锁管理系统的集群文件系统来检验本发明的可靠性以及可扩展性；最后，使用程序模拟估算负载平衡算法的性能；结果表明，基于SAN的集群分布式锁管理方法能够灵活配置多个主从式Lock Quorum，分别针对名字空间的不同区域提供锁服务，无中心瓶颈，具有良好的性能，高可扩展性以及高可靠性。

附图说明

图1.分布式锁系统中各服务器之间的关系；

图2.分布式锁系统的实现与应用；

图3.Quorum侦测流程；

图4.负责平衡过程；

具体实施方式

基于SAN的集群分布式锁管理方法主要应用于基于共享存储的集群环境。在集群的各节点上设立一个状态服务器State Server，负责包括监测各节点的生灭状态、屏蔽故障节点、维护整个集群在内的各项正常工作，形成一个状态侦测集群State Quorum，负责节点生灭状态的管理；在集群各节点中选择若干节点，各自设立一个锁服务器Lock Server，负责包括对共享数据资源并发访问的控制、保障集群卷管理系统、文件系统或数据库读写查询在内的各项操作的正确执行，维护共享存储系统的一致性并且按照锁更新协议构成每个锁服务子集群Lock Quorum，负责名字空间中读写访问锁的管理。整个分布式锁系统中各服务器之间的关系如图1。

图1为该系统的典型实现，该实现由6个节点形成一个State Quorum，其中共包含两个锁服务子集群Lock Quorum，一个由3个节点构成，另一个由2个节点构成，这两个Lock Quorum分管整个名字空间的不同分区。软件结构如图2，内核态的SCSI驱动、适配卡驱动、目标器模拟驱动构成了一个软件实现的存储区域网络系统，将I/O目标器端的存储资源通过光纤线路，如图中灰线所示，共享给所有节点使用；用户态软件中，State Server负责构成整个StateQuorum，Lock Server负责维护Lock Quorum结构，各个节点通过使用Lock Proxy向LockQuorum提交锁申请；用户态的集群卷管理软件、内核态的集群文件系统为集群锁管理系统的应用，通过统一的接口向Lock Quorum中的Master发起锁请求。

Quorum是由指定数量的Server构成的服务单元，如果Quorum中Server数量高于某阈值，称该Quorum转为正常状态，即Quorate，否则称为探测状态，即Inquorate。Inquorate状态为中间状态，并不向外提供服务，此时Quorum中各Server会继续侦听，接收新Server的加入，直到Server数量达到阈值为止。

本方法中，各节点在State Quorum内分别扮演如下角色：State Master，主服务器，仅存在于Quorate的Quorum中，负责提供相关服务，同步Quorum中各Server的状态和数据，接收其他节点的加入，一个State Quorum有且仅有一个State Master；State Arbitrator，仲裁服务器，仅存在于Inquorate的State Quorum中，为Quorum中所有节点按照选举协议临时选举出来的管理者，其功能与State Master相似，当Quorum中节点数量超过阈值时，State Arbitrator转换为State Master；State Slave，从属服务器，State Quorum中的成员服务器，作为State Master的热备，存储重要数据的副本，参与State Quorum中的投票与决策，如果当前State Master失效，各State Slave能够重新投票，选举出新的StateMaster，保证服务的无缝转移。同理，各节点在Lock Quorum内也分别担任：Lock Master，有且仅有一个；Lock Arbitrator，仅存在与Inquorate的Lock Quorum中；Lock Slave，作为Lock Master的热备。集群中的所有节点，无论是否属于Lock Quorum，都能够向Lock Quorum发起锁请求。

两类Quorum的功能不相同。State Quorum只负责维护集群的结构，检测各节点状态，并不向Quorum外开放服务；Lock Quorum负责维护读写访问锁信息，是本系统中的核心服务单元，向外部提供锁管理服务。与Lock Quorum通信的节点必须安装Lock Agent作为客户端，只有通过Lock Agent节点才能申请读写访问锁。

整个分布式锁系统中只有一个State Quorum，系统中的所有存活节点都是该Quorum的一员。State Quorum中的State Master的功能主要包括：(1)接受其他节点的加入，实时向各State Slave广播State Quorum的信息变更，例如：当前状态是否是Quorate，共有哪些节点已经成为State Quorum成员；(2)State Master会监听各State Slave发送过来的心跳，处理各State Slave的发来的消息，监控其状态，维护集群结构，当一个节点故障时，StateMaster会发起屏蔽操作将该节点从State Quorum中清除；(3)State Master接受本节点其他进程的注册与注销，并负责与各注册单元的通信，及时向其通告本机状态的改变，例如，如果本节点也隶属于某个Lock Quorum，则State Master需要及时响应本节点Lock Server进程的注册，将本节点所在Lock Quorum中其他节点的生灭状态及时传递给该Lock Server。State Quorum中的State Slave的主要功能包括：(1)保持与State Master的同步，监听StateMaster在State Quorum中的广播，在本机维护State Quorum的相关信息；(2)定期向StateMaster发送心跳，报告自己的状态；(3)接受本机其他进程的注册与注销，并负责与各注册单元的通信，及时向其通告本机状态的改变。

系统中的Lock Quorum可以有多个，分别管理名字空间中互不交叠的区域，例如，分管文件系统某目录下的不同的文件集合。Lock Quorum的具体信息是可配置的，例如：系统中一共设立多少个Lock Quorum，每个Lock Quorum具体由哪几个节点构成。Lock Quorum在稳定状态下有且仅有一个Lock Master，有若干个Lock Slave。Lock Quorum中的Lock Master的主要功能是：(1)维护锁持有信息，将名字空间的每个元素看作是一个共享数据资源单位，为每个这样的资源维护一个锁链表，链表中包含所有对该资源已经持有的锁，Lock Master接收来自Lock Agent的锁请求，遍历所请求资源的锁链表，根据锁的兼容性，申请节点对该资源已持有锁的种类、粒度等不同情况作相应处理，例如，分配新的锁、将申请节点已持有的锁与新申请的锁合并、将申请转移到冲突链表，延迟后再处理，等等；(2)负责管理其他节点的登陆，生成并维护Quorate的Lock Quorum，将锁状态的更新实时广播给各个Lock Slave，做到锁更新的同步；(3)随时监听本机的节点相关状态的变化，并对Lock Quorum作出相应调整。Lock Quorum中的Lock Slave的主要功能是：(1)监听Lock Master在本Lock Quorum中的广播，同步维护Lock Master资源锁链表的一个副本，当Lock Master故障时，系统当前资源的锁持有信息依然可以在Lock Slave中找到，通过重新选举流程，新的Lock Master会从Lock Slave中产生并实现服务的无缝迁移；(2)监听本机的节点相关状态的变化，并对Lock Quorum作相应调整。

整个系统，不论是State Quorum，还是Lock Quorum都是可配置的，其配置文件采用Xml的语法。

配置文件的内容包括：

版本、根元素的版本；所述根元素代表整个锁集群，其版本及其名称，用<cluster_version>及<name>表示，根元素的具体内容包括：

<cluster_nodes>标签，其内容包括：

集群中每个节点的标签及其内容，其中包括节点名name、节点优先级rank、节点投票时的权重votes，所述各节点的权重必须满足以下条件：对于进入正常状态，即Quorate状态的State Quorum或Lock Quorum，已经加入其中的节点的权重和必须大于应该加入其中的所有节点权重和的一半，该条件用公式表示为$\underset{i\in \mathrm{QUORUM}}{\Sigma }\mathrm{vote}{s}_i>\frac{1}{2}\times \left(\underset{i\in \mathrm{ALL}}{\Sigma }{\mathrm{votes}}_i\right),$上式中，集合QUORUM代表当前已经加入State Quorum或Lock Quorum的节点集，集合ALL代表应加入的节点的全集；在缺省情况下，设各节点的权重为1，则Quorate状态成立的条件为当前已加入StateQuorum或Lock Quorum的节点必须多于半数，上述公式退化为

$\mathrm{nodes}\_\mathrm{count}\_\mathrm{in}\_\mathrm{quorum}>\frac{1}{2}\times \mathrm{all}\_\mathrm{nodes}\_\mathrm{count}.$

<thudlm_dom>标签，包括：

构成锁服务子集群的所有节点，其属性为：权重weight，描述该锁服务子集群的锁处理能力；代表该锁服务子集群中一个节点的标签<lock_server>，以及每个节点的名称name。

无论是State Quorum，还是Lock Quorum，都采用了主从式结构。因此，当一个节点启动时，都必须进行侦测，如果当前状态为Inquorate的探测状态，大家还必须发起投票选举出仲裁服务器State Arbitrator或Lock Arbitrator，投票的基本思想是比较各节点的rank，各节点分别统计当前能够探测到的Quorum内其他节点的rank，如果其他节点的rank都低于自己，则可以自升级为仲裁服务器，否则，主动放弃候选人资格。一旦投票数超过一个阈值，则Quorum转入正常状态，即Quorate状态，仲裁服务器升级为主服务器。

以State Quorum为例，其中的各节点启动后侦测流程的简易步骤如图3，具体步骤如下：

步骤(1).状态初始化，对集群内各节点同时运行以下操作：

步骤(1.1).读取并分析配置文件，脚本参数，初始化各内存的数据结构，包括：节点当前状态、状态侦测集群的节点链表；

步骤(1.2).开放本节点的服务端口，侦听集群内其他节点的消息；

步骤(1.3).定义节点在本集群中的四种状态为：初始化状态Beginner，仲裁服务器状态Arbitrator，主服务器状态Master，以及从属服务器状态Slave；

步骤(2).把集群中的所有节点读入节点链表，并设定一个游标指针指向该链表的首节点；

步骤(3).若本节点的当前状态为开始状态Beginner或仲裁服务器状态Arbitrator，则执行如下操作：

步骤(3.1).若当前游标指向节点链表的末尾，则把游标指针指向节点链表的首节点

步骤(3.2).发起探测游标所指向的节点的操作，发起连接申请，侦听本节点在集群中的服务端口，持续侦听，直到有事件到来；

步骤(4).若被探测节点发出同意连接的响应，则登录所探测节点，向所探测发出本节点的基本信息，并请求对方的基本信息；

步骤(5).若被探测节点返回其基本信息，则根据不同情况，作以下处理：

若：锁探测节点当前处于初始状态，且本节点的优先级低于被探测节点，则退出在所探测节点上的登录，重置游标指针，重新探测，转步骤(7)；

若：所探测节点为从属服务器则退出在所探测节点上的登录，转步骤(7)；

若：所探测节点当前为仲裁服务器状态，且本节点也为仲裁服务器状态，则根据优先级确定最终候选者，一旦本节点候选失败，则遣散所有本节点上的登录者并勒令登录者转换为初始状态，而本节点转为从属服务器，同时结束本节点的探测流程；

若：所探测节点当前为主服务器状态，则遣散所有在本节点上的登录者，并勒令所有登录者转为初始状态重新探测，而本节点则转为从属服务器状态，结束本节点的探测流程；

若：所探测的节点其状态为未知，则退出在所探测节点上的登录，转步骤(6)；

步骤(6).若本节点探测到节点链表末尾且仍然为初始状态，检查本节点的权重，将本节点转换为Arbitrator；

步骤(7).转步骤(3)，开始下一轮探测；

步骤(8).若本节点收到其他节点的探测请求，则建立连接，发回同意连接的消息；

步骤(9).若本节点收到其他节点的登录信息，则向对方节点发回本节点的具体信息，并作以下处理：

步骤(9.1).若本节点处于初始状态或从属服务器状态下，则转步骤(3)，否则接受对方登录；

步骤(9.2).若本节点已经处于主服务器状态，则结束本节点的探测流程，否则执行步骤(9.3)；

步骤(9.3).若本节点处于仲裁服务器状态，且本集群中的权重已足够使本集群转为Quorate状态，则记录对方节点在本集群中的权重，本节点转为主服务器状态，结束本节点的探测流程；

步骤(10).把事件内容记录入日志，转步骤(3)；

对于Lock Quorum，探测一个节点前还必须确认该节点已经存在于State Quorum中，否则说明该被探测节点为不可用节点，可能已出故障或者由于通信链路问题被隔绝于集群之外。

各个Lock Quorum分管名字空间的不同分段，其服务能力由配置文件中<thudlm_dom>标签的weight属性记录，在系统启动时被读入内存。

整个名字空间在Lock Quorum中被映射到一个水平的哈希地址空间，设哈希值有n位，则整个哈希地址空间可表示为{i|0≤i≤2ⁿ}。各个Lock Quorum所管理的名字空间分段信息都记录在资源表RT中。每个RT表项主要包含两个域：(1)哈希地址hash_addr，对应名字空间某数据资源；(2)Lock Quorum的标识lqid，例如，整个集群系统中包含m个Lock Quorum，其lqid分别为1、2、......、m。通过这样的表项，RT才能够将哈希地址空间映射到各个LockQuorum。下文中，令RT_i代表RT中由隶属于LQ_i的表项组成的集合，即RT_i＝{p|p∈RT∧p.lqid＝i}；设整个集群系统包含m个Lock Quorum，分别为LQ₁、LQ₂、......、LQ_m，各Quorum的权重分别为w₁、w₂、......、w_m。

各Lock Quorum的Master负责统计本Quorum的负载情况。以LQ_i为例，每隔周期T为RT_i中的每个表项，例如表项p，计算负载值load_p。load_p反应了单位时间内接收到的对p所代表数据资源的锁请求数，计算公式为load_p(T)＝(1-α)×ar_p+α×load_p(T-1)。其中，ar_p为当前周期计算得到的单位时间内接收锁请求数；α为历史因子，用于表示load_p历史数值在新计算得到的load_p数值中所占的比例。当一个Lock Quorum所负担的锁管理任务过于繁重时，会触发负载平衡过程，将本Quorum的部分任务分流给其他Quorum，其主要步骤如图4。

负载平衡过程由State Quorum中的State Master完成，它负责接收各Lock Quorum的负载信息，在负载平衡过程完成后，State Master会广播新的RT给State Quorum的所有成员。负载平衡过程按照各Lock Quorum的处理能力，即权重，均衡分布资源，将过载Lock Quorum中的部分RT资源表项分流给轻负载的Lock Quorum。该问题可以看作是装箱问题的扩展，过载服务器中的过载服务量可看成是各个物品，轻载服务器的剩余容量可看作是空箱，当然这里的空箱体积各不相同，而且物品可以分割，增加了复杂度，我们采用贪婪法求其近似解，力求使各物品能够装在最合适的箱子中，减少装箱次数，也就减少了负载平衡任务中的请求消息数。

负载平衡过程如下文所示。其中，我们为每个Lock Quorum维护一个目标链表target_list，用来存放本Lock Quorum过载时分流负载的对方Lock Quorum的lqid，以及分流的负载量，链表元素结构target_info包含三个域：id、loadvalue、next，分别对应lqid，负载量和指向下一个链表元素的指针。要使各个Lock Quorum达到完全的平衡是非常耗费资源的，因此，算法中引入了一个阈值参量Threshold，当过载Lock Quorum的最大过载量低于该阈值时，我们就认为系统达到了一个可接受的近似平衡状态而结束平衡算法；该值越小，平衡结果越精确，但算法耗费的时间也越多，各个Lock Quorum之间为平衡流量而传递的消息也越多。

步骤(1).各锁服务器子集群中的主服务器在时刻T为每个锁服务子集群LQ_i对应的资源表RT_i的每一项按下式计算负载load_p(T)，公式为load_p(T)＝(1-α)×ar_p+α×load_p(T-1)；

其中：

p为RT_i中的某个表项，1≤i≤m，m为锁子集群数；

ar_p为当前间隔T计算得到的单位时间内接收的锁请求数；

a为历史因子，表示(T-1)周期的负载值load_p(T-1)在T周期中新计算得到的负载load_p(T)中的比例；

步骤(2).各锁服务子集群计算各自的现实负载$\mathrm{current}\_\mathrm{load}\_{\mathrm{lq}}_i\left(T\right)=\underset{p{\in \mathrm{RT}}_i}{\Sigma }{\mathrm{load}}_p\left(T\right),1\le i\le m;$

步骤(3).状态侦测集群的主服务器通过锁代理收集各个锁服务子集群在同期T内的负载量，进而求出各锁服务子集群按各自权重所应负担的理论负载量post_load_lq_i(T)，同时，求出各锁服务子集群的过载负载量delta_lq_i(T)，该过载负载量为现实负载量与理论负载量之差，即：delta_lq_i(T)＝post_load_lq_i(T)-current_load_lq_i(T)；

步骤(4).根据所述过载负载量delta_lq_i(T)的正负，把各个锁服务子集群分别划分到轻载集合和过载集合；

步骤(5).按以下步骤使负载量近似均衡分布：

步骤(5.1).结束条件判断：当过载集合或轻载集合中其中任何一个为空，或最大过载量低于设定的阈值时则转步骤(5.5)，否则，执行步骤(5.2)；

步骤(5.2).对于过载集合中的每一个元素，在轻载集合中寻求最佳分流匹配，把已匹配成对的从相应集合中去除，并把要分流的负载量记录到相应的过载集合的元素上；

步骤(5.3).对于轻载集合中的每一个元素，在过载集合中寻求最佳负载与分流匹配，并把已匹配的从相应集合中去除，把要分流的负载量仍然记录在过载集合的元素上；

步骤(5.4).结束一轮匹配，转步骤(5.1)；

步骤(5.5).负载分流，遍历过载集合中的每个节点，根据记录的分流信息把相应的流量分流到相应的轻载集合中。