CN108023939A - 分布式系统中锁服务器故障的处理方法及其系统 - Google Patents
分布式系统中锁服务器故障的处理方法及其系统 Download PDFInfo
- Publication number
- CN108023939A CN108023939A CN201711118701.5A CN201711118701A CN108023939A CN 108023939 A CN108023939 A CN 108023939A CN 201711118701 A CN201711118701 A CN 201711118701A CN 108023939 A CN108023939 A CN 108023939A
- Authority
- CN
- China
- Prior art keywords
- lock
- server
- lock server
- adapter
- request
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2023—Failover techniques
- G06F11/203—Failover techniques using migration
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2023—Failover techniques
- G06F11/2028—Failover techniques eliminating a faulty processor or activating a spare
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/17—Details of further file system functions
- G06F16/176—Support for shared access to files; File sharing support
- G06F16/1767—Concurrency control, e.g. optimistic or pessimistic approaches
- G06F16/1774—Locking methods, e.g. locking methods for file systems allowing shared and concurrent access to files
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/805—Real-time
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Quality & Reliability (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Hardware Redundancy (AREA)
- Computer And Data Communications (AREA)
Abstract
一种分布式系统中锁服务器故障处理方法,分布式系统中包括m个锁服务器,每个锁服务器本地存储有同一锁服务器接管关系信息,m为大于2的自然数。分布式系统中未发生故障的锁服务器接收第一通知消息,所述第一通知消息中携带第一锁服务器发生故障的信息;第二锁服务器接收到第一通知消息后根据本地存储的锁服务器接管关系信息,确定自己是第一锁服务器的接管锁服务器,进入静默状态;第三锁服务器接收到第一通知消息后根据本地存储的锁服务器接管关系信息,确定自己不是第一锁服务器的接管锁服务器;第三锁服务器接收到加锁请求后,根据加锁请求分配锁权限信息。本发明可以把锁服务器发生故障所影响的范围减小到最小,提高分布式系统的稳定性。
Description
技术领域
本发明涉及存储技术,尤其是涉及一种分布式系统中的锁服务器(master)故障的处理方法及其系统。
背景技术
NAS(Network Attached Storage,网络附属存储)系统以其简单、高效和易管理等特点,广泛应用于企业文件分布式系统中的共享,其典型组网附图1所示。
在NAS系统中,同一文件可以接收不同的应用主机发送的读写请求,为了避免读写冲 突,当一个文件接收到某个应用主机的读写请求时,节点设备中的锁服务器需要把当前文 件加锁(锁权限),用于实现共享资源的并发互斥访问。当读写操作结束后,释放该文件。锁权限信息与应用主机之间的对应关系,可以存储在各节点中,也可以存储在一个共享存储中。共享存储独立于各节点,且各节点均可访问,在附图1中未示出。
近来,伴随虚拟化技术的发展,VDI(Virtual Desktop Infrastructure,虚拟桌面基础架构)、Oracle数据库和SQLServer(Structured Query Language,结构化查询语言)数据库平台等应用也开始部署到分布式系统中,从而对分布式系统的可靠性提出更高的要求。当分布式系统中的某个节点设备发生故障后,NAS系统会采用节点设备IP Failover(IP漂移)的方式,将发生故障的节点设备的IP地址配置到其他的节点设备上,增强NAS 系统的可靠性。这些切换对各应用主机来讲是透明,即各应用主机感知不到NAS系统中各 节点设备的IP漂移,从而减少对应用主机中各应用的影响。
NFS(Network File System,网络文件系统)V3是目前应用最久、最多的协议版本,但是由于该协议在锁的定义方面不完善,依赖于另外的辅助协议NLM(Network LockManager,网络锁管理器)和NSM(Network State Manager,网络状态管理器),导致NFS V3在锁恢复流程复杂。
如附图1所示,当节点设备1故障后,节点设备1的IP地址漂移到节点设备2,即将节点 设备1的IP地址配置到节点设备2。IP漂移对应用主机1来讲是透明的,也就是说应用主机1 并不知道节点设备之间发生的变化。在一些协议的设计方案中,例如NFS协议和SMB(Server Message Block,服务器信息块)协议,为了加速应用主机的访问效率,故障节点设备的 IP地址漂移到新的节点设备之后,应用主机可以通过锁重申(Reclaim)请求来重新申请 所述应用主机中的应用已经获取的文件的锁权限。这样分布式系统中的锁服务器需要安全 地对锁请求进行控制,例如锁重申请求或加锁请求,否则可能会由于权限控制不当导致多 个应用主机得到的数据不一致,甚至多个应用主机同时读写数据时造成系统崩溃的问题。
这样,当分布式系统中的某一节点设备发生故障时,例如节点设备中锁服务器发生故障时,分布式系统中的所述锁服务器全部静默,即,节点设备中的锁服务器进入 静默状态。这样,当节点设备中的协议服务器接收到锁重申请求时,根据锁重申请求 中携带的信息或者存储的锁权限把锁重申请求发送给对应的锁服务器处理;当协议服 务器接收到加锁请求时,直接向请求方回复拒绝的响应消息。加锁请求是应用主机中 的应用向锁服务器申请文件的新的锁权限。也就是说,在节点设备中的锁服务器为静 默状态时,分布式系统只能处理锁重申请求,不能处理加锁请求这样,虽然分布式系 统中只是一个锁服务器发生故障,但是由于将所述锁服务器都静默了,这样就使局部 问题变成了全局问题,并且不能处理正常的加锁请求,可能引起业务中断从而降低了 分布式系统的可靠性。
发明内容
本发明实施例提出一种分布式系统中一种锁服务器故障的处理方法及其系统,以解决现有技术中一个锁服务器发生故障时将所有锁服务器静默无法处理加锁请求从 而降低分布式系统可靠性的问题。
第一方面,本发明实施例提出的一种分布式系统中锁服务器故障的处理方法,所述分布式系统中包括至少三个锁服务器,其中,每个锁服务器中存储有同一锁服务器 接管关系信息,包括步骤:
所述分布式系统中未发生故障的锁服务器接收第一通知消息,所述第一通知消息中携带所述分布式系统中的第一锁服务器发生故障的信息;所述分布式系统中的第 二锁服务器接收到所述第一通知消息后,根据本地存储的锁服务器接管关系信息确定 自己为所述第一锁服务器的接管锁服务器,所述接管锁服务器进入静默状态;所述分 布式系统中的第三锁服务器接收到所述第一通知消息后,根据本地存储的锁服务器接 管关系信息,确定自己不是所述第一锁服务器的接管锁服务器;确定为非接管锁服务 器的第三锁服务器接收到加锁请求时,根据所述加锁请求分配锁权限信息。
结合第一方面,在第一方面的第一种可能的实现方式中,所述接管锁服务器接收到锁重申请求时,根据锁权限信息表返回对应的锁权限信息;所述接管锁服务器接收 到加锁请求时,返回拒绝的响应消息。
结合第一方面的第一种可能的实现方式,在第一方面的第二种可能的实现方式中,所述分布式系统中还包括至少三个协议服务器和相应的锁代理,所述协议服务器 和相应的锁代理位于同一节点设备中,所述方法还包括:当所述协议服务器接收到锁 请求后,将所述锁请求发送给的相应的锁代理,所述锁请求为锁重申请求或加锁请求。
结合第一方面的第二种可能的实现方式,在第一方面的第三种可能的实现方式中,所述每个锁代理本地存储有所述锁服务器接管关系信息和锁服务器管理范围信 息,所述方法还包括:所述锁代理接收到锁请求后,根据本地存储的锁服务器管理范 围信息确定处理所述锁请求的锁服务器;若所述锁服务器管理范围信息中确定出的处 理所述锁请求的锁服务器标识为故障状态,所述锁代理根据本地存储的锁服务器接管 关系信息确定所述故障状态的锁服务器的接管锁服务器;将接收到的锁请求发送给所 述接管锁服务器。
结合第一方面的第二种可能的实现方式,在第一方面的第四种可能的实现方式中,所述锁服务器接管关系信息通过一致性哈希环来确定,所述第三锁服务器根据本 地存储的锁服务器接管关系信息确定自己不是所述第一锁服务器的接管锁服务器具 体为:所述第三锁服务器按照本地存储的一致性哈希环的顺时针方向或者逆时针方向 确定自己不是所述第一锁服务器的接管锁服务器。
结合第一方面的第四种可能的实现方式,在第一方面的第五种可能的实现方式中,所述每个锁代理本地存储有所述锁服务器接管关系信息和锁服务器管理范围信 息,所述锁服务器管理范围信息和所述锁服务器接管关系信息通过所述一致性哈希环 来确定;所述锁代理接收到锁请求后,按照本地存储的一致性哈希环的顺时针方向或 者逆时针方向确定处理所述锁请求的锁服务器;若所述本地存储的一致性哈希环中的 所述处理所述锁请求的锁服务器标识为故障状态;所述锁代理按照本地存储的一致性 哈希环的同样的方向确定所述处理所述锁请求的锁服务器的接管锁服务器。
第二方面,本发明实施例提出的一种实现锁服务器故障处理的分布式系统,包括:至少三个锁服务器,所述每个锁服务器中存储有同一锁服务器接管关系信息;所述至 少三个锁服务器中未发生故障的锁服务器用于接收第一通知消息,所述第一通知消息 中携带第一锁服务器发生故障的信息;第二锁服务器用于根据本地存储的锁服务器接 管关系信息确定自己为所述第一锁服务器的接管锁服务器,所述接管锁服务器进入静 默状态;第三锁服务器用于根据本地存储的锁服务器接管关系信息,确定自己不是所 述第一锁服务器的接管锁服务器;确定为非接管锁服务器的所述第三锁服务器用于接 收到加锁请求后,根据所述加锁请求分配锁权限信息。
第三方面,本发明实施例提出的一种在分布式系统中实现故障处理的锁服务器,所述锁服务器包括接收模块801、处理模块803和存储模块805,所述存储模块805 中存储有锁服务器接管关系信息;所述接收模块801用于接收第一通知消息,并将所 述第一通知消息发送给所述处理模块803;所述第一通知消息中携带有故障锁服务器 的信息;所述处理模块803用于接收到第一通知消息后,根据所述锁服务器接管关系 信息,确定自己是否是故障锁服务器的接管锁服务器;若为所述故障锁服务器的接管 锁服务器,所述锁服务器进入静默状态;所述处理模块803还用于接收到加锁请求之 后,确定所述锁服务器是否处于静默状态,如果所述锁服务器不处于静默状态,则根 据所述加锁请求分配锁权限信息;若所述锁服务器处于静默状态,则返回拒绝的响应 消息,并将分配的锁权限信息或拒绝的响应消息发送给接收模块801;所述接收模块 801还用于将接收到的锁权限信息或者拒绝的响应消息返回给锁代理。
第四方面,本发明实施例提出的一种在分布式系统中实现故障处理的锁服务器,包括:存储器901,被配置为存储有锁服务器接管关系信息和锁权限信息表;接口902, 被配置为用于提供对外连接;计算机可读介质903,被配置为用于存储计算机程序; 处理器904,和所述存储器901、接口902、计算机可读介质903连接,被配置为用于 通过运行所述程序,执行上述的锁服务器故障处理方法。
第五方面,本发明实施例提出的一种在分布式系统中实现故障处理的锁代理装置,包括接收模块1001、处理模块1003、存储模块1005和发送模块1007,其特征在 于:所述接收模块1001用于接收协议服务器发送的锁请求,并将接收的锁请求发送 给处理模块1003,其中所述锁请求是锁重申请求或加锁请求;所述处理模块1003用 于接收到锁请求之后,根据存储模块1003中存储的锁服务器管理范围信息,确定处 理所述锁请求的锁服务器,将接收到的锁请求发送给发送模块1007;所述发送模块 1007用于将锁请求发送给确定的锁服务器。
结合第五方面,在第五方面的第一种可能的实现方式中,锁服务器接管关系信息和锁服务器管理范围信息通过一致性哈希环来确定;所述处理模块1003根据存储模 块1005中存储的锁服务器管理范围信息具体为:处理模块1003按照所述一致性哈希 环的顺时针方向或者逆时针方向确定所述处理所述锁请求的锁服务器;所述处理模块 1003根据存储模块1005中存储的锁服务器接管关系信息确定所述处理所述锁请求的 锁服务器的接管锁服务器具体为:处理模块1003按照所述一致性哈希环的相同的方 向确定所述处理所述锁请求的锁服务器的接管锁服务器。
第六方面,本发明实施例提出的一种在分布式系统中实现故障处理的锁代理设备,包括:存储器1101,被配置为存储有锁服务器接管关系信息和锁服务器管理范围 信息;接口1102,被配置为用于提供对外连接;计算机可读介质1103,被配置为用 于存储计算机程序;处理器1104,和所述存储器1101、接口1102、计算机可读介质 1103连接,被配置为用于通过运行所述程序,执行上述锁服务器故障处理方法。
第七方面,本发明实施例提出的一种在分布式系统中实现故障处理的锁管理器,包括如上所述的锁服务器和如上所述的锁代理装置。
本发明实施例提出在分布式系统中的锁服务器中记录各个锁服务器接管关系信息,这样当其中一个锁服务器发生故障时,根据所述锁服务器的接管关系信息确认故 障锁服务器的接管锁服务器,仅将接管锁服务器静默,其他的非接管锁服务器正常运 行,可以正常处理加锁请求。通过这种方法,当分布式系统中的某个锁服务器发生故 障时,可以将受影响的范围减小到最小,只将接管服务器静默,其他的非接管锁服务 器正常运行,不影响业务的正常运行,提高了分布式系统的稳定性。
附图说明
图1为现有技术中的分布式系统结构示意图;
图2为本发明实施例提供的一种分布式系统结构示意图;
图3-1为本发明实施例提供的一种一致性哈希环示意图;
图3-2为本发明实施例提供的另一种一致性哈希环示意图;
图3-3为本发明实施例提供的一种更新后的一致性哈希环示意图;
图3-4为本发明实施例提供的又一种一致性哈希环示意图;
图3-5为本发明实施例提供的一种更新后的一致性哈希环示意图;
图4-1为本发明实施例提供的一种实现锁服务器故障处理方法的分布式系统的结构示意图;
图4-2为本发明实施例提供的一种分布式系统中锁服务器故障处理方法的流程示意图;
图4-3为本发明实施例提供的另一种分布式系统中锁服务器故障处理方法的流程示意图;
图5-1为本发明实施例提供的一种实现锁服务器故障处理方法的分布式系统的结构示意图;
图5-2为本发明实施例提供的一种分布式系统中锁服务器故障处理方法的流程示意图;
图5-3为本发明实施例提供的一种一致性哈希环的示意图;
图6-1为本发明实施例提供的又一种实现锁服务器故障处理方法的分布式系统的结构示意图;
图6-2为本发明实施例提供的一种分布式系统中锁服务器故障处理方法的流程示意图;
图7为本发明实施例提供的一种处理锁服务器故障的分布式系统结构示意图;
图8为本发明实施例提供的一种在分布式系统中实现故障处理的锁服务器结构示意图;
图9为本发明实施例提供的一种在分布式系统中实现故障处理的锁服务器设备示意图;
图10为本发明实施例提供的一种在分布式系统中实现故障处理的锁代理结构示意图;
图11为本发明实施例提供的一种在分布式系统中实现故障处理的锁代理设备示意图;
图12为本发明实施例提供的一种在分布式系统中实现故障处理的锁管理器结构示意图;
图13为本发明实施例提供的一种在分布式系统中实现故障处理的节点设备示意图。
具体实施方式
本发明实施例针对分布式系统中一个锁服务器故障需要将全部锁服务器静默并且静默期只能处理锁重申请求不能处理加锁请求的问题,提出在分布式系统的各个锁 服务器中存储锁服务器接管关系信息,这样,当某个锁服务器发生故障时,通过所述 锁服务器接管关系信息,确定所述故障锁服务器的接管锁服务器,其他的非接管锁服 务器(系统中除接管锁服务器之外的其他锁服务器)可以正常的处理加锁请求,这样, 将锁服务器发生故障影响的范围减小到最少,提高整个系统的可靠性。
本发明实施例涉及的分布式系统如附图2所示。多个应用主机通过NAS网络与多个节点设备相连。每个节点设备中包括协议服务器和锁代理。协议服务器为使用不同 协议的服务器,例如,FC服务器、NFS服务器、SMB服务器,与上层应用主机通过NAS 网络进行通信,基本工作原理类似。协议服务器与锁代理一一对应,位于同一节点设 备中。锁代理还与锁服务器对应,锁服务器可以与协议服务器和锁代理位于同一节点 设备中,也可以单独位于另一节点中。在本发明实施例中,锁服务器与协议服务器和 锁代理位于一个节点设备中。
分布式系统中可以单独设立一个管理节点,控制管理各个节点设备,也可以由一节点设备来执行各节点设备的管理控制。管理控制各节点设备的节点设备一般为主节 点设备,也可以称之为管理节点设备。
如附图2所示,所述分布式系统包括n个节点设备,n为大于2的自然数。每个 节点设备中分别包含了一个协议服务器PS和一个锁代理P。为了便于区分,节点设备 1中的协议服务器和锁代理分别以PS1和P1来表示。同样的,节点设备2中的协议服 务器和锁代理分别以PS2和P2来表示。以此类推,在此不再一一说明。
如上所述,锁服务器可以与协议服务器和锁代理位于一个节点设备中,也可以位于不同的节点设备中。锁服务器使用S来表示。附图2所示的分布式系统中,可以 包含m个锁服务器,m为大于2的自然数。一个锁服务器可以与节点设备中的多个锁 代理对应,即锁服务器S1可以与节点设备1中的锁代理P1对应,也可以和节点设备 2中的锁代理P2对应。
为了使图示更清晰明了,在附图2中,锁服务器与协议服务器和锁代理在一个节点设备中。例如,锁服务器S1与锁代理P1和协议服务器PS1位于节点设备1中,锁 服务器S2与锁代理P2和协议服务器PS2位于节点设备2中,以此类推。这种情况下, 一个锁服务器仍然可以和多个锁代理对应。不过这种情况下,锁代理可以共享本节点 中锁服务器存储的信息,因此,锁代理的缓存中可以存储较少的信息。
本发明实施例中,当分布式系统中有锁服务器发生故障时,可以由分布式系统中的其他锁服务器来接管所述故障锁服务器的锁相关业务,接管故障锁服务器的锁相关 业务的锁服务器称为接管锁服务器。当有锁服务器发生故障时,可以由一个接管锁服 务器接管故障锁服务器的锁相关业务,也可以有多个接管锁服务器来接管故障锁服务 器的锁相关业务。在下面的实施例中,以一个接管锁服务器的情况来进行说明。当有 多个接管锁服务器时,其实现原理类似,只是需要预先设置算法来将故障锁服务器的 锁相关业务在多个接管锁服务器之间进行分配。在此不再详述。
本发明实施例可以采用两种方式来记录锁服务器接管关系信息,一种是采用表格的方式来记录(如表一所示),另外一种是通过一致性哈希环的方式来确定(如附图 3所示)。
本发明实施例以分布式系统中有四个锁服务器为例来进行说明,这四个锁服务器分别为S1、S2、S3、和S4,使用表格的方式来记录锁服务器接管关系信息的方式如 表一(锁服务器接管关系表)所示。锁服务器接管关系记录表由管理节点统一配置, 并发送给所有的锁服务器保存,也可以在锁服务器中分别配置。
锁服务器 | 接管锁服务器 |
S1 | S2 |
S2 | S4 |
S4 | S3 |
S3 | S1 |
表一锁服务器接管关系表
如表一所示,当锁服务器S1发生故障时,分布式系统中的未发生故障的锁服务 器会接收到通知消息,接收到通知消息后根据本地存储的锁服务器接管关系表,来确 定自己是否为锁服务器S1的接管服务器。如表一所示,S2确定自己是锁服务器S1的 接管锁服务器,S3确定自己不是锁服务器S1的接管锁服务器,S4确定自己不是锁服 务器S1的接管锁服务器。根据确认结果,锁服务器S2进入静默状态,此时只处理锁 重申请求不处理加锁请求,而锁服务器S3和S4不静默,可以正常的处理加锁请求。
本发明实施例还提供另外一种记录锁服务器接管关系信息的方式,按照一致性哈希环特定的顺序来确定分布式系统中各个锁服务器的接管关系。
当锁服务器与锁代理和协议服务器位于同一节点设备中时,可以对节点名称利用一致性哈希算法得到一致性哈希环,或者是对节点设备的IP地址利用一致性哈希算 法得到一致性哈希环。当锁服务器不与锁代理和协议服务器在同一节点设备中时,可 以对锁服务器的名称或者ID利用一致性哈希算法得到一致性哈希环。当然,也可以 根据锁服务器的其他标识利用一致性哈希算法得到一致性哈希环。本发明实施例中, 以根据锁服务器的ID利用一致性哈希算法进行哈希计算得到一致性哈希环为例进行 说明。
管理节点预先在各个锁服务器中配置一致性哈希算法、锁服务器接管关系的确定规则等信息。这样,在系统初始化启动后,各服务器根据预先配置的信息进行相应的 哈希计算,得到表示锁服务器接管关系的一致性哈希环。由于算法、参数和范围确定 规则都是相同的,因此各锁服务器计算得到的一致性哈希环是相同的。当然,也可以 由管理节点根据预先配置的信息计算得到一致性哈希环,再将计算得到的一致性哈希 环广播给各锁服务器。还可以由管理节点和各个锁服务器分别计算得到一致性哈希 环,这时算法、参数和预定的规则都是相同的,因此管理节点和各个锁服务器分别计 算得到的一致性哈希环和确定的接管锁服务器也是相同的。
下面以锁服务器对各个锁服务器的ID进行哈希计算得到一致性哈希环为例进行说明。例如,分布式系统中有4个锁服务器,其ID分别为1、2、3、4,各个锁服务 器分别将ID利用一致性哈希算法进行哈希计算,并按顺时针方向,将计算结果按从 小到大的顺序进行排列,得到一致性哈希环。如附图3-1所示,一致性哈希环为0-232, 对锁服务器的ID进行哈希计算得到的结果依次为hash(S1)=5000,hash(S2)=8000, hash(S3)=1024,hash(S4)=512,按顺时针方向,从0开始,锁服务器在哈希环上的 位置依次是锁服务器S4、锁服务器S3、锁服务器S1和锁服务器S2。
然后,也可以按逆时针的方向将计算结果按从小到大的顺序进行排列,得到一致性哈希环,如附图3-2所示。锁服务器在哈希环上的位置按逆时针方向依次是锁服务 器S4、锁服务器S3、锁服务器S1和锁服务器S2。
锁服务器的接管关系的确定可以按生成的一致性哈希环的顺时针方向来确定接管锁服务器,也可以按生成的一致性哈希环的逆时针原则来确定接管锁服务器。
如附图3-1所示,所述一致性哈希环是按锁服务器的ID的哈希计算结果按顺时 针排列的。如果按一致性哈希环的照顺时针方向来确定锁服务器接管关系,那么锁服 务器S1的接管锁服务器为S2,锁服务器S2的接管锁服务器为S4,锁服务器S4的接 管锁服务器为S3,锁服务器S3的接管锁服务器为S1。同埋,如果按附图3-1中的一 致性哈希环的逆时针方向来确定锁服务器接管关系,锁服务器S1的接管锁服务器为 S3,锁服务器S3的接管锁服务器为S4,锁服务器S4的接管锁服务器为S2,锁服务 器S2的接管锁服务器为S1。
对于如附图3-2所示的一致性哈希环,也可以按一致性哈希环的顺时针方向或者按一致性哈希环的逆时针方向来确定接管锁服务器,其实现原理与上段描述的相同, 在此不再一一举例说明。
因此,按照利用锁服务器标识生成的一致性哈希环的顺时针方向或者按一致性哈希环的逆时针方向,就可以确定锁服务器的接管关系。
当锁服务器与锁代理和协议服务器位于同一节点设备中时,各个锁服务器接管关系的确定原则与上述方法类似;不同点在于,此时的一致性哈希环可以根据节点的名 称来利用一致性哈希算法得到。在此不再详细描述。
在本发明实施例中,节点设备中的锁代理也需要存储锁服务器接管关系信息,除此以外,还需要存储锁服务器管理范围信息。这样,锁代理接收到锁请求(例如锁重 申请求或者加锁请求)后,根据存储的锁服务器管理范围信息确定该锁请求应该由哪 个锁服务器处理。如果确定处理锁请求的锁服务器发生故障时,根据锁服务器接管关 系信息确定接管锁服务器,将锁请求发送给接管锁服务器处理。
锁代理存储的锁服务器接管关系信息与锁服务器中存储的锁服务器接管关系信息相同。当使用锁服务器接管关系表来记录锁服务器接管关系信息时,锁服务器接管 关系表由管理节点统一配置,并发送给所有的锁代理保存。当通过一致性哈希环来确 定锁服务器接管关系信息时,可以由管理节点计算出一致性哈希环之后发送给各个锁 代理,也可以通过管理节点事先配置锁代理,由各个锁代理分别计算得到相同的一致 性哈希环,还可以由管理节点和各个锁代理分别计算得到相同的一致性哈希环,锁代 理的一致性哈希环与锁服务器中的一致性哈希环相同。锁代理中锁服务器接管关系信 息的记录方式与锁服务器中的锁服务器接管关系信息的记录方式相同,在上文已进行 了详细的描述,此处不再另行说明。
在锁代理中的锁服务器接管关系信息使用锁服务器接管关系表来记录的情况下,锁代理中的锁服务器管理范围信息也使用表格的方式来记录(如表二所示)。可以由 管理节点预先配置好,以锁服务器管理范围记录表的方式发送给各个锁代理。所述锁 服务器管理范围记录表如表二所示。
锁服务器 | 锁服务器管理范围 |
S1 | 1024-5000 |
S2 | 5000-8000 |
S4 | 8000-512 |
S3 | 512-1024 |
表二锁服务器管理范围记录表
锁代理接收到锁请求之后,对锁请求中的文件的标识利用相同的一致性哈希算法进行哈希计算,看计算出的结果落入哪个范围,则由对应的锁服务器负责处理。例如, 锁请求为加锁请求,加锁请求中携带的文件为(foo1.txt),锁代理对(foo1.txt)进行 哈希计算,得到的结果为4500,应该由锁服务器S1管理,锁代理将加锁请求发送给 锁服务器S1。再如,锁重申请求中携带的文件信息为(foo8.txt),锁代理对(foo8.txt) 进行哈希计算,得到的结果为9000,应该由锁服务器S4管理,锁代理将加锁请求发 送给锁服务器S4。如果锁代理根据锁服务器管理范围信息确定的锁服务器发生了故 障,那么还要根据锁服务器接管关系信息来确定故障锁服务器的接管锁服务器。
锁服务器管理范围信息和锁服务器接管关系信息可以体现在一个表(如:表三,锁服务器信息表)中,也可以分别存储为如表一和表二所示的锁服务器接管关系表和 锁服务器管理范围记录表。
表三锁服务器信息表
当某个锁服务器发生故障后,锁代理将锁服务器管理范围记录表、锁服务器接管关系表和/或锁服务器信息表中的发生故障的锁服务器标识为故障。当锁代理接收到 锁请求之后,对锁请求中携带的文件的唯一标识进行哈希计算,根据锁服务器管理范 围记录表或者锁服务器信息表确定计算出来的结果落入哪个锁服务器的管理范围,如 果确定的锁服务器为故障状态,锁代理再根据锁服务器接管关系表或者锁服务器信息 表确定所述故障锁服务器的接管锁服务器,将锁请求发送给接管锁服务器处理。
如表三所示,锁服务器S2故障。锁代理接收到锁重申请求中携带的文件信息为(foo5.txt),锁代理对(foo5.txt)进行哈希计算,得到的结果是7000,根据锁管理 范围信息,应该由锁服务器S2负责处理。但是目前锁服务器S2处于故障状态,根据 锁服务器接管关系信息,故障锁服务器S2的接管锁服务器是锁服务器S4,因此锁代 理将锁重申请求发送给接管锁服务器S4处理。
到达预定的时间或者收到管理节点的第二通知消息之后,锁代理需要更新存储的锁服务器接管关系信息和锁服务器管理范围信息,使得更新后的锁服务器接管关系信 息和锁服务器管理范围信息中不包括故障锁服务器的信息。所述第二通知消息用于通 知锁代理更新锁服务器接管关系信息和锁服务器管理范围信息,所述第二通知消息中 携带故障锁服务器的信息。
当然,也可以由管理节点将更新后的锁服务器接管关系信息和锁服务器管理范围信息发送给各个锁代理。以表三为例,更新后的锁服务器信息表表四所示:
锁服务器 | 锁服务器管理范围 | 接管锁服务器 |
S1 | 1024-5000 | S4 |
S4 | 5000-512 | S3 |
S3 | 512-1024 | S1 |
表四更新后的锁服务器信息表
当锁代理中的锁服务器接管关系通过一致性哈希环来确定时,除了用一致性哈希环来确定锁服务器接管关系外,还可以用一致性哈希环来确定各个锁服务器的管理范 围。
在本发明实施例中,还可以在各个锁代理中配置相同的一致性哈希算法、锁服务器管理范围的确定规则等信息。这样在系统启动后,锁代理中根据已配置的一致性哈 希算法、锁服务器管理范围的确定规则等计算得到一致性哈希环。锁代理中配置的一 致性哈希算法和锁服务器管理范围的确定规则等信息要与锁服务器中配置的相关信 息一致,以使得锁代理中计算得到的一致性哈希环与锁服务器中的一致性哈希环相 同。这样锁代理在接收到锁请求(例如,加锁请求或者锁重申请求)后,可以根据一 致性哈希环确定由哪个锁服务器处理该锁请求,将锁请求发送给确定的锁服务器处 理。如果确定的锁服务器发生了故障,锁代理还可以根据一致性哈希环确认该故障锁 服务器的接管锁服务器,将锁请求发送给接管锁服务器进行处理。
同样的,还可以由管理节点计算出一致性哈希环之后,一并广播给各个锁代理和各个锁服务器。
例如,附图3-1中所示的一致性哈希环是根据顺时针方向生成的,那么锁服务器接管关系可以按一致性哈希环的顺时针方向来确定,而此时锁服务器管理范围也要按 照一致性哈希环的顺时针方向来确定。如附图3-4所示,锁服务器S1的接管锁服务 器为S2,锁服务器S2的接管锁服务器为S4,锁服务器S4的接管锁服务器为S3,锁 服务器S3的接管锁服务器为S1。锁服务器S3与锁服务器S1之间的范围(1024-5000) 是锁服务器S1的管理范围,即锁服务器S3与锁服务器S1之间的范围按顺时针方向 的锁服务器S1的管理。同理,锁服务器S1与锁服务器S2之间的范围(5000-8000) 是锁服务器S2的管理范围,锁服务器S2与锁服务器S4之间的范围(8000-512)是 锁服务器S4的管理范围为,锁服务器S4与锁服务器S3之间的范围(512-1024)是 锁服务器S3的管理范围。
对于附图3-1中所示的一致性哈希环,锁服务器接管关系也可以按一致性哈希环的逆时针方向来确定,而此时锁服务器管理范围也要按照一致性哈希环的逆时针方向 来确定。确定方式和按一致性哈希环的顺时针方向确定锁服务器接管关系的方法相 同,不再另行描述。
当有应用主机需要访问分布式系统中的某个文件时,协议服务器发送加锁请求给锁代理,锁代理对文件的唯一标识(例如FSID、FID)进行哈希计算,根据计算结果 确定该文件属于哪个范围,将加锁请求发送给管理该范围的锁服务器进行相应的处 理。对文件的唯一标识进行哈希计算的哈希算法需要与生成一致性哈希环的哈希算法 相同。例如,加锁请求中携带的文件信息为(foo2.txt),锁代理对该文件信息
(foo2.txt)进行哈希计算,得到结果为6500,我们可以看出,落入一致性哈希环上的锁服务器S1与锁服务器S2之间范围,该加锁请求由锁服务器S2处理。
当锁服务器S2发生故障时,锁代理将一致性哈希环中的锁服务器S1标识为故障。此时锁代理接收到锁请求后,对锁请求中携带的文件信息为(foo3.txt)进行哈希计 算,得到结果为7500,落入一致性哈希环上的锁服务器S1与锁服务器S2之间范围, 由锁服务器S2管理,但是由于锁服务器S2处于故障状态,根据一致性哈希环,锁服 务器S2的接管锁服务器为锁服务器S4,因此,锁代理将锁请求发送给锁服务器S4管 理。
到达预定的时间或者收到管理节点的第二通知消息之后,锁代理需要更新存储的锁服务器接管关系信息和锁服务器管理范围信息,使得更新后的锁服务器接管关系信 息和锁服务器管理范围信息中不包括故障锁服务器的信息。当然,也可以由管理节点 将更新后的锁服务器接管关系信息和锁服务器管理范围信息发送给各个锁代理和锁 服务器。
更新后一致性哈希环如附图3-3所示,则此时各个锁服务器的管理范围更新为:锁服务器S4的管理范围为(5000-512),锁服务器S3的管理范围为(512-1024), 锁服务器S1的管理范围为(1024-5000)。锁服务器S1的接管锁服务器为S4,锁服 务器S4的接管锁服务器为S3,锁服务器S3的接管锁服务器为S1。
如附图3-2中所示的一致性哈希环是根据逆时针方向生成的,那么锁服务器接管关系可以按一致性哈希环逆时针方向来确定,此时锁服务器管理范围也需要按一致性 哈希环的逆时针方向来确定。例如,如附图3-2所示,锁服务器S1的接管锁服务器 为S2,锁服务器S2的接管锁服务器为S4,锁服务器S4的接管锁服务器为S3,锁服 务器S3的接管锁服务器为S1。锁服务器S1与锁服务器S2之间的范围(5000-8000) 由锁服务器S2管理,锁服务器S2与锁服务器S4之间的范围(8000-512)由锁服务 器S4管理,锁服务器S4与锁服务器S3之间的范围(512-1024)由锁服务器S3管理, 锁服务器S3与锁服务器S1之间的范围(1024-5000)由锁服务器S1管理。
根据附图3-2中所示的一致性哈希环确定锁服务器接管关系式,还可以按一致性哈希环顺时针方向来确定,此时锁服务器管理范围也需要按一致性哈希环的顺时针方 向来确定。确定方式和按一致性哈希环的逆时针方向确定锁服务器接管关系的方法相 同,此处不再另行描述。
根据节点的名称或者锁服务器ID利用一致性哈希算法得到一致性哈希环的方法可以采用已有的技术,在此不再赘述。
当分布式系统中增加新的锁服务器时,管理节点设备在分布式系统中广播第三通知消息,第三通知消息用于通知锁服务器更新本地存储的一致性哈希环,所述第三通 知消息中携带新增加的锁服务器的信息。分布式系统中的锁服务器和锁代理根据第三 通知消息中携带的新增加的锁服务器的信息更新本地存储的锁服务器接管关系信息 或者锁服务器管理范围信息。当然也可以由管理节点设备更新了锁服务器接管关系信 息或者锁服务器管理范围信息之后发送给分布式系统中的锁服务器和锁代理。
在采用表格的形式来记录锁服务器接管关系信息(如表一所示)或者锁服务器管理范围信息(如表二所示)的情况下,当增加锁服务器的时,管理节点需要对锁服务 器接管关系或者锁服务器管理范围信息进行重新配置更新。管理节点可以将更新好的 表格发送给各个锁服务器和锁代理,也可以发送第三通知消息给各个锁服务器和锁代 理(即在分布式系统中广播所述第三通知消息),通知锁服务器和锁代理进行更新。 更新规则可以根据用户需求、系统负载、业务量等信息进行设定,在本发明实施例中 不做限定。
当分布式系统中增加新的锁服务器时,更新后的锁服务器接管关系信息和锁服务器管理范围信息如表四所示。
锁服务器 | 锁服务器管理范围 | 接管锁服务器 |
S1 | 1024-4000 | S2 |
S2 | 4000-7000 | S5 |
S5 | 7000-9000 | S4 |
S4 | 9000-512 | S3 |
S3 | 512-1024 | S1 |
在通过一致性哈希环来确定锁服务器接管关系信息或者锁服务器管理范围信息时,当有新的锁服务器加入时,管理节点检测到了之后,将携带新的锁服务器的ID (或者其他用于计算得到一致性哈希环的信息)的第三通知消息在分布式系统中广 播,锁服务器和锁代理接收到所述第三通知消息之后,根据所述第三通知消息中携带 的信息更新本地的一致性哈希环。锁服务器(包括新增加的锁服务器)和锁代理接收 到所述第三通知消息之后,对所述通知消息中携带的锁服务器的ID进行哈希计算, 并根据哈希计算的结果在本地的一致性哈希环中加入新加入的锁服务器的计算结果, 并根据确定的规则更新新加入的锁服务器在一致性哈希环中相邻的锁服务器的管理 范围和接管关系。
如附图3-1所示的一致性哈希环是根据锁服务器的ID以及顺时针原则计算得到的,当分布式系统中新增加锁服务器(如S5)时,管理节点将锁服务器S5的ID携带 在第三通知消息中发送给分布式系统中的锁服务器。锁服务器对锁服务器S5的ID利 用一致性哈希算法做哈希计算,假设计算读出来的结果为3000,那么更新的后的一致 性哈希环如附图3-5所示,新增加的锁服务器S5在一致性哈希环中的锁服务器S3和 锁服务器S1之间。相应的,锁服务器S3的接管锁服务器变更为锁服务器S5,锁服务 器S5的接管锁服务器为锁服务器S1;锁服务器S1的管理范围变更为(3000-5000), 锁服务器S5的管理范围为(1024-3000)。一致性哈希环中的其他锁服务器的接管关 系和管理范围不变。
本发明实施例提供一种分布式系统中锁服务器故障的处理方法,其流程如附图4-2所示。本方法应用于附图4-1所示的分布式系统。在本发明实施例分布式系统中, 有i个锁服务器,其中,i为大于2的自然数。为了以示区别,锁服务器分别标识为 锁服务器S1,锁服务器S2,锁服务器S3...锁服务器Si。
当分布式系统中有锁服务器(例如,锁服务器S1)发生故障时,本实施例的分布 式系统中锁服务器故障处理方法的流程如下:
步骤401:分布式系统中未发生故障的锁服务器接收第一通知消息,所述第一通知消息中携带第一锁服务器发生故障的信息。
当分布式系统中的某个锁服务器发生故障时,管理节点设备检测到有锁服务器发生故障后,向分布式系统中的锁服务器广播第一通知消息,第一通知消息中携带故障 锁服务器S1发生故障的信息。分布式系统中未发生故障的锁服务器都可以接收到第 一通知消息。
步骤403:分布式系统中的第二锁服务器接收到所述第一通知消息后,根据本地存储的锁服务器接管关系信息确定自己为所述第一锁服务器的接管锁服务器,作为接 管锁服务器的第二锁服务器进入静默状态。
分布式系统中的所有锁服务器在本地都存储有锁服务器接管关系信息。锁服务器S2接收到所述第一通知消息后,根据本地存储的锁服务器接管关系信息,确定自己是 故障锁服务器S1的接管锁服务器。
锁服务器接管关系信息记录了分布式系统中各个锁服务器之间的接管关系,即当某个锁服务器发生故障时,由其接管锁服务器接管发生故障的锁服务器的业务。例如, 在本发明实施例中,锁服务器S1的接管锁服务器为锁服务器S2,这样,当锁服务器 S1发生故障时,其相应的业务由锁服务器S2接管,由锁服务器S2负责处理锁服务器 S1原来的业务。
接管锁服务器进入静默状态时,可以通过启动静默定时器进入静默状态。接管服务器可以待静默定时器结束时退出静默状态;也可以由管理节点通知退出静默状态; 还可以在处理完锁重申请求后退出静默状态,在本发明实施例中不做限定。
步骤405:所述分布式系统中的第三锁服务器接收到所述第一通知消息后,根据本地存储的锁服务器接管关系信息,确定自己不是所述第一锁服务器的接管锁服务 器。
在本发明实施例中,锁服务器S3接收到所述第一通知消息后,根据本地存储的 锁服务器接管关系信息,确定自己不是故障锁服务器S1的接管锁服务器。锁服务器 S4接收到所述第一通知消息后,根据本地存储的锁服务器接管关系信息,确定自己不 是故障锁服务器S1的接管锁服务器。以此类推,锁服务器Si接收到所述第一通知消 息后,根据本地存储的锁服务器接管关系信息,确定自己不是故障锁服务器S1的接 管锁服务器。
不是故障锁服务器的接管锁服务器可以统称为非接管锁服务器。当某个锁服务器发生故障时,由其接管锁服务器接管发生故障的锁服务器的业务,非接管锁服务器的 业务不受影响,可以正常处理业务。
而在现有技术中,当某个锁服务器发生故障时,需要将分布式系统中的所有的锁服务器都静默,而处于静默状态的锁服务器只能处理锁重申请求,不能处理加锁请求, 因此,一旦其中一个锁服务器发生故障时,整个分布式系统都无法处理加锁请求,会 造成业务中断或者多个客户端同时读写文件而导致分布式系统崩溃的问题。而本发明 实施例中,通过锁服务器之间的接管关系,当其中一个锁服务器发生故障时,只会影 响到其接管锁服务器(接管锁服务器进入静默状态,只能处理所重申请求),其他的 非接管锁服务器的业务不受影响,非接管锁服务器可以处理加锁请求。这样能够保证 在分布式系统中的某个锁服务器发生故障时,将影响的范围减少到最小,并且可以处 理加锁请求,从而保证整个分布式系统的稳定性。
锁服务器接管信息可以以锁服务器接管信息表的方式来记录,也可以利用一致性哈希算法对锁服务器的ID进行哈希计算,并根据一定的规则得到锁服务器的一致性 哈希环,根据一致性哈希环来确定锁服务器之间的接管关系。相关内容在前文已进行 了详细的描述,在此不再赘述。
在本实施例中,锁服务器S2是故障锁服务器S1的接管锁服务器,此时,其他的 锁服务器相对故障锁服务器S1而言,都是非接管锁服务器。
步骤407:作为非接管锁服务器的所述第三锁服务器接收到加锁请求时,根据所述加锁请求分配锁权限信息。
确定为非接管锁服务器的锁服务器接收到加锁请求后,根据所述加锁请求分配锁权限信息。
在本发明实施例中,锁服务器S3不是故障锁服务器S1的接管锁服务器,即锁服 务器S3为故障锁服务器S1的非接管锁服务器,不静默。因此,锁服务器S3接收到 加锁请求时,根据所述加锁请求分配锁权限信息。同样的,锁服务器S4为故障锁服 务器S1的非接管锁服务器,可以处理加锁请求。
在本发明实施例中,故障锁服务器的非接管锁服务器不需要静默,因此,当非接管锁服务器接收到加锁请求时,根据所述加锁请求分配锁权限信息。非接管锁服务器 接收到加锁请求时后的处理,与现有技术相同,例如,查看锁权限信息表中是否有互 斥的加锁请求,从而决定分配的锁权限信息,在此不再赘述。
通过本发明实施例提供的方法,可以在分布式系统中有锁服务器发生故障时,将受影响的范围减小到最小,故障锁服务器的非接管锁服务器的业务不受影响,非接管 锁服务器可以正常处理加锁请求,避免了分布式系统的业务中断和系统不稳定的问 题。
在本发明另一实施例中,其流程图如附图4-3所示,还包含以下步骤:
步骤409:当作为接管锁服务器的第二锁服务器接收到锁重申请求后,根据锁权限信息表返回对应的锁权限信息。
接管锁服务器处于静默状态时,可以处理锁重申请求。在本发明实施例中,接管锁服务器S2接收到锁重申请求后,根据锁权限信息表返回对应的锁权限信息。在NFS V3中,接管锁服务器锁重申请求后,根据锁权限信息返回OK的响应消息。
锁权限信息表中存储有访问的文件信息、已授权的锁权限信息、访问的客户端信息等信息,可以使用现有的实现方案实现对锁重申请求的处理,在本发明实施例中不 再详述。锁权限信息表可以存储在一共享存储中,各个锁服务器可以访问获取信息; 也可以在每个锁服务器的本地存储一个锁信息表,由管理节点负责信息同步,在本发 明实施例中不再详细描述。锁重申请求是由客户端发出的,具体的触发流程与现在的 实现方式相同,在本发明实施例中不再详述。
步骤411:当作为接管锁服务器的第二锁服务器接收到加锁请求后,返回拒绝的响应消息。
接管锁服务器处于静默状态时,只能处理锁重申请求,处理不了加锁请求。在本发明实施例中接管锁服务器S2处于静默状态时,如果接收到了加锁请求,则返回拒 绝的响应消息。当然接管锁服务器满足一定的条件退出静默状态之后,就可以处理加 锁请求了。此时的处理方式与非接管锁服务器处理加锁请求的方式相同,在此不再详 述。
分布式系统中除了包括锁服务器外,还会包括协议服务器和锁代理。协议服务器和锁代理一一对应,并且对应的协议服务器和锁代理位于一个节点设备中。锁服务器 可以和多个锁代理对应,可以和协议服务器与锁代理位于同一个节点设备中,也可以 设置在其他节点设备中。本发明实施例还提供另外一种分布式系统中锁服务器故障的 处理方法,其适用的系统如附图5-1所示,其流程如附图5-2所示。
如附图5-1所示,分布式系统中有j个节点设备,j为大于2的自然数。每个节 点设备中包括一个协议服务器、锁代理和锁服务器。例如,协议服务器PS1、锁代理 P1、锁服务器S1在节点设备1中,协议服务器PS2、锁代理P2、锁服务器S2在节点 设备2中,以此类推。协议服务器与锁代理一一对应,也就是说,协议服务器PS1接 收到锁请求之后发送给锁代理P1;协议服务器PS2接收到锁请求之后发送给锁代理 P2;以此类推。锁服务器则可以与多个锁代理对应,即锁服务器S1可以接收锁代理 P1发送的锁请求,也可以接收其他锁代理(例如锁代理P2)发送的锁请求。
本实施例中锁服务器执行的步骤与附图4-2和4-3以及相应的文字描述的方案相同,在此不再另行描述。
步骤501:协议服务器接收到锁请求后,将所述锁请求发送给对应的锁代理,所 述锁请求可以为锁重申请求或加锁请求。
协议服务器与外部的协议客户端相连,用于接收协议客户端的请求以及向所述协议客户端返回处理结果。协议服务器可以是NFS(Network File System,网络文件系 统)协议服务器,还可以是SMB(Server Message Block,服务器信息块)协议服务 器,在本发明实施例中不做限定。协议服务器接收到协议客户端发送的锁请求之后, 进行协议转换处理,将接收到的锁请求转换为DLM(Distributed Lock Manager,分 布式锁管理器)的锁请求,并发送给对应的锁代理。在本发明实施例中,协议锁服务 器和对应的锁代理位于一个节点设备中,因此,协议服务器将转换后的锁请求发送给 本节点内的锁代理。例如,协议服务器PS2接受到锁请求后,将转换后的锁请求发送 给锁代理P2。
在现有技术中,由于在一个锁服务器发生故障时分布式系统中的锁服务器都会进入静默状态,因此协议服务器接收到锁请求之后,只将锁重申请求发送给对应的锁代 理;对于接收到的加锁请求,协议服务器会直接返回拒绝的响应消息。也就是说,现 有技术中的分布式系统中,当一个锁服务器发生故障,分布式系统中的锁服务器都会 进入静默状态,此时的分布式系统无法处理加锁请求,影响分布式系统业务的正常运 行,大大影响了分布式系统的稳定性。
而通过本发明实施例提供的方案,在一个锁服务器发生故障后,只需要故障锁服务器的接管锁服务器进入静默状态,而其他的非接管锁服务器可以正常处理业务。协 议服务器在接收到锁请求(包括加锁请求和锁重申请求)之后,会将锁请求发送给对 应的锁代理,由锁代理根据一定的规则发送给负责处理锁请求的锁服务器。此时,只 有处于静默状态的接管锁服务器不能处理加锁请求,其他的非接管锁服务器都可以处 理加锁请求,而锁重申请求都可以得到处理。因此,分布式系统中的绝大多数的锁请 求都可以得到处理,大大提高了分布式系统的稳定性。
步骤503:锁代理接收到锁请求后,根据本地存储的锁服务器管理范围信息确定处理锁请求的锁服务器;将接收到的锁请求发送给确定出的锁服务器。
在每个锁代理的本地存储有锁服务器管理范围信息,当锁代理接收到协议服务器发送的锁请求之后,锁代理根据本地存储的锁服务器管理范围信息,确定负责处理该 锁请求的锁服务器,并将锁请求发送给确定的锁服务器处理。
在锁服务器管理范围信息使用锁服务器管理范围信息表来记录时,锁代理接收到锁请求之后,对锁请求中携带的文件信息(例如文件ID)进行hash计算,计算出来 的结果落入哪个锁服务器的管理范围,这个锁服务器就是负责处理该锁请求的锁服务 器,锁代理将锁请求发送给确定的锁服务器处理。
在锁服务器管理范围信息通过一致性哈希环来确定时,锁代理接收到锁请求之后,对锁请求中携带的文件信息(例如文件ID)进行hash计算,计算出来的结果落 入哪个锁服务器的管理范围,这个锁服务器就是负责处理该锁请求的锁服务器,锁代 理将锁请求发送给确定的锁服务器处理。对锁请求中携带的文件信息进行哈希计算的 哈希算法要与生成一致性哈希环的一致性哈希算法相同。
在本发明实施例中,当管理节点发现有锁服务器发生故障时,会在分布式系统中广播第一通知消息,第一通知消息中会携带发生故障的锁服务器的信息。锁代理和锁 服务器都会接收到第一通知消息,锁代理接收到第一通知消息之后,会将本地存储的 锁服务器管理范围信息中发生故障的锁服务器标注为故障。因此,锁代理接收到锁请 求之后,根据锁服务器管理范围信息确定的负责处理锁请求的锁服务器有可能是发生 了故障的锁服务器。这时,锁代理要根据存储的服务器接管关系信息确定故障锁服务 器的接管锁服务器,确定方法如步骤505所述。
步骤505:所述锁代理接收到锁请求后,根据本地存储的锁服务器管理范围信息确定处理锁请求的锁服务器;当所述锁服务器管理范围信息中确定出的处理锁请求的 锁服务器为故障状态时,所述锁代理根据本地存储的锁服务器接管关系信息确定所述 故障状态的锁服务器的接管锁服务器;将接收到的锁请求发送给所述接管锁服务器。
在锁服务器管理范围信息使用锁服务器管理范围信息表来记录时,锁服务器接管关系信息也使用锁服务器接管关系表来记录。锁服务器管理范围信息和锁服务器接管 关系信息可以由一个锁服务器信息表来记录。锁服务器信息表如表三所示,表中记录 了各个锁服务器的管理范围和相互之间的接管关系,可以根据用户的需求预先配置。 锁服务器信息表以及更新情况以前文已进行了详细的描述,此外不再赘述。
在锁服务器管理范围信息通过一致性哈希环来确定时,锁服务器接管关系信息也通过同一致性哈希环来确定。如前文所述,若锁服务器管理范围是按一致性哈希环的 顺时针方向确定时,锁服务器接管关系也要按一致性哈希环的顺时针方向来确定。同 样的,若锁服务器管理范围信是按一致性哈希环的逆时针方向确定则时,锁服务器接 管关系也要按一致性哈希环的逆时针方向来确定。
如附图5-3所示,锁服务器S4与锁服务器S1之间的范围由锁服务器S1管理, 锁服务器S1与锁服务器S2之间的范围由锁服务器S2管理,锁服务器S2与锁服务器 S3之间的范围由锁服务器S3管理,锁服务器S3与锁服务器S4之间的范围由锁服务 器S4管理;锁服务器S1的接管锁服务器为锁服务器S2,锁服务器S2的接管锁服务 器为锁服务器S3,锁服务器S3的接管锁服务器为锁服务器S4,锁服务器S4的接管 锁服务器为锁服务器S1。
通过本发明实施例提供的技术方案,当分布式系统中有锁服务器发生故障时,协议服务器可以接收锁请求(例如锁重申请求或者加锁请求),并将接收到的锁请求发 送给锁代理。锁代理根据存储的锁服务器管理范围信息确定锁服务器,将锁请求发送 给锁服务器处理。如果确定的锁服务器为发生故障的锁服务器,锁代理还需要根据锁 服务器接管关系信息确定发生故障的锁服务器的接管锁服务器,将锁请求发送给接管 锁服务器处理。接管锁服务器在静默期间只能处理锁重申请求,不能处理加锁请求。 这样,将锁服务器发生故障的影响范围减小到最少,使得绝大多数的锁请求都能得到 及时处理,防止因锁请求不能及时处理而导致的业务中断或者因业务冲突而导致系统 崩溃的问题,提高了分布式系统的稳定性。
在本发明另一实施例中,分布式系统中锁服务器故障处理方法还可以包含以下步骤:
步骤507:分布式系统中未发生故障的锁服务器接受到第一通知消息之后,将本地存储的一致性哈希环中的所述第一锁服务器标识为故障状态;到达预定的时间后, 未发生故障的锁服务器更新本地存储的所述一致性哈希环,所述更新后的一致性哈希 环中不包括所述第一锁服务器。
当分布式系统中有锁服务器发生故障时,分布式系统中未发生故障的锁服务器会接受到管理节点发送的第一通知消息,第一通知消息中携带有发生故障的锁服务器的 标识;接受到第一通知消息之后,未发生故障的锁服务器将本地存储的一致性哈希 环中的故障锁服务器标识为故障状态。未发生故障的锁服务器还可以启动一定时器。 到达预定的时间后,未发生故障的锁服务器更新本地存储的一致性哈希环,更新后的 一致性哈希环中不包括故障锁服务器。
可选的,分布式系统中未发生故障的锁服务器还可以在接受到管理节点的通知之后再更新本地存储的一致性哈希环,同样的,更新后的一致性哈希环中不包括故障锁 服务器,具体方法如步骤509所述。
步骤509:所述未发生故障的锁服务器接收第二通知消息,所述第二通知消息用于通知锁服务器更新本地存储的一致性哈希环,所述第二通知消息中携带故障锁服务 器的信息;未发生故障的锁服务器更新本地存储的一致性哈希环,所述更新后的一 致性哈希环中不包括所述故障锁服务器。
步骤511:所述锁代理接收所述第一通知消息之后;将本地存储的一致性哈希环中的故障锁服务器标识为故障状态;到达预定的时间后,更新本地存储的一致性哈希 环,所述更新后的一致性哈希环中不包括所述第一锁服务器。
步骤511与步骤507或509没有严格的先后顺序,步骤511可以和步骤507或509 并行执行。
当分布式系统中有新的锁服务器加入时,本发明实施例还可以包括以下步骤:
步骤513:未发生故障的锁服务器接收第三通知消息,更新本地存储的一致性哈希环,更新后的一致性哈希环中包含了新加入的锁服务器;其中所述所述第三通知消 息用于通知锁服务器更新本地存储的一致性哈希环,所述第三通知消息中携带新加入 锁服务器的信息。
步骤515:锁代理接收所述第三通知消息;更新本地存储的一致性哈希环,更新 后的一致性哈希环中包含了新加入的锁服务器。
步骤513和515可以并行执行,没有严格的先后顺序。
本发明实施例提供另一种分布式系统中锁服务器故障的处理方法,其流程如附图6-2所示。本方法应用于附图6-1所示的分布式系统。
在本分布式系统中,有4个节点设备,每个节点设备中都包括一个协议服务器、 锁代理和锁服务器。例如,协议服务器PS1、锁代理P1、锁服务器S1在节点设备1 中,协议服务器PS2、锁代理P2、锁服务器S2在节点设备2中,以此类推。协议服 务器与本节点内的锁代理一一对应,锁代理可以与多个锁服务器对应。当然,锁服务 器也可以单独设置在另外的一个节点设备中,如4个锁服务器都设置在节点设备5中 (图中未示出)。
在本实施例中,锁服务器接管关系信息和锁服务器管理范围信息都按照一致性哈希环的顺时针方向来确定。锁代理和锁服务器的本地都存储有一致性哈希环,并且存 储的一致性哈希环相同。锁代理P1中的一致性哈希环使用HP1来表示,锁服务器S1 中的一致性哈希环使用HS1来表示,以此类推。本实施例中的一致性哈希环是根据节 点设备的名称计算得到的。如前所述,一致性哈希环还可以根据锁服务器的ID或者 节点设备的IP地址计算得到,在此不再赘述。一致性哈希环及其更新在前文已进行 了详细的描述,在此处不再赘述。
本实施例的分布式系统中故障处理方法的流程如下:
步骤601:未发生故障的锁服务器接收到第一通知消息,第一通知消息中携带锁服务器S1发生故障的信息。
分布式系统中的管理节点检测到锁服务器S1发生故障时,向分布式系统中的锁代理和锁服务器广播第一通知消息,通知锁代理和锁服务器S1发生故障。管理节点 可以位于其中一个节点设备中,也可以单独设置一个节点设备来执行分布式系统的管 理功能,管理节点的位置不影响本实施例的实施,因此不限定管理节点的位置,也未 在附图6-1中示出。管理节点在分布式系统中广播所述第一通知消息,分布式系统中 的锁代理和未发生故障的锁服务器接收到第一通知消息。
步骤602:未发生故障的锁服务器根据本地的一致性哈希环确定自己是否是故障锁服务器S1的接管锁服务器。本实施例中,锁服务器S2根据本地的一致性哈希环HS2 确定自己是故障锁服务器S1的接管锁服务器。锁服务器S3根据本地的致性哈希环HS3 确定自己不是故障锁服务器S1的接管锁服务器;锁服务器S4根据本地的一致性哈希 环HS4确定自己不是故障锁服务器S1的接管锁服务器。此时锁服务器S3和锁服务器 S4在本实施例中都称为非接管锁服务器,锁服务器S2称为接管锁服务器。锁服务器 S1为故障服务器。
步骤603:未发生故障的锁服务器将本地存储的一致性希环中的锁服务器S1标识为故障状态。锁服务器S2接收到第一通知消息之后,还可以将本地存储的一致性希 环HS2中的锁服务器S1标识为故障状态。此时,锁服务器S2还可以启动定时器,待 定时器结束后,更新本地的一致性希环HS2。同样的,锁服务器S3和锁服务器S4也 执行同样的操作。
步骤603与步骤602没有严格的先后顺序,未发生故障的锁服务器可以先将本地存储的一致性哈希环的锁服务器S1标识为故障状态,也可以先根据本地存储的一致 性哈希环判断自己是否为故障锁服务器S1的接管锁服务器。
步骤604:锁服务器S2确定自己为故障锁服务器S1的接管锁服务器,进入静默 状态。进入静默状态的接管锁服务器只能处理锁重申请求,不能处理加锁请求。此时 锁服务器S2还可以启动一个静默定时器,待静默定时器结束时,锁服务器S2退出静 默状态。锁服务器S3或者锁服务器S4确认自己不是故障锁服务器S1的接管锁服务 器,则保持目前的状态不变。非接管锁服务器可以正常的处理加锁请求。
锁服务器S2确定自己为故障锁服务器S1的接管锁服务器之后,可以向管理节点返回响应消息,通知管理节点自己为故障锁服务器S1的接管锁服务器。当然,管理 节点也可以在本地存储相同的一致性哈希环,当管理节点检测到锁服务器S1发生故 障之后,根据本地存储的一致性哈希环确认锁服务器S2为故障锁服务器S1的接管锁 服务器。
通过本发明实施例的方法,当分布式系统中的一个锁服务器发生故障时,只需要将故障锁服务器的接管锁服务器静默,而其他的非接管锁服务器正常工作,这样其他 的非接管锁服务器可以处理加锁请求,将影响范围减小到最小,提高了分布式系统的 可靠性。
步骤605:锁代理接收到第一通知消息,将本地存储的一致性希环中的锁服务器S1标识为故障状态。由于管理节点在分布式系统中广播的所述第一通知消息,分布式 系统中的锁代理也会接收到第一通知消息。锁代理接收到第一通知消息之后,将本地 存储的一致性希环中的锁服务器S1标识为故障状态。例如:分布式系统中的锁代理 P2接收到第一通知消息后,将本地存储的一致性希环HP2中的锁服务器S1标识为故 障状态。此时,锁代理还可以启动定时器,待定时器结束后,更新本地存储的一致性 希环。这里的定时器的时长要与步骤603中的定时器的时长相等,可以比步骤604中 的静默定时器的时长略长,也可以相等。这样等接管锁服务器S2退出静默状态之后, 非接管锁服务器S3或S4和锁代理可以同时更新各自在本地存储的一致性哈希环。
需要说明的是,步骤605与前面的步骤没有严格的先后顺序。一般情况下,锁代 理的操作与锁服务器的操作可以同时进行。
步骤606:协议服务器接收到锁请求后,将锁请求发送给相应的锁代理,协议服 务器和所述相应的锁代理位于同一节点设备中。在本发明的实施例中,锁请求可以是 锁重申请求,也可以是加锁请求。由于分布式系统中只静默了接管锁服务器,其他锁 服务器可以正常的工作,因此协议服务器接收到锁请求之后,将锁请求发送给本节点 设备内的对应的锁代理。例如,协议服务器PS1接收到锁请求之后,将锁请求发送给 锁代理P1。
加锁请求可以是由客户端通过NAS网络发送给协议服务器的,其格式与现有的实现方式相同,在此不再赘述。
锁重申请求可以是在客户端接收到协议服务器的通知之后,向协议服务器发起锁重申请求。协议服务器如何通知特定的客户端发起锁重申请求可以采用现有技术中的 方案,其格式也与现有的实现方式相同,在本发明实施例中不再赘述。
步骤607:锁代理接收到锁请求之后,根据本地存储的一致性哈希环,确认所述 锁请求应该由哪个锁服务器负责处理,将所述锁请求发送给确定的处理所述锁请求的 锁服务器。本步骤中的锁请求可以是加锁请求,也可以是锁重申请求。
锁代理接收到锁请求之后,对锁请求中携带的文件的唯一标识(FSID,FID)进 行哈希计算,并根据计算出的结果位于本地存储的一致性哈希环中的位置确定由哪个 锁服务器负责处理,将锁请求发送给确认处理所述锁请求的锁服务器。如果确定出来 处理所述锁请求的锁服务器在一致性哈希环中为故障状态,则还需要根据一致性哈希 环确定处理所述锁请求的锁服务器的接管锁服务器,所述锁代理将锁请求发送给接管 锁服务器处理。例如,锁代理P1接收到协议服务器PS1发送的锁请求之后,对锁请 求中的文件标识利用一致性哈希算法进行计算,得到的结果落入锁服务器S4和锁服 务器S1之间的范围,锁代理P1根据本地存储的一致性哈希环的顺时方向,确定收到 的锁请求由锁服务器S1处理,但是本地存储的一致性哈希环中,锁服务器S1为故障 状态,因此,锁代理P1根据本地存储的一致性哈希环的顺时针方向,确定锁服务器 S2为锁服务器S1的接管锁服务器,锁代理P1将锁请求发送给锁服务器S2。
步骤608:锁服务器S2接收到锁请求后,进行相应的处理。如果锁服务器S2接 收到的是锁重申请求,则根据锁权限信息表中记录的信息,返回锁重申请求中携带的 文件唯一标识对应的锁权限信息。在使用NFS v3锁服务器S2接收到的是锁重申请求, 则根据锁权限信息表中记录的信息,返回OK的响应消息。锁如果锁服务器S2接收到 的是加锁请求,查看自己此时是否处于静默状态(例如,查看静默定时器是否已结束); 如果还处于静默状态,则返回拒绝的响应消息;如果不处于静默状态,则为加锁请求 分配新的锁权限信息并返回给锁代理P1。在分配新的锁权限信息时,锁服务器S2还 可以将分配的新的锁权限信息和加锁请求中携带的文件唯一标识的对应关系存储到 锁权限信息表中,用于以后的锁重申请求的处理。
锁权限信息表可以由管理节点统一管理,更新后再发送给各个锁服务器。也可以由管理节点统一存储,在锁服务器需要时从管理节点中获取需要的信息。锁权限信息 表还可以由各个锁服务器独立存储和管理,这样当一个锁服务器分配了新的锁权限信 息时,还需要通知其他的锁服务器更新其存储的锁权限信息表。
锁权限信息由锁服务器返回给发送锁请求的锁代理,再由锁代理返回给本节点内的协议服务器,由协议服务器返回给发起锁请求的客户端。例如,锁服务器S2将锁 权限信息返回给锁代理P1,锁代理P1把锁权限信息返回给协议服务器PS1,由协议 服务器PS1把锁权限信息返回给发起锁请求的客户端。具体处理方式可以与现有技术 相同,在本实施例中不再赘述。
步骤609:非接管锁服务器接收到锁请求后,进行相应的处理。例如锁服务器S3 接收到的加锁请求时,为加锁请求分配新的锁权限信息并返回给客户端。同样的,锁 服务器S3还可以将分配的新的锁权限信息和加锁请求中携带的文件唯一标识的对应 关系存储到锁权限信息表中,用于以后的锁重申请求的处理。
需要说明的是,在本实施例的流程中,此时的锁服务器S3不是故障锁服务器S1 的接管锁服务器,没有进入静默状态,可以处理加锁请求。但是在分布式系统中锁服 务器较多时,可能出现2个锁服务器故障,锁服务器S3可能是其他故障锁服务器的 接管锁服务器。因此锁服务器S3在接收到加锁请求时,也需要查看自己是否处于静 默状态,如果处于静默状态的话,则处理方式同步骤608,即不能处理加锁请求,直 接返回拒绝的响应消息。在本步骤中,为了使得故障锁服务器的接管锁服务器与非接 管锁服务器的不同的处理方式更清楚,省略了非接管服务器查看自己是否处于静默状 态的步骤。
步骤610:未发生故障的锁服务器更新本地存储的一致性哈希环。到达预定的时间时,例如,定时器结束后,未发生故障的锁服务器将更新本地存储的一致性哈希环, 更新后的一致性哈希环中不包括故障过服务器S1。还可以由管理节点发送第二通知消 息,所述第二通知消息用于通知锁服务器更新本地存储的一致性哈希环,所述第二通 知消息中携带故障锁服务器的信息。未发生故障的锁服务器接收到第二通知消息后, 更新本地存储的一致性哈希环,更新后的一致性哈希环中不包括故障锁服务器。管理 节点可以在故障锁服务器的锁权限信息重申完毕后发送更新通知,也可以检测到故障 锁服务器一段时间后发送更新通知。
在本发明实施例中,由于一致性哈希环是根据将锁服务器所在的节点设备的名称进行哈希计算得到的,并按照一致性哈希环的顺时针方向来确定故障锁服务器的接管 锁服务器,这样有锁服务器发生故障时,更新一致性哈希环时只影响在一致性哈希环 上与故障锁服务器相邻的锁服务器,影响范围小。
步骤611:锁代理更新一致性哈希环。到达预定的时间后,例如,定时器结束后, 锁代理更新本地存储的一致性哈希环,更新后的一致性哈希环中不包括故障锁服务 器。还可以由管理节点发送更新通知,锁代理接收到更新通知后,更新本地存储的一 致性哈希环,更新后的一致性哈希环中不包括故障锁服务器。
步骤610和611之间没有严格的时间顺序要求,可以同时进行。在故障锁服务器 的节点设备修复之后可以要求重新加入,或者有新的锁服务器的节点设备加入时,本 方法实施例还可以包括:
步骤612:未发生故障的锁服务器接收第三通知消息并更新本地存储的一致性哈希环,更新后的一致性哈希环中包含了新加入的锁服务器;所述第三通知消息用于通 知锁服务器更新本地存储的一致性哈希环,所述第三通知消息中携带新加入锁服务器 的信息。管理节点检测到有新的锁服务器加入时,通知分布式系统中的未发生故障的 锁服务器更新本地存储的一致性哈希环,更新后的一致性哈希环中包含了新加入的锁 服务器。
在本发明实施例中,由于一致性哈希环是根据将锁服务器所在的节点设备的名称进行哈希计算得到的,并按照一致性哈希环的顺时针方向来确定故障锁服务器的接管 锁服务器,因此新加入锁服务器时,只影响到在一致性哈希环上与新加入的锁服务器 相邻的锁服务器,影响范围小。
步骤613:锁代理接收第三通知消息并更新本地存储的一致性哈希环。管理节点检测到有新的锁服务器加入时,通知分布式系统中的锁代理更新本地存储的一致性哈 希环,更新后的一致性哈希环中包含了新加入的锁服务器。
步骤612和613之间没有严格的先后顺序要求,可以同时进行。另外,步骤612 和613与前述的步骤601-611之间没有严格的先后顺序,本发明实施例只是示例性的 说明,不是对本发明方法流程的严格限制。
通过本发明实施例提供的方法,当分布式系统中有锁服务器发生故障时,只需要将按照一致性哈希环的特定方向确定出的故障锁服务器的接管锁服务器静默,而其他 分布式系统中的非接管锁服务器不需要静默,可以正常的处理锁请求,使得分布式系 统收到的绝大多数的锁请求都能得到处理,将锁服务器发生故障影响的范围减少到最 少,提高分布式系统的可靠性。
本发明实施例还提供一种处理锁服务器故障的分布式系统,其结构如附图7所示。如附图7所示,所述分布式系统中包括4个锁服务器。为了以示区别,锁服务器分别 标识为锁服务器S1,锁服务器S2,锁服务器S3,锁服务器S4。每个锁服务器在本地 存储有锁服务器接管关系信息。
分布式系统中未发生故障的锁服务器接收第一通知消息,所述第一通知消息中携带第一锁服务器发生故障的信息;
所述分布式系统中的第二锁服务器接受到第一通知消息后,根据本地存储的锁服务器接管关系信息,确定自己为所述第一锁服务器的接管锁服务器;所述接管锁服务 器进入静默状态。
所述分布式系统中的第三锁服务器接受到第一通知消息后,根据本地存储的锁服务器接管关系信息,确定自己不是所述第一锁服务器的接管锁服务器;所述第三锁服 务器接收到加锁请求时,根据所述加锁请求分配锁权限信息。
若所述为接管锁服务器的第二锁服务器接收到锁重申请求后,根据锁权限信息表返回对应的锁权限信息;若所述第二锁服务器接收到加锁请求时,返回拒绝的响应消 息。
分布式系统中某个锁服务器发生故障时,其他锁服务器的处理流程在上述方法实施例中已经进行了详细了描述,在此不再赘述。
此处涉及的锁服务器接管关系信息的记录方式也在上文进行了详细的描述,在此不再赘述。
进入静默状态的接管锁服务器可以在接收到管理节点的通知以后退出静默状态,也可以在预定的时间之后退出静默状态。
分布式系统中未发生故障的锁服务器在接收到第一通知消息之后,还可以将本地存储的锁服务器管理范围信息或者锁服务器接管关系信息中的故障锁服务器标识为 故障状态,并在设定的时间之后或者接收到管理节点的第二通知消息之后,更新本地 存储的锁服务器管理范围信息或者锁服务器接管关系信息,更新后的锁服务器管理范 围信息或者锁服务器接管关系信息中不包括故障锁服务器的信息。
分布式系统中未发生故障的锁服务器还可以在接收到管理节点发送的第三通知消息后,更新本地存储的一致性哈希环,更新后的一致性哈希环中包含了新加入的锁 服务器;其中所述所述第三通知消息用于通知锁服务器更新本地存储的一致性哈希 环,所述第三通知消息中携带新加入锁服务器的信息。
所述分布式系统中还包括所述分布式系统中还包括4个协议服务器和相应的锁代理。协议服务器和相应的锁代理位于一个节点设备中,锁服务器可以和协议服务器和 锁代理位于一个节点设备中,锁服务器也可以单独设置在其他的节点设备中。在本发 明实施例中,以锁服务器和协议服务器和锁代理在一个节点设备中为例进行说明。
每个节点设备中包括一个协议服务器、锁代理和锁服务器。例如,协议服务器PS1、锁代理P1、锁服务器S1在节点设备1中,协议服务器PS2、锁代理P2、锁服务器S2 在节点设备2中,以此类推。协议服务器与锁代理一一对应,也就是说,协议服务器 PS1接收到锁请求之后发送给锁代理P1;协议服务器PS2接收到锁请求之后发送给锁 代理P2;以此类推。锁服务器则可以与多个锁代理对应,即锁服务器S1可以接收锁 代理P1发送的锁请求,也可以接收其他锁代理(例如锁代理P2)发送的锁请求。锁 请求可以为锁重申请求或加锁请求。
所述协议服务器接收到锁请求后,将所述锁请求发送给对应的锁代理。协议服务器和对应的锁代理位于同一节点设备中。
锁代理接收到锁请求后,根据本地存储的锁服务器管理范围信息确定处理锁请求的锁服务器;如果确定的处理锁请求的锁服务器不是故障状态,锁代理将接收到的锁 请求发送给所述处理锁请求的锁服务器。
所述锁代理接收到锁请求后,根据本地存储的锁服务器管理范围信息确定处理锁请求的锁服务器;当本地存储的锁服务器管理范围信息中的确定处理锁请求的锁服务 器为故障状态时,根据本地存储的锁服务器接管关系信息确定所述处理锁请求的锁服 务器的接管锁服务器;将接收到的锁请求发送给所述接管锁服务器。
此处所提及的锁服务器管理范围信息或锁服务器接管关系信息可以采用表格的方式来记录,还可以通过一致性哈希环的方式来确定,具体的实现方式在前文已进行 了详细的举例和说明,在此外不再赘述。
锁代理中的锁服务器范围信息或锁服务器接管关系信息的记录方式与锁服务器中的锁服务器范围信息或锁服务器接管关系信息的记录方式相同。锁代理和锁服务器 中的锁服务器范围信息或锁服务器接管关系信息的更新规则也相同,因此,锁代理和 锁服务器更新后得到的锁服务器管理范围信息或者锁服务器接管关系信息亦相同。
当锁服务器接管关系通过一致性哈希环来确定时,分布式系统中的未发生故障的锁服务器在接受到第一通知消息后,按照本地存储的一致性哈希环的顺时针方向确定 自己是否为故障锁服务器的接管锁服务器。如前文所述,未发生故障的锁服务器还可 以按照本地存储的一致性哈希环的逆时针方向确定自己是否为故障锁服务器的接管 锁服务器。若其中的第二锁服务器根据本地存储的一致性哈希环确定自己为所述第一 锁服务器的接管锁服务器,为接管锁服务器的第二锁服务器进入静默状态;若所述为 接管锁服务器的第二锁服务器接收到锁重申请求,根据锁权限信息表返回对应的锁权 限信息;若为接管锁服务器的第二锁服务器接收到加锁请求时,返回拒绝的响应消息。
若分布式系统中未发生故障的第三锁服务器根据本地存储的一致性哈希环,确定自己不是所述第一锁服务器的接管锁服务器;则所述第三锁服务器接收到加锁请求 时,根据所述加锁请求分配锁权限信息。
锁代理接收到锁请求后,根据本地存储的一致性哈希环确定处理锁请求的锁服务器。每个锁代理本地存储的一致性哈希环都相同,锁代理本地存储的一致性哈希环与 锁服务器本地存储的一致性哈希环相同。
锁代理在接收到故第一通知消息之后,还可以将本地存储的锁服务器管理范围信息或者锁服务器接管关系信息中的第一锁服务器标识为故障状态,并在设定的时间之 后或者接收到管理节点的第二通知之后,更新本地存储的锁服务器管理范围信息或者 锁服务器接管关系信息。更新后的锁服务器管理范围信息或者锁服务器接管关系信息 中不包括第一锁服务器的信息。
锁代理在还可以接收到管理节点发送的第三通知消息,所述所述第三通知消息用于通知锁服务器更新本地存储的一致性哈希环,所述第三通知消息中携带新加入锁服 务器的信息,更新本地存储的锁服务器管理范围信息或者锁服务器接管关系信息。更 新后的锁服务器管理范围信息或者锁服务器接管关系信息中包含新加入的锁服务器 的信息。
对分布式系统中某个锁服务器发生故障时,锁代理的处理流程在上述方法实施例中已经进行了详细了描述,在此不再赘述。
此处涉及的锁服务器接管关系信息的记录方式也在上文进行了详细的描述,在此不再赘述。
本发明实施例中提供的分布式系统,当分布式系统中的某个锁服务器发生故障时,各个锁服务器根据本地存储的锁服务器接管关系信息确定自己是否为故障锁服务 器的接管锁服务器。当确定自己不是故障锁服务器的接管锁服务器时,即为非接管锁 服务器时,非接管锁服务器接收到加锁请求后,可以正常的为加锁请求分配锁权限信 息。如果确定自己是故障锁服务器的接管锁服务器,进入静默状态,接收到加锁请求 后,返回拒绝的响应消息。这样,只将接管锁服务器静默而其他的非接管锁服务器可 以正常处理加锁请求,把锁服务器发生故障所影响的范围减小到最小,绝大多数的锁 业务都可以正常进行,防止了因为无法处理加锁请求而导致的业务中断或者由于锁权 限冲突而导致系统崩溃的问题,提高了分布式系统的稳定性。
本发明实施例还提供了一种在分布式系统中实现故障处理的锁服务器8,其结构如附图8所示。
所述锁服务器8包括接收模块801、处理模块803和存储模块805。
所述接收模块801用于接收第一通知消息,并将所述第一通知消息发送给处理模块803;所述第一通知消息中携带有故障锁服务器的信息。
所述处理模块803用于接收到第一通知消息后,根据存储模块805中存储的锁服务器接管关系信息,确定自己是否是故障锁服务器的接管锁服务器。如果是故障锁服 务器的接管锁服务器,所述锁服务器进入静默状态,则处理模块803还用于启动静默 定时器。如果不是故障锁服务器的接管锁服务器,则处理模块803不做处理。处理模 块803启动静默定时器之后,所述锁服务器8进入静默状态。
所述接收模块801还用于接收锁代理发送的锁请求,并将接收的锁请求发送给处理模块803。
若锁请求是锁重申请求,所述处理模块803接收到锁重申请求之后,还用于根据存储模块805中存储的锁权限信息表返回对应的锁权限信息。
若锁请求是加锁请求,所述处理模块803接收到加锁请求之后,还用于确定所述锁服务器是否处于静默状态,即可确定静默定时器是否处于启动状态;若所述静默定 时器不处于启动状态,则所述锁服务器不处于静默。所述处理模块803为所述加锁请 求分配锁权限信息,并发送给接收模块801。若所述静默定时器处于启动状态,则所 述锁服务器处于静默状态,所述处理模块803发送拒绝的响应消息给接收模块801。 所述处理模块803为所述加锁请求分配锁权限信息以后,还可以将分配的锁权限信息 和加锁请求中的文件信息存储到存储模块805中的锁权限信息表中。
所述接收模块801还用于将接收到的锁权限信息或者拒绝的响应消息返回给锁代理。
在本发明实施例中,锁服务器接管关系信息可以通过锁服务器接管关系表(如表一所示)来确定,也可以通过一致性哈希环(如图3-1所示)来确定。
所述处理模块803根据存储模块805中存储的锁服务器接管关系信息确定自己是否是故障锁服务器的接管锁服务器具体可以为:处理模块803按所述一致性哈希环的 顺时针方向确定自己是否是故障锁服务器的接管锁服务器。
所述处理模块803根据存储模块805中存储的锁服务器接管关系信息确定自己是否是故障锁服务器的接管锁服务器具体还可以为:处理模块803按所述一致性哈希环 的逆时针方向确定自己是否是故障锁服务器的接管锁服务器。
所述接收模块801还用于接收第二通知消息,并将所述第二通知消息发送给处理模块803,所述第二通知消息用于通知锁服务器更新一致性哈希环,所述第二通知消 息中携带有故障锁服务器的信息。
所述处理模块803还用于更新存储模块805中存储的一致性哈希环,使得更新后的一致性哈希环中不包括故障锁服务器。
所述接收模块801还用于接收第三通知消息,并将所述第三通知消息发送给处理模块803,所述第三通知消息用于通知锁服务器更新一致性哈希环,所述第三通知消 息中还携带有新增加的锁服务器的信息。
所述处理模块803还用于更新存储模块805中存储的一致性哈希环,使得更新后的一致性哈希环中包括新增加的锁服务器。
所述处理模块803还用于在接收到所述第一通知消息之后,将存储模块805中的一致性哈希环中的故障锁服务器标识为故障状态。
所述存储模块805用于存储锁服务器接管关系信息和锁权限信息表等所述锁服务器8需要使用到的信息。
所述锁服务器8所执行的锁服务器故障处理方法流程,如附图4-2、4-3、5-2和 6-2以及相应的文字所描述的方法流程,在此不再赘述。
本发明实施例还提供了另一种在分布式系统中实现故障处理的锁服务器,其结构如附图9所示。如图9所示,锁服务器包括:存储器901,被配置为存储有锁服务器 接管关系信息和锁权限信息表;接口902,被配置为用于提供对外连接;计算机可读 介质903,被配置为用于存储计算机程序;处理器904,和所述存储器901、接口902、 计算机可读介质903连接,被配置为用于通过运行所述程序,执行前文所述的锁服务 器故障处理方法。如附图4-2、4-3、5-2和6-2以及相应的文字所描述的方法流程, 在此不再赘述。
本发明实施例还提供了一种在分布式系统中实现故障处理的锁代理装置10,其结构如附图10所示。
所述锁代理包括接收模块1001、处理模块1003、存储模块1005和发送模块1007。所述接收模块1001用于接收协议服务器发送的锁请求,并将接收的锁请求发送给处 理模块1003,其中所述锁请求可以是锁重申请求,也可以是加锁请求。
所述处理模块1003用于接收到锁请求之后,根据存储模块1003中存储的锁服务器管理范围信息,确定处理所述锁请求的锁服务器,将接收到的锁请求发送给发送模 块1007。
所述处理模块1003还用于接收到锁请求之后,根据存储模块1003中存储的锁服务器管理范围信息,确定处理所述锁请求的锁服务器;在所述锁服务器管理范围信息 中的处理所述锁请求的锁服务器为故障状态时,根据存储模块1005中存储的锁服务 器接管关系信息,确定所述处理所述锁请求的锁服务器的接管锁服务器,并将接收到 的锁请求发送给发送模块1007。
所述发送模块1007用于将锁请求发送给确定的锁服务器。当所述锁服务器管理范围信息中的处理所述锁请求的锁服务器为故障状态时,发送模块1007将锁请求发 送给接管锁服务器。当所述锁服务器管理范围信息中的处理所述锁请求的锁服务器不 是故障状态时,发送模块1007将锁请求发送给确定的处理所述锁请求的接管锁服务 器。
在本发明实施例中,锁服务器接管关系信息和锁服务器管理范围信息可以通过锁服务器信息表(如表三所示)来确定,也可以通过一致性哈希环(如图3-1中所示) 来确定。
所述处理模块1003根据存储模块1005中存储的锁服务器管理范围信息具体可以为:处理模块1003按所述一致性哈希环的顺时针方向或者逆时针方向确定所述处理 所述锁请求的锁服务器。所述处理模块1003根据存储模块1005中存储的锁服务器接 管关系信息确定所述处理所述锁请求的锁服务器的接管锁服务器具体可以为:处理模 块1003按所述一致性哈希环的相同的方向确定所述处理所述锁请求的锁服务器的接 管锁服务器。也就是说,如果处理模块1003按所述一致性哈希环的顺时针方向确定 所述处理所述锁请求的锁服务器,则也按所述一致性哈希环的顺时针方向确定所述处 理所述锁请求的锁服务器的接管锁服务器。如果处理模块1003按所述一致性哈希环 的逆时针方向确定所述处理所述锁请求的锁服务器,则也按所述一致性哈希环的逆时 针方向确定所述处理所述锁请求的锁服务器的接管锁服务器。具体确认方式可参照前 文的详细描述,在此不再赘述。
所述接收模块1001还用于接收第一通知消息,并将所述第一通知消息发送给处理模块1003;所述第一通知消息中携带有故障锁服务器的信息。
所述处理模块1003还用于在接收到所述第一通知消息之后,将存储模块1005中的一致性哈希环中的故障锁服务器标识为故障状态。
所述接收模块1001还用于接收第二通知消息,并将所述第二通知消息发送给处理模块1003,所述第二通知消息用于通知锁服务器更新一致性哈希环。
所述处理模块1003还用于更新存储模块1005中存储的一致性哈希环,使得更新后的一致性哈希环中不包括故障锁服务器。
所述接收模块1001还用于接收第三通知消息,并将所述第三通知消息发送给处理模块1003,所述第三通知消息用于通知锁服务器更新一致性哈希环,所述第三通知 消息中还携带有新增加的锁服务器的标识。
所述处理模块1003还用于更新存储模块1005中存储的一致性哈希环,使得更新后的一致性哈希环中包括新增加的锁服务器。
所述存储模块1005用于存储锁服务器接管关系信息、锁服务器管理范围信息和锁权限信息表等需要所述锁服务器需要使用到的信息。
本发明实施例还提供了一种在分布式系统中实现故障处理的锁代理设备,其结构如附图11所示。如图11所示,锁代理设备包括:存储器1101,被配置为存储有锁服 务器接管关系信息和锁服务器管理范围信息;接口1102,被配置为用于提供对外连接; 计算机可读介质1103,被配置为用于存储计算机程序;处理器1104,和所述存储器 1101、接口1102、计算机可读介质1103连接,被配置为用于通过运行所述程序,执 行上述锁服务器故障处理方法。如附图4-3、5-2和6-2以及相应的文字所描述的方 法流程,在此不再赘述。
本发明实施例还提供了一种在分布式系统中实现故障处理的锁管理器,其结构如附图12所示,包括锁代理1201和锁服务器1203。锁服务器1203的结构及实现的功 能如附图8和9以及相应的文字描述所示。锁代理1201的结构及实现的功能如附图10和11以及相应的方案描述所示。所述锁管理器执行前文所述的锁服务器故障处理 方法,如附图4-2、4-3、5-2和6-2以及相应的文字所描述的方法流程,在此不再赘 述。
本发明实施例还提供了一种在分布式系统中实现故障处理的协议服务器。所述协议服务器用于接收外部协议客户端发送的锁请求,并将锁请求发送给锁代理。所述锁 请求可以为锁重申请求,也可以为加锁请求。协议服务器处理业务的具体流程在上文 已进行了详细的描述,在此不再赘述。
本发明实施例还提供了一种在分布式系统中实现故障处理的节点设备13,其结构如附图13所示,包括协议服务器1305、锁代理1301和锁服务器1303。
所述协议服务器1305用于接收外部协议客户端发送的锁请求,并将锁请求发送给锁代理1301。所述锁请求可以为锁重申请求,也可以为加锁请求。
所述锁代理1301用于根据本地存储的锁服务器管理范围信息确定处理所述锁请求的锁服务器,并将所述锁请求发送给确定的处理所述锁请求的锁服务器。
所述锁代理1301还用于根据存储的锁服务器管理范围信息确定处理所述锁请求的锁服务器,并在确定的处理所述锁请求的锁服务器发生故障时,根据本地存储的锁 服务器接管关系信息确定接管锁服务器,并将所述锁请求发送给接管锁服务器。
所述锁服务器1303用于当接收到的锁请求是锁重申请求时,根据存储的锁权限信息表反馈对应的锁权限信息;所述锁服务器130还用于当接收到锁请求是加锁请求 时,查看自己是否处于静默状态,如果处于静默状态,则返回拒绝的响应消息,如果 不处于静默状态,则分配锁权限信息。
锁服务器1303的结构及实现的功能如附图8和9以及相应的文字描述所示。锁 代理1301的结构及实现的功能如附图10和11以及相应的方案描述所示。所述节点 设备执行前文所述的锁服务器故障处理方法,如附图4-2、4-3、5-2和6-2以及相应 的文字所描述的方法流程,在此不再赘述。
本发明的各个方面、或各个方面的可能实现方式可以被具体实施为系统、方法或者计算机程序产品。因此,本发明的各方面、或各个方面的可能实现方式可以采用完 全硬件实施例、完全软件实施例(包括固件、驻留软件等等),或者组合软件和硬件 方面的实施例的形式,在这里都统称为“电路”、“模块”或者“系统”。此外,本 发明的各方面、或各个方面的可能实现方式可以采用计算机程序产品的形式,计算机 程序产品是指存储在计算机可读介质中的计算机可读程序代码。
计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质。计算机可读存储介质包含但不限于电子、磁性、光学、电磁、红外或半导体系统、设备或者 装置,或者前述的任意适当组合,如随机存取存储器(RAM)、只读存储器(ROM)、可 擦除可编程只读存储器(EPROM或者快闪存储器)、光纤、便携式只读存储器(CD-ROM)。
计算机中的处理器读取存储在计算机可读介质中的计算机可读程序代码,使得处理器能够执行在流程图中每个步骤、或各步骤的组合中规定的功能动作;生成实施在 框图的每一块、或各块的组合中规定的功能动作的装置。
显然,本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样,倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的 范围之内,则本发明也意图包含这些改动和变型在内。
Claims (26)
1.一种分布式系统中锁服务器故障处理方法,其特征在于,所述分布式系统中包括至少三个锁服务器,所述方法包括:
当所述分布式系统中的第一锁服务器发生故障时,所述分布式系统中的第二锁服务器和所述分布式系统中的第三锁服务器分别确定自己是否为所述第一锁服务器的接管锁服务器;
所述第三锁服务器确定自己不是所述第一锁服务器的接管锁服务器时,所述第三锁服务器用于处理加锁请求;
所述第二锁服务器确定自己为所述第一锁服务器的接管锁服务器时,进入静默状态,进入所述静默状态之后,所述接管锁服务器用于处理锁重申请求,不用于处理加锁请求。
2.根据权利要求1所述的方法,其特征在于,还包括:
所述接管锁服务器接收到锁重申请求时,根据锁权限信息表返回对应的锁权限信息;
所述接管锁服务器接收到加锁请求时,返回拒绝的响应消息。
3.根据权利要求1或2所述的方法,其特征在于,所述分布式系统中还包括至少三个协议服务器和相应的锁代理,所述协议服务器和相应的锁代理位于同一节点设备中,所述方法还包括:
当所述协议服务器接收到锁请求后,将所述锁请求发送给的相应的锁代理,所述锁请求为锁重申请求或加锁请求。
4.根据权利要求3所述的方法,其特征在于,所述每个锁代理本地存储有锁服务器接管关系信息和锁服务器管理范围信息,所述方法还包括:
所述锁代理接收到锁请求后,根据本地存储的锁服务器管理范围信息确定处理所述锁请求的锁服务器;
若所述锁服务器管理范围信息中确定出的处理所述锁请求的锁服务器标识为故障状态,所述锁代理根据本地存储的锁服务器接管关系信息确定所述故障状态的锁服务器的接管锁服务器;
将接收到的锁请求发送给所述接管锁服务器。
5.根据权利要求4所述的方法,其特征在于,所述第三锁服务器中保存有所述锁服务器接管关系信息,所述锁服务器接管关系信息通过一致性哈希环来确定,所述第三锁服务器确定自己不是所述第一锁服务器的接管锁服务器具体为:
所述第三锁服务器按照本地存储的一致性哈希环的顺时针方向或者逆时针方向确定自己不是所述第一锁服务器的接管锁服务器。
6.根据权利要求5所述的方法,其特征在于,所述方法还包括:
所述第三锁服务器将本地存储的一致性哈希环中的所述第一锁服务器标识为故障状态;
到达预定的时间后,更新本地存储的所述一致性哈希环,所述更新后的一致性哈希环中不包括所述第一锁服务器。
7.根据权利要求5-6任一所述的方法,其特征在于,所述每个锁代理本地存储有所述锁服务器接管关系信息和锁服务器管理范围信息,所述锁服务器管理范围信息和所述锁服务器接管关系信息通过所述一致性哈希环来确定;
所述锁代理接收到锁请求后,按照本地存储的一致性哈希环的顺时针方向或者逆时针方向确定处理所述锁请求的锁服务器;
若所述本地存储的一致性哈希环中的所述处理所述锁请求的锁服务器标识为故障状态;
所述锁代理按照本地存储的一致性哈希环的同样的方向确定所述处理所述锁请求的锁服务器的接管锁服务器。
8.根据权利要求7所述的方法,其特征在于,还包括:
所述锁代理将本地存储的一致性哈希环中的所述第一锁服务器标识为故障状态;
到达预定的时间后,更新本地存储的一致性哈希环,所述更新后的一致性哈希环中不包括所述第一锁服务器。
9.根据权利要求7所述的方法,其特征在于,还包括:
所述第三锁服务器接收第一通知消息,更新本地存储的一致性哈希环,所述更新后的一致性哈希环中不包括所述第一锁服务器,其中所述第一通知消息用于通知锁服务器更新本地存储的一致性哈希环,所述第一通知消息中携带所述第一锁服务器的信息;
所述锁代理接收所述第一通知消息,更新本地存储的一致性哈希环,所述更新后的一致性哈希环中不包括所述第一锁服务器。
10.根据权利要求7所述的方法,其特征在于,还包括:
所述第三锁服务器接收第二通知消息,更新本地存储的一致性哈希环,更新后的一致性哈希环中包含了新加入的锁服务器;其中所述第二通知消息用于通知锁服务器更新本地存储的一致性哈希环,所述第二通知消息中携带新加入的锁服务器的信息;
所述锁代理接收所述第二通知消息;更新本地存储的一致性哈希环,更新后的一致性哈希环中包含了新加入的锁服务器。
11.一种实现锁服务器故障处理的分布式系统,其特征在于,包括至少三个锁服务器;
当所述分布式系统中的第一锁服务器发生故障时,第三锁服务器用于确定自己是否为所述第一锁服务器的接管锁服务器;
所述第三锁服务器还用于确定自己不是所述第一锁服务器的接管锁服务器时,所述第三锁服务器用于处理加锁请求;
第二锁服务器用于确定自己是否为所述第一锁服务器的接管锁服务器;
所述第二锁服务器还用于确定自己为所述第一锁服务器的接管锁服务器时进入静默状态,进入所述静默状态之后,所述接管锁服务器用于处理锁重申请求,不用于处理加锁请求。
12.根据权利要求11所述的系统,其特征在于,还包括,所述接管锁服务器用于:
接收到锁重申请求时,根据锁权限信息表返回对应的锁权限信息;
接收到加锁请求时,返回拒绝的响应消息。
13.根据权利要求11或12所述的系统,其特征在于,所述分布式系统中还包括至少三个协议服务器和锁代理,其中,所述协议服务器和对应的锁代理位于一个节点设备中,所述系统还包括:
所述协议服务器用于接收到锁请求后,将所述锁请求发送给对应的锁代理,所述锁请求为锁重申请求或加锁请求。
14.根据权利要求13所述的系统,其特征在于,所述每个锁代理中存储有锁服务器接管关系信息和锁服务器管理范围信息,所述系统还包括:
所述锁代理用于接收到锁请求后,根据本地存储的锁服务器管理范围信息确定处理所述锁请求的锁服务器;
若所述锁服务器管理范围信息中的处理所述锁请求的锁服务器标识为故障状态,所述锁代理还用于根据本地存储的锁服务器接管关系信息确定所述处理所述锁请求的锁服务器的接管锁服务器;并将接收到的锁请求发送给所述处理所述锁请求的锁服务器的接管锁服务器。
15.根据权利要求14所述的系统,其特征在于,所述第三锁服务器中保存有所述锁服务器接管关系信息,所述锁服务器接管关系信息通过一致性哈希环来确定,所述第三锁服务器具体用于按照本地存储的一致性哈希环的顺时针方向或者逆时针方向,确定自己不是所述第一锁服务器的接管锁服务器。
16.根据权利要求15所述的系统,其特征在于,
所述第三锁服务器还用于将本地存储的一致性哈希环中的所述第一锁服务器标识为故障状态;并在到达预定的时间后,更新本地存储的一致性哈希环,所述更新后的一致性哈希环中不包括所述第一锁服务器。
17.根据权利要求15所述的系统,其特征在于,所述每个锁代理中存储有所述锁服务器接管关系信息和锁服务器管理范围信息,所述锁服务器管理范围信息和所述锁服务器接管关系信息通过所述一致性哈希环来确定;
所述锁代理还用于接收到锁请求后,按照本地存储的一致性哈希环的顺时针方向或者逆时针方向确定处理所述锁请求的锁服务器;
若所述本地存储的一致性哈希环中的所述处理所述锁请求的锁服务器标识为故障状态;所述锁代理还用于按照本地存储的一致性哈希环的同样的方向确定所述处理所述锁请求的锁服务器的接管锁服务器。
18.根据权利要求17所述的系统,所述系统还包括:
所述锁代理还用于将本地存储的一致性哈希环中的所述第一锁服务器标识为故障状态;并到达预定的时间后,更新本地存储的一致性哈希环,所述更新后的一致性哈希环中不包括所述第一锁服务器。
19.根据权利要求17所述的系统,其特征在于,还包括:
所述第三锁服务器还用于接收第一通知消息,并更新本地存储的一致性哈希环,所述更新后的一致性哈希环中不包括所述第一锁服务器,其中,所述第一通知消息用于通知锁服务器更新本地存储的一致性哈希环,所述第一通知消息中携带所述第一锁服务器的信息;
所述锁代理还用于接收所述第一通知消息,更新本地存储的一致性哈希环,所述更新后的一致性哈希环中不包括所述第一锁服务器。
20.根据权利要求17所述的系统,其特征在于,还包括:
所述第三锁服务器还用于接收第二通知消息,更新本地存储的一致性哈希环,更新后的一致性哈希环中包含了新加入的锁服务器;所述第二通知消息用于通知锁服务器更新本地存储的一致性哈希环,所述第二通知消息中携带新加入锁服务器的信息;
所述锁代理还用于接收所述第二通知消息;并更新本地存储的一致性哈希环,更新后的一致性哈希环中包含了新加入的锁服务器。
21.一种在分布式系统中实现故障处理的锁服务器,其特征在于,所述锁服务器包括接收模块、处理模块;
所述接收模块用于接收第一通知消息,并将所述第一通知消息发送给所述处理模块;所述第一通知消息中携带有故障锁服务器的信息;
所述处理模块用于接收到第一通知消息后,确定自己是否是故障锁服务器的接管锁服务器;若为所述故障锁服务器的接管锁服务器,所述锁服务器进入静默状态;
所述处理模块还用于接收到加锁请求之后,确定所述锁服务器是否处于静默状态,如果所述锁服务器不处于静默状态,则根据所述加锁请求分配锁权限信息;若所述锁服务器处于静默状态,则返回拒绝的响应消息,并将分配的锁权限信息或拒绝的响应消息发送给接收模块;
所述接收模块还用于将接收到的锁权限信息或者拒绝的响应消息返回给锁代理。
22.根据权利要求21所述的锁服务器,其特征在于,
所述处理模块还用于接收到锁重申请求之后,根据存储模块中存储的锁权限信息表返回对应的锁权限信息。
23.根据权利要求22所述的锁服务器,其特征在于,所述锁服务器还包括存储模块,所述存储模块存储有锁服务器接管关系信息,所述锁服务器接管关系信息可以通过一致性哈希环来确定;所述处理模块根据存储模块中存储的锁服务器接管关系信息确定自己是否是故障锁服务器的接管锁服务器具体为:
处理模块按所述一致性哈希环的顺时针方向或者逆时针方向确定自己是否是故障锁服务器的接管锁服务器。
24.根据权利要求23所述的锁服务器,其特征在于,
所述处理模块还用于在接收到所述第一通知消息之后,将存储模块中的一致性哈希环中的故障锁服务器标识为故障状态。
25.根据权利要求23所述的锁服务器,其特征在于,
所述接收模块还用于接收第二通知消息,并将所述第二通知消息发送给处理模块,述第二通知消息用于通知锁服务器更新存储模块中的一致性哈希环,所述第二通知消息中携带所述故障锁服务器的信息;
所述处理模块还用于更新存储模块中存储的一致性哈希环,使得更新后的一致性哈希环中不包括故障锁服务器。
26.根据权利要求23或24所述的锁服务器,其特征在于,所述接收模块还用于接收第三通知消息,并将所述第三通知消息发送给处理模块,所述第三通知消息用于通知锁服务器更新一致性哈希环,所述第三通知消息中还携带有新增加的锁服务器的标识;
所述处理模块还用于更新存储模块中存储的一致性哈希环,使得更新后的一致性哈希环中包括新增加的锁服务器。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201711118701.5A CN108023939B (zh) | 2014-11-12 | 2014-11-12 | 分布式系统中锁服务器故障的处理方法及其系统 |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201711118701.5A CN108023939B (zh) | 2014-11-12 | 2014-11-12 | 分布式系统中锁服务器故障的处理方法及其系统 |
PCT/CN2014/090886 WO2016074167A1 (zh) | 2014-11-12 | 2014-11-12 | 分布式系统中锁服务器故障的处理方法及其系统 |
CN201480064790.8A CN105794182B (zh) | 2014-11-12 | 2014-11-12 | 分布式系统中锁服务器故障的处理方法及其系统 |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201480064790.8A Division CN105794182B (zh) | 2014-11-12 | 2014-11-12 | 分布式系统中锁服务器故障的处理方法及其系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN108023939A true CN108023939A (zh) | 2018-05-11 |
CN108023939B CN108023939B (zh) | 2021-02-05 |
Family
ID=55953572
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201480064790.8A Active CN105794182B (zh) | 2014-11-12 | 2014-11-12 | 分布式系统中锁服务器故障的处理方法及其系统 |
CN201711118701.5A Active CN108023939B (zh) | 2014-11-12 | 2014-11-12 | 分布式系统中锁服务器故障的处理方法及其系统 |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201480064790.8A Active CN105794182B (zh) | 2014-11-12 | 2014-11-12 | 分布式系统中锁服务器故障的处理方法及其系统 |
Country Status (6)
Country | Link |
---|---|
US (1) | US9952947B2 (zh) |
EP (1) | EP3059932B1 (zh) |
JP (1) | JP6388290B2 (zh) |
CN (2) | CN105794182B (zh) |
HU (1) | HUE042424T2 (zh) |
WO (1) | WO2016074167A1 (zh) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110580232A (zh) * | 2018-06-08 | 2019-12-17 | 杭州宏杉科技股份有限公司 | 一种锁管理的方法及装置 |
CN111125048A (zh) * | 2019-12-06 | 2020-05-08 | 浪潮电子信息产业股份有限公司 | 一种故障通知方法、装置、设备及计算机可读存储介质 |
WO2022077777A1 (zh) * | 2020-10-16 | 2022-04-21 | 华为技术有限公司 | 一种锁重申方法、锁管理方法以及服务器 |
CN115277379A (zh) * | 2022-07-08 | 2022-11-01 | 北京城市网邻信息技术有限公司 | 分布式锁容灾处理方法、装置、电子设备及存储介质 |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP3232609B1 (en) | 2015-12-30 | 2019-09-04 | Huawei Technologies Co., Ltd. | Locking request processing method and server |
WO2018094686A1 (zh) * | 2016-11-25 | 2018-05-31 | 华为技术有限公司 | 一种smb业务故障处理方法和存储设备 |
US10999361B2 (en) * | 2018-09-07 | 2021-05-04 | Red Hat, Inc. | Consistent hash-based load balancer |
CN113034752B (zh) * | 2021-05-25 | 2021-08-03 | 德施曼机电(中国)有限公司 | 一种智能锁故障处理方法、装置及计算机可读存储介质 |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1945539A (zh) * | 2006-10-19 | 2007-04-11 | 华为技术有限公司 | 计算机集群系统中共享资源锁分配方法与计算机及集群系统 |
CN101252603A (zh) * | 2008-04-11 | 2008-08-27 | 清华大学 | 基于存储区域网络san的集群分布式锁管理方法 |
CN101329681A (zh) * | 2007-06-20 | 2008-12-24 | 国际商业机器公司 | 管理共享文件系统的方法和系统 |
US20120226673A1 (en) * | 2011-03-01 | 2012-09-06 | Vmware, Inc. | Configuration-less network locking infrastructure for shared file systems |
US8276013B2 (en) * | 2008-02-13 | 2012-09-25 | Broadcom Corporation | System and method for reducing a link failure detection delay using a link energy signal while in a low power idle mode |
CN103297268A (zh) * | 2013-05-13 | 2013-09-11 | 北京邮电大学 | 基于p2p技术的分布式数据一致性维护系统和方法 |
CN103812685A (zh) * | 2012-11-15 | 2014-05-21 | 腾讯科技(深圳)有限公司 | 同时在线统计系统及统计方法 |
Family Cites Families (22)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5943422A (en) | 1996-08-12 | 1999-08-24 | Intertrust Technologies Corp. | Steganographic techniques for securely delivering electronic digital rights management control information over insecure communication channels |
US6173293B1 (en) * | 1998-03-13 | 2001-01-09 | Digital Equipment Corporation | Scalable distributed file system |
US6990606B2 (en) * | 2000-07-28 | 2006-01-24 | International Business Machines Corporation | Cascading failover of a data management application for shared disk file systems in loosely coupled node clusters |
JP4478321B2 (ja) * | 2000-11-27 | 2010-06-09 | 富士通株式会社 | ストレージシステム |
US6601070B2 (en) * | 2001-04-05 | 2003-07-29 | Hewlett-Packard Development Company, L.P. | Distribution of physical file systems |
US7765329B2 (en) * | 2002-06-05 | 2010-07-27 | Silicon Graphics International | Messaging between heterogeneous clients of a storage area network |
US7289992B2 (en) * | 2003-05-01 | 2007-10-30 | International Business Machines Corporation | Method, system, and program for lock and transaction management |
US7356531B1 (en) * | 2003-07-25 | 2008-04-08 | Symantec Operating Corporation | Network file system record lock recovery in a highly available environment |
US7162666B2 (en) | 2004-03-26 | 2007-01-09 | Emc Corporation | Multi-processor system having a watchdog for interrupting the multiple processors and deferring preemption until release of spinlocks |
US7962915B2 (en) * | 2005-03-18 | 2011-06-14 | International Business Machines Corporation | System and method for preserving state for a cluster of data servers in the presence of load-balancing, failover, and fail-back events |
US7619761B2 (en) * | 2005-06-30 | 2009-11-17 | Microsoft Corporation | Extensible and distributed job execution service in a server farm |
JP4371321B2 (ja) * | 2006-03-10 | 2009-11-25 | 富士通株式会社 | Nfsサーバ、nfsサーバ制御プログラム、nfsサーバ制御方法 |
US8244846B2 (en) * | 2007-12-26 | 2012-08-14 | Symantec Corporation | Balanced consistent hashing for distributed resource management |
US8296599B1 (en) * | 2009-06-30 | 2012-10-23 | Symantec Corporation | System and method for implementing clustered network file system lock management |
US8533171B2 (en) * | 2011-04-08 | 2013-09-10 | Symantec Corporation | Method and system for restarting file lock services at an adoptive node during a network filesystem server migration or failover |
EP2686805A4 (en) | 2011-10-31 | 2016-02-24 | Hewlett Packard Development Co | Maintaining a File Capture |
US8661005B2 (en) | 2011-12-08 | 2014-02-25 | International Business Machines Corporation | Optimized deletion and insertion for high-performance resizable RCU-protected hash tables |
US8856583B1 (en) * | 2012-01-20 | 2014-10-07 | Google Inc. | Failover operation on a replicated distributed database system while maintaining access invariance |
US20140019429A1 (en) | 2012-07-12 | 2014-01-16 | Volker Driesen | Downtime reduction for lifecycle management events |
US8874535B2 (en) | 2012-10-16 | 2014-10-28 | International Business Machines Corporation | Performance of RCU-based searches and updates of cyclic data structures |
US10049022B2 (en) * | 2013-06-24 | 2018-08-14 | Oracle International Corporation | Systems and methods to retain and reclaim resource locks and client states after server failures |
US9304861B2 (en) * | 2013-06-27 | 2016-04-05 | International Business Machines Corporation | Unobtrusive failover in clustered network-attached storage |
-
2014
- 2014-11-12 EP EP14906065.9A patent/EP3059932B1/en active Active
- 2014-11-12 CN CN201480064790.8A patent/CN105794182B/zh active Active
- 2014-11-12 CN CN201711118701.5A patent/CN108023939B/zh active Active
- 2014-11-12 WO PCT/CN2014/090886 patent/WO2016074167A1/zh active Application Filing
- 2014-11-12 JP JP2016539939A patent/JP6388290B2/ja active Active
- 2014-11-12 HU HUE14906065A patent/HUE042424T2/hu unknown
-
2017
- 2017-05-11 US US15/592,217 patent/US9952947B2/en active Active
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1945539A (zh) * | 2006-10-19 | 2007-04-11 | 华为技术有限公司 | 计算机集群系统中共享资源锁分配方法与计算机及集群系统 |
CN101329681A (zh) * | 2007-06-20 | 2008-12-24 | 国际商业机器公司 | 管理共享文件系统的方法和系统 |
US8276013B2 (en) * | 2008-02-13 | 2012-09-25 | Broadcom Corporation | System and method for reducing a link failure detection delay using a link energy signal while in a low power idle mode |
CN101252603A (zh) * | 2008-04-11 | 2008-08-27 | 清华大学 | 基于存储区域网络san的集群分布式锁管理方法 |
US20120226673A1 (en) * | 2011-03-01 | 2012-09-06 | Vmware, Inc. | Configuration-less network locking infrastructure for shared file systems |
CN103812685A (zh) * | 2012-11-15 | 2014-05-21 | 腾讯科技(深圳)有限公司 | 同时在线统计系统及统计方法 |
CN103297268A (zh) * | 2013-05-13 | 2013-09-11 | 北京邮电大学 | 基于p2p技术的分布式数据一致性维护系统和方法 |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110580232A (zh) * | 2018-06-08 | 2019-12-17 | 杭州宏杉科技股份有限公司 | 一种锁管理的方法及装置 |
CN110580232B (zh) * | 2018-06-08 | 2021-10-29 | 杭州宏杉科技股份有限公司 | 一种锁管理的方法及装置 |
CN111125048A (zh) * | 2019-12-06 | 2020-05-08 | 浪潮电子信息产业股份有限公司 | 一种故障通知方法、装置、设备及计算机可读存储介质 |
CN111125048B (zh) * | 2019-12-06 | 2022-04-22 | 浪潮电子信息产业股份有限公司 | 一种故障通知方法、装置、设备及计算机可读存储介质 |
WO2022077777A1 (zh) * | 2020-10-16 | 2022-04-21 | 华为技术有限公司 | 一种锁重申方法、锁管理方法以及服务器 |
CN114710976A (zh) * | 2020-10-16 | 2022-07-05 | 华为技术有限公司 | 一种锁重申方法、锁管理方法以及服务器 |
CN115277379A (zh) * | 2022-07-08 | 2022-11-01 | 北京城市网邻信息技术有限公司 | 分布式锁容灾处理方法、装置、电子设备及存储介质 |
Also Published As
Publication number | Publication date |
---|---|
JP6388290B2 (ja) | 2018-09-12 |
US20170242762A1 (en) | 2017-08-24 |
HUE042424T2 (hu) | 2019-07-29 |
CN105794182B (zh) | 2017-12-15 |
EP3059932A4 (en) | 2016-12-21 |
CN108023939B (zh) | 2021-02-05 |
CN105794182A (zh) | 2016-07-20 |
JP2017500653A (ja) | 2017-01-05 |
WO2016074167A1 (zh) | 2016-05-19 |
EP3059932A1 (en) | 2016-08-24 |
EP3059932B1 (en) | 2018-09-19 |
US9952947B2 (en) | 2018-04-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN105794182B (zh) | 分布式系统中锁服务器故障的处理方法及其系统 | |
CN107391294B (zh) | 一种ipsan容灾系统的建立方法及装置 | |
US8990368B2 (en) | Discovery of network software relationships | |
US9262229B2 (en) | System and method for supporting service level quorum in a data grid cluster | |
US8667096B2 (en) | Automatically generating system restoration order for network recovery | |
US9690675B2 (en) | Dynamically changing members of a consensus group in a distributed self-healing coordination service | |
EP2754059B1 (en) | Clustered client failover | |
CN111130835A (zh) | 数据中心双活系统、切换方法、装置、设备及介质 | |
CN109845192B (zh) | 动态地适配网络的计算机系统和方法及计算机可读介质 | |
CN106775953A (zh) | 实现OpenStack高可用的方法与系统 | |
US11169973B2 (en) | Atomically tracking transactions for auditability and security | |
CN107466456A (zh) | 加锁请求的处理方法及服务器 | |
CN112965784B (zh) | 一种服务访问方法、装置、设备及计算机可读存储介质 | |
US11784905B2 (en) | Method and apparatus for ensuring continued device operational reliability in cloud-degraded mode | |
US8977595B1 (en) | Message-recovery file log locating and monitoring | |
US20110197062A1 (en) | Method and system for license management | |
US20160050113A1 (en) | Methods for managing storage virtual machine configuration changes in a distributed storage system and devices thereof | |
US11544162B2 (en) | Computer cluster using expiring recovery rules | |
JP2020135571A (ja) | コンピュータシステム、コンピュータ装置およびライセンス管理方法 | |
Ramasamy et al. | Hacm: high availability control method in container-based microservice applications over multiple clusters | |
US11290318B2 (en) | Disaster recovery of cloud resources | |
US8799926B1 (en) | Active node detection in a failover computing environment | |
EP3961419A1 (en) | Computer-implemented method for storing a dataset and computer network | |
Dimitrov et al. | Low-cost Open Data As-a-Service in the Cloud. | |
CN115237682A (zh) | 区块链节点故障同步方法、装置、计算机设备和存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |