CN112100190A - 一种基于更新序列的分布式锁状态同步方法 - Google Patents

Abstract

本发明涉及一种基于更新序列的分布式锁状态同步方法，其主要技术特点是：在每个从节点锁对象上设置更新序列，主节点维护各个从节点持有锁状态的记录，并在每个记录上设置更新序列；从节点向主节点发送加锁请求；主节点根据请求节点锁状态进行加锁处理，返回加锁成功消息，或者向当前持有锁的冲突节点发送放锁请求；从节点收根据从节点锁状态进行放锁处理并返回放锁成功消息；主节点检查冲突节点锁状态当前的更新序列，再次尝试加锁处理；从节点检查锁状态当前的更新序列并再次尝试加锁。本发明设计合理，能够有效地维护各个节点之间锁状态的一致性，保证了数据库服务的正常运行，防止数据库服务的中断，提高了系统运行的安全性和可靠性。

Description

一种基于更新序列的分布式锁状态同步方法

技术领域

本发明属于数据库技术领域，涉及分布式锁定同步方法，尤其是一种基于更新序列的分布式锁状态同步方法。

背景技术

在共享存储集群环境中，每个数据库实例节点可以独立地提供服务，节点操作位于共享存储设施上的数据内容。集群中各个节点在提供服务的同时，需要对共享存储上的数据进行访问。当有多个节点同时访问同一项数据库资源时，由于并发操作的原因，可能会造成数据的不一致。通用的解决方案是，在访问某项数据库资源之前，必须要获得该项资源对应的锁。只有获得锁的事务，可以操作资源；其他想要操作同一资源的事务只能等待持有锁的事务放锁后，再尝试获得锁进行操作。

在集群环境中，上述锁为分布式锁。分布式锁由分布式锁管理器统一进行管理，多个节点发起的加锁请求，需要通过主节点上的分布式锁管理器进行协调，当满足加锁条件后，会将锁分配给请求节点；否则，请求节点只能等待。当发生加锁冲突，分布式锁管理器还会请求持有锁的节点放锁。因此，从节点会向主节点请求加锁，主节点会请求从节点放锁。节点之间通过高速网络进行交互，发送加锁和放锁的请求。

在集群环境中，节点的锁请求都是并发进行的。分布式锁管理器并发处理多个加锁放锁请求。同时，由于加锁和放锁的请求都要通过网络进行发送，在通信网络较差或不稳定的环境下，可能会造成请求丢失、回复延迟等现象，因此，一个节点在发起加锁请求的同时，可能又会接收到放锁请求，或者，在处理放锁的同时，又接到同一节点的加锁请求。在高并发的场景下，这种现象尤其频繁。

由于加锁、放锁都会影响到节点对于锁状态的处理，因此，需要仔细的处理上述由于并发请求和网络延迟可能导致的集群中主从节点锁状态不一致的问题。下面给出两个具体实例对不一致问题的情况进行说明：

如图4所示，其处理过程为：(1)从节点N1向主节点发送加锁请求。(2)主节点分布式锁管理器处理加锁请求，并返回加锁成功消息；此时锁管理器认为从节点N1持有锁。(3)此时，另一节点N2请求加锁，锁管理器判定发生锁冲突；主节点向持有锁的节点N1发送放锁请求。(4)由于网络延迟，消息产生乱序；从节点N1首先接到放锁请求，此时节点还未持有锁，向主节点返回放锁成功消息。(5)主节点收到从节点N1返回的消息，认为N1此时不再持有锁。(6)由于网络延迟，消息产生乱序。从节点N1此时才接到主节点发来的加锁成功消息。从节点加锁成功。(7)此时，主节点和从节点的锁状态已经不一致。

