CN117424910A - 一种增量数据的自动同步方法、系统、设备和介质 - Google Patents

Abstract

本方案涉及一种增量数据的自动同步方法、系统、设备和介质，方法包括以下步骤：确定需要数据同步的第一网络设备，对第一网络设备进行初步过滤，激活并监听初步过滤之后的第一网络设备，从初步过滤之后的第一网络设备中读取第一数据包，解析第一数据包，得到第一消息数据包；第一数据包的形式包括业务流量数据和预存数据，根据第一消息数据包形成消息元数据，根据消息元数据和目的端的通信协议生成第二消息数据包，将第二消息数据包发送给目的端，以使目的端根据第二消息数据包实现数据同步，目的端包括服务端和中间组件。本发明可以实现不同规模、不同配置的集群之间的增量数据同步，且增加了应用场景，应用于通信技术领域。

Description

一种增量数据的自动同步方法、系统、设备和介质

技术领域

本发明涉及通信技术领域，尤其涉及一种增量数据的自动同步方法、系统、设备和介质。

背景技术

业务系统、缓存、NoSQL存储服务、数据库等在高可靠性建设上都存在数据同步的需求，否则任何一个部分的单点都可能带来业务故障。虽然数据库、Redis等成熟软件都能实现主从同步，但都不支持不同集群或不同机房的集群之间的数据同步。由于待同步的数据都由上层业务系统产生，还会存在业务系统之间的数据同步或从业务系统向不同缓存或存储服务同时同步的需求。

但现有的同步方法需要深入到请求的各个属性，再分别封装、处理每一个请求，不能实现将增量数据同步到任意目的端，不支持不同规模、不同配置的集群之间的增量数据同步，且应用场景有限。

发明内容

有鉴于此，本发明的目的是提供一种增量数据的自动同步方法、系统、设备和介质，可以实现不同规模、不同配置的集群之间的增量数据同步，且增加了应用场景。

一方面，本发明提供了一种增量数据的自动同步方法，包括以下步骤：

确定需要数据同步的第一网络设备，对所述第一网络设备进行初步过滤，激活并监听初步过滤之后的第一网络设备；

从初步过滤之后的第一网络设备中读取第一数据包，解析所述第一数据包，得到第一消息数据包；所述第一数据包的形式包括业务流量数据和预存数据；

根据所述第一消息数据包形成消息元数据，根据所述消息元数据和目的端的通信协议生成第二消息数据包，将所述第二消息数据包发送给目的端，以使所述目的端根据所述第二消息数据包实现数据同步；所述目的端包括服务端和中间组件。

可选地，所述确定需要数据同步的第一网络设备，对所述第一网络设备进行初步过滤，具体包括：

根据拦截地址和端口要求确定需要数据同步的第一网络设备；

根据链路参数、数据读取参数和所述第一网络设备的网络连接参数筛选所述第一网络设备的端口，完成初步过滤。

可选地，所述解析所述第一数据包，得到第一消息数据包，具体包括：

根据所述第一数据包的格式和内容识别所述第一数据包的通信协议；

根据所述第一数据包的网络连接参数和所述第一数据包的通信协议解析所述第一数据包，得到第一数据包属性参数；

根据所述第一数据包属性参数将所述第一数据包进行组装，得到所述第一消息数据包。

可选地，所述第一数据包属性参数包括源端口、目的端口、源端通信协议、目的端通信协议、序列号、响应号，其中，所述根据所述第一数据包属性参数将所述第一数据包进行组装，得到所述第一消息数据包，具体包括：

根据源端口、目的端口、源端通信协议、目的端通信协议、响应号的顺序进行按位或运算，得到所述第一数据包的身份识别号；

将具有相同身份识别号的第一数据包根据所述序列号的排序进行组装，得到第二数据包；

根据第一数据包的序列号确认是否存在新的第一数据包，若不存在新的第一数据包，所述第二数据包作为所述第一消息数据包。

可选地，所述方法还包括：

若存在新的第一数据包，将新的第一数据包组装到所述第二数据包中，得到新的第二数据包，直到不存在新的第一数据包，以最终得到的第二数据包作为所述第一消息数据包。

可选地，所述根据所述第一消息数据包形成消息元数据，具体包括：

检查所述第一消息数据包是否完整，若所述第一消息数据包完整，确定所述第一消息数据包的类型；所述第一消息数据包的类型包括请求和响应；

根据所述第一消息数据包的类型得到第一消息数据包的身份识别号；

根据所述第一消息数据包的身份识别号和所述第一消息数据包的属性参数形成消息元数据。

可选地，所述根据所述第一消息数据包的类型得到第一消息数据包的身份识别号，具体包括：

若所述第一消息数据包是请求，对源端口、目的端口、源段通信协议进行按位或运算，得到第一序列值，在所述第一序列值上添加所述第一消息数据包的响应号，得到所述第一消息数据包的身份识别号；

若所述第一消息数据包是响应，对目的端口、源端口、目的端通信协议进行按位或运算，得到第二序列值，在第二序列值上添加所述第一消息数据包的序列号，所述第一消息数据包的身份识别号。

可选地，所述根据所述消息元数据和目的端的通信协议生成第二消息数据包，具体包括：

将消息元数据按照目的端的通信协议生成待转发消息；

调整所述待转发消息的内容，并根据目的端的通信协议封装调整后的待转发消息，得到所述第二消息数据包。

可选地，所述方法还包括：

