一种数据同步方法及设备与流程

本申请涉及通信技术领域，特别涉及一种数据同步方法。本申请同时还涉及一种服务器。

背景技术：

随着分布式系统的发展、网络业务的不断扩充以及快速增长的网络用户数量，一个分布式的业务系统往往需要几十台、上百台或者上千台设备来支撑现有的大规模业务。当某一个客户端连上某台设备之后，出于用户主观需求或是客观的因素，客户端有可能修改这台设备的状态或是该设备所运行的程序中的某项属性配置，由于当前的业务系统为分布式系统，因此集群中其他节点需要获知所发生的变化以及变化前后的配置。在分布式业务系统中发生连续变化时，要保证集群节点间随时能够获知发生了变化，以及与最新的配置同步。

目前的技术一般采取以下三种方式进行集群之间的同步，其各自的特性以及缺点如下：

(1)基于广播的同步

现有的基于广播的复制过程如图1所示，当某个服务器接到客户端请求时，该服务器修改本节点状态，随后本节点基于广播直接将变化内容同步给兄弟节点，从而使兄弟节点保持内容一致。

然而，基于广播的同步技术是基于UDP广播，所以要求所有集群节点位于同一网段，并且必须是IP广播(UDP)可到达的。另外，基于广播的同步技术是一个节点要向所有的节点同步数据，当同步数据量比较大时，对网络带 宽以及性能影响较大，且随着集群节点数的增多，集群的节点数越多，需要同步的机器越多，从而线性伸缩的能力受到很大制约。

(2)基于数据库备份的集中存放

现有的基于数据库集中存放配置如图2所示，在客户端连接到某个节点发起变更请求之后，该节点直接把变更写入数据库，其他节点在有请求需要获取这个最新的配置项时则直接从数据库中获取。该方案中各节点之间不直接同步数据，而是通过数据库持久化配置集中存储，从而做到各个节点共享配置。

由于基于数据库备份的集中存放实质是集群共享的数据直接存入数据库，当集群中的节点需要不断获取这个配置时，则会对数据库带来不小的压力，从而对稳定性带来影响。

(3)对等同步方式

如图3所示，在现有的对等方式中，每台服务器将任意选择一台服务器备份其内存中的会话信息，这样每台服务器都有一台自己的对等服务器，而不是其他所有的服务器，这种方式消除在集群中加入过多服务器实例的话影响伸缩性的问题。相应地，基于对等同步方式给负载均衡器带来了更多的复杂性。当一台服务失效后，负载均衡器必须知道那台服务是这台己失效服务器的对等备份服务器。这将缩小了负载均衡器的选择范围，同时有些硬件也不能满足这种要求。并且除了处理正常的请求外，服务器还将负责复制的任务。由于备份会话数据的任务也需要占用CPU的周期，所以每台服务器的请求处理能力也降低了

由此可见，如何在分布式业务系统中的节点配置变化频繁的情况下，保证集群节点能够实时同步更新最新的配置数据，成为本领域技术人员亟待解决的技术问题。

技术实现要素：

本申请提供了一种数据更新方法。用以在提高通知效率以及节省设备资源的前提下，使集群中的节点的配置以及属性数据能够及时得到更新。该方法应用于包括多个集群节点以及数据库的集群中，所述集群节点包括接收到待同步数据的数据写入节点和数据拉取节点，包括以下步骤：

当集群节点接收到数据获取消息时，所述集群节点生成与所述数据获取消息对应的数据获取任务；其中，所述数据获取消息为所述数据写入节点在将所述待同步数据处理完毕并写入所述数据库之后向自身以及所述数据拉取节点发送的；

所述集群节点根据所述数据获取任务从所述数据库中获取所述待同步数据。

优选地，在所述集群节点接收到数据获取消息之前，还包括：

若所述集群节点为所述数据写入节点，所述数据写入节点接收所述客户端发送的所述待同步数据，并根据所述待同步数据的类型对所述待同步数据进行处理；

