数据节点监听方法及装置与流程

本申请涉及网络通信技术领域，尤其涉及数据节点监听方法及装置。

背景技术：

zookeeper作为分布式协调服务系统，能够为大型分布式计算提供开源的分布式配置、同步服务和命名注册等服务。zookeeper系统包括服务端和多个客户端，服务端包括多个数据节点。

在zookeeper支持的监听机制中，客户端可以向服务端注册监听器(watcher)，以便服务端监听客户端所关注的目标数据节点。若服务端监听到目标数据节点发生变化则触发该监听器，以通知注册该监听器的客户端。

但是，由于zookeeper默认监听器使用一次后会删除该监听器，所以zookeeper中监听器仅能执行一次触发操作，即在目标数据节点发生变化后，客户端仅会接收到一次通知。此后，目标数据节点再次发生变化，之前设置该监听器的客户端不会再接收到通知。

若客户端仍希望监听目标数据节点的情况下，则需要再次向服务端注册监听器，这会增加客户端与服务端的网络交互次数；并且，若在删除原监听器之后构建新监听器之前，目标数据节点发生变化，则服务端是无法监听到该变化的，即会遗漏此期间目标数据节点的变化。

即zookeeper中现有监听机制，其操作过程繁琐、占用较多网络资源且具有一定的遗漏率。

技术实现要素：

鉴于此，本申请提供数据节点监听方法及装置，可以简化监听机制的操作过程，避免占用较多网络资源，避免遗漏数据节点的变化。

为了实现上述目的，本申请提供了下述技术特征：

一种数据节点监听方法，包括：

利用监听器监听目标数据节点；

若所述监听器监听到所述目标数据节点发生变化，则发送通知请求至注册所述监听器的客户端；

保留所述监听器继续监听所述目标数据节点。

可选的，在所述利用监听器监听目标数据节点之前，还包括：

接收所述客户端发送的注册请求；其中，所述注册请求包括目标数据节点标识和监听类型；

构建与所述注册请求对应的监听器；

存储所述监听器的监听信息；其中，所述监听信息包括所述客户端标识、所述目标数据节点标识和所述监听类型。

可选的，所述若所述监听器监听到所述目标数据节点发生变化，则发送通知请求至注册所述监听器的客户端，包括：

若所述监听器监听到所述目标数据节点发生所述监听类型指示的变化，则生成通知请求；

发送所述通知请求至客户端；其中，通知请求可以包括所述客户端标识、目标数据节点标识和监听类型。

可选的，所述注册请求还包括监听结束条件，所述监听结束条件包括监听参数和监听阈值；

则在所述发送通知请求至注册所述监听器的客户端之后，还包括更新所述监听参数；

在所述保留所述监听器继续监听所述目标数据节点之前，还包括：

判断更新后的监听参数是否达到所述监听阈值；

若更新后的监听参数达到所述监听阈值，则表示达到所述监听结束条件，删除所述监听器；

若更新后的监听参数未达到所述监听阈值，则表示未达到监听结束条件，执行所述保留所述监听器继续监听所述目标数据节点的步骤。

可选的，在所述监听参数包括监听次数的情况下，所述监听阈值包括预设次数。

在所述监听参数包括监听时长的情况下，所述监听阈值包括预设时长。

可选的，还包括：

接收到所述客户端发送的删除请求；其中，所述删除请求包括客户端标识、目标数据节点标识和监听类型；

查找与所述删除请求对应的监听器；

删除与所述删除请求对应的监听器。

一种数据节点监听方法，包括：

发送注册请求至服务端，以供所述服务端构建与所述注册请求对应的监听器，并利用该监听器来监听目标数据节点；

接收所述服务端发送的通知请求；

其中，所述通知请求为所述服务端的所述监听器监听到所述目标数据节点发生变化后发送至客户端的，并且，服务端会保留所述监听器继续监听所述目标数据节点。

可选的，在接收所述服务端发送的通知请求之后，还包括：

向所述服务端发送与所述通知请求对应的数据获取请求；

接收服务端发送的所述目标数据节点的数据内容；

若所述目标数据节点的数据内容达到设定条件，则执行与所述注册请求对应的触发操作；