按照预设过滤规则对所述第一消息数据包进行筛选；

记录未通过筛选的第一消息数据包和未通过筛选的原因；

根据预设时间将所述未通过筛选的第一消息数据包和所述未通过筛选的原因，上报给服务端。

可选地，所述方法还包括：

将所有所述第二消息数据包进行存储，并按照预设路由规则将所有所述第二消息数据包分组；

调用与目的端的通信协议对应的目的端组件将所述第二消息数据包按照所述路由规则发送给所述目的端；

接收目的端的响应，根据所述目的端的响应确认第二消息数据包是否成功发送给所述目的端，若所述第二消息数据包未成功发送给所述目的端，重复执行调用与目的端的通信协议对应的目的端组件将所述第二消息数据包按照路由规则发送给所述目的端这一步骤，直到满足结束规则。

另一方面，本发明提供了一种增量数据的自动同步系统，所述系统包括源端、客户端和目的端，其中，

所述源端，用于产生第一数据包；

所述客户端，用于实现前面所述的一种增量数据的自动同步方法，并同步源端的增量数据；

所述目的端，用于根据第二消息数据包同步增量数据。

另一方面，本发明提供了一种电子设备，所述电子设备包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现前面所述的一种增量数据的自动同步方法。

另一方面，本发明提供了一种计算机可读存储介质，其中存储有处理器可执行的程序，所述处理器可执行的程序在由处理器执行时用于执行前面所述的一种增量数据的自动同步方法。

实施本发明包括以下有益效果：本发明通过确定需要数据同步的第一网络设备，对所述第一网络设备进行初步过滤，激活并监听初步过滤之后的第一网络设备，从初步过滤之后的第一网络设备中读取第一数据包，解析所述第一数据包，得到第一消息数据包，所述第一数据包的形式包括业务流量数据和预存数据，可以通过业务流量数据的形式读取业务系统、中间件或存储服务任一层的增量数据，更加灵活方便；通过根据所述第一消息数据包形成消息元数据，根据所述消息元数据和目的端的通信协议生成第二消息数据包，将所述第二消息数据包发送给目的端，以使所述目的端根据所述第二消息数据包实现数据同步，所述目的端包括服务端和中间组件，可以将增量数据同步到通信协议不同的服务端和中间件，按照路由规则将增量数据发送给目的端，可以实现增量数据在不同规模、不同配置的集群之间同步，增加应用场景。

附图说明

图1是本发明提供的一种增量数据的自动同步方法流程图；

图2是本发明提供的一种从网络设备读取数据、解析数据以及存储的流程图；

图3是本发明提供的一种增量数据无线处理链的结构示意图；

图4是本发明提供的一种形成第一消息数据包的流程图；

图5是本发明提供的一种根据第一消息数据包形成消息元数据的流程图；

图6是本发明提供的一种客户端调用源端组件和目的端组件的系统结构图；

图7是本发明提供的一种生成第二消息数据包的流程图；

图8是本发明提供的一种完成增量数据同步并上报异常数据的流程图；

图9是本发明提供的一种增量数据的自动同步系统的结构示意图；

图10是本发明提供的一种电子设备的结构示意图。

具体实施方式

下面结合附图和具体实施例对本发明做进一步的详细说明。对于以下实施例中的步骤编号，其仅为了便于阐述说明而设置，对步骤之间的顺序不做任何限定，实施例中的各步骤的执行顺序均可根据本领域技术人员的理解来进行适应性调整。

为了更好的理解本发明的实施例，现对本发明实施例涉及的系统进行解释说明。

系统包括服务端和客户端，其中，客户端可以采用基于网络数据采集分析工具(TCPDump)采用C扩展开发实现一种增量数据的自动同步方法，客户端还可以直接与服务端建立通信，接收服务端的数据同步调度操作、向服务端上报数据同步结果、开放Prometheus形式的内部数据同步指标和上报数据同步过程发现的问题，其中，开放Prometheus形式的内部数据同步指标包括一定时间内收到的待同步的总数据量、成功同步的量、各类型失败的量、同步操作性能最大值、TP99和平均值。

服务端根据客户端同步过来的数据，将数据同步到浏览器等网页，并通过浏览器向用户提供客户端下载分发、数据同步对象管理、同步操作分发、数据同步过程监控、接收同步日志、结果和同步过程中发现的问题，服务端还能向用户提供同步配置、同步结果。

如图1所示，图1是一种增量数据的自动同步方法流程图，本发明提供一种增量数据的自动同步方法，包括以下步骤：

S100、确定需要数据同步的第一网络设备，对第一网络设备进行初步过滤，激活并监听初步过滤之后的第一网络设备。

其中，在一个系统中具有多个网络设备，对第一网络设备进行初步过滤包括筛选需要数据同步的第一网络设备和对筛选第一网络设备的端口。

具体地，根据运行机器的地址和端口确定出需要上传数据的第一网络设备，根第一网络设备的网络连接参数、数据传输参数和链路参数等对选中的第一网络设备进行过滤，得到需要上传数据的端口，激活并持续监听具有需要上传数据的端口的第一网络设备。

S200、从初步过滤之后的第一网络设备中读取第一数据包，解析第一数据包，得到第一消息数据包；第一数据包的形式包括业务流量数据和预存数据。

其中，第一数据包包括第一网络设备的实时业务流量数据、预存的流量文件，即预存数据。业务流量可以直接从网络层、协议层、应用层读取。可以满足各类应用系统、中间件、缓存和存储服务等不同场景下的数据同步需求。