所述数据写入节点生成与所述待同步数据对应的标识，并将所述标识以及所述待同步数据对应写入所述数据库；

所述数据写入节点设置并触发数据同步事件；

当所述数据写入节点监听到所述数据同步事件时，所述数据写入节点向所述集群中的所有集群节点发送携带所述标识的数据获取消息。

优选地，在所述数据写入节点向自身以及所述数据拉取节点发送携带所述标识的数据获取消息之后，还包括：

所述数据写入节点判断所述数据拉取节点是否成功接收所述数据获取消息；

若所述数据拉取节点未成功接收所述数据获取消息，所述数据写入节点 在预设的时间阈值之后向所述数据拉取节点重新发送所述数据获取消息。

优选地，所述节点根据所述数据获取任务从所述数据库中获取所述待同步数据，具体为：

所述集群节点将所述数据获取任务加入自身的任务队列中；

所述集群节点监听所述任务队列当前是否存在数据获取任务；

若存在，所述集群节点根据所述数据获取任务对应的标识从所述数据库中获取所述待同步数据，所述标识携带于所述数据获取消息中，所述标识在所述待同步数据被写入所述数据库之前对应生成。

优选地，所述集群节点将所述数据获取任务加入自身的任务队列中，具体为：

所述集群节点判断所述任务队列中是否存在配置与所述数据获取任务一致的重复数据获取任务；

若存在，所述集群节点将所述重复数据获取任务替换为所述数据获取任务；

若不存在，所述集群节点将所述数据获取任务添加至所述任务队列中。

优选地，在所述集群节点根据所述数据获取任务从所述数据库中获取所述待同步数据之后，还包括：

若所述集群节点发生重启，所述集群节点将当前本地的所有内存数据以及缓存数据删除；

所述集群节点从所述数据库获取与自身对应的内存数据以及缓存数据，并根据所获取的数据进行初始化。

优选地，还包括：

若所述集群节点根据所述数据获取任务对应的标识从所述数据库中获取所述待同步数据失败，所述集群节点将该所述数据获取任务更新时间戳后重 新加入所述任务队列。

相应地，本申请还提出了一种服务器，该服务器作为集群节点应用于包括多个集群节点以及数据库的集群中，所述集群节点包括接收到待同步数据的数据写入节点和数据拉取节点，该服务器包括：

生成模块，当接收到数据获取消息时，生成与所述数据获取消息对应的数据获取任务；其中，所述数据获取消息为所述数据写入节点在将所述待同步数据处理完毕并写入所述数据库之后向所述集群中的所有集群节点发送的；

获取模块，根据所述数据获取任务从所述数据库中获取所述待同步数据。

优选地，还包括：

处理模块，接收客户端发送的所述待同步数据，并根据所述待同步数据的类型对所述待同步数据进行处理；

写入模块，生成与所述待同步数据对应的标识，并将所述标识以及所述待同步数据对应写入所述数据库；

设置模块，设置并触发数据同步事件；

发送模块，当监听到所述数据同步事件时，向所述集群中的所有服务器发送携带所述标识的数据获取消息。

优选地，还包括：

判断模块，判断所述数据拉取节点是否成功接收所述数据获取消息，并在所述数据拉取节点未成功接收所述数据获取消息时指示所述发送模块在预设的时间阈值之后向所述数据拉取节点重新发送所述数据获取消息。

优选地，所述获取模块具体包括：

添加子模块，将所述数据获取任务加入自身的任务队列中；

监听子模块，监听所述任务队列当前是否存在数据获取任务；

获取子模块，在所述监听子模块监听所述任务队列当前存在数据获取任务时根据所述数据获取任务对应的标识从所述数据库中获取所述待同步数据，所述标识携带于所述数据获取消息中，所述标识在所述待同步数据被写入所述数据库之前对应生成。

优选地，所述添加子模块具体用于：