发送删除请求至服务端，以供所述服务端删除所述监听器。

一种数据节点监听装置，包括：

监听节点单元，用于利用监听器监听目标数据节点；

发送通知单元，用于若所述监听器监听到所述目标数据节点发生变化，则发送通知请求至注册所述监听器的客户端；

保留单元，用于保留所述监听器继续监听所述目标数据节点。

一种数据节点监听装置，包括：

发送请求单元，用于发送注册请求至服务端，以供所述服务端构建与所述注册请求对应的监听器，并利用该监听器来监听目标数据节点；

接收通知单元，用于接收所述服务端发送的通知请求；

其中，所述通知请求为所述服务端的所述监听器监听到所述目标数据节点发生变化后发送至客户端的，并且，服务端会保留所述监听器继续监听所述目标数据节点。

一种电子设备，包括：

处理器；以及

存储器，用于存储所述处理器的可执行指令；

其中，所述处理器配置为经由执行所述可执行指令来执行所述的数据节点监听方法。

一种存储介质，所述存储介质用于存储软件程序，该软件程序可用于实现所述的数据节点监听方法。

通过以上技术手段，可以实现以下有益效果：

本申请在一次监听操作后监听器可以保留下来，不会被删除，所以可以重复监听目标数据节点，避免删除和新建监听器之间遗漏目标数据节点变化的情况，从而解决删除监听器后与新建监听器之间遗漏目标数据节点的变化问题。

客户端仅需向服务端发送一次注册请求即可，不必多次向服务端发送注册请求，所以可以减少客户端与服务端网络交互次数，从而节省网络资源和简化监听机制操作。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例公开的一种数据节点监听系统的结构示意图；

图2为本申请实施例公开的一种数据节点监听方法的流程图；

图3为本申请实施例公开的又一种数据节点监听方法的流程图；

图4为本申请实施例公开的一种数据节点监听装置的结构示意图；

图5为本申请实施例公开的又一种数据节点监听装置的结构示意图。

具体实施方式

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

本申请主要应用于zookeeper中，所以本申请涉及的服务端为zookeeper的服务器集群，客户端为使用zookeeper服务的机器。后续不再一一解释说明。

根据本申请的一种实施例，提供一种数据节点监听系统。参见图1，数据节点监听系统包括：

服务端100；其中，服务端100可以存储有多个数据节点。

与服务端100相连的多个客户端200。

在介绍本申请提供的数据节点监听方法之前，先介绍服务端100和客户端200的预执行操作。参见图2，预执行操作包括以下步骤：

步骤s201：客户端生成注册请求，并发送注册请求至服务端。

服务端具有多个数据节点，若一客户端关注服务端中某个数据节点，即客户端需要得知某个数据节点是否发生变化，则客户端可以生成注册请求，以便向服务端发送注册请求，从而于服务端中构建监听器，以用于监听数据节点是否发生变化。

以目标数据节点为例，若客户端需要得知目标数据节点是否发生变化，则需要构建与目标数据节点对应的注册请求。其中，注册请求包括目标数据节点标识、监听类型。注册请求还可以包括监听结束条件，当然注册请求中不包含监听结束条件也是可以的。

下面一一介绍注册请求中的各个内容：

目标数据节点标识：由于服务端包括多个数据节点，所以采用目标数据节点标识，来表示注册请求是对于目标数据节点的。

监听类型：目标数据节点发生变化包括很多类型，例如，创建子节点、数据值改变、删除子节点等等。

客户端可以根据需求选择一个类型作为监听类型，例如选择数据值改变作为监听类型，则后续构建的监听器则可以用来监听目标数据节点是否发生数据值改变。通常情况下，一个监听器对应一个监听类型，若需要监听目标数据节点的多种类型变化，则可以构建用于监听不同类型变化的多个监听器。

监听结束条件：在注册请求中增加监听结束条件，可以有助于在服务端持续监听目标数据节点的过程中，为监听过程提供一个结束条件，避免监听无限制持续的进行。

监听结束条件包括监听参数和监听阈值，本实施例提供监听结束条件的两种实现方式：

