[发明专利]一种基于更新序列的分布式锁状态同步方法

说明书

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

技术领域

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

背景技术

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

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

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

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

如图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)此时，主节点和从节点的锁状态已经不一致。