CN115866018B

CN115866018B - 业务处理方法、装置、电子设备及计算机可读存储介质

Info

Publication number: CN115866018B
Application number: CN202310173709.0A
Authority: CN
Inventors: 位风杰
Original assignee: Inspur Electronic Information Industry Co Ltd
Current assignee: Inspur Electronic Information Industry Co Ltd
Priority date: 2023-02-28
Filing date: 2023-02-28
Publication date: 2023-05-16
Anticipated expiration: 2043-02-28
Also published as: CN115866018A

Abstract

本申请公开了一种业务处理方法、装置、电子设备及计算机可读存储介质，涉及存储技术领域，旨在当发生透明故障切换时保证客户端业务转移成功，应用于第一节点，为集群系统中任一节点，包括：当接收到客户端发送的重连请求时与客户端进行重连；重连请求由客户端在与第二节点断连时向第一节点发起，第二节点为集群系统中除第一节点之外的任一节点；当重连成功时，对第二节点中关于客户端的剩余业务进行处理，发送重连成功消息至第二节点，以使其将对应于客户端的定时进程关闭；定时进程用于当第二节点与客户端断连且第二节点存储有关于客户端的可恢复标志时开始计时，在计时时间达到预设时间时，若客户端的连接状态为断连状态，则删除可恢复标志。

Description

业务处理方法、装置、电子设备及计算机可读存储介质

技术领域

本申请涉及存储技术领域，特别涉及一种业务处理方法、装置、电子设备及计算机可读存储介质。

背景技术

SMB（Server Message Block，一种通信协议）透明故障转移，是SMB3.0提供的一种特性，是指在一台服务器故障的情况下，客户端请求可以平滑切换到另外一台服务器，可以实现0宕机时间，切换过程少量IO会有延迟，客户端感知不到节点故障连接断开。在相关技术中，一般是通过durable handles（网络短暂中断后可恢复）技术来实现透明故障转移，其实现如下：

1、SMB客户端在创建请求时携带dh2q tag（一种标签），服务端在处理请求时同步创建durable handle返回客户端并同步保存到本地数据库；

2、由于一些异常原因（如节点断电、网络异常等），当客户端和服务端session（会话）断开连接后，客户端将会重新请求连接；

3、客户端与新的服务节点建立session连接后，会重新请求该duanble handle；服务端在接收到该请求后，会查找该记录，并在查找到相关记录之后进行恢复连接，继续业务处理。

其中，上述实现流程存在scavenge机制，scavenge机制为SMB原生的数据记录清除机制，其实现过程如下：

1、服务端在与客户端断连时，如果存在durable handle标志，则启动scavenge定时器，60s后检查是否重连成功；

2、如果重连成功，则不清除记录的durable handle标志；

3、如果没有重连成功，则清除记录的durable handle标志。

但是，scavenge机制的存在，在节点频繁故障的场景中，会出现故障重连之后，再次故障时间和scavenge定时器时间重合的情景，此种情景下scavenge会清除记录的durable handle标志，导致再次重连时无法查找到对应的记录，进而导致请求重连失败，客户端业务中断退出。

因此，如何在集群节点异常，发生透明故障切换转移的过程中，保证客户端业务转移的成功，进而保证集群系统的高可用性和高可靠性是本领域技术人员亟待解决的问题。

发明内容

本申请的目的是提供一种业务处理方法，该业务处理方法可以在集群节点异常，发生透明故障切换转移的过程中，保证客户端业务转移的成功，进而保证集群系统的高可用性和高可靠性；本申请的另一目的是提供另一种业务处理方法、业务处理装置、电子设备及计算机可读存储介质，均具有上述有益效果。

第一方面，本申请提供了一种业务处理方法，应用于第一节点，所述第一节点为集群系统中的任一节点，所述方法包括：

当接收到客户端发送的重连请求时，根据所述重连请求与所述客户端进行重连；所述重连请求由所述客户端在与第二节点断连时向所述第一节点发起，所述第二节点为所述集群系统中除所述第一节点之外的任一节点；

当与所述客户端重连成功时，对所述第二节点中关于所述客户端的剩余业务进行处理，并发送重连成功消息至所述第二节点，以使所述第二节点将对应于所述客户端的定时进程关闭；

其中，所述定时进程，用于当所述第二节点与所述客户端断连且所述第二节点存储有关于所述客户端的可恢复标志时开始计时，并在计时时间达到预设时间时，若所述客户端的连接状态为断连状态，则删除所述可恢复标志。

可选地，所述当接收到客户端发送的重连请求时，根据所述重连请求与所述客户端进行重连之前，还包括：

当接收到连接请求时，判断所述连接请求中是否包含关于所述可恢复标志的请求信息；

若是，则确定所述连接请求为所述重连请求；

若否，则确定所述连接请求为初始连接请求。

可选地，所述根据所述重连请求与所述客户端进行重连，包括：

根据所述重连请求确定所述第二节点的节点信息；

根据所述节点信息查询所述第二节点是否存储有所述可恢复标志；

若是，则与所述客户端进行重连。

根据所述重连请求，查询所述集群系统中的每一节点是否存储有所述可恢复标志；

若是，则与所述客户端进行重连。

根据所述重连请求查询集群数据库中是否存储所述可恢复标志；

若是，则与所述客户端建立连接。

可选地，当所述连接请求为所述初始连接请求时，所述方法还包括：

根据所述初始连接请求与所述客户端建立连接；

对所述客户端的客户端业务进行处理。

可选地，所述根据所述初始连接请求与所述客户端建立连接之后，还包括：

创建所述可恢复标志并发送至所述客户端；

对所述可恢复标志进行保存；

将所述客户端的连接状态设置为已连接状态。

可选地，所述对所述可恢复标志进行保存，包括：