判断是否存在配置与所述数据获取任务一致的重复数据获取任务；

若存在，将所述重复数据获取任务替换为所述数据获取任务；

若不存在，将所述数据获取任务添加至所述任务队列中。

优选地，还包括：

删除模块，当所述服务器发生重启，将当前本地的所有内存数据以及缓存数据删除；

初始化模块，从所述数据库获取与自身对应的内存数据以及缓存数据，并根据所获取的数据进行初始化。

优选地，还包括：

重处理模块，当所述服务器根据所述数据获取任务对应的标识从所述数据库中获取所述待同步数据失败，将该所述数据获取任务更新时间戳后重新加入所述任务队列。

由此可见，通过应用本申请的技术方案，当集群节点接收到数据获取消息时，生成与所述数据获取消息对应的数据获取任务，随后根据数据获取任务从数据库中获取待同步数据，由于数据获取消息为接收到待同步数据的数据写入节点在将待同步数据处理完毕并写入数据库之后向集群中的所有集群节点发送，因此能够在保证集群中各集群节点的配置数据保持一致的基础上，提高了集群节点之间进行数据同步的效率以及节省了同步数据的资源。

附图说明

图1为现有的基于广播的复制过程示意图；

图2为现有的基于数据库集中存放配置示意图；

图3为现有的对等同步方式示意图；

图4为本申请提出的一种数据同步方法的流程示意图；

图5为本申请具体实施例中集群同步的流程示意图；

图6为本申请具体实施例中加载流程示意图；

图7为本申请具体实施例中轻量级的集群同步方式流程图；

图8为本申请提出的一种服务器模块组成示意图。

具体实施方式

有鉴于背景技术中的问题，本申请提出了一种数据同步方法，用以实现轻量级的集群同步方式，从而在兼顾性能的基础上有效地保证集群中的各个集群节点内容一致。

为便于区分不同角色以及职能的集群节点，针对某一次的写入事件，本申请将接收到待同步数据以及将该待同步数据写入数据库的节点称之为数据写入节点，此时集群中的其他集群节点相对于该数据写入节点而言则称为数据拉取节点。

如4所示，为本申请提出的一种数据同步方法的流程示意图，该方法应用于包括多个集群节点以及数据库的集群中，所述集群节点包括接收到待同步数据的数据写入节点和数据拉取节点，包括以下步骤：

S401，当集群节点接收到数据获取消息时，所述集群节点生成与所述数据获取消息对应的数据获取任务；其中，所述数据获取消息为所述数据写入节点在将所述待同步数据处理完毕并写入所述数据库之后向所述集群中的所有集群节点发送的。

如背景技术所述，由接收同步数据的集群节点或是由数据库同时向所有 其他集群节点写入待同步数据将增大集群节点以及数据库的负担，并且耗费的资源也将变得非常之多。为了解决该技术问题，本申请在当有客户端连接到某个集群节点发起变更请求时，指示该集群节点首先先将变更写入数据库，并同时触发一个配置变更的事件，而不是向各个集群节点广播数据同步。相应地，该集群中的所有集群节点(包括该节点和其他节点)监听到配置变更事件后，并非如现有技术一样直接进行数据同步，而是以轻量级的通知方式告诉其他集群节点去数据库获取变更的配置，。

在本申请优选的实施例中，若该集群节点为所述数据写入节点，那么该集群节点在接收到数据获取消息之前的通知流程如下：

步骤a)所述数据写入节点接收所述客户端发送的所述待同步数据，并根据所述待同步数据的类型对所述待同步数据进行处理；

步骤b)所述数据写入节点生成与所述待同步数据对应的标识，并将所述标识以及所述待同步数据对应写入所述数据库；

步骤c)所述数据写入节点设置并触发数据同步事件；

步骤d)当所述数据写入节点监听到所述数据同步事件时，所述数据写入节点向所述集群中的所有集群节点发送携带所述标识的数据获取消息。