具体地，如图2所示，图2是从网络设备读取数据、解析数据以及存储的流程图，并发地从多个第一网络设备中分别读取、处理每一个设备的数据包，直到出错或强制退出，一边读取一边利用包含多种通信协议的解析函数解析从第一网络设备读取到的第一数据包，另外，本方法还包括将解析后的第一网络数据包以及设备的网络连接类型、网络连接大小保存在一个内部缓存中。

在从内部缓存中读取解析后的第一网络数据包，将同一设备同一请求和响应的多个第一数据包组合，得到第一消息数据包。

第一网络数据包可以通过TCPDump、Wireshark等常见的网络流量截获工具获取，第一网络数据包呈现的数据是原始二进制数据流经过处理后方便人工分析阅读的形式，但这些数据具有只有具备一定基础的软件专业技术人员才可能读懂部分，从第一网络数据包并无法得到完整的数据起止位置和含义。

通过步骤S200可以对这些数据执行协议识别并按进一步解析流量数据的方式得到以协议形式封装并且独立于具体业务的数据，这样的结果可以按对应的协议统一地处理、转发，更为直观，方便人工分析，可以作为后续一系列处理的关键基础，达到使用流量数据实现更多业务功能。

另外，如图3所示，图3是增量数据无线处理链的结构示意图，图中N：1、1：N表示前一端与后一端的集群服务器比例，MQ表示消息中间件，HTTP表示以HTTP协议连接的源端，Stdout表示以Stdout连接的源端，Redis表示源端为Redis数据库，Dubbo表示源端为远程过程调用框架，Binary表示二进制文件，ES表示Elasticsearch，可以提供全文搜索或NoSQL服务，提供一种定制的独有HTTP协议，可以通过其协议对Elasticsearch中的数据执行增删改查操作。在这一步骤中支持通过TCP或消息队列把上面处理得到的第一消息数据包，即数据流，转发、汇总到客户端的另外的目的地处理，到达目的地后的流量还可以在处理后存储或继续转发给另一个目的地，不限制处理和转发的深度。通过以上步骤满足多种大小访问量环境下的流量读取、处理，提高处理效率、保障稳定性和可靠性，另外，基于Nginx等流量镜像工具先把业务的实际网络流量镜像到另外的服务器上供读取、处理，然后再转发到目的端，这种方式因为不会占用业务服务器的任何资源，不会对业务服务器太大影响。

S300、根据第一消息数据包形成消息元数据，根据消息元数据和目的端的通信协议生成第二消息数据包，将第二消息数据包发送给目的端，以使目的端根据第二消息数据包实现数据同步。目的端包括服务端和中间组件。

具体地，从步骤S200的内部缓存中不断读取第一消息数据包，并组装成新的消息数据包，生成消息数据包的消息元数据，将消息元数据转换为与目的端的通信协议对应的数据，再将该数据形成能够采用目的端通信协议传输的第二消息数据包。

通过本步骤，可以从协议层面通过支持对应通信协议的客户端把请求流量数据转发到与源端相同的软件，这些数据在同步场景下可以在目的端被正常处理，可以实现同步过程中协议之间的转换，例如把数据库中的数据同步到Redis，或者根据业务场景需求组合多种协议实现多端数据同步，例如把一个数据库的数据同步到多个不同的数据库、MQ、Redis等，不需要按常规技术必须深入到不同业务请求的各个属性并分别封装、处理后才能使相同协议的不同系统之间正常通信，从实现可靠、通用的数据同步。

一些实施例中，步骤S100确定需要数据同步的第一网络设备，对第一网络设备进行初步过滤，具体包括：

S110、根据拦截地址和端口要求确定需要数据同步的第一网络设备。

具体地，根据拦截地址和端口要求，从运行机器的所有网络设备中找出需要读取流量的设备，如果没有拦截地址，则读取所有网络设备指定端口的流量。

可可选择地，还可以通过指定要读取的网络涉密名确定第一网络设备。

S120、根据链路参数、数据读取参数和第一网络设备的网络连接参数筛选第一网络设备的端口，完成初步过滤。

其中，网络连接参数包括但不限于包括网络连接的类型和大小，数据读取参数包括但不限于包括读取超时值、最大允许读的快照长度。

确定第一网络设备对应的网络连接的类型和大小，设置读取超时值、最大允许读的快照长度，还可以设置链路过滤配置，从这个环节过滤掉不需要的数据。

在一些实施例中，步骤S200解析第一数据包，得到第一消息数据包，具体包括：

S210、根据第一数据包的格式和内容识别第一数据包的通信协议。

具体地，建立数据包解析器实例，包括开始函数、结束函数和解析函数，其中，通过函数指针设置支持解析多种通信协议的开始函数和结束函数。

开始函数用于校验数据，根据通过检验的第一数据包的格式、内容识别数据包的通信协议，并判断该数据包内的是请求还是响应。

结束函数进一步根据协议要求和数据包Seq号，即序列号，校验数据的完整性并设置数据的方向，以便可以确定一个完整消息的结束位置并正常解析协议数据。

S220、根据第一数据包的网络连接参数和第一数据包的通信协议解析第一数据包，得到第一数据包属性参数。

其中，第一数据包属性参数包括但不限于包括数据包的时间戳、源端IP和目的端IP、端口、序列号Seq、响应号Ack、FIN、SYN等和payload。