将所述可恢复标志保存至所述第一节点的本地数据库；

将所述可恢复标志发送至所述集群系统内除所述第一节点之外的任一其他节点，以使所述其他节点将所述可恢复标志保存至所述其他节点对应的本地数据库。

可选地，所述集群系统内各所述节点对应的本地数据库为持久化数据库。

可选地，所述业务处理方法还包括：

当接收到所述客户端发送的业务完成信息时，与所述客户端断开连接；

将各所述持久化数据库中对应于所述客户端的可恢复标志删除。

可选地，所述业务处理方法还包括：

当监控到节点异常时，与所述客户端断开连接，并将所述连接状态设置为所述断连状态；

查询自身是否存储有所述可恢复标志，若是，则启动所述定时进程。

可选地，所述业务处理方法还包括：

当查询到所述可恢复标志时，对所述客户端业务的业务处理记录进行保存。

可选地，所述对所述第二节点中关于所述客户端的剩余业务进行处理，包括：

根据所述重连请求确定所述第二节点的节点信息；

根据所述节点信息查询所述第二节点中关于客户端业务的业务处理记录；

根据所述业务处理记录确定所述第二节点中关于所述客户端的剩余业务；

对所述剩余业务进行处理。

可选地，所述发送重连成功消息至所述第二节点，以使所述第二节点将对应于所述客户端的定时进程关闭，包括：

根据所述重连请求确定所述第二节点的节点信息；

根据所述节点信息将所述重连成功消息发送至所述第二节点，以使所述第二节点将所述定时进程关闭。

将所述重连成功消息发送至所述集群系统中除所述第一节点之外的各其他节点，以使各所述其他节点查询自身是否开启有所述定时进程，若是，则关闭所述定时进程。

第二方面，本申请提供了另一种业务处理方法，应用于客户端，所述方法包括：

当与集群系统中的第二节点断连时，发送重连请求至第一节点；所述第二节点为所述集群系统中的任一节点，所述第二节点为所述集群系统中除所述第一节点之外的任一节点；

当与所述第一节点重连成功时，请求所述第一节点对所述第二节点中关于所述客户端的剩余业务进行处理；所述第一节点还用于发送重连成功消息至所述第二节点，以使所述第二节点将对应于所述客户端的定时进程关闭；

第三方面，本申请还公开了一种业务处理装置，应用于第一节点，所述第一节点为集群系统中的任一节点，所述装置包括：

重连模块，用于当接收到客户端发送的重连请求时，根据所述重连请求与所述客户端进行重连；所述重连请求由所述客户端在与第二节点断连时向所述第一节点发起，所述第二节点为所述集群系统中除所述第一节点之外的任一节点；

处理模块，用于当与所述客户端重连成功时，对所述第二节点中关于所述客户端的剩余业务进行处理，并发送重连成功消息至所述第二节点，以使所述第二节点将对应于所述客户端的定时进程关闭；

第四方面，本申请还公开了另一种业务处理装置，应用于客户端，所述装置包括：

发送模块，用于当与集群系统中的第二节点断连时，发送重连请求至第一节点；所述第二节点为所述集群系统中的任一节点，所述第二节点为所述集群系统中除所述第一节点之外的任一节点；

请求模块，用于当与所述第一节点重连成功时，请求所述第一节点对所述第二节点中关于所述客户端的剩余业务进行处理；所述第一节点还用于发送重连成功消息至所述第二节点，以使所述第二节点将对应于所述客户端的定时进程关闭；

第五方面，本申请还公开了一种电子设备，包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现如上所述的任一种业务处理方法的步骤。

第六方面，本申请还公开了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如上所述的任一种业务处理方法的步骤。

应用本申请所提供的技术方案，对于集群系统中的任一节点，如若接收到了客户端由于与实际处理节点（即上述第二节点）断连而发起的重连请求，则与客户端进行重连，并在重连成功后接管第二节点中关于客户端的剩余业务，并继续对其进行处理，与此同时，可以发送重连成功消息至第二节点，即主动告知第二节点客户端重连成功，由此，第二节点即可关闭在与客户端断连时所建立的定时进程，该定时进程即为上述scavenge机制中的定时任务，由于定时任务已关闭，那么，将不会再执行durable handle标志（即上述可恢复标志）的清除操作，从而避免客户端重连成功时durable handle标志被误删除的情况，因此，基于该种实现方式，当客户端在集群节点异常，发生透明故障切换转移的过程中，可以有效保证客户端业务转移成功，进而保证集群系统的高可用性和高可靠性。

附图说明

为了更清楚地说明现有技术和本申请实施例中的技术方案，下面将对现有技术和本申请实施例描述中需要使用的附图作简要的介绍。当然，下面有关本申请实施例的附图描述的仅仅是本申请中的一部分实施例，对于本领域普通技术人员来说，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图，所获得的其他附图也属于本申请的保护范围。

图1为本申请所提供的一种业务处理系统的结构示意图；

图2为本申请所提供的一种业务处理方法的流程示意图；

图3为本申请所提供的另一种业务处理方法的流程示意图；

图4为现有技术中的一种业务处理方法的时序图；

图5为本申请所提供的一种业务处理方法的时序图；

图6为本申请所提供的一种集群系统中进行信息共享的原理图；

图7为本申请提供的一种数据更新记录方法的时序图；

图8为本申请所提供的一种业务处理装置的流程示意图；

图9为本申请所提供的另一种业务处理装置的流程示意图；

图10为本申请所提供的一种电子设备的结构示意图。

具体实施方式

本申请的核心是提供一种业务处理方法，该业务处理方法在集群节点异常，发生透明故障切换转移的过程中，保证客户端业务转移的成功，进而保证集群系统的高可用性和高可靠性；本申请的另一核心是提供另一种业务处理方法、业务处理装置、电子设备及计算机可读存储介质，均具有上述有益效果。