如图5所示，其处理过程为：(1)从节点N1向主节点发送加锁请求，主节点锁管理器加锁成功，并返回加锁成功消息。(2)从节点N1收到加锁成功消息，此时，主从节点的锁状态是一致的，都认为从节点已经持有锁。(3)此时，另一节点N2请求加锁，锁管理器判定发生锁冲突；主节点向持有锁的节点N1发送放锁请求。(4)从节点N1收到放锁请求，放锁后向主节点返回放锁成功消息；此时从节点不再持有锁。(5)因为此时从节点N1未持有锁，再次向主节点请求加锁。(6)由于网络延迟，消息产生乱序；主节点首先接收到N1的加锁请求，并返回加锁成功消息。(7)从节点N1收到主节点返回的加锁成功消息，认为自己持有锁。(8)由于网络延迟，消息产生乱序。主节点此时才接到N1发来的放锁成功消息。认为从节点N1不再持有锁。(9)此时，主节点和从节点的锁状态已经不一致。

上述两个实例都产生了主从节点锁状态不一致的现象。从节点认为自己持有锁，可以进一步对数据库资源进行操作；而主节点认为从节点不持有锁，因此可能将锁分配给其他节点。其他节点拿到锁之后，对同一数据库资源进行操作，因此存在多个事务并发操作同一数据库资源的可能，造成数据库不一致。在高并发的场景下，发生不一致的概率会大大增加。一旦产生数据不一致状态，轻则影响业务需求，重则发生宕机，造成数据库服务中断。

发明内容

本发明的目的在于克服现有技术的不足，提出一种设计合理且能够有效维护各个节点之间锁状态的一致性的基于更新序列的分布式锁状态同步方法。

本发明解决其技术问题是采取以下技术方案实现的：

一种基于更新序列的分布式锁状态同步方法，包括以下步骤：

步骤1、在每个从节点锁对象上设置更新序列，主节点维护各个从节点持有锁状态的记录，并在每个记录上设置更新序列；

步骤2、从节点向主节点发送加锁请求；

步骤3、主节点收到从节点的加锁请求后，根据请求节点锁状态进行加锁处理，返回加锁成功消息，或者向当前持有锁的冲突节点发送放锁请求；

步骤4、从节点收到主节点的放锁请求后，根据从节点锁状态进行放锁处理并返回放锁成功消息；

步骤5、主节点收到从节点返回的冲突节点放锁成功消息后，检查冲突节点锁状态当前的更新序列，再次尝试加锁处理；

步骤6、从节点收到主节点的加锁成功消息后，检查锁状态当前的更新序列并再次尝试加锁。

进一步，所述更新序列的长度为8字节，所述更新序列的初始值为0。

进一步，所述步骤2的具体处理方法为：

⑴如果从节点的锁状态为持有锁，则加锁成功；

⑵如果本节点锁状态为未持有锁，记录锁状态当前的更新序列；

⑶向主节点发送加锁请求，并等待请求返回。

进一步，所述步骤3的具体处理方法为：

⑴主节点根据收到的加锁请求进行判断，如果请求节点锁状态为持有锁，返回加锁成功消息；

⑵请求节点锁状态为未持有锁，如果不存在锁冲突，则更新请求节点锁状态为持有锁，对应的更新序列值加一，返回加锁成功消息；

⑶如果存在锁冲突，则记录冲突节点锁状态当前的更新序列，并向当前持有锁的冲突节点发送放锁请求。

进一步，所述步骤4的具体处理方法为：

⑴从节点收到放锁请求后进行判断，如果本节点的锁状态为未持有锁，则返回放锁成功消息；

⑵如果本节点的锁状态为持有锁，则更新锁状态为未持有锁，更新序列值加一，返回放锁成功消息。

进一步，所述步骤5的具体处理方法为：

⑴检查冲突节点锁状态当前的更新序列是否与发起请求前记录的更新序列一致；

⑵如果一致，则更新冲突节点锁状态为未持有锁，更新序列值加一，放锁成功，并转到步骤3；

⑶如果不一致，则直接转到步骤3。

进一步，所述步骤6的具体处理方法为：

⑴检查锁状态当前的更新序列是否与发起请求前记录的更新序列一致；

⑵如果一致，则更新锁状态为持有锁，更新序列值加一，转到步骤2；