通过采用以上事件触发的通知方式，大大减轻了同步的成本，且提高了集群的线性伸缩能力。而接收到的配置缓存在本节点内存或者磁盘，这样后续当客户端需要获得这个配置或者该节点需要获得这个配置，则直接从本地内存或者本地磁盘直接获取对应的数据，避免了直接访问数据库。

需要说明的是，该方式仅为本申请提供的一种优选实施方式，在实现节点能够将所接收到的客户端的待同步数据处理完毕并写入所述数据库之后向集群中的所有集群节点发送数据获取消息的基础上，本领域技术人员也可以采取其他的类似实现方法，这些都属于本申请的保护范围。

此外，对于已发送的数据获取消息，数据写入节点也将针对其是否送达 至其他集群节点进行判断。在本申请优选的实施例中，数据写入节点判断数据拉取节点是否成功接收数据获取消息，若数据拉取节点未成功接收数据获取消息，数据写入节点在预设的时间阈值之后向数据拉取节点重新发送数据获取消息。

S402，所述集群节点根据所述数据获取任务从所述数据库中获取所述待同步数据。

由于本申请通过轻量级信息来减少通信资源负担，因此与现有技术中携带数据所不同的是，本申请的数据获取消息中仅包含与待同步数据对应的标识，该标识由数据写入节点在将待同步数据写入数据库之前生成，后续其他集群节点直接通过该标识在数据库中查询对应的待同步数据并进行同步处理。

在本申请优选的实施例中，为了使各个集群节点能够有序地从数据库中获取待同步数据，集群节点首先将数据获取任务加入自身的任务队列中，然后监听任务队列当前是否存在数据获取任务，并在存在的情况下根据数据获取任务对应的标识从数据库中获取待同步数据，该标识携带于数据获取消息中且在待同步数据被写入数据库之前对应生成。

需要说明的是，以上方案中所涉及的待同步数据可以为与集群节点相关的配置数据，也可以为客户端需要保存在集群节点中的存储数据，也可以为由客户端上传至数据写入节点处理并需要保存处理结果的数据。此外，当客户端请求变更了某个集群节点对应的服务器的配置之后，若该配置需要同时应用在其他集群中的其他集群节点时，亦可以通过本申请的方案将客户端所改变的设置同步至其他的集群节点对应的服务器，具体地，本申请技术方案中“待同步数据”至少包括以下几种类型：

(1)待同步数据为用户通过客户端上传到数据写入节点的数据，该数据 在被写入数据库后需要其他集群节点同步至自身。该上传数据可以为在该数据写入节点中运行的系统相关的配置数据、用户在使用系统或是系统中的应用程序的过程中产生的相关配置数据、针对集群节点本身进行设置的配置数据以及普通的需要存储的资料数据(例如文档、图片、多媒体文件等)等，这样用户仅通过客户端向集群中的一个集群节点上传配置数据后，可以使集群中的其他集群节点快速采取与该集群节点相同的配置数据，这样用户后续在使用其他集群节点中的系统或是运行其中的应用程序时能够采用之前相同的使用配置。

(2)待同步数据为用户通过客户端对集群节点进行修改的数据，当修改结束之后，修改的结果(被处理完毕的待同步数据)被写入数据库后需要其他集群节点同步至自身。

(3)待同步数据为用户通过客户端向集群节点发送的请求(该请求可能不直接是修改数据的)中所携带的关键数据或根据该请求所生成的关键数据。举例来说，集群节点在处理完毕客户端的请求后，需要在程序的逻辑处理中保存该请求中的某个ID值(比如用户ID)，将其写入数据库并通知集群中的其他集群节点同步；或者是在处理完毕该请求后需要在程序的逻辑处理中根据该请求中的值(例如ID)生成另外一个关键数据(ID)，将生成的关键数据写入数据库并通知集群中的其他集群节点同步。