具体地，解析器根据网络连接的类型、大小，从以太网层、IP和TCP协议层分别解析得到数据包的时间戳、源端IP和目的端IP、端口、序列号Seq、响应号Ack、FIN、SYN等和payload，并设置数据包的请求、响应方向。

S230、根据第一数据包属性参数将第一数据包进行组装，得到第一消息数据包。

其中，一个第一消息数据包包括所有属于该消息的请求和响应。

具体地，根据第一数据包属性参数建立第一数据包的ID，将具有相同ID的第一数据包组合在一起，形成一个完整的消息，即第一消息数据包。

在一些实施例中，如图4所示，图4是形成第一消息数据包的流程图，步骤S230第一数据包属性参数包括源端口、目的端口、源端通信协议、目的端通信协议、序列号、响应号，其中，根据第一数据包属性参数将第一数据包进行组装，得到第一消息数据包，具体包括：

S231、根据源端口、目的端口、源端通信协议、目的端通信协议、响应号的顺序进行按位或运算，得到第一数据包的身份识别号。

具体地，按源端口、目的端口、源端IP、目的端IP、数据包的Ack号的顺序进行按位或运算构建消息ID，即身份识别号。

S232、将具有相同身份识别号的第一数据包根据序列号的排序进行组装，得到第二数据包。

具体地，逐渐添加具有相同ID的第一数据包，并将添加到同一消息中的第一数据包按照Seq号升序进行排序，得到第二数据包，同时计算第二数据包的长度、结束时间。

S233、根据第一数据包的序列号确认是否存在新的第一数据包，若不存在新的第一数据包，第二数据包作为第一消息数据包。

具体地，结束函数通过序列号Seq确认第一数据包传输是否结束，在发现结束时立即转发最后一次添加得到的第二数据包，到另一个顺序缓存，即第一消息数据包。

在一些实施例中，增量数据的自动同步方法还包括：

S234、若存在新的第一数据包，将新的第一数据包组装到第二数据包中，得到新的第二数据包，直到不存在新的第一数据包，以最终得到的第二数据包作为第一消息数据包。

具体地，在结束函数确认第一数据包传输结束时，发现存在新的第一数据包，不断增加Ack号、合并新发现的第一数据包到第二数据包后再检查是否结束，直到不存在新的第一数据包，以最终得到的第二数据包作为第一消息数据包。

通过步骤S231-S234能够实现最大限度地适应网络数据包的随机传输机制，实现接近网络层的处理性能，还能准确获取一个请求的响应。另外，由于基于相同的网络模型和基础协议，还可以支持解析采用TCPDump或Wireshark输出的流量文件，结果都可以封装为供后续进一步处理的消息序列。

在一些实施例中，如图5所示，图5是根据第一消息数据包形成消息元数据的流程图，S300根据第一消息数据包形成消息元数据，具体包括：

S310、检查第一消息数据包是否完整，若第一消息数据包完整，确定第一消息数据包的类型；第一消息数据包的类型包括请求和响应。

具体地，如图6所示，图6是客户端调用源端组件和目的端组件的系统结构图，客户端的转发组件调用源端组件从存储第一消息数据包的顺序缓存中，不断读取第一消息数据包，把读取到第一消息数据包全部按元数据、第一消息数据包、源端IP和目的端IP的规范组装，然后检查数据内容，如果发现第一消息数据包包括的请求或响应不完整或格式不符则提示，还可以选择将不符合的第一消息数据包过滤并记录，异步上报到服务端。

S320、根据第一消息数据包的类型得到第一消息数据包的身份识别号。

具体地，确认第一消息数据包中的数据包是请求还是响应，根据第一消息数据包的参数分别形成请求的ID和响应的ID。

S330、根据第一消息数据包的身份识别号和第一消息数据包的属性参数形成消息元数据。

其中，第一消息数据包的属性参数包括消息的发生时间、相比上个消息的延迟时长、是请求还是响应。

具体地，将第一消息数据包的属性参数和ID形成一定序列值，并生成满足TCP协议层传输要求的消息元数据。

在一些实施例中，步骤S320根据第一消息数据包的类型得到第一消息数据包的身份识别号，具体包括：

S321、若第一消息数据包是请求，对源端口、目的端口、源段通信协议进行按位或运算，得到第一序列值，在第一序列值上添加第一消息数据包的响应号，得到第一消息数据包的身份识别号。

具体地，如果是请求消息，则依次对源端口、目的端口、源端IP进行按位或运算后再附加上数据包的Ack号，得到第一消息数据包的身份识别号。

S322、若第一消息数据包是响应，对目的端口、源端口、目的端通信协议进行按位或运算，得到第二序列值，在第二序列值上添加第一消息数据包的序列号，第一消息数据包的身份识别号。

具体地，如果是响应，则依次对目的端口、源端口和目的端IP进行按位或运算后再附加上数据包的Seq号，得到第一消息数据包的身份识别号。

在这一步骤，可以按相同的ID组装请求及其响应，通过这样的机制可以高效地基于内存从随机传输的第一消息数据包直接构建完整的请求及其响应数据集。

在一些实施例中，步骤S330之前，增量数据的自动同步方法还包括：

S323、按照预设过滤规则对第一消息数据包进行筛选。