第一种实现方式：在所述监听参数包括监听次数的情况下，所述监听阈值包括预设次数，在监听次数达到预设次数情况下，达到监听结束条件。

第二种实现方式：在所述监听参数包括监听时长的情况下，所述监听阈值包括预设时长，在监听时长达到预设时长情况下，达到监听结束条件。

步骤s202：客户端存储与注册请求对应的设定条件和触发操作。

客户端可以设置与注册请求对应的设定条件，以及，达到设定条件后需要执行的触发操作。然后，存储与注册请求对应的设定条件和触发操作。关于设定条件和触发操作会在步骤s310～s312中描述，在此暂不赘述。

步骤s203：服务端接收所述客户端发送的注册请求，并构建与所述注册请求对应的监听器。

服务端接收客户端发送的注册请求，服务端构建与注册请求对应的监听器。

在注册请求包括客户端标识、目标数据节点标识和监听类型的情况下，服务端构建监听器用于监听目标数据节点是否发生该监听类型的变化，并在确定发生变化后，通知与客户端标识对应的客户端。

注册请求还可以包括监听结束条件，该监听结束条件即为上述构建监听器的存活周期，到达监听结束条件后便需删除监听器，若未达到监听结束条件则可以继续使用监听器。

步骤s204：服务端保存监听信息。

服务端通常会维护监听信息表，监听信息表可以统一保存各个监听信息，以便服务端统一管控各个客户端的监听器。

参见表1，为服务端的监听信息表的一种示意(未示出监听结束条件)。

表1

以表格中颜色加重一栏为例该栏对应一个监听器，该监听器用于为客户端1和客户端2监听数据节点1是否发生“创建子节点”的变化。数据栏中为客户端1对应的客户端标识1和客户端2对应的客户端标识2。

上述为服务端和客户端预执行操作，下面介绍服务端和客户端的在线执行过程。

根据本申请一种实施例，提供一种数据节点监听方法，应用于图1所示的数据节点监听系统。本实施例中与注册请求对应的监听器设置有监听结束条件。可以理解的是，若注册请求中不包含监听结束条件则可以不执行步骤s304～306。

参见图3，数据节点监听方法可以包括以下步骤：

步骤s301：服务端利用监听器监听目标数据节点。

通常情况下，服务端会依据监听信息表来统一监听各个数据节点是否发生变化。以表1为例，服务端会监听表1中各个数据节点标识对应的数据节点、是否发生监听类型指示的变化。

以步骤203中构建与注册请求对应的监听器为例，服务端会监听目标数据节点标识对应的目标数据节点，是否发生指定的监听类型指示的变化。

步骤s302：监听器监听目标数据节点是否发生变化，若是则进入步骤s303，若否则进入步骤s304。

通常情况下，服务端中一监听器监听到一数据节点发生某一监听类型指示的变化，则会通知该数据节点中该监听类型对应的所有客户端。仍以表1中颜色加重一栏为例，在数据节点标识1对应的数据节点1发生创建子节点的变化，则服务端会通知客户端标识1对应的客户端1和客户端标识2对应的客户端2。

以步骤203中构建与注册请求对应的监听器为例，监听器监听目标数据节点是否发生注册请求中监听类型指示的变化，若是则进入步骤s303，若否则进入步骤s304。

步骤s303：若所述监听器监听到所述目标数据节点发生变化，则发送通知请求至所述客户端。

若所述监听器监听到所述目标数据节点发生注册请求中监听类型指示的变化，则生成通知请求，并发送所述通知请求至客户端。其中通知请求可以包括所述客户端标识、目标数据节点标识和监听类型。

步骤s304：服务端更新监听结束条件中的监听参数。

在所述监听参数包括监听次数情况下，则可以更新监听次数。例如，在监听次数初始化为零的情况下，可以递增监听次数；又或者，在监听次数初始化为监听次数的情况下，可以递减监听次数。

在所述监听参数包括监听时长情况下，则可以持续记录监听时长。例如，在监听时长初始化为零的情况下，可以持续记录监听时长。又或者，在监听时长初始化为预设监听时长的情况下，可以对监听时长执行倒计时操作。

步骤s305：服务端判断是否达到监听结束条件；若是则进入步骤s306，若否则进入步骤s307。