此外，如果一个配置项连续变更导致集群节点连续收到多个数据获取消息时(例如有大量变更发生)，本申请可通过数据库锁本身的能力保证数据库中存放的是最新的配置。同时，集群节点在根据数据获取消息生成数据获取任务后会判断任务队列中是否有相同配置的任务，并将新的任务替换旧的任务。从而保证避免重复获取过时的数据，在本申请优选地实施例中，集群节点在将所述数据获取任务加入自身的任务队列时，首先判断所述任务队列中是否存在配置与所述数据获取任务一致的重复数据获取任务；若存在则将所 述重复数据获取任务替换为所述数据获取任务；若不存在则将所述数据获取任务添加至所述任务队列中。此外，在当集群节点根据数据获取任务对应的标识从数据库中获取待同步数据失败时，集群节点也会将该数据获取任务更新时间戳后重新加入任务队列。

在日常的使用过程中，集群中的集群节点可能因为自身或是其他客观原因而导致发生重启，当有集群节点重启后，该集群节点需要从数据库中全量加载最新数据。在本申请的优选实施例中，若集群节点发生重启，该集群节点将当前本地的所有内存数据以及缓存数据删除，从所述数据库获取与自身对应的内存数据以及缓存数据，并根据所获取的数据进行初始化。

通过采用以上方案，集群中的某个集群节点将配置变更写入数据库后，设置用于指示其他集群节点从数据库获取变更配置的触发事件，集群节点在监听到该触发事件之后向其他集群节点发送数据获取消息，如果某个集群节点获取该数据获取消息失败，则写入数据的集群节点重新将数据获取消息投递至获取消息失败的集群节点，保证所有的集群节点都能接收到加载消息。从而在节省资源的前提下，保证了集群节点本地磁盘的最终一致性。在该方案中，写入配置的数据写入可通过直接通知或是发送消息至总线的方式通知其他集群节点进行同步，在前一种方式中，集群的各个集群节点之间通过Http的调用通知直接通知对方同步；而在后一种方式中，数据写入节点将配置变更写入数据库后发布一个消息到消息总线，其他所有集群节点订阅这样的消息，监听到有这样的消息后开始同步，这些都属于本申请的保护范围。

为了进一步阐述本申请的技术思想，现结合具体的应用场景，对本申请的技术方案进行说明。

如图5所示，为本申请具体实施例中集群同步的流程示意图，具体交互过程如下：

步骤1.1，客户端发起修改的请求；

步骤2.1，集群中的某个节点接到请求后，直接将变更写入数据库；

步骤2.2，该节点接到写入完成的请求后，转至步骤2.3；

步骤2.3，该节点发起一个配置项变更的事件；

步骤2.4，该节点监听到配置项变更，转至步骤3.1；

步骤3.1，通知本节点以及其他兄弟节点加载最新配置变更；

步骤3.2，兄弟节点以及本节点接到通知后，生成数据获取任务，并加入

任务对列节点监听任务队列，如有任务，则通过任务进行拉取配置

步骤3.3，拉取配置变更后，缓存到内存或者保存到本地磁盘。

在以上过程中，当客户端有连续的变更请求时，通过数据库本身的锁保证并发，从而保证最后的更新能持久化到数据库中，当从数据库中加载时，从而保证加载永远是最新的配置。

当某个Server重启时，需要把缓存在本地节点的配置需要从数据库中全量加载出来，从而保证本地磁盘缓存的最新，在如图6所示的流程图中，加载的流程如下：

步骤1.管理员重启Server

步骤2.Server在重启过程中，从磁盘上删除所有的磁盘上的配置缓存。

步骤3.Server从数据库全量加载所有的配置项，并保存到磁盘

步骤4.其他初始化。

步骤5.Server启动完成，对外提供服务

步骤6.客户端或者本节点需要配置信息时，直接从磁盘缓存获取。