为了对本申请实施例中的技术方案进行更加清楚、完整地描述，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行介绍。显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请实施例提供了一种业务处理方法。

首先，请参考图1，图1为本申请所提供的一种业务处理系统的结构示意图，本申请实施例所提供的业务处理方法可以基于图1所示业务处理系统实现。图1所示业务处理系统包括客户端100和集群系统200，集群系统200中包括有大量的节点设备，用于为客户端100提供业务处理服务。在一种可能的实现方式中，集群系统200可以为分布式集群系统。

需要说明的是，本申请实施例所提供的业务处理方法应用于集群系统中的第一节点，该第一节点为集群系统中的任一节点。

进一步，请参考图2，图2为本申请所提供的一种业务处理方法的流程示意图，该业务处理方法可以包括如下S101和S102。

S101：当接收到客户端发送的重连请求时，根据重连请求与客户端进行重连；重连请求由客户端在与第二节点断连时向第一节点发起，第二节点为集群系统中除第一节点之外的任一节点；

本步骤旨在实现客户端重连，也就是在接收到客户端发送的重连请求时，与客户端进行重连，需要说明的是，“重连”是指客户端在与第一节点建立连接之前，与集群系统中的其他节点建立有连接关系，并且由该其他节点提供了部分业务处理服务。

有基于此，重连请求是客户端在与第二节点断开连接时向第一节点发起的，在客户端与第二节点断开连接之前，第二节点用于为客户端提供业务处理服务，当然，该第二节点可以为集群系统中除第一节点之外的任一节点（即上述其他节点）。换而言之，当客户端需要进行业务处理时，需要由集群系统中的节点为其提供业务处理服务，因此，需要与集群系统中节点建立连接关系，此处，将与客户端建立连接关系的节点称之为第二节点；进一步，在第二节点为客户端提供业务处理服务的过程中，如若发生了异常问题，如节点断电、网络异常等，将会与客户端断开连接，停止为其提供业务处理服务，但是，由于客户端业务仍未处理完毕，因此，客户端将会向集群系统中除第二节点之外的任意一个其他节点发起重连请求，此处，将与接收到该重连请求的节点称之为第一节点。在此基础上，当第一节点接收到客户端发送的重连请求时，将会与客户端进行重连，也就是重新建立连接关系，以便于为客户端继续提供未完成的业务处理服务。

S102：当与客户端重连成功时，对第二节点中关于客户端的剩余业务进行处理，并发送重连成功消息至第二节点，以使第二节点将对应于客户端的定时进程关闭；

其中，定时进程，用于当第二节点与客户端断连且第二节点存储有关于客户端的可恢复标志时开始计时，并在计时时间达到预设时间时，若客户端的连接状态为断连状态，则删除可恢复标志。

本步骤旨在实现客户端业务中重剩余业务（即未完成的客户端业务）的处理以及重连成功消息的转发。具体而言，当第一节点与客户端重连成功时，即可对第二节点中关于客户端的剩余业务继续进行处理，以实现集群系统对于客户端的完整的业务处理服务。与此同时，可以将重连成功消息发送至第二节点，以主动告知第二节点客户端重连成功，此时，第二节点即可将自身创建的对应于客户端的定时进程关闭。

其中，定时进程由第二节点创建。如上所述，在客户端与第二节点断开连接之前，第二节点用于为客户端提供业务处理服务，当出现异常问题时，客户端与第二节点断开连接，此时，对于第二节点而言，如若自身存储有关于客户端的可恢复标志，即上述durablehandle标志，说明集群系统支持durable handle技术，并且其在正常处理客户端业务时（发生异常问题之前）已经创建了durable handle标志，由此，即可创建定时进程，该定时进程即为上述scavenge机制中的定时任务。进一步，定时进程在启动运行之后开始计时，直至计时时间达到预设时间时，查询客户端的连接状态，若连接状态为断连状态，则将可恢复标志删除，若连接状态为已连接状态，则不删除可恢复标志。

显然，通过在集群系统的节点中设置消息通知机制，可以在与客户端重连成功时将重连成功消息发送给原本为客户端提供业务处理服务的异常节点，使得该异常节点将自身创建的scavenge机制中的定时任务删除（即上述关闭定时进程），由此，即使后续出现再次故障时间和scavenge机制中定时时间重合的场景，异常节点也不会再执行将可恢复标志清除的操作，以有效避免客户端重连失败的问题，从而保证客户端业务转移成功。

可见，本申请实施例所提供的业务处理方法，对于集群系统中的任一节点，如若接收到了客户端由于与实际处理节点（即上述第二节点）断连而发起的重连请求，则与客户端进行重连，并在重连成功后接管第二节点中关于客户端的剩余业务，并继续对其进行处理，与此同时，可以发送重连成功消息至第二节点，即主动告知第二节点客户端重连成功，由此，第二节点即可关闭在与客户端断连时所建立的定时进程，该定时进程即为上述scavenge机制中的定时任务，由于定时任务已关闭，那么，将不会再执行durable handle标志（即上述可恢复标志）的清除操作，从而避免客户端重连成功时durable handle标志被误删除的情况，因此，基于该种实现方式，当客户端在集群节点异常，发生透明故障切换转移的过程中，可以有效保证客户端业务转移成功，进而保证集群系统的高可用性和高可靠性。

在本申请的一个实施例中，上述当接收到客户端发送的重连请求时，根据重连请求与客户端进行重连之前，还可以包括如下步骤：

当接收到连接请求时，判断连接请求中是否包含关于可恢复标志的请求信息；

若是，则确定连接请求为重连请求；

若否，则确定连接请求为初始连接请求。