服务端可以判断监听参数是否达到监听阈值；若所述监听参数达到所述监听阈值，则表示达到监听结束条件，否则表示未达到监听结束条件。

在所述监听参数包括监听次数情况下，所述监听阈值包括预设次数；在监听次数达到预设次数情况下，表示达到监听结束条件，否则表示未达到监听结束条件。

在所述监听参数包括监听时长情况下，在监听阈值包括预设时长。在监听时长达到预设时长情况下，表示达到监听结束条件，否则表示未达到监听结束条件。

步骤s306：删除所述监听器。

若所述监听参数达到所述监听阈值，则表示达到监听结束条件，删除所述监听器。删除监听器具体可以包括：服务端在表1的监听信息表中删除目标数据节点标识对应的监听类型中的客户端标识，从而达到目标数据节点再发生相同监听类型的变化，则不会再通知该客户端。需要指出的是，目标数据节点再发生相同监听类型的变化，仍是可以通知到其它客户端的。

步骤s307：保留所述监听器，进入步骤s301。

若所述监听参数未达到所述监听阈值，则表示未达到监听结束条件，保留所述监听器，继续监听所述目标数据节点。本步骤可以避免客户端重复向服务端注册监听器。

步骤s308：客户端接收服务端发送的通知请求，向所述服务端发送与通知请求对应的数据获取请求。

客户端接收服务端发送的通知请求，通知请求可以包括所述客户端标识、目标数据节点标识和监听类型。

客户端在得知目标数据节点发生变化后，为了得知变化的数据，可以生成数据获取请求。

步骤s309：客户端接收服务端发送的所述目标数据节点的数据内容。

在数据获取请求包括目标数据节点标识的情况下，客户端接收服务端发送的目标数据节点的全部数据内容。

步骤s310：客户端判断所述目标数据节点的数据内容是否达到设定条件。若是则进入步骤s311，若否不执行操作。

客户端预先存储有与注册请求对应的设定条件以及触发操作，在所述目标数据节点的数据内容达到设定条件的情况下，表示服务端中目标数据节点的变化已经达到客户端的需求，此时可以执行触发操作，且，无需再监听目标数据节点。

在所述目标数据节点的数据内容未达到设定条件的情况下，表示服务端中目标数据节点的变化未达到客户端的需求，此时不执行触发操作，需继续监听目标数据节点。

步骤s311：客户端执行与所述注册请求对应的触发操作。

若所述数据内容中与监听类型对应的数据值达到设定条件，则客户端执行与所述注册请求对应的触发操作。

例如，目标数据节点为投诉次数，设定条件为3次，触发操作为接通人工客服，则客户端设置与投诉次数对应的监听器，在监听到投诉次数的发生变化，且，获取到投诉次数的数据值为3次，满足设定条件的3次，此情况下可以触发接通人工客服的操作。

步骤s312：客户端发送删除请求至服务端，以供服务端删除所述监听器。

由于客户端监听目标数据节点已经达到设定条件，也即满足监听需求，所以后续无需再监听目标数据节点，客户端发送删除请求至服务端。删除请求可以包括所述删除请求包括客户端标识、目标数据节点标识和监听类型。

步骤s313：服务端删除与删除请求对应的监听器。

即便监听器在服务端中未达到监听结束条件，服务端在接收到客户端发送的删除请求后，也会删除与删除请求对应的监听器。

删除监听器具体可以包括：服务端在表1的监听信息表中删除目标数据节点标识对应的监听类型中的客户端标识，从而达到目标数据节点再发生相同监听类型的变化，则不会再通知该客户端。

通过上述技术特征可以得知本申请具有以下有益效果：

第一，本实施例在一次监听操作后监听器会保留下来，不会被删除，所以可以重复监听目标数据节点，避免删除和新建监听器之间遗漏目标数据节点变化的情况，从而解决删除监听器后与新建监听器之间遗漏目标数据节点的变化问题。

第二，本申请提供多种方式持续监听机制：在不具有监听结束条件情况下为持续重复监听方式；在具有监听结束条件且监听结束条件为指定次数情况下，为指定次数重复方式；在具有监听结束条件且监听结束条件为指定时间的情况下，为指定时间重复方式。可以依据实际情况来设定重复通知方式。