其中，预设规则可以是但不限于是第一消息数据包的请求响应是否成功、用户自定义的规则、忽略响应而只以请求形成消息元数据。其中，第一消息数据包的请求响应是否成功中成功则通过筛选，执行步骤S330，未成功，则执行步骤S323。

S324、记录未通过筛选的第一消息数据包和未通过筛选的原因。

具体地，未通过筛选的请求、响应和未通过筛选地原因，即失败的请求、响应和失败原因。

S325、根据预设时间将未通过筛选的第一消息数据包和未通过筛选的原因，上报给服务端。

具体地，用户可以自定义上传时间，即预设时间，在预设时间将第一消息数据包和未通过筛选的原因，上报给服务端。

在一些实施例中，如图7所示，图7是生成第二消息数据包的流程图，S300中根据消息元数据和目的端的通信协议生成第二消息数据包，具体包括：

S340、将消息元数据按照目的端的通信协议生成待转发消息。

具体地，将TCP协议层的消息元数据按照目的端的通信协议生成供目的端可读的待转发消息。例如，目的端的通信协议为HTTP协议，则将消息元数据转换为常见的请求头和消息体依次组装并按行分割的形式，目的端的协议为Redis等二进制协议，把消息元数据的可见内容转换为可直观阅读的内容，在显示或保存供人工分析时可选择去除不必要的换行，再设置消息的源端IP、目的端IP。

S350、调整待转发消息的内容，并根据目的端的通信协议封装调整后的待转发消息，得到第二消息数据包。

具体地，为了适应目的端的数据传输要求，调整步骤S340中的待转发消息的内容，比如增加、修改或删除部分消息头信息，根据消息内容过滤部分消息并记录，将调整内容之后的待转发消息按照目的端的通信协议得到第二消息数据包。

通过步骤S321-S324和步骤S340-S350，可以实现根据应用层通信协议增加支持的源端、目的端协议类型的服务，例如根据增量数据同步场景的需要，支持从流量文件、第三方存储读取消息流后再向HTTP、Redis、ES、数据库或RPC服务转发流量，这样源端和目的端都可以支持很多种类型和形式的服务，还可以支持更多协议或输出扩展，例如支持通过云端的存储服务暂存流量。

通过步骤S340和S350，可以实现在同步过程中进行数据拆分、保持，减少业务集群数据同步相关的开发、部署或配置上的调整。

在一些实施例中，如图8所示，图8是一种完成增量数据同步并上报异常数据的流程图，增量数据的自动同步方法还包括：

S400、将所有第二消息数据包进行存储，并按照预设路由规则将所有第二消息数据包分组。

具体地，对于源端、目的端集群在规模和服务器配置等方面可能有差异，在集群各服务器实例分别处理部分数据子集的情况下的数据同步，可以根据目的端的需求和规模建立不同路由规则。

其中，预设路由规则包括但不限于以下几种规则：

1.按顺序把消息转发到不同的目的端，例如有2个目的端时，第一个总是收到奇数序号的消息，第二个总收到偶数序号的消息。

2.对不同的目的端实例按要求的不同比例分配待转发消息的请求量，比例配置和目的端数量不做限制。例如对3个目的端实例依次按30％、50％、20％的比例分配待转发消息。

3.可以选择把相同ID的消息都转发到一个相同的目的端服务实例，以便在把业务切换到备份集群后，用户仍然访问正常，即当用户的访问涉及数据同步前后的不同集群时，整个过程对集群切换无感知。

4.可以解析消息后根据其部分字段的值按一定规则路由消息到目的端部分实例。

若目的端服务器的处理能力比源端集群强大时，把多个源端的消息都转发到一个目的端组件，若源端集群比目的端服务器的处理能力强大时，可以按上述逻辑将多个源端的拆分消息。

S500、调用与目的端的通信协议对应的目的端组件将第二消息数据包按照预设路由规则发送给目的端。

具体地，如图6所示，其中，转发组件，作用类似交换机，作为各种数据同步场景下的流量数据从源端到目的端的处理、转换引擎，通过反射机制初始化各类源端和目的端组件后供转发组件调度；命名以From开头的是源端组件，负责实时读取数据源网络设备的通信数据流、识别组件对应的协议和按协议解析消息、缓存消息，即实现上述步骤S100-S200，以及步骤S100-S200下面的所有子步骤；以To开头的是目的端组件，负责按目的端在通信协议上的要求构建对应的客户端连接对象，例如HTTP、socket连接，也可以是MongoDB等成熟中间件的专有客户端的封装，然后接收外部传入的数据并使用连接提交到目的端，即步骤S300以及步骤S300下面的子步骤。

在转发第二消息数据包时，客户端调用与目的端的通信协议对应的目的端组件将第二消息数据包，先放入顺序缓存，然后再并发地读缓存、处理第二消息数据包并准备按照步骤S400的路由规则发送给目的端。

S600、接收目的端的响应，根据目的端的响应确认第二消息数据包是否成功发送给目的端，若第二消息数据包未成功发送给目的端，返回执行调用与目的端的通信协议对应的目的端组件将第二消息数据包按照预设路由规则发送给目的端这一步骤，直到满足结束规则。

其中，满足结束规则包括但不限于包括满足重发次数、重发成功。

具体地，根据目的端的作用和通信协议要求，转发组件调用目的端组件执行第二消息数据包的转发和响应的处理，可以通过以下步骤a-c选择记录下列所有输出操作的类型、内容、发生时间及响应到第三方存储服务：