可以理解的是，第一节点接收到客户端的重连请求是因为客户端与第二节点连接失败，重连请求本质上也是一个连接请求，并且对于第一节点而言，其只是接收到了一个连接请求，因此，需要对该连接请求进行进一步判断，以确定该连接请求为重连请求（发生节点断连后发起的连接请求）还是为初始连接请求（为处理客户端业务第一次发起的连接请求）。

如上所述，durable handles技术即网络短暂中断后可恢复技术，支持在发生节点断连时重新恢复连接，即重连，其在重新恢复连接过程中所发起的请求将会包含有关于durable handles标志的请求信息。因此，对于第一节点而言，其在接收到客户端发起的连接请求时，可以对其进行解析以确定是否包含有关于可恢复标志的请求信息，若是，则可以确定该连接请求为重连请求，否则为初始连接请求。

在本申请的一个实施例中，上述根据重连请求与客户端进行重连，可以包括如下步骤：

根据重连请求确定第二节点的节点信息；

根据节点信息查询第二节点是否存储有可恢复标志；

若是，则与客户端进行重连。

本申请实施例提供了一种第一节点与客户端之间的重连方法。如上所述，第一节点接收到客户端的重连请求是因为客户端与第二节点连接失败，在第一节点接收到重连请求之前，由第二节点为客户端提供业务处理服务，因此，客户端在向第一节点发起重连请求时，可以将第二节点的节点信息附加于该重连请求中。由此，第一节点在接收到重连请求之后，即可通过对其解析确定第二节点的节点信息，使得第一节点根据该节点信息确定之前为客户端提供业务处理服务的集群节点，也就是第二节点。进一步，在第二节点中查询其中是否存储有可恢复标志，若是，则可以确定自身所属集群系统支持durable handles技术，同时也可以确定客户端确实处于暂时断连状态且支持重连，由此，即可与客户端进行重连；反之，若并未在第二节点中查询到可恢复标志，则拒绝客户端的重连请求。

根据重连请求，查询集群系统中的每一节点是否存储有可恢复标志；

若是，则与客户端进行重连。

本申请实施例提供了另一种第一节点与客户端之间的重连方法。可以理解的是，在第一节点接收到客户端发起的重连请求时，第一节点无法确定在此之前为客户端提供业务处理服务的集群节点，也就是无法确定第二节点，有基于此，第一节点可以根据该重连请求依次查询集群系统中的每一个节点上是否存储有可恢复标志，若至少存在一个节点中存储有可恢复标志，则可以确定自身所属集群系统支持durable handles技术，同时也可以确定客户端确实处于暂时断连状态且支持重连，由此，即可与客户端进行重连；反之，若集群系统中每一个节点均为存储有可恢复标志，则拒绝客户端的重连请求。

根据重连请求查询集群数据库中是否存储可恢复标志；

若是，则与客户端建立连接。

本申请实施例提供了又一种第一节点与客户端之间的重连方法。具体而言，可以为集群系统创建集群数据库，对于每一个集群节点而言，均可以将自身创建的可恢复标志存储至该集群数据库中。由此，第一节点在接收到重连请求之后，即可直接在集群数据库中进行查询，以确定其中是否存储有对应于当前客户端的可恢复标志，若是，则可以确定自身所属集群系统支持durable handles技术，同时也可以确定当前客户端确实处于暂时断连状态且支持重连，然后与客户端进行重连；反之，若并未在集群数据库中查询到当前客户端对应的可恢复标志，则拒绝客户端的重连请求。

可以理解的是，由于集群数据库用于为集群系统中的所有节点提供存储服务，因此，在集群数据库中，客户端信息与可恢复标志信息可以采用一一对应存储的存储方式，更加方便进行可恢复标志的查询操作。

在本申请的一个实施例中，当连接请求为初始连接请求时，该方法还可以包括如下步骤：

根据初始连接请求与客户端建立连接；

对客户端的客户端业务进行处理。

如上所述，对于第二节点而言，其所接收到的连接请求可能为初始连接请求，也就是说，在第二节点接收到连接请求之前，集群系统中没有任何节点为其提供过业务处理服务，此时，可以直接与客户端建立连接关系，并对客户端的客户端业务进行处理。

在本申请的一个实施例中，上述根据初始连接请求与客户端建立连接之后，还可以包括如下步骤：

创建可恢复标志并发送至客户端；

对可恢复标志进行保存；

将客户端的连接状态设置为已连接状态。

为保证客户端业务的正常处理，在根据初始连接请求与客户端建立连接关系之后，如若集群系统支持durable handles技术，则可以创建可恢复标志，并将其发送至客户端，同时对其进行保存，以便于在自身发生异常与客户端断开连接时，客户端可以基于该可恢复标志向集群系统中的其他节点发起重连请求，并利用重连节点继续处理客户端中的剩余业务，进而实现客户端业务转移，从而保证客户端业务的正常处理。

此外，在于客户端连接成功之后，还可以将客户端的连接状态设置为已连接状态，以供自身创建的定时进程对客户端连接状态进行查询。当然，在连接请求为重连请求且与客户端重连成功之后，同样可以将客户端的连接状态设置为已连接状态，但是，由于在此之前客户端已经处于断连状态，因此，此处将客户端的连接状态设置为已连接状态，本质上是将客户端的连接状态由断连状态更改为已连接状态，显然，其中客户端的断连状态则是由之前为客户端提供业务处理服务的节点在自身发生异常时设置的。

在本申请的一个实施例中，上述对可恢复标志进行保存，可以包括如下步骤：

将可恢复标志保存至第一节点的本地数据库；

将可恢复标志发送至集群系统内除第一节点之外的任一其他节点，以使其他节点将可恢复标志保存至其他节点对应的本地数据库。