如果在Server A启动过程中，其他节点发生了配置变更，但是Server A加载结束前，这个配置还没有入库，或者在另外一个节点通知ServerA时因为网络原因，导致通知失败，轻量级的集群同步方式可以通过其他节点不断的通 知尝试来保证这个更新同步到Server A，该流程如图7所示，包括以下步骤：

1.ServerB通知Server A节点从数据库同步配置

2.因为网络或其他原因，通知失败

3.Server B接到失败的结果后，间隔一定的时间，重新发起通知

4.ServerB通知ServerA节点从数据库同步配置

5.Server A接到通知请求后，生成加载任务并放入加载队列。

6.Server B接到通知成功反馈。

7.ServerA监听加载队列，发现有加载任务，开始从数据库加载对应的配置。

8.ServerA加载完配置，并更新完本地磁盘缓存。

为达到以上技术目的，本申请还提出了一种服务器，所述服务器作为节点应用于包括多个节点以及数据库的集群中，如图8所示，该服务器包括：

生成模块810，当接收到数据获取消息时，生成与所述数据获取消息对应的数据获取任务；其中，所述数据获取消息为所述数据写入节点在将所述待同步数据处理完毕并写入所述数据库之后向所述集群中的所有集群节点发送的；

获取模块820，根据所述数据获取任务从所述数据库中获取所述待同步数据。

在具体的应用场景中，还包括：

处理模块，接收客户端发送的所述待同步数据，并根据所述待同步数据的类型对所述待同步数据进行处理；

写入模块，生成与所述待同步数据对应的标识，并将所述标识以及所述待同步数据对应写入所述数据库；

设置模块，设置并触发数据同步事件；

发送模块，当监听到所述数据同步事件时，向所述集群中的所有服务器发送携带所述标识的数据获取消息。

在具体的应用场景中，还包括：

判断模块，判断所述数据拉取节点是否成功接收所述数据获取消息，并在所述数据拉取节点未成功接收所述数据获取消息时指示所述发送模块在预设的时间阈值之后向所述数据拉取节点重新发送所述数据获取消息。

在具体的应用场景中，所述获取模块具体包括：

添加子模块，将所述数据获取任务加入自身的任务队列中；

监听子模块，监听所述任务队列当前是否存在数据获取任务；

获取子模块，在所述监听子模块监听所述任务队列当前存在数据获取任务时根据所述数据获取任务对应的标识从所述数据库中获取所述待同步数据，所述标识携带于所述数据获取消息中，所述标识在所述待同步数据被写入所述数据库之前对应生成。

在具体的应用场景中，所述添加子模块具体用于：

判断是否存在配置与所述数据获取任务一致的重复数据获取任务；

若存在，将所述重复数据获取任务替换为所述数据获取任务；

若不存在，将所述数据获取任务添加至所述任务队列中。

在具体的应用场景中，还包括：

删除模块，当所述服务器发生重启，将当前本地的所有内存数据以及缓存数据删除；

初始化模块，从所述数据库获取与自身对应的内存数据以及缓存数据，并根据所获取的数据进行初始化。

在具体的应用场景中，还包括：

重处理模块，当所述服务器根据所述数据获取任务对应的标识从所述数据库中获取所述待同步数据失败，将该所述数据获取任务更新时间戳后重新 加入所述任务队列。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本申请可以通过硬件实现，也可以借助软件加必要的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施场景所述的方法。

本领域技术人员可以理解附图只是一个优选实施场景的示意图，附图中的模块或流程并不一定是实施本申请所必须的。

本领域技术人员可以理解实施场景中的装置中的模块可以按照实施场景描述进行分布于实施场景的装置中，也可以进行相应变化位于不同于本实施场景的一个或多个装置中。上述实施场景的模块可以合并为一个模块，也可以进一步拆分成多个子模块。

上述本申请序号仅仅为了描述，不代表实施场景的优劣。

以上公开的仅为本申请的几个具体实施场景，但是，本申请并非局限于此，任何本领域的技术人员能思之的变化都应落入本申请的保护范围。