a.同步数据时，根据目的端协议(例如Redis、HTTP、Dubbo等)的特点和要求采用协议对应的组件或机制把处理后的数据发送到目的端，再处理响应，包括利用协议识别函数判断协议响应是否完整、正常，确认第二消息数据包是否成功发送给目的端，如果失败则随机延迟并重试一定次数，直到满足预设次数。若最后仍失败，则汇总记录失败的次数、失败的时间、失败的原因等。还可以缓存响应待后续分析、记录每个响应、同步总量、成功量等统计结果，供随时排查。

b.当数据同步需分布式运行时，如果需要发送到TCP端，则按常规socket操作在建立连接后同步发送，然后执行步骤a；如果需发送到MQ，则采用MQ的客户端或按类似机制发送。

C.在分布式同步时，如果接收端是TCP服务，接下来可以Socket服务端接收、汇聚数据后再发送到下一层的TCP服务、MQ、同步数据的目的端(HTTP服务、Dubbo服务、Redis或ES等中间件)，这种情况下接下来执行上述步骤a；如果接收端是MQ，接下来则消费MQ中的数据，支持在线实时消费，离线消费之前预存的数据，这时候会自动记录消费位置，下次从下一个位置开始消费、处理，接下来可以把消息发送到数据同步的目的端，执行上述步骤a，也可以继续发送到下一个MQ或者TCP服务，还可以在这样的环节根据需要把部分数据转发到数据同步的目的端。按这样的方式根据实际同步需求，把消息的转发、处理环节不断延伸下去，实现不限深度的数据处理、同步链。

在一些实施例中，还可以选择把数据写到标准输出或文件供分析。

在一些实施例中，目的端组件定时或在合适时机记录转发日志，更新反映转发结果质量的监控指标，在存在MQ时记录消费位置，还可以通过转发时刻-转发前消息元数据中的发生时间得到同步延迟，也可以根据需要把这些数据上报到服务端。

通过以上方法，本发明跳出了常见的各类应用开发技术栈，包括中间件的客户端或驱动，可以从网络层入手，通过实时自动读取、复制网络流量并识别出业务系统各部分的网络协议得到所有请求及其数据，支持按照统一接口调用新的通信协议解析网络数据流，进一步实现各协议数据的转发服务，数据增量可以在不同通信协议的各种应用场景下成功同步到目的端。

本发明还可以建立支持分布式运行、不限长度的复制流量处理链，可以通过文件、TCP、中间件并发地传输、处理复制的流量，形成稳定、高效的复制流量传输、处理服务。

可以在增量数据转发之前识别通信协议、记录异常、过滤异常数据并提醒用户，可以把复制的数据按不同通信协议转发到业务集群不同层次，在同步过程中支持数据拆分、保持，减少业务集群数据同步相关的开发、部署或配置上的调整。

在一些实施例中，如图9所示，图9是一种增量数据的自动同步系统的结构示意图，本发明提供一种增量数据的自动同步系统，系统包括源端、客户端和目的端，其中，

源端，用于产生第一数据包；

客户端，用于实现上述增量数据的自动同步方法，并同步源端的增量数据；

目的端，用于根据第二消息数据包同步增量数据。

其中，源端包括但不限于包括TCP协议层、中间件、数据库、存储服务器，目的端包括但不限于包括TCP协议层、中间件、数据库、存储服务器，客户端包括但不限于包括转发组件、多个与源端对应的源端组件和多个与目的端对应的目的端组件。

具体地，源端在日常运行中，根据业务要求，会产生数据包，客户端的转发组件调用源端组件获取数据包，通过目的端组件数据包转发给目的端，实现数据源端和目的端的数据同步。

具体地方法与前述实施例相同。

另外，通过以下两个例子阐述本发明在增量数据同步场景的应用。

应用场景1，在两个相同软件之间同步增量数据。

以同步两个ES(ElasticSearch)集群之间的增量数据为例，由于ES以HTTP协议为基础提供增加、修改和删除数据的功能，并且支持批量添加操作，所以可以基于HTTP协议读取应用系统对ES的修改操作的业务流量，即第一数据包，在识别HTTP协议、获得请求数据并处理后，再把数据按HTTP协议的要求组装请求头、请求体，然后再结合ES的特点、要求构建HTTP协议的请求客户端，即ES目的端组件，并通过该目的端组件把处理后的请求数据提交到写入目的地，从而可以实现高效、一致的ES之间的数据同步，还可以自然规避Java、Python、Go甚至Bash等开发的系统在具体技术细节上的差异，即对不同语言、平台的业务系统都能实现高效、100％准确的ES增量数据同步。

具体而言，当需要实时同步时，可以先调用图6的FromFlow组件拦截到对ES操作的流量并判断、解析为HTTP协议数据，然后根据HTTP方法过滤查询操作的流量，接下来根据ES对HTTP协议的支持检查剩余数据的方法，如果是PUT，说明应用系统正在以表象化状态转变(Representational State Transfer，RESTful)方式把记录ID写入到统一资源定位符(Uniform Resource Locator，URL)，这时可以先检测应用总共操作哪些索引。接下来对每个索引分别创建一个ToES组件的实例，每个实例对应一个不同的写入URL和相应的HTTP协议客户端连接。具体先把剩余流量的HTTP方法修改为POST，再根据目的端地址、索引和_doc组装生成目的URL并提交。这时还可以合并多个PUT请求，然后改用POST方法批量提交到ES，实现更高效的数据同步效率。如果是POST方法，则检查请求地址是否包含/_bulk，如果不包含说明不是批量操作，这时可以直接同步，否则可以先检查消息数据是否完整、是否符合HTTP协议的要求，检查通过则按设置的URL提交，否则说明读取到的协议数据不完整。先检查原请求的响应的状态码来判断原始请求是否成功，如果成功则保存发现的问题、读取到协议数据并提示用户检查流量读取相关的设置，协助用户调整例如最大允许快照长度来正确解析协议数据；如果原始请求出错，则记录该请求及其响应到日志，同时提示用户，也可以根据需要选择继续转发并记录响应。该机制有助于在同步过程中发现原始数据的问题，助力在协议识别、解析上及时发现、改善不同情况和大小的请求带来的问题。