本申请实施例提供了一种保存可恢复标志的实现方法，在本申请实施例中，实现了可恢复标志的双重备份。具体而言，可以为集群系统中的每一个节点配置相应的本地数据库，第一节点在创建完成可恢复标志之后，可以将其保存至自身的本地数据库，同时，还可以将其转发至集群系统内除第一节点之外的任一其他节点上，使得该其他节点将可恢复标志存储至自身的本地数据库。也就是说，对于客户端而言，其所对应的可恢复标志在集群系统内会有两份记录，显然，该种实现方式可以避免由于第一节点的本地数据库发生故障导致的对应于客户端的可恢复标志丢失的问题，进而避免客户端重连失败的问题，从而保证客户端业务转移成功。

当然，双重备份也可以替换为集群备份，即第一节点在创建完成可恢复标志之后，除了将其保存至自身的本地数据库，还可以将其转发至集群系统内除第一节点之外的所有其他节点上，使得所有其他节点将可恢复标志存储至自身的本地数据库，实现可恢复标志的集群备份。

在本申请的一个实施例中，集群系统内各节点对应的本地数据库为持久化数据库。

本申请实施例提供了一种具体类型的本地数据库，即持久化数据库，用于实现可恢复标志的记录。可以理解的是，在已有的实现方案中，多使用smbXsrv_open_global.tdb.n（n为ctdb节点的pnn号）和locking.tdb.n数据库来记录duanble handle标志，但是，这两个数据库均为非持久化数据库。在面对一些特殊的场景，如集群系统的扩容、缩容等场景，集群系统中所有的节点都会进行重启，此时，由于集群系统中的数据库均为非持久化数据库，因此集群系统会在重启服务时进行数据库清理，集群系统重启完成后，客户端进行重连时，重连节点将无法查找相应的duanble handle标志记录，因而无法进行业务恢复，导致客户端业务退出。

因此，为解决该技术问题，本申请实施例采用持久化数据库实现上述功能，即便面对集群系统重启的场景，集群系统也无法将持久化数据库中的duanble handle标志删除，进而避免客户端业务退出的问题。

在本申请的一个实施例中，该业务处理方法还可以包括如下步骤：

当接收到客户端发送的业务完成信息时，与客户端断开连接；

将各持久化数据库中对应于客户端的可恢复标志删除。

本申请实施例所提供的业务处理方法，可以在客户端业务完成之后，实现持久化数据库内可恢复标志的删除，从而可以避免由于持久化数据库中存储数据过多而造成的业务处理效率降低的问题。

在实现过程中，当客户端业务处理完毕时，可以发送业务完成消息至第一节点，由此，第一节点即可与客户端断开连接，然后转发该业务完成消息至集群系统中的其他节点，使得集群系统中的每一个节点均将自身的持久化数据库中的对应于该客户端的可恢复标志删除。

当监控到节点异常时，与客户端断开连接，并将连接状态设置为断连状态；

查询自身是否存储有可恢复标志，若是，则启动定时进程。

具体而言，第一节点在对客户端业务进行处理的过程中，无论是客户端初次连接集群系统还是重连集群系统，均可以实时监控自身是否出现异常，并在出现异常时，与客户端断开连接，此时，可以将客户端的连接状态设置为断连状态，当然，其本质上是由已连接状态更改为断连状态。进一步，查询自身是否存储有可恢复标志，若是，则说明自身所属的集群系统支持durable handles技术，可以启动定时进程，反之，如若自身并未存储有可恢复标志，则说明当前集群系统不支持durable handles技术，因此，将不会启动定时进程，直接结束客户端业务即可。

当查询到可恢复标志时，对客户端业务的业务处理记录进行保存。

本申请实施例所提供的业务处理方法可以进一步实现客户端业务的业务处理记录的保存，显然，通过对客户端业务处理过程中的业务处理记录进行保存，有助于业务转移之后可基于该业务处理记录继续进行剩余业务的处理，保证客户端业务可被正常处理且可以处理完毕。因此，在可以查询到自身存储有可恢复标志时，可以对客户端业务的业务处理记录进行保存。

可以理解的是，当无法查询到可恢复标志时，说明当前集群系统不支持durablehandles技术，在节点异常与客户端断连之后，客户端将无法发起重连请求继续进行剩余业务的处理，因此，无需对业务处理记录进行保存，以有效节省存储资源。当然，该种实现方式仅为本申请实施例所提供的一种实现方式，本领域技术人员依然可以根据实际需求进行设定，为便于后续异常溯源，即便无法查询到可恢复标志，依然可以对客户端业务的业务处理记录进行保存，本申请对此不做限定。

在本申请的一个实施例中，上述对第二节点中关于客户端的剩余业务进行处理，可以包括如下步骤：

根据重连请求确定第二节点的节点信息；

根据节点信息查询第二节点中关于客户端业务的业务处理记录；

根据业务处理记录确定第二节点中关于客户端的剩余业务；

对剩余业务进行处理。

本申请实施例提供了一种对客户端剩余业务进行处理的实现方法。如上所述，第一节点可以根据接收到的重连请求确定第二节点的节点信息，且集群节点在处理客户端业务时可以进行业务处理记录的存储，因此，可以根据该节点信息确定第二节点，并从第二节点中获取关于客户端业务的业务处理记录，因为在客户端重连第一节点之前，由第二节点对客户端业务进行处理，因此，可以从第二节点中获取相应的业务处理记录以确定客户端业务中的剩余业务，并对其进行处理。由此，实现客户端重连之后剩余业务的处理。

在本申请的一个实施例中，上述发送重连成功消息至第二节点，以使第二节点将对应于客户端的定时进程关闭，可以包括如下步骤：

根据重连请求确定第二节点的节点信息；

根据节点信息将重连成功消息发送至第二节点，以使第二节点将定时进程关闭。

