本申请涉及数据同步技术领域，特别涉及一种分布式集群数据同步方法、主节点、从节点、分布式集群数据同步系统以及计算机可读存储介质。
背景技术：
随着数据量和服务人员的急速增加，采用传统单一节点的方式已经无法满足当前的要求，由多个节点组成但对外表现为一个整体的分布式集群技术开始崭露头角。
分布式集群一般包含多个节点，这些节点组成一个集群统一的对外提供服务，通常还会在众多组成节点中选取一个节点作为管理节点(主节点)，通过在其上部署上层管理软件实现对其它组成节点(从节点)的管理。在用户通过集群管理软件对集群进行参数配置时，通常会将本次参数配置得到配置更新信息保存在主节点的本地数据库中，而基于冗余原则还需要实现主节点与从节点中数据的实时同步，这也是实现灾备、主备切换的重要前提条件。
现有主从节点数据同步机制通常是在主节点的本地数据库更新时，将每次进行的具体更新操作以某种形式保存下来，以便根据保存下来的文件确定进行了何种更新操作，而实现主从同步则是由各从节点向主节点发起更新查询请求，即主节点去对比从节点数据库与自身的差异，当确实存在差异时将对应的更新操作发给从节点，以使从节点根据接收到的更新操作完成同步。
此种方式由于每个从节点都会向主节点发起查询请求，主节点会在自身完成差异判断的操作并发送相应更新操作给从节点才算完成该查询请求，当从节点数量众多时，会显著加重主节点的负载；同时，由于从节点并不确定主节点是否进行了更新，因此即使频繁发送查询请求还是会存在一定的延迟，实际使用效果不好。
因此，如何克服现有分布式集群数据同步机制存在的缺陷，提供一种主节点负载更小、延迟更小的数据同步机制是本领域技术人员亟待解决的问题。
技术实现要素：
本申请的目的是提供一种分布式集群数据同步方法，将从节点向主节点发送查询请求，并由主节点完成更新差异的判断的传统方式变更为每当主节点执行了更新操作就通过相应的端口即时的向所有从节点推送本次更新对应的更新操作，以使各从节点在判断接收到的更新操作是自身未同步过的后利用其完成与主节点的数据同步，由于采用即时主动推送方式，基本消除了传统方式下存在的更新查询延迟，同时将更新差异判断交由每个从节点自己去判断，主节点只需在后续根据从节点所要的信息发送增量更新即可，将原有全部由主节点承担的负载平摊至各从节点，更加合理，使用效果更佳。
本申请的另一目的在于提供了一种主节点、从节点、包括主节点和从节点的分布式集群数据同步系统以及计算机可读存储介质。
为实现上述目的，本申请提供一种应用于主节点的分布式集群数据同步方法，包括：
根据接收到的更新指令执行数据更新操作，并对应生成包含具体更新操作步骤的更新消息；
将所述更新消息排列保存于主节点数据库对应的主更新消息表；
当所述主更新消息表中新增所述更新消息时，将所述更新信息分发至各从节点，以使各所述从节点根据自身数据库对应的更新消息表中是否包含接收到的更新信息相应的选择是否向利用所述更新信息完成数据同步。
可选的，在将所述更新信息分发至各从节点之前，还包括：
将所述更新信息按通用信息传输协议进行封装，得到通用更新信息。
可选的，将所述更新信息按通用信息传输协议进行封装，包括：
将所述更新信息按套接字协议的标准格式进行封装。
为实现上述目的，本申请还提供了一种主节点，该主节点包括：
更新消息生成单元，用于根据接收到的更新指令执行数据更新操作，并对应生成包含具体更新操作步骤的更新消息；
更新消息排列保存单元，用于将所述更新消息排列保存于主节点数据库对应的主更新消息表；
新增更新消息推送单元，用于当所述主更新消息表中新增所述更新消息时，将所述更新信息分发至各从节点，以使各所述从节点根据自身数据库对应的更新消息表中是否包含接收到的更新信息相应的选择是否向利用所述更新信息完成数据同步。
可选的，该主节点还包括：
通用传输协议封装单元，用于将所述更新信息按通用信息传输协议进行封装，得到通用更新信息。
可选的，该通用传输协议封装单元包括：
套接字协议封装单元，用于将所述更新信息按套接字协议的标准格式进行封装。
为实现上述目的，本申请还提供了一种应用于从节点的分布式集群数据同步方法，包括：
接收主节点发来的更新消息；
判断自身数据库对应的更新消息表中是否包含与接收到的更新消息相同的更新消息；
若包含与接收到的更新消息相同的更新消息，则将本次接收到的更新消息做无效处理；
若不包含与接收到的更新消息相同的更新消息，则根据接收到的更新消息中包含的具体更新操作步骤执行数据同步操作。
可选的，该应用于从节点的分布式集群数据同步方法还包括：
当从节点自身数据库对应的更新消息表中不包含与接收到的更新消息相同的更新消息时，根据接收到的更新消息确定与主节点的差异数据，并根据所述差异数据向所述主节点发送增量更新请求。
可选的，该应用于从节点的分布式集群数据同步方法还包括：
当所述从节点为新上线的空白节点时，向所述主节点发送全量数据同步请求。
可选的，该应用于从节点的分布式集群数据同步方法还包括：
当所述从节点为异常掉线节点时，向所述主节点发送自身数据库对应的更新消息表中最新的更新消息，以使所述主节点根据接收到的最新的更新消息与所述主更新消息表中包含的更新信息进行比对，并根据得到的比对结果向所述异常掉线节点返回相应数量的更新消息。
为实现上述目的，本申请还提供了一种从节点，该从节点包括：
更新消息接收单元，用于接收主节点发来的更新消息；
更新消息相同判断单元，用于判断自身数据库对应的更新消息表中是否包含与接收到的更新消息相同的更新消息；
无效处理单元，用于当包含与接收到的更新消息相同的更新消息时，将本次接收到的更新消息做无效处理；
同步操作执行单元，用于当不包含与接收到的更新消息相同的更新消息时，根据接收到的更新消息中包含的具体更新操作步骤执行数据同步操作。
可选的，该从节点还包括：
差异数据确定及增量更新请求单元，用于当从节点自身数据库对应的更新消息表中不包含与接收到的更新消息相同的更新消息时，根据接收到的更新消息确定与主节点的差异数据，并根据所述差异数据向所述主节点发送增量更新请求。
可选的，该从节点还包括：
空白节点全量同步单元，用于当所述从节点为新上线的空白节点时，向所述主节点发送全量数据同步请求。
可选的，该从节点还包括：
异常掉线节点同步单元，用于当所述从节点为异常掉线节点时，向所述主节点发送自身数据库对应的更新消息表中最新的更新消息，以使所述主节点根据接收到的最新的更新消息与所述主更新消息表中包含的更新信息进行比对，并根据得到的比对结果向所述异常掉线节点返回相应数量的更新消息。
为实现上述目的，本申请还提供了一种分布式集群数据同步系统，包括：
主节点，用于根据接收到的更新指令执行数据更新操作，并对应生成包含具体更新操作步骤的更新消息；将所述更新消息排列保存于主节点数据库对应的主更新消息表；当所述主更新消息表中新增所述更新消息时，将所述更新信息分发至各从节点；
所述从节点，用于接收主节点发来的更新消息；判断自身数据库对应的更新消息表中是否包含与接收到的更新消息相同的更新消息；若包含与接收到的更新消息相同的更新消息，则将本次接收到的更新消息做无效处理；若不包含与接收到的更新消息相同的更新消息，则根据接收到的更新消息中包含的具体更新操作步骤执行数据同步操作。
为实现上述目的，本申请还提供了一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如上述内容所描述的分布式集群数据同步方法的步骤。
显然，本申请所提供的一种分布式集群数据同步方法，将从节点向主节点发送查询请求，并由主节点完成更新差异的判断的传统方式变更为每当主节点执行了更新操作就通过相应的端口即时的向所有从节点推送本次更新对应的更新操作，以使各从节点在判断接收到的更新操作是自身未同步过的后利用其完成与主节点的数据同步，由于采用即时主动推送方式，基本消除了传统方式下存在的更新查询延迟，同时将更新差异判断交由每个从节点自己去判断，主节点只需在后续根据从节点所要的信息发送增量更新即可，将原有全部由主节点承担的负载平摊至各从节点，更加合理，使用效果更佳。本申请同时还提供了主节点、从节点、包括主节点和从节点的分布式集群数据同步系统以及计算机可读存储介质，均具有上述有益效果，在此不再赘述。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
图1为本申请实施例提供的一种应用于主节点的分布式集群数据同步方法的流程图；
图2为本申请实施例提供的一种应用于从节点的分布式集群数据同步方法的流程图；
图3为本申请实施例提供的另一种应用于从节点的分布式集群数据同步方法的流程图；
图4为本申请实施例提供的一种分布式集群数据同步方法的流程图；
图5为本申请实施例提供的一种主节点的结构框图；
图6为本申请实施例提供的一种从节点的结构框图；
图7为本申请实施例提供的一种包括主节点和从节点的分布式集群数据同步系统的结构示意图。
具体实施方式
本申请的核心是提供一种分布式集群数据同步方法、主节点、从节点、包括主节点和从节点的分布式集群数据同步系统以及计算机可读存储介质，将从节点向主节点发送查询请求，并由主节点完成更新差异的判断的传统方式变更为每当主节点执行了更新操作就通过相应的端口即时的向所有从节点推送本次更新对应的更新操作，以使各从节点在判断接收到的更新操作是自身未同步过的后利用其完成与主节点的数据同步，由于采用即时主动推送方式，基本消除了传统方式下存在的更新查询延迟，同时将更新差异判断交由每个从节点自己去判断，主节点只需在后续根据从节点所要的信息发送增量更新即可，将原有全部由主节点承担的负载平摊至各从节点，更加合理，使用效果更佳。
为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。
实施例一
以下结合图1，图1为本申请实施例提供的一种应用于主节点的分布式集群数据同步方法的流程图，以主节点为执行主体，其具体包括以下步骤：
S101：根据接收到的更新指令执行数据更新操作，并对应生成包含具体更新操作步骤的更新消息；
每当主节点执行了一次数据更新操作(数据文件的修改、删除、新增)就根据组成本次数据更新操作的具体操作步骤生成对应的更新消息。
更新消息更像是一个记录每次数据更新操作中所有操作步骤的日志文件，会将所有操作步骤事无巨细的记录以来，以便能够根据该更新消息确定对应数据更新操作具体做了哪些事情、修改了哪些参数、删去了哪些文件以及新增了哪些文件等等，也能够根据包含这些内容的更新消息在未进行同样数据更新操作的节点上按照同样的操作步骤完成同样的数据更新操作。
当主节点数据库采用以Mysql为例的关系型数据库时，由结构化查询语言(Structured Query Language，SQL)组成的更新消息可以被写入该关系型数据库的binlog(用于记录更新操作的文件)文件中。
当然，未进行同样数据更新操作的节点也可以根据更新消息确定出自身与进行过该数据更新操作的节点的差异，以请求增量更新的方式快速完成数据同步。增量更新是指只将存在差异的文件进行更新的快速同步或升级方式，即不对不同版本中存在的相同数据文件进行更新，因此可有效减少更新文件的体积，加快更新、同步的速度。
S102：将更新消息排列保存于主节点数据库对应的主更新消息表；
在S101的基础上，本步骤旨在将每次数据更新操作对应生成的更新消息排列保存于主节点数据库上的主更新消息表。
通常情况下，该主更新消息表中的各更新消息应按生成的时间先后顺序排列于该主更新消息表中，即最新生成的更新消息应位于该主更新消息表中的最顶层，之后生成的更新消息则置于之前生成的更新消息的上面。此种排列方式旨在增加差异判断速度和效率，因为主节点和从节点通常保持数据同步，当某个从节点短暂掉线后重新上线时，拿掉线节点数据库中更新消息表中最新的更新消息与未掉线节点数据库中更新消息表中自上而下的各更新消息进行对比，以此能够快速确定在掉线过程中缺少了几次数据同步，因为在此种情况下相同的更新消息应占大多数，从最旧的更新消息从头开始比较会显著浪费时间和计算资源，降低数据同步效率。
当然，当实际应用场景下存在所有可能的特殊要求时，也可以改变更新消息表保存各更新消息的排列方式，例如在某个对各节点数据一致性要求非常高的集群中，就可以采用从最初的更新消息开始相同与否的比较，以防止某个节点在持久化存储过程中出现异常出现底层数据存储错误的现象；也可以每隔一定时间将更新消息表中的部分老旧的更新消息从该更新消息表中分离出去，前提是集群中所有节点中对分离出去的部分更细消息对应的数据更新操作均已确定完成了数据同步，具体的，可以将分离出去的按照每个分离时间点生成包含一定数量老旧更新消息的旧更新消息表，之后仅利用包含较新更新信息的更新消息表完成与其它节点是否完成数据同步的差异性判断等方式，此处并不做具体限定，可以根据实际情况灵活选择。
S103：当主更新消息表中新增更新消息时，将更新信息分发至各从节点，以使各从节点根据自身数据库对应的更新消息表中是否包含接收到的更新信息相应的选择是否向利用更新信息完成数据同步。
在S102的基础上，本步骤旨在利用即时性的主动推送方式将主节点数据库对应的主更新消息表中新增的更新消息分发给各从节点，以使各从节点根据自身数据库对应的更新消息表中是否包含接收到的更新信息相应的选择是否向利用更新信息完成数据同步。
本申请采用的是区别于现有技术各从节点向同一主节点发送更新查询请求的主动推送方式，无需各从节点频繁向主节点发送查询请求，每当主节点数据库对应的主更新消息表中新增更新消息，即将本次新增的更新消息推送给各从节点，将判断接收到的更新消息是否是自身缺少的更新信息的步骤交由各从节点去完成，可有效降低主节点的负载，提升数据同步效率。
进一步的，在实际应用过程中往往存在一些具有特殊要求的集群，其中一种为主节点与从节点采用了不同的数据库类型，而通常不同数据库类型的在传输更新消息时的方式是不通用，即存在从节点无法接受到主节点发来的更新消息的可能性。本申请针对此种可能存在的情况，还提出了一种解决方法，即在主节点采用不受限于不同数据库类型的通用传输方式对更新消息进行封装，以使不同类型的数据库均可以接收到封装后的更新消息。
一种包括但不限于的更新消息封装方式为：采用套接字协议完成更新信息的封装操作，套接字(socket)协议是网络通信过程中端点的抽象表示，包含进行网络通信必需的五种信息：连接使用的协议，本地主机的IP地址，本地进程的协议端口，远地主机的IP地址，远地进程的协议端口。
基于上述技术方案，本申请实施例提供的一种分布式集群数据同步方法，将从节点向主节点发送查询请求，并由主节点完成更新差异的判断的传统方式变更为每当主节点执行了更新操作就通过相应的端口即时的向所有从节点推送本次更新对应的更新操作，以使各从节点在判断接收到的更新操作是自身未同步过的后利用其完成与主节点的数据同步，由于采用即时主动推送方式，基本消除了传统方式下存在的更新查询延迟，同时将更新差异判断交由每个从节点自己去判断，主节点只需在后续根据从节点所要的信息发送增量更新即可，将原有全部由主节点承担的负载平摊至各从节点，更加合理，使用效果更佳。
实施例二
以下结合图2，图2为本申请实施例提供的一种应用于从节点的分布式集群数据同步方法的流程图，以从节点为执行主体，具体包括以下步骤：
S201：接收主节点发来的更新消息；
S202：判断自身数据库对应的更新消息表中是否包含与接收到的更新消息相同的更新消息；
S203：判断自身存在相同更新消息的从节点将本次接收到的更新消息做无效处理；
本步骤建立在S202的判断结果为从节点自身数据库对应的更新消息表中包含与接收到的更新消息相同的更新消息的基础上，说明本次接收到的更新消息对应的更新数据该从节点已经完成了数据同步，可能是主节点出现了异常导致重复发送，该从节点将本次接收到的更新消息做无效处理，即无需做出任何动作。
S204：判断自身不存在相同更新消息的从节点根据接收到的更新消息中包含的具体更新操作步骤执行数据同步操作。
本步骤建立在S202的判断结果为从节点自身数据库对应的更新消息表中不包含与接收到的更新消息相同的更新消息的基础上，说明该从节点未执行过对本次新接收到的更新消息对应的更新数据进行同步，本实施例采用从节点根据接收到的更新消息中包含的具体更新操作步骤执行数据同步操作，即按照具体更新操作步骤重复执行一次，以期实现与主节点的数据同步。
进一步的，从节点在执行上述判断及同步操作过程中，可能存在不可避免的两种状态，一种是在S102中描述过的从节点因短暂掉线后又在之后重新上线的情况，此种情况下可以拿该异常掉线节点自身数据库对应的更新消息表中最新的更新消息与未掉线节点数据库中更新消息表中自上而下的各更新消息进行对比，以此能够快速确定在掉线过程中缺少了几次数据同步，因为在此种情况下相同的更新消息应占大多数，从最旧的更新消息从头开始比较会显著浪费时间和计算资源，降低数据同步效率。
在此种情况下，本实施例还提供一种包括但不限于的实现方案为：当从节点为异常掉线节点时，向主节点发送自身数据库对应的更新消息表中最新的更新消息，以使主节点根据接收到的最新的更新消息与主更新消息表中包含的更新信息进行比对，并根据得到的比对结果向异常掉线节点返回相应数量的更新消息。
进一步的，除因短暂掉线后重新上线的情况外，还存在集群新上线一个空白从节点的情况，在此种情况再按照短暂掉线后重新上线的方式进行差异判断的话，无疑是在无用功，针对此种情况可采用该空白节点直接向主节点或其它正常节点发送全量数据更新请求的方法，直接将自己“复制”为与其它正常节点一样的节点即可。
相应的，本实施例也提供一种包括但不限于的实现方案为：当所述从节点为新上线的空白节点时，向所述主节点发送全量数据同步请求。
实施例三
以下结合图3，图3为本申请实施例提供的另一种应用于从节点的分布式集群数据同步方法的流程图，具体包括以下步骤：
S301：接收主节点发来的更新消息；
S302：判断自身数据库对应的更新消息表中是否包含与接收到的更新消息相同的更新消息；
S303：判断自身存在相同更新消息的从节点将本次接收到的更新消息做无效处理；
S304：判断自身不存在相同更新消息的从节点根据接收到的更新消息确定与主节点的差异数据，并根据差异数据向主节点发送增量更新请求。
本实施例S304提供了一种区别于实施例二S204的实现与主节点数据同步的方法：即从节点根据接收到的更新消息确定与主节点的差异数据，并根据差异数据向主节点发送增量更新请求，可在不影响主节点负载的情况下快速实现数据同步，只需要将增量更新文件添加进自身数据库即可，在添加过程中，同名的文件会保留拥有最新修改时间的那个。
实施例四
以下结合图4，图4为本申请实施例提供的一种分布式集群数据同步方法的流程图，本实施例以体现所有执行主体(主节点和从节点)的方式来完整的阐述具体实现过程：
S401：主节点根据接收到的更新指令执行数据更新操作，并对应生成包含具体更新操作步骤的更新消息；
S402：主节点将生成的更新消息排列保存于主节点数据库对应的主更新消息表；
S403：当主更新消息表中新增更新消息时，主节点将新增的更新信息按通用信息传输协议进行封装，得到通用更新信息，并分发至各从节点；
本实施例在S403提供了一种按通用信息传输协议封装新增的更新消息的方式，以使发送节点与接收节点采用了不同类型的数据库依然能够正常接收到的新增的更新消息。
一种包括但不限于的更新消息封装方式为：将更新信息按套接字协议的标准格式进行封装。
S404：各从节点接收主节点发来的通用更新消息；
S405：各从节点判断自身数据库对应的更新消息表中是否包含与接收到的更新消息相同的更新消息；
S406：判断自身存在相同更新消息的从节点将本次接收到的更新消息做无效处理；
S407：判断自身不存在相同更新消息的从节点根据接收到的更新消息中包含的具体更新操作步骤执行数据同步操作。
当然，S407也可以使用如S304的方式实现与主节点的数据同步，重复内容在此不再赘述。
本实施例基于上述各实施例，不仅具备上述各实施例的有益效果，还通过在发送更新消息给各从节点之前利用通用信息传输协议对其进行封装，消除了特殊应用场景下可能存在的数据库类型不一致出现无法接收到发送的更新消息的可能性，可适应更多复杂的集群，实际使用效果更佳。
因为情况复杂，无法一一列举进行阐述，本领域技术人员应能意识到根据本申请提供的基本方法原理结合实际情况可以存在很多的例子，在不付出足够的创造性劳动下，应均在本申请的保护范围内。
下面请参见图5，图5为本申请实施例提供的一种主节点的结构框图，该主节点100可以包括：
更新消息生成单元110，用于根据接收到的更新指令执行数据更新操作，并对应生成包含具体更新操作步骤的更新消息；
更新消息排列保存单元120，用于将更新消息排列保存于主节点数据库对应的主更新消息表；
新增更新消息推送单元130，用于当主更新消息表中新增更新消息时，将更新信息分发至各从节点，以使各从节点根据自身数据库对应的更新消息表中是否包含接收到的更新信息相应的选择是否向利用更新信息完成数据同步。
进一步的，该主节点还可以包括：
通用传输协议封装单元，用于将更新信息按通用信息传输协议进行封装，得到通用更新信息。
其中，该通用传输协议封装单元还可以包括：
套接字协议封装单元，用于将更新信息按套接字协议的标准格式进行封装。
本申请在此给出一种主节点数据库实际情况下的具体更新流程：
(1)更新主节点本地的数据库；
(2)利用数据库的事物机制，同时生成一条记录步骤(1)中具体更新操作内容(例如SQL语句)的更新消息，并保存至主节点数据库的更新消息表中；
(3)主节点运行一个消息发送模块，该模块监听数据库更新消息表的变化，当更新消息表有新增的更新消息时，将该条新增的更新消息，通过socket协议封装后发送至各个从节点。
下面请参见图6，图6为本申请实施例提供的一种从节点的结构框图，该从节点200可以包括：
更新消息接收单元210，用于接收主节点发来的更新消息；
更新消息相同判断单元220，用于判断自身数据库对应的更新消息表中是否包含与接收到的更新消息相同的更新消息；
无效处理单元230，用于当包含与接收到的更新消息相同的更新消息时，将本次接收到的更新消息做无效处理；
同步操作执行单元240，用于当不包含与接收到的更新消息相同的更新消息时，根据接收到的更新消息中包含的具体更新操作步骤执行数据同步操作。
进一步的，该从节点还可以包括：
差异数据确定及增量更新请求单元，用于当从节点自身数据库对应的更新消息表中不包含与接收到的更新消息相同的更新消息时，根据接收到的更新消息确定与主节点的差异数据，并根据差异数据向主节点发送增量更新请求；
空白节点全量同步单元，用于当从节点为新上线的空白节点时，向主节点发送全量数据同步请求；
异常掉线节点同步单元，用于当从节点为异常掉线节点时，向主节点发送自身数据库对应的更新消息表中最新的更新消息，以使主节点根据接收到的最新的更新消息与主更新消息表中包含的更新信息进行比对，并根据得到的比对结果向异常掉线节点返回相应数量的更新消息。
本实施例在此给出一种从节点数据库实际情况下具体更新流程：
(1)从节点运行一个消息接收模块，该模块通过socket协议监听相应信息收发端口，以接收主节点通过socket协议发送来的更新消息；
(2)接收模块收到消息后，和本地数据库中的已处理消息列表比较，若已存在此条消息，则放弃此次接收到的消息；若不存在，则根据消息中携带的具体操作内容(例如SQL语句)，完成本地数据库的更新；
(3)步骤2中更新完成后，将此条消息保存至已处理消息列表，以便和之后接收的消息进行比对。
此外，在同步数据时，从节点有两种情况需要考虑：
(1)作为全新节点加入集群，则在新节点启动时，向主节点请求全量同步，同步完成后即可按照上述的流程进行处理；
(2)从节点从宕机、网络异常等情况恢复后，向主节点请求差异同步，先向主节点发送已处理消息列表中的距离当前时间最近的记录，主节点根据该记录，即可向相应从节点返回还未完成同步的记录。
下面请参见图7，图7为本申请实施例提供的一种包括主节点和从节点的分布式集群数据同步系统的结构示意图，该分布式集群数据同步系统包括：
主节点，用于根据接收到的更新指令执行数据更新操作，并对应生成包含具体更新操作步骤的更新消息；将更新消息排列保存于主节点数据库对应的主更新消息表；当主更新消息表中新增更新消息时，将更新信息分发至各从节点；
从节点，用于接收主节点发来的更新消息；判断自身数据库对应的更新消息表中是否包含与接收到的更新消息相同的更新消息；若包含与接收到的更新消息相同的更新消息，则将本次接收到的更新消息做无效处理；若不包含与接收到的更新消息相同的更新消息，则根据接收到的更新消息中包含的具体更新操作步骤执行数据同步操作。
基于上述实施例，本申请还同时提供了一种主节点和从节点，该主节点和从节点均可以包括存储器和处理器，其中，该存储器中存有计算机程序，该处理器调用该存储器中的计算机程序时，可以实现上述实施例中为实现分布式集群数据同步所提供的步骤。当然，该主节点和从节点还可以包括各种必要的网络接口、电源以及其它零部件等。
本申请还提供了一种计算机可读存储介质，其上存有计算机程序，该计算机程序被执行终端或处理器执行时可以实现上述实施例中为实现分布式集群数据同步所提供的步骤。该存储介质可以包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。
专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想。对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以对本申请进行若干改进和修饰，这些改进和修饰也落入本申请权利要求的保护范围内。
还需要说明的是，在本说明书中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其它变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其它要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、物品或者设备中还存在另外的相同要素。