如需离线同步，可以先调用FromFlow组件读取业务操作ES的流量并解析为HTTP协议数据，然后调用ToFile按一定格式把HTTP协议形式的业务数据保存到文件，后续可以调用FromFile反向读取协议数据到内存，按需处理后再按上述机制写入到另一个ES，还可以调用ToTCP把来自预存文件及实时解析的HTTP(其它协议类似)流量通过socket发送到另外的同步客户端实例，或调用ToMQ把读取的HTTP流量数据写入到MQ，这种情况下可以启动另外的同步客户端调用FromTCP作为TCP服务器、调用FromMQ作为MQ消费者，汇聚消息后再处理，再根据目的端的协议要求创建对应的客户端连接对象，然后通过该连接把处理后的数据转发给目的端ES或发送到下一个处理环节；也可以把文件中的流量分别拆分后发送到几个不同的ES实例，具体步骤可参考步骤S350、S400-S600按照上述。

应用场景2，在异构软件之间同步增量数据。

例如当需要在多个数据库之间同步增量数据，部分业务操作有一定顺序性要求和特殊逻辑，要求严格的操作顺序，同时还希望把数据的一部分同步到外部缓存服务Redis，把另一部分数据同步到Cassandra或其它数据库。这时常见的做法包括由应用系统自行开发数据同步功能，同时对Redis等的同步则作为另外的项目，当另外的业务有类似需求时，不仅需要重复工作，业务数据在不同部分的同步结果还可能存在不一致。

这种情况可以类似上面采用实时、离线的方式同步数据，不同之处在于，基于一种增量数据的自动同步方法可以选择根据业务使用的通信协议直接同步访问业务的流量，常见的是HTTP或远程过程调用协议(Remote Procedure Call Protocol，RPC)操作，按业务对应的协议解析读取的流量后，可以得到协议形式的业务数据。接下来按需过滤得到真正需要同步操作，对于有业务特殊性的数据的同步，可以直接从业务层把协议形式的待同步的“请求”转发到另外的业务实例，相同的业务实例自然能正确处理已被其它相同实例验证可正确处理的请求，这样不但肯定可以轻松完成同步，还能保障两端结果的一致性，也可以通过读取、解析流量得到的请求对应的响应，判断请求能否成功，并且记录失败的请求及其响应，让用户了解到这些关键信息并及时应用必要措施。

对于存储中间件的数据同步，以Redis、Cassandra为例，除了上述从业务流量入手的方案外，还可以在读取原始二进制流量数据、识别协议、按协议解析业务数据后，通过过滤规则从业务系统的流量中分别得到需要同步的数据，然后再分别调用ToRedis或ToCassandra写入到目的端；还可以直接读取对Redis和Cassandra的写操作流量，把Redis写操作的流量转换为Redis协议形式的操作请求再调用ToRedis转发到目的端，再把对Cassandra的操作转换为对应的包含数据的CQL语句，然后发给目的端执行，这种情况下也可以合并多端的数据然后批量提交到目的端以实现高效同步。

在一些实施例中，如图10所示，图10是本发明提供的一种电子设备的结构示意图，本发明还提供了一种电子设备，电子设备包括处理器10和存储器20，存储器20存储有计算机程序，处理器10执行计算机程序时实现上述方法实施例的任何一种方法。

其中，存储器作为一种非暂态计算机可读存储介质，可用于存储非暂态软件程序以及非暂态性计算机可执行程序。存储器可以包括高速随机存取存储器，还可以包括非暂态存储器，例如至少一个磁盘存储器件、闪存器件、或其他非暂态固态存储器件。在一些实施方式中，存储器可选包括相对于处理器远程设置的远程存储器，这些远程存储器可以通过网络连接至处理器。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

此外，本申请实施例还公开了一种计算机程序产品或计算机程序，计算机程序产品或计算机程序存储在计算机可读存介质中。计算机设备的处理器可以从计算机可读存储介质读取该计算机程序，处理器执行该计算机程序，使得该计算机设备执行上述的方法。

本发明还提供了一种计算机可读存储介质，其中存储有处理器可执行的程序，处理器可执行的程序在由处理器执行时用于执行上述方法实施例的任何一种方法。

同样地，上述方法实施例中的内容均适用于本存储介质实施例中，本存储介质实施例所具体实现的功能与上述方法实施例相同，并且达到的有益效果与上述方法实施例所达到的有益效果也相同。

可以理解的是，上文中所公开方法中的全部或某些步骤、系统可以被实施为软件、固件、硬件及其适当的组合。某些物理组件或所有物理组件可以被实施为由处理器，如中央处理器、数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、数字多功能盘(DVD)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。