本申请实施例提供了一种关闭第二节点中定时进程的实现方法。如上所述，在客户端重连第一节点之前，由第二节点对客户端业务进行处理，且第一节点可以根据接收到的重连请求确定第二节点的节点信息，因此，可以直接根据该节点信息确定第二节点。由此，第一节点可以直接将重连成功消息发送至第二节点，使得第二节点直接关闭自身所创建的定时进程。

将重连成功消息发送至集群系统中除第一节点之外的各其他节点，以使各其他节点查询自身是否开启有定时进程，若是，则关闭定时进程。

本申请实施例提供了另一种关闭第二节点中定时进程的实现方法。具体而言，在面对第一节点无法确定第二节点的情况下，可以直接将重连成功消息发送至集群系统中除第一节点之外的所有其他节点，使得每一个其他节点均自行查询确定自身是否创建有对应于该客户端的定时进程（定时进程与客户端相对应，旨在防止集群系统中进行多客户端业务处理造成定时任务混淆的问题），若存在，则直接将其关闭即可。

本申请实施例提供了另一种业务处理方法。

请参考图3，图3为本申请所提供的另一种业务处理方法的流程示意图，该业务处理方法应用于客户端，可以包括如下S201和S202。

S201：当与集群系统中的第二节点断连时，发送重连请求至第一节点；第二节点为集群系统中的任一节点，第二节点为集群系统中除第一节点之外的任一节点；

S202：当与第一节点重连成功时，请求第一节点对第二节点中关于客户端的剩余业务进行处理；第一节点还用于发送重连成功消息至第二节点，以使第二节点将对应于客户端的定时进程关闭；

对于本申请实施例提供的方法的介绍请参照上一方法实施例，本申请在此不做赘述。

在上述各实施例的基础上，本申请实施例CTDB（Cluster Trivial Database，一种轻量级的集群数据库）集群系统为例，提供了又一种业务处理方法。

第一方面：

首先，请参考图4，图4为现有技术中的一种业务处理方法的时序图，其实现流程如下：

（1）假设集群系统部署有N个节点，节点A目前为客户端提供SMB服务，其数据库中记录有duanble handle标志，在0时刻时，节点A异常，虚拟IP发生漂移，无法继续提供服务，此时，节点A将会启动scavenge定时器（定时进程），并将客户端连接状态标记为disconnected状态（断连状态）；

（2）客户端请求重新连接，20s时，客户端重连到B节点，重连成功，此时B节点提供服务，并将客户端连接状态修改为connected状态（已连接状态）；

（3）50s时，节点B也出现异常，断开连接，再次将客户端连接状态修改为disconnected状态；

（4）60s时，节点A的scavenge任务到达执行时间，检查客户端连接状态为disconnected状态，认为重连失败，清除数据库中对应于客户端的duanble handle标志；

（5）70s时，客户端和节点C重连，但是在查找duanble handle标志时，查找失败（相应记录已经被步骤（4）清除），客户端业务重连失败，业务退出。

进一步，为了解决此场景下客户端重连失败导致业务退出的问题，请参考图5和图6，图5为本申请所提供的一种业务处理方法的时序图，图6为本申请所提供的一种集群系统中进行信息共享的原理图，在上述步骤（2）中，在客户端重连成功提供服务后，可以在B节点增加消息通知机制，其实现流程如下：

（1）20s时，在节点B重连成功提供服务后，节点B的SMBD进程通知节点B的CTDB进程重连成功；

（2）21s时，节点B的CTDB进程接收到重连成功的消息后，将此消息发送给集群系统的其他节点；

（3）22s时，各个其他节点的CTDB进程接收到重连成功的消息后，通知给自身节点的SMBD进程；

（4）23s时，每个节点的SMBD进程接收到本节点CTDB进程发送的重连成功的消息后，检查自身是否存在scavenge任务，如果存在对应的scavenge任务，则将对应任务删除；

（5）删除scavenge任务后，60s时，将不会进行duanble handle标志记录清除，如此，在70s时，节点C请求重连时，就能够查到对应的duanble handle标志记录，重连成功，业务继续。

第二方面：

首先，请参考图7，图7为本申请提供的一种数据更新记录方法的时序图，其实现流程如下：

（1）节点A的SMBD进程在保存记录（关于duanble handle标志的记录）到本地数据库之前，可以通过CTDB进程查找（可以采用任意一种随机查找算法）集群系统内一个正在运行的节点，并发送该记录的备份，最后把记录保存在其对应的本地数据库，由此，最新的记录会保存在该记录的Dmaster（自身所属节点）和任意一个节点上，这样每条记录在集群系统内部都会有两份最新数据；

（2）当节点A发生异常之后，CTDB进程将会进行集群系统的恢复和数据库的同步；

（3）集群系统恢复后，客户端进行重连，此时，可以查找到备份节点数据库中的备份记录，来进行业务恢复。

在此基础上，可以新增持久化数据库来保存上述记录，用于实现记录的持久化保存，具体可分为如下过程：

（1）更新数据库记录：如图7所示，在CTDBn进程进行数据库备份时，可以将记录备份到本地持久化数据库，这样，当集群系统重启时，也不会删除该持久化数据库中的记录；

（2）客户端正常关闭文件的流程（即客户端业务完成退出）：在客户端正常关闭流程中，由于是正常关闭文件，程序将会直接进入清除数据库记录的流程，在此流程中，可以清除持久化数据库中的记录，不会对原有流程造成影响，也不会发生一直向本持久化数据库中写记录，使得数据库记录过多，造成访问过慢的情况；

（3）当出现集群系统内所有节点CTDB服务重启的时候，由于新增的持久化数据库属性为持久化保存，因此在CTDB进程启动时，不会首先清除该持久化数据库中的记录，因此，在CTDB进程和SMBD进程重启完成并且恢复正常后，客户端请求重连时，可以从新增的持久化数据库中找到相应的记录用于业务恢复，可以使客户端业务继续，不会断流。