⑶如果不一致，则直接转到步骤2。

本发明的优点和积极效果是：

本发明设计合理，其给每个从节点锁对象上设置更新序列并通过主节点维护各个从节点持有锁状态的记录，在加锁及解锁过程中对更新序列实施进行更新，完成相应的加锁解锁处理功能，能够有效地维护各个节点之间锁状态的一致性，保证了数据库服务的正常运行，防止数据库服务的中断，提高了系统运行的安全性和可靠性。

附图说明

图1为本发明的从节点请求加锁的处理流程图；

图2为本发明的主节点加锁与请求放锁的处理流程图；

图3为本发明的从节点放锁的处理流程图；

图4为现有技术导致集群中主从节点锁状态不一致问题的示例1；

图5为现有技术导致集群中主从节点锁状态不一致问题的示例2。

具体实施方式

以下结合附图对本发明做进一步详述。

本发明的设计思想是：集群中每个从节点记录自己持有的锁状态，同时为该锁状态维护一个更新序列；主节点记录各个从节点持有的锁状态，同时为每个从节点的锁状态维护一个更新序列。每当从节点的锁状态或者主节点上记录的从节点锁状态发生变化时，其对应的更新序列值加一。当主节点接到请求的反馈消息时，首先判断锁上的更新序列与发送请求时记录的序列值是否一致，若一致，可以更新锁状态，同时对应的更新序列值加一。若不一致，说明存在乱序消息，锁状态在等待请求返回期间，已经发生了变化，不能直接更新，需要丢弃此反馈消息，然后重试。

一种基于更新序列的分布式锁状态同步方法，包括以下步骤：

步骤1、在每个从节点锁对象上设置8字节长度的更新序列，主节点维护各个从节点持有锁状态的记录，并在每个记录上设置8字节长度的更新序列。

本发明为了能够维护主从节点锁状态的一致性，在每个从节点锁对象上设置8字节长度的更新序列。在主节点上维护各个节点持有锁状态的记录，同时在每个记录上设置8字节长度的更新序列。

在本实施例中，各个从节点的更新序列在初始化时被设置为0。

步骤2、从节点提出加锁请求，向主节点发送加锁请求。

如图1所示，本步骤的处理过程为：

(1)若本节点锁状态为持有锁，加锁成功。

(2)本节点锁状态为未持有锁，向主节点发起加锁请求，在发起请求前记录锁状态当前的更新序列。

(3)向主节点发送加锁请求，并等待请求返回。

步骤3、主节点根据从节点的加锁请求，检查请求节点锁状态进行加锁处理。

如图2所示，本步骤的处理过程为：

(1)主节点分布式锁管理器根据收到的加锁请求进行判断，如果请求节点锁状态为持有锁，返回加锁成功消息。

(2)请求节点锁状态为未持有锁，若不存在锁冲突，则更新请求节点锁状态为持有锁，对应的更新序列值加一，返回加锁成功消息。

(3)若存在锁冲突，则向当前持有锁的冲突节点发送放锁请求，在发起请求前记录冲突节点锁状态当前的更新序列。

步骤4、从节点收到主节点的放锁请求后，根据本节点的锁状态进行放锁处理并返回放锁成功消息。

如图3所示，本步骤的处理过程为：

(1)从节点收到放锁请求后进行判断，如果本节点的锁状态为未持有锁，则返回放锁成功消息。

(2)如果本节点的锁状态为持有锁，则更新锁状态为未持有锁，更新序列值加一，返回放锁成功消息。

步骤5、主节点收到从节点返回的冲突节点放锁成功消息后，检查冲突节点锁状态当前的更新序列，再次尝试加锁处理。

本步骤的具体实现方法为：

(1)检查冲突节点锁状态当前的更新序列，是否与发起请求前记录的更新序列一致。

(2)若一致，则更新冲突节点锁状态为未持有锁，更新序列值加一，放锁成功。转到步骤3，再次尝试加锁。