以上是对本发明的较佳实施进行了具体说明，但本发明创造并不限于实施例，熟悉本领域的技术人员在不违背本发明精神的前提下还可做作出种种的等同变形或替换，这些等同的变形或替换均包含在本申请权利要求所限定的范围内。

Claims (13)

1.一种增量数据的自动同步方法，其特征在于，包括以下步骤：

确定需要数据同步的第一网络设备，对所述第一网络设备进行初步过滤，激活并监听初步过滤之后的第一网络设备；

从初步过滤之后的第一网络设备中读取第一数据包，解析所述第一数据包，得到第一消息数据包；所述第一数据包的形式包括业务流量数据和预存数据；

根据所述第一消息数据包形成消息元数据，根据所述消息元数据和目的端的通信协议生成第二消息数据包，将所述第二消息数据包发送给目的端，以使所述目的端根据所述第二消息数据包实现数据同步；所述目的端包括服务端和中间组件。

2.根据权利要求1所述的方法，其特征在于，所述确定需要数据同步的第一网络设备，对所述第一网络设备进行初步过滤，具体包括：

根据拦截地址和端口要求确定需要数据同步的第一网络设备；

根据链路参数、数据读取参数和所述第一网络设备的网络连接参数筛选所述第一网络设备的端口，完成初步过滤。

3.根据权利要求1所述的方法，其特征在于，所述解析所述第一数据包，得到第一消息数据包，具体包括：

根据所述第一数据包的格式和内容识别所述第一数据包的通信协议；

根据所述第一数据包的网络连接参数和所述第一数据包的通信协议解析所述第一数据包，得到第一数据包属性参数；

根据所述第一数据包属性参数将所述第一数据包进行组装，得到所述第一消息数据包。

4.根据权利要求3所述的方法，其特征在于，所述第一数据包属性参数包括源端口、目的端口、源端通信协议、目的端通信协议、序列号、响应号，其中，所述根据所述第一数据包属性参数将所述第一数据包进行组装，得到所述第一消息数据包，具体包括：

根据源端口、目的端口、源端通信协议、目的端通信协议、响应号的顺序进行按位或运算，得到所述第一数据包的身份识别号；

将具有相同身份识别号的第一数据包根据所述序列号的排序进行组装，得到第二数据包；

根据第一数据包的序列号确认是否存在新的第一数据包，若不存在新的第一数据包，所述第二数据包作为所述第一消息数据包。

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

若存在新的第一数据包，将新的第一数据包组装到所述第二数据包中，得到新的第二数据包，直到不存在新的第一数据包，以最终得到的第二数据包作为所述第一消息数据包。

6.根据权利要求1所述的方法，其特征在于，所述根据所述第一消息数据包形成消息元数据，具体包括：

检查所述第一消息数据包是否完整，若所述第一消息数据包完整，确定所述第一消息数据包的类型；所述第一消息数据包的类型包括请求和响应；

根据所述第一消息数据包的类型得到第一消息数据包的身份识别号；

根据所述第一消息数据包的身份识别号和所述第一消息数据包的属性参数形成消息元数据。

7.根据权利要求6所述的方法，其特征在于，所述根据所述第一消息数据包的类型得到第一消息数据包的身份识别号，具体包括：

若所述第一消息数据包是请求，对源端口、目的端口、源段通信协议进行按位或运算，得到第一序列值，在所述第一序列值上添加所述第一消息数据包的响应号，得到所述第一消息数据包的身份识别号；

若所述第一消息数据包是响应，对目的端口、源端口、目的端通信协议进行按位或运算，得到第二序列值，在第二序列值上添加所述第一消息数据包的序列号，所述第一消息数据包的身份识别号。

8.根据权利要求1所述的方法，其特征在于，所述根据所述消息元数据和目的端的通信协议生成第二消息数据包，具体包括：

将消息元数据按照目的端的通信协议生成待转发消息；

调整所述待转发消息的内容，并根据目的端的通信协议封装调整后的待转发消息，得到所述第二消息数据包。

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

按照预设过滤规则对所述第一消息数据包进行筛选；

记录未通过筛选的第一消息数据包和未通过筛选的原因；

根据预设时间将所述未通过筛选的第一消息数据包和所述未通过筛选的原因，上报给服务端。

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

将所有所述第二消息数据包进行存储，并按照预设路由规则将所有所述第二消息数据包分组；

调用与目的端的通信协议对应的目的端组件将所述第二消息数据包按照所述预设路由规则发送给所述目的端；

接收目的端的响应，根据所述目的端的响应确认第二消息数据包是否成功发送给所述目的端，若所述第二消息数据包未成功发送给所述目的端，返回执行调用与目的端的通信协议对应的目的端组件将所述第二消息数据包按照所述预设路由规则发送给所述目的端这一步骤，直到满足结束规则。

11.一种增量数据的自动同步系统，其特征在于，所述系统包括源端、客户端和目的端，其中，

所述源端，用于产生第一数据包；

所述客户端，用于实现权利要求1-10任一项所述的方法，并同步源端的增量数据；

所述目的端，用于根据第二消息数据包同步增量数据。

12.一种电子设备，其特征在于，所述电子设备包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现权利要求1-10任一项所述的方法。

13.一种计算机可读存储介质，其特征在于，其中存储有处理器可执行的程序，所述处理器可执行的程序在由处理器执行时用于执行如权利要求1-10任一项所述的方法。