本申请实施例提供了一种业务处理装置。

请参考图8，图8为本申请所提供的一种业务处理装置的结构示意图，该业务处理装置应用于第一节点，第一节点为集群系统中的任一节点，可以包括：

重连模块1，用于当接收到客户端发送的重连请求时，根据重连请求与客户端进行重连；重连请求由客户端在与第二节点断连时向第一节点发起，第二节点为集群系统中除第一节点之外的任一节点；

处理模块2，用于当与客户端重连成功时，对第二节点中关于客户端的剩余业务进行处理，并发送重连成功消息至第二节点，以使第二节点将对应于客户端的定时进程关闭；

可见，本申请实施例所提供的业务处理装置，对于集群系统中的任一节点，如若接收到了客户端由于与实际处理节点（即上述第二节点）断连而发起的重连请求，则与客户端进行重连，并在重连成功后接管第二节点中关于客户端的剩余业务，并继续对其进行处理，与此同时，可以发送重连成功消息至第二节点，即主动告知第二节点客户端重连成功，由此，第二节点即可关闭在与客户端断连时所建立的定时进程，该定时进程即为上述scavenge机制中的定时任务，由于定时任务已关闭，那么，将不会再执行durable handle标志（即上述可恢复标志）的清除操作，从而避免客户端重连成功时durable handle标志被误删除的情况，因此，基于该种实现方式，当客户端在集群节点异常，发生透明故障切换转移的过程中，可以有效保证客户端业务转移成功，进而保证集群系统的高可用性和高可靠性。

在本申请的一个实施例中，该业务处理装置还可以包括判断模块，用于在上述当接收到客户端发送的重连请求时，根据重连请求与客户端进行重连之前，当接收到连接请求时，判断连接请求中是否包含关于可恢复标志的请求信息；若是，则确定连接请求为重连请求；若否，则确定连接请求为初始连接请求。

在本申请的一个实施例中，上述重连模块1可具体用于根据重连请求确定第二节点的节点信息；根据节点信息查询第二节点是否存储有可恢复标志；若是，则与客户端进行重连。

在本申请的一个实施例中，上述重连模块1可具体用于根据重连请求，查询集群系统中的每一节点是否存储有可恢复标志；若是，则与客户端进行重连。

在本申请的一个实施例中，上述重连模块1可具体用于根据重连请求查询集群数据库中是否存储可恢复标志；若是，则与客户端建立连接。

在本申请的一个实施例中，该业务处理装置还可以包括初始处理模块，用于当连接请求为初始连接请求时，根据初始连接请求与客户端建立连接；对客户端的客户端业务进行处理。

在本申请的一个实施例中，上述初始处理模块还用于在上述根据初始连接请求与客户端建立连接之后，创建可恢复标志并发送至客户端；对可恢复标志进行保存；将客户端的连接状态设置为已连接状态。

在本申请的一个实施例中，上述初始处理模块可具体用于将可恢复标志保存至第一节点的本地数据库；将可恢复标志发送至集群系统内除第一节点之外的任一其他节点，以使其他节点将可恢复标志保存至其他节点对应的本地数据库。

在本申请的一个实施例中，集群系统内各节点对应的本地数据库可以为持久化数据库。

在本申请的一个实施例中，该业务处理装置还可以包括断连模块，用于当接收到客户端发送的业务完成信息时，与客户端断开连接；将各持久化数据库中对应于客户端的可恢复标志删除。

在本申请的一个实施例中，该业务处理装置还可以包括启动模块，用于当监控到节点异常时，与客户端断开连接，并将连接状态设置为断连状态；查询自身是否存储有可恢复标志，若是，则启动定时进程。

在本申请的一个实施例中，该业务处理装置还可以包括保存模块，用于当查询到可恢复标志时，对客户端业务的业务处理记录进行保存。

在本申请的一个实施例中，上述处理模块2可具体用于根据重连请求确定第二节点的节点信息；根据节点信息查询第二节点中关于客户端业务的业务处理记录；根据业务处理记录确定第二节点中关于客户端的剩余业务；对剩余业务进行处理。

在本申请的一个实施例中，上述处理模块2可具体用于根据重连请求确定第二节点的节点信息；根据节点信息将重连成功消息发送至第二节点，以使第二节点将定时进程关闭。

在本申请的一个实施例中，上述处理模块2可具体用于将重连成功消息发送至集群系统中除第一节点之外的各其他节点，以使各其他节点查询自身是否开启有定时进程，若是，则关闭定时进程。

对于本申请实施例提供的装置的介绍请参照上述方法实施例，本申请在此不做赘述。

本申请实施例提供了另一种业务处理装置。

请参考图9，图9为本申请所提供的另一种业务处理装置的结构示意图，该业务处理装置应用于客户端，可以包括：

发送模块3，用于当与集群系统中的第二节点断连时，发送重连请求至第一节点；第二节点为集群系统中的任一节点，第二节点为集群系统中除第一节点之外的任一节点；

请求模块4，用于当与第一节点重连成功时，请求第一节点对第二节点中关于客户端的剩余业务进行处理；第一节点还用于发送重连成功消息至第二节点，以使第二节点将对应于客户端的定时进程关闭；

本申请实施例提供了一种电子设备。

请参考图10，图10为本申请所提供的一种电子设备的结构示意图，该电子设备可包括：

存储器，用于存储计算机程序；

处理器，用于执行计算机程序时可实现如上述任意一种业务处理方法的步骤。

如图10所示，为电子设备的组成结构示意图，电子设备可以包括：处理器10、存储器11、通信接口12和通信总线13。处理器10、存储器11、通信接口12均通过通信总线13完成相互间的通信。