(3)若不一致，则说明冲突节点锁状态已经发生变化，直接转到步骤3，重新尝试加锁。

步骤6、从节点收到主节点的加锁成功消息后，检查锁状态当前的更新序列并再次尝试加锁。

本步骤的具体实现方法为：

(1)检查锁状态当前的更新序列，是否与发起请求前记录的更新序列一致。

(2)若一致，则更新锁状态为持有锁，更新序列值加一，转到步骤2，再次尝试加锁。

(3)若不一致，则说明锁状态已经发生变化，转到步骤2，重新尝试加锁。

需要强调的是，本发明所述的实施例是说明性的，而不是限定性的，因此本发明包括并不限于具体实施方式中所述的实施例，凡是由本领域技术人员根据本发明的技术方案得出的其他实施方式，同样属于本发明保护的范围。

Claims (7)

1.一种基于更新序列的分布式锁状态同步方法，其特征在于：包括以下步骤：

步骤1、在每个从节点锁对象上设置更新序列，主节点维护各个从节点持有锁状态的记录，并在每个记录上设置更新序列；

步骤2、从节点向主节点发送加锁请求；

步骤3、主节点收到从节点的加锁请求后，根据请求节点锁状态进行加锁处理，返回加锁成功消息，或者向当前持有锁的冲突节点发送放锁请求；

步骤4、从节点收到主节点的放锁请求后，根据从节点锁状态进行放锁处理并返回放锁成功消息；

步骤5、主节点收到从节点返回的冲突节点放锁成功消息后，检查冲突节点锁状态当前的更新序列，再次尝试加锁处理；

步骤6、从节点收到主节点的加锁成功消息后，检查锁状态当前的更新序列并再次尝试加锁。

2.根据权利要求1所述的一种基于更新序列的分布式锁状态同步方法，其特征在于：所述更新序列的长度为8字节，所述更新序列的初始值为0。

3.根据权利要求1所述的一种基于更新序列的分布式锁状态同步方法，其特征在于：所述步骤2的具体处理方法为：

⑴如果从节点的锁状态为持有锁，则加锁成功；

⑵如果本节点锁状态为未持有锁，记录锁状态当前的更新序列；

⑶向主节点发送加锁请求，并等待请求返回。

4.根据权利要求1所述的一种基于更新序列的分布式锁状态同步方法，其特征在于：所述步骤3的具体处理方法为：

⑴主节点根据收到的加锁请求进行判断，如果请求节点锁状态为持有锁，返回加锁成功消息；

⑵请求节点锁状态为未持有锁，如果不存在锁冲突，则更新请求节点锁状态为持有锁，对应的更新序列值加一，返回加锁成功消息；

⑶如果存在锁冲突，则记录冲突节点锁状态当前的更新序列，并向当前持有锁的冲突节点发送放锁请求。

5.根据权利要求1所述的一种基于更新序列的分布式锁状态同步方法，其特征在于：所述步骤4的具体处理方法为：

⑴从节点收到放锁请求后进行判断，如果本节点的锁状态为未持有锁，则返回放锁成功消息；

⑵如果本节点的锁状态为持有锁，则更新锁状态为未持有锁，更新序列值加一，返回放锁成功消息。

6.根据权利要求1所述的一种基于更新序列的分布式锁状态同步方法，其特征在于：所述步骤5的具体处理方法为：

⑴检查冲突节点锁状态当前的更新序列是否与发起请求前记录的更新序列一致；

⑵如果一致，则更新冲突节点锁状态为未持有锁，更新序列值加一，放锁成功，并转到步骤3；

⑶如果不一致，则直接转到步骤3。

7.根据权利要求1所述的一种基于更新序列的分布式锁状态同步方法，其特征在于：所述步骤6的具体处理方法为：

⑴检查锁状态当前的更新序列是否与发起请求前记录的更新序列一致；

⑵如果一致，则更新锁状态为持有锁，更新序列值加一，转到步骤2；

⑶如果不一致，则直接转到步骤2。

Images