第三，客户端仅需向服务端发送一次注册请求即可，不必多次向服务端发送注册请求，所以可以减少客户端与服务端网络交互次数，从而节省网络资源和简化监听机制操作。

参见图4，本申请提供了一种数据节点监听装置，包括：

监听节点单元41，用于利用监听器监听目标数据节点；

发送通知单元42，用于若所述监听器监听到所述目标数据节点发生变化，则发送通知请求至注册所述监听器的客户端；

保留单元43，用于保留所述监听器继续监听所述目标数据节点。

其中，数据节点监听装置在监听节点单元41之前还包括：

接收单元44，用于接收所述客户端发送的注册请求；其中，所述注册请求包括目标数据节点标识和监听类型；

构建单元45，用于构建与所述注册请求对应的监听器；

存储单元46，用于存储所述监听器的监听信息；其中，所述监听信息包括所述客户端标识、所述目标数据节点标识和所述监听类型。

其中，发送通知单元42包括：

通知请求生成单元421，用于若所述监听器监听到所述目标数据节点发生所述监听类型指示的变化，则生成通知请求；

发送单元422，用于发送所述通知请求至客户端；其中，通知请求可以包括所述客户端标识、目标数据节点标识和监听类型。

其中，所述注册请求还包括监听结束条件，所述监听结束条件包括监听参数和监听阈值；

则在发送通知单元42之后，还包括：

更新单元47，用于更新所述监听参数；

在所述保留所述监听器继续监听所述目标数据节点之前，还包括：

判断单元48，用于更新后的监听参数是否达到所述监听阈值；

删除单元49，用于若更新后的监听参数达到所述监听阈值，则表示达到所述监听结束条件，删除所述监听器；

若更新后的监听参数未达到所述监听阈值，则表示未达到监听结束条件，进入保留单元43执行所述保留所述监听器继续监听所述目标数据节点的步骤。

其中，在所述监听参数包括监听次数的情况下，所述监听阈值包括预设次数；在所述监听参数包括监听时长的情况下，所述监听阈值包括预设时长。

其中，数据节点监听装置还包括：

接收单元410，用于接收到所述客户端发送的删除请求；其中，所述删除请求包括客户端标识、目标数据节点标识和监听类型；

查找单元411，用于查找与所述删除请求对应的监听器；

删除单元49，用于删除与所述删除请求对应的监听器。

关于数据节点监听装置的具体实现可以参见图2和图3所示的实施例，在此不再赘述。

参见图5，本申请又提供了一种数据节点监听装置，包括：

发送请求单元51，用于发送注册请求至服务端，以供所述服务端构建与所述注册请求对应的监听器，并利用该监听器来监听目标数据节点；

接收通知单元52，用于接收所述服务端发送的通知请求；

其中，所述通知请求为所述服务端的所述监听器监听到所述目标数据节点发生变化后发送至客户端的，并且，服务端会保留所述监听器继续监听所述目标数据节点。

其中，数据节点监听装置在接收通知单元52之后，还包括：

发送获取请求单元53，用于向所述服务端发送与所述通知请求对应的数据获取请求；

接收数据内容单元54，用于接收服务端发送的所述目标数据节点的数据内容；

执行单元55，用于若所述目标数据节点的数据内容达到设定条件，则执行与所述注册请求对应的触发操作；

发送删除请求单元56，用于发送删除请求至服务端，以供所述服务端删除所述监听器。

关于数据节点监听装置的具体实现可以参见图2和图3所示的实施例，在此不再赘述。

本申请还提供一种电子设备，包括：

处理器；以及

存储器，用于存储所述处理器的可执行指令；

其中，所述处理器配置为经由执行所述可执行指令来执行如图2和图3所示的数据节点监听方法。

本申请提供了一种存储介质，所述存储介质用于存储软件程序，该软件程序可用于实现如图2和图3所示的数据节点监听方法。

本实施例方法所述的功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算设备可读取存储介质中。基于这样的理解，本申请实施例对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得一台计算设备(可以是个人计算机，服务器，移动计算设备或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。