在本申请实施例中，处理器10可以为中央处理器（Central Processing Unit，CPU）、特定应用集成电路、数字信号处理器、现场可编程门阵列或者其他可编程逻辑器件等。

处理器10可以调用存储器11中存储的程序，具体的，处理器10可以执行业务处理方法的实施例中的操作。

存储器11中用于存放一个或者一个以上程序，程序可以包括程序代码，程序代码包括计算机操作指令，在本申请实施例中，存储器11中至少存储有用于实现以下功能的程序：

当接收到客户端发送的重连请求时，根据重连请求与客户端进行重连；重连请求由客户端在与第二节点断连时向第一节点发起，第二节点为集群系统中除第一节点之外的任一节点；

当与客户端重连成功时，对第二节点中关于客户端的剩余业务进行处理，并发送重连成功消息至第二节点，以使第二节点将对应于客户端的定时进程关闭；

其中，定时进程，用于当第二节点与客户端断连且第二节点存储有关于客户端的可恢复标志时开始计时，并在计时时间达到预设时间时，若客户端的连接状态为断连状态，则删除可恢复标志；

或者：

当与集群系统中的第二节点断连时，发送重连请求至第一节点；第二节点为集群系统中的任一节点，第二节点为集群系统中除第一节点之外的任一节点；

当与第一节点重连成功时，请求第一节点对第二节点中关于客户端的剩余业务进行处理；第一节点还用于发送重连成功消息至第二节点，以使第二节点将对应于客户端的定时进程关闭；

在一种可能的实现方式中，存储器11可包括存储程序区和存储数据区，其中，存储程序区可存储操作系统，以及至少一个功能所需的应用程序等；存储数据区可存储使用过程中所创建的数据。

此外，存储器11可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件或其他易失性固态存储器件。

通信接口12可以为通信模块的接口，用于与其他设备或者系统连接。

当然，需要说明的是，图10所示的结构并不构成对本申请实施例中电子设备的限定，在实际应用中电子设备可以包括比图10所示的更多或更少的部件，或者组合某些部件。

本申请实施例提供了一种计算机可读存储介质。

本申请实施例所提供的计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时可实现如上述任意一种业务处理方法的步骤。

该计算机可读存储介质可以包括：U盘、移动硬盘、只读存储器（Read-OnlyMemory，ROM）、随机存取存储器（Random Access Memory，RAM）、磁碟或者光盘等各种可以存储程序代码的介质。

对于本申请实施例提供的计算机可读存储介质的介绍请参照上述方法实施例，本申请在此不做赘述。

说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器（RAM）、内存、只读存储器（ROM）、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM或技术领域内所公知的任意其它形式的存储介质中。

以上对本申请所提供的技术方案进行了详细介绍。本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想。应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以对本申请进行若干改进和修饰，这些改进和修饰也落入本申请的保护范围内。

Claims

1.一种业务处理方法，其特征在于，应用于第一节点，所述第一节点为集群系统中的任一节点，所述方法包括：

2.根据权利要求1所述的方法，其特征在于，所述当接收到客户端发送的重连请求时，根据所述重连请求与所述客户端进行重连之前，还包括：

若是，则确定所述连接请求为所述重连请求；

若否，则确定所述连接请求为初始连接请求。

3.根据权利要求2所述的方法，其特征在于，所述根据所述重连请求与所述客户端进行重连，包括：

根据所述重连请求确定所述第二节点的节点信息；

若是，则与所述客户端进行重连。

4.根据权利要求2所述的方法，其特征在于，所述根据所述重连请求与所述客户端进行重连，包括：

若是，则与所述客户端进行重连。

5.根据权利要求2所述的方法，其特征在于，所述根据所述重连请求与所述客户端进行重连，包括：

若是，则与所述客户端进行重连。

6.根据权利要求2所述的方法，其特征在于，当所述连接请求为所述初始连接请求时，所述方法还包括：

根据所述初始连接请求与所述客户端建立连接；

对所述客户端的客户端业务进行处理。

7.根据权利要求6所述的方法，其特征在于，所述根据所述初始连接请求与所述客户端建立连接之后，还包括：

创建所述可恢复标志并发送至所述客户端；

对所述可恢复标志进行保存；

将所述客户端的连接状态设置为已连接状态。

8.根据权利要求7所述的方法，其特征在于，所述对所述可恢复标志进行保存，包括：

将所述可恢复标志保存至所述第一节点的本地数据库；

9.根据权利要求8所述的方法，其特征在于，所述集群系统内各所述节点对应的本地数据库为持久化数据库。

10.根据权利要求9所述的方法，其特征在于，还包括：

11.根据权利要求7所述的方法，其特征在于，还包括：

12.根据权利要求11所述的方法，其特征在于，还包括：

13.根据权利要求1所述的方法，其特征在于，所述对所述第二节点中关于所述客户端的剩余业务进行处理，包括：

根据所述重连请求确定所述第二节点的节点信息；

对所述剩余业务进行处理。

14.根据权利要求1所述的方法，其特征在于，所述发送重连成功消息至所述第二节点，以使所述第二节点将对应于所述客户端的定时进程关闭，包括：

根据所述重连请求确定所述第二节点的节点信息；

15.根据权利要求1所述的方法，其特征在于，所述发送重连成功消息至所述第二节点，以使所述第二节点将对应于所述客户端的定时进程关闭，包括：

16.一种业务处理方法，其特征在于，应用于客户端，所述方法包括：

17.一种业务处理装置，其特征在于，应用于第一节点，所述第一节点为集群系统中的任一节点，所述装置包括：

18.一种业务处理装置，其特征在于，应用于客户端，所述装置包括：

19.一种电子设备，其特征在于，包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现如权利要求1至15任一项所述的业务处理方法的步骤。

20.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至15任一项所述的业务处理方法的步骤。