分布式系统的数据处理方法及装置的制造方法
【技术领域】
[0001]本发明涉及数据处理领域，具体来说，涉及一种分布式系统的数据处理方法及装置。
【背景技术】
[0002]分布式集群文件系统是一种基于集群技术，向用户提供文件系统访问接口的存储系统。为了维护数据在集群系统中的一致性，需要在分布式的环境下维护锁信息。但是，硬件设备是不可靠的，在发生集群内部网络设备或计算机设备故障时，但是目前并没有一种技术可以监测到故障的发生并及时处理锁请求的超时，因此无法保证分布式锁的可靠性与可用性。
[0003]针对相关技术中的问题，目前尚未提出有效的解决方案。
【发明内容】
[0004]针对相关技术中的问题，本发明提出一种分布式系统的数据处理方法及装置。
[0005]本发明的技术方案是这样实现的:
[0006]根据本发明的一个方面，提供了一种分布式系统的数据处理方法。
[0007]该方法包括:
[0008]发送端向接收端发送锁请求；
[0009]在锁请求成功发送至接收端后，发送端与接收端之间同步锁请求的状态信息；
[0010]根据状态信息及发送端与接收端之间的通信状态确定是否发生故障；
[0011 ] 发送端及接收端根据故障选择是否释放锁请求占用的资源。
[0012]其中，发送端及接收端根据故障选择是否释放锁请求占用的资源，包括:
[0013]在发送端获取到状态信息并确认发生故障后，发送端释放锁请求占用的资源。
[0014]此外，在故障被修复后，包括:
[0015]在发送端接收到接收端发送的锁服务授予请求后，发送端向接收端发送故障信息;
[0016]接收端接收故障信息并释放锁请求占用的资源。
[0017]其中，同步的配置参数包括以下至少之一:
[0018]同步间隔时间、同步失败后重试次数。
[0019]另外，发送端及接收端根据故障选择是否释放锁请求占用的资源，包括:
[0020]在发送端接收到状态信息并确认发生故障后，发送端重新发起一锁请求。
[0021]根据本发明的另一方面，还提供了一种分布式系统的数据处理装置，该装置，包括:
[0022]第一发送模块，用于发送端向接收端发送锁请求；
[0023]建立模块，用于在锁请求成功发送至接收端后，发送端与接收端之间同步锁请求的状态信息；
[0024]确定模块，用于根据状态信息及发送端与接收端之间的通信状态确定是否发生故障；
[0025]释放模块，用于发送端及接收端根据故障选择是否释放锁请求占用的资源。
[0026]其中，释放模块进一步包括:
[0027]第一释放子模块，用于在发送端接收到状态信息并确认发生故障后，发送端释放锁请求占用的资源。
[0028]此外，该装置还包括:
[0029]第二发送模块，用于在发送端接收到接收端发送的锁服务授予请求后，发送端向接收端发送故障信息。
[0030]其中，释放模块进一步包括:
[0031]第二释放子模块，用于接收端接收故障信息并释放锁请求占用的资源。
[0032]此外，该装置还可以包括:
[0033]重发模块，用于在发送端接收到状态信息并确认发生故障后，发送端重新发起一锁请求。
[0034]通过本发明的分布式系统的数据处理方法在有效地保证了锁业务的请求效率的同时不会影响系统正常的性能，并且对于锁请求不会产生额外的开销。
【附图说明】
[0035]为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
[0036]图1是根据本发明实施例的分布式系统的数据处理方法的流程图；
[0037]图2是根据本发明实施例的分布式系统的数据处理方法的示意性流程图；
[0038]图3是根据本发明实施例的分布式系统的数据处理装置的框图。
【具体实施方式】
[0039]下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本发明保护的范围。
[0040]为了更好的理解本发明的技术方案，在实现本发明的技术方案之前，首先简练阐述关于分布式锁服务的步骤:
[0041]锁发起者是锁服务的使用者，锁协调者是锁服务的提供者；分布式锁的授予过程是一个需要两次通信的异步操作。第一次通信是锁发起者发送锁请求，锁协调者收到后回复确认收到请求；第二次通信是锁协调者发送锁授予请求，锁发起者收到后回复确认授予，最后，锁发起者向使用者返回加锁结果。至此，一次锁请求完成。
[0042]根据本发明的实施例，提供了分布式系统的数据处理方法及装置。
[0043]如图1所示，根据本发明实施例的分布式系统的数据处理方法包括:
[0044]步骤S101，发送端向接收端发送锁请求；
[0045]步骤S103，在锁请求成功发送至接收端后，发送端与接收端之间同步锁请求的状态?目息;
[0046]步骤S105，根据状态信息及发送端与接收端之间的通信状态确定是否发生故障；
[0047]步骤S107，发送端及接收端根据故障选择是否释放锁请求占用的资源。
[0048]综上，本发明在锁发起者收到锁协调者确认收到请求的回复后会产生一个同步机制，采用定时同步状态信息的方式，监测硬件设备与软件系统的异常导致的通信失败，根据接收到的加锁结果及通信状态来确认是否发生故障，之后根据配置选择处理与响应方式，从而保证了系统的稳定性与锁服务的请求效率。
[0049]具体的，发送端可以根据具体的故障原因选择是否释放当前锁请求所占用的资源，比如当发送端获取到锁请求的状态信息也即获知了加锁结果后，并确认发生了故障由于通信失败导致的超时，可以根据当前的故障原因选择释放本次锁请求占用的资源或者再次重新发起一个新的锁请求。
[0050]然而，如果发送端在确认了故障后，故障又得到了修复，那么接收端会向发送端发送锁服务授予请求，此时接收端可以发现本次锁服务授予请求对的锁已经不存在了，则通知接收端，此次锁请求所需的锁由于故障超时不存在了，那么此刻接收端在接收到该通知后就会释放本次锁请求占用的资源。如果之前发送端释放了锁请求占用的资源，那么至此，故障超时的锁在发起端与接收端的资源就均被释放了，因此不会发生资源的泄露。
[0051]在同步锁请求的状态信息的过程，对于同步的控制参数则可以根据当前环境的需要进行配置调节以调整对于故障监测的敏感度，比如控制参数可以为