具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述，所描述的实施例不应视为对本申请的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。

在以下的描述中，所涉及的术语“第一\第二\第三”仅仅是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

对本申请实施例进行进一步详细说明之前，对本申请实施例中涉及的名词和术语进行说明，本申请实施例中涉及的名词和术语适用于如下的解释。

1)远程字典服务(Remote Dictionary Server，Redis)，一个开源、内存存储的数据结构服务器，可用作数据库、高速缓存和消息队列代理。它支持字符串、哈希表、列表、集合、有序集合、位图、HyperLogLog等数据类型。

2)ElasticSearch(简称ES)，一个分布式、高扩展、高实时的搜索与数据分析引擎。它能很方便的使大量数据具有搜索、分析和探索的能力。

本申请实施例提供一种应用于数据同步系统数据同步方法。本申请实施例提供的方法可以通过计算机程序来实现，该计算机程序在执行的时候，完成本申请实施例提供的数据同步方法中各个步骤。在一些实施例中，该计算机程序可以数据同步设备中的处理器执行。图1为本申请实施例提供的数据同步方法的一种实现流程示意图，如图1所示，所述数据同步方法包括以下步骤：

步骤S101，基于预先配置的数据源，获取用于获取待同步数据所需的参数。

本申请实施例中，数据同步系统可以包括数据获取器、数据处理器、自定义参数Map、数据源和ES日志文件。针对不同的数据源，进行数据同步时所需的参数一般不同。这里的用于获取待同步数据所需的参数，可以由数据同步系统中的自定义参数Map来获取。该数据同步系统可以是计算机或移动终端等设备上的应用系统，该参数通常是由用户输入的，示例性地，数据同步系统为移动终端，用户在移动终端的数据同步系统上输入参数“值1”和“slave”，自定义参数Map获取的参数可以表示为：

其中，“搜索字段1”和“cacheSource”为属性，分别指搜索字段和搜索空间，“值1”和“slave”为属性值。

在一种实现方式中，搜索字段的属性值可以由用户通过键盘输入至各搜索字段属性对应的编辑框，这里的搜索字段可以有多个，如用户在属性“搜索字段1”的编辑框中输入“值1”，在属性“搜索字段2”的编辑框中输入“值2”。在一种实现方式中，搜索空间的属性值可以由用户基于预设的候选框进行选择输入，例如，预设的搜索空间包括主集群master、辅集群slave和辅集群slave1该三个候选属性值，这里的辅集群可以为多个。

这里预先配置的数据源可以为数据库，Redis缓存、ES或其他存储结构的数据。当数据源为数据库或ES时，获取的参数可以包括搜索字段和搜索空间；当数据源为Redis缓存时，获取的参数除搜索字段和搜索空间以外，还可以包括“match”属性，该属性表征批量地确定出前缀为该属性的属性值的数据，例如，属性“match”的属性值为“prodBM_*”，表征批量地确定出所有前缀为prodBM_的数据。

步骤S102，利用参数和数据同步系统中的数据获取器，从数据源中获取待同步数据。

该数据获取器基于数据同步系统的获取器接口定义的。在定义数据获取器时，无需对数据同步系统的模型进行重复开发，只需继承数据同步系统的获取器接口，添加新的实现类即可，即数据获取器为数据同步系统中用于获取正确的需要被同步的数据的实现类。该实现类继承获取器接口，当需要配置新的数据源，或者需要增加新的数据获取方式时，基于新配置的数据源或新增加的获取方式，定义对应的数据获取器，在数据同步系统中添加继承获取器接口的逻辑编码，对该数据获取器进行初始化，使得数据获取器关联对应的数据源，在初始化中将其装配至Map中。利用该数据获取器从数据源获取待同步数据，能够实现可配置化地选择数据源、可配置化地获取待同步数据的能力，使得数据同步系统的模型具有较高的复用性。

数据获取器获取待同步数据时，根据该数据获取器定义的获取逻辑和步骤S101中获取到的参数，从数据源中获取符合获取逻辑的数据作为待同步数据。例如，属性“搜索字段1”和“cacheSource”的属性值分别“值1”和“slave”，利用数据获取器从关联的数据源中的“slave”搜索空间中进行“值1”的关键字搜索，搜索得到的数据即为待同步数据。这里，获取待同步数据时，可以是以ES搜索的方式进行的。

步骤S103，利用数据同步系统中的数据处理器，对待同步数据包括的每条数据进行同步处理，得到每条数据的同步处理结果。

该数据处理器基于数据同步系统的处理器接口定义的。在定义数据处理器时，无需对数据同步系统的模型进行重复开发，只需继承数据同步系统的处理器接口，添加新的实现类即可，即数据处理器为数据同步系统中用于处理数据实现数据同步的实现类。与数据获取器相同，数据处理器的每个实现类均继承数据处理器接口，当需要增加新的数据同步处理方式时，定义对应的数据处理器，在数据同步系统中添加集成处理器接口的逻辑编码，对该数据处理器进行初始化，使得数据处理器关联对应的数据源，在初始化中将其装配至Map中。各数据源可以对应一个数据获取器和一个数据处理器，针对各数据源的数据处理逻辑在各数据处理器中实现的。利用该数据处理器对待同步数据进行同步处理时，能够实现可配置化地处理同步信息的能力，使得数据同步系统的模型具有较高的复用性。

在一些实施例中，在进行数据同步之前，先判断数据同步系统是否已初始化，当确定数据同步系统未初始化时，首先对其进行初始化，初始化过程中，通过反射机制获取数据同步系统包括的所有数据获取器对应的实现类和所有数据处理器对应的实现类，对各数据获取器和各数据处理器进行初始化并将其装配至Map中，以供后续从数据处理器入参中匹配对应的数据处理器，根据对应数据处理器定义的数据处理逻辑，对各数据源的数据进行同步处理。在对数据获取器进行初始化时，将每个获取器关联一个数据源，数据源在初始化时注入，以商品为例，可关联：商品基本信息库-表、商品特殊属性库-表、商品图片库-表、Redis缓存、ElasticSearch索引-类型。针对入参中查询信息枚举进行转换，达到可从对应数据源获取满足所需查询信息的要求的目的。

需要说明的是，本申请实施例中基于获取器接口定义数据获取器、基于处理器接口定义数据处理器时，均可支持用户自定义逻辑编码，当用户需要进行其他数据源的数据同步，或以其他获取逻辑获取待同步数据，或者以其他处理逻辑对待同步数据进行同步处理时，均可以在数据同步系统上进行自定义的配置，从而使得数据同步系统能够提供配置化数据源选择的能力、可配置化同步信息获取的能力、可配置化处理同步信息的能力。

本申请实施例提供的数据同步方法，应用于数据同步系统，该方法包括：基于预先配置的数据源，获取用于获取待同步数据所需的参数；利用参数和数据同步系统中的数据获取器，从数据源中获取待同步数据，数据获取器基于数据同步系统的获取器接口定义的；利用数据同步系统中的数据处理器，对待同步数据包括的每条数据进行同步处理，得到每条数据的同步处理结果，数据处理器基于数据同步系统的处理器接口定义的，当增加新的数据源、或者需要新的数据获取逻辑、处理逻辑时，仅需基于数据同步系统的获取器接口增加对应的获取器类、基于数据同步系统的处理器接口增加对应的处理器类，如此根据定义的数据获取器和数据处理器进行数据同步，实现数据同步系统的高度复用性，能够减少代码开发量、降低开发成本。

针对不同的数据源，获取待同步数据所需的参数一般是不同的，常见的数据源的类型包括数据库、Redis缓存和ES。

在一些实施例中，当数据源的类型为数据库或ES时，获取待同步数据所需的参数可以包括搜索字段和搜索空间。此时，上述图1所示实施例中的步骤S102“利用参数和数据同步系统中的数据获取器，从数据源中获取待同步数据”可以通过以下步骤来实现：

步骤S102a1，基于搜索字段，利用数据获取器在搜索空间中进行ES搜索，得到符合搜索字段条件的搜索数据。

在实际搜索时，由于redis.scan操作性能很差，在大数量级的搜索情况下应避免直接使用redis.scan操作，以提高处理效率。本申请实施例中，当搜索空间中待搜索的数据量少于预设数据量阈值时，认为搜索空间中待同步数据较少，可以通过redis.scan进行搜索得到待同步数据；当搜索空间中待搜索的数据量不少于预设数据量阈值时，认为搜索空间中待同步数据较多，此时利用数据获取器在搜索空间中进行ES搜索。例如，通过ES检索出符合“搜索字段1”条件的搜索数据，即搜索字段的属性值为“值1”的搜索数据。

步骤S102a2，将搜索数据确定为待同步数据。

当数据源为数据库或ES时，由于数据库和ES的搜索匹配方式为精确匹配，因此根据搜索字段获取到的搜索数据即为待同步数据。

在一些实施例中，当数据源的类型为Redis缓存时，获取待同步数据所需的参数可以包括搜索字段、匹配规则和搜索空间。此时，上述图1所示实施例中的步骤S102“利用参数和数据同步系统中的数据获取器，从数据源中获取待同步数据”可以通过以下步骤来实现：

步骤S102b1，基于搜索字段，利用数据获取器在搜索空间中进行ES搜索，得到符合搜索字段条件的搜索数据。

与上述步骤S102a1相同，本申请实施例中，当搜索空间中待搜索的数据量少于预设数据量阈值时，可以通过redis.scan进行搜索得到待同步数据；当搜索空间中待搜索的数据量不少于预设数据量阈值时，利用数据获取器在搜索空间中进行ES搜索。例如，通过ES检索出符合“搜索字段1”条件的搜索数据，即搜索字段的属性值为“值1”的搜索数据，搜索结果为id为01、03和06的数据对应的属性“搜索字段1”的属性值为“值1”，搜索结果可以表示为{01,03,06}。

步骤S102b2，将匹配规则与搜索数据进行融合，得到缓存关键字。

例如，匹配规则“match”可以为匹配前缀为属性值的数据，也可以为匹配后缀为属性值的数据，还可以为中缀为属性值的数据，例如匹配前缀为“prod BM_*”，可以批量地确定出所有前缀为prodBM_的数据。

将匹配规则与搜索数据进行融合，可以是拼接，如将“prodBM_”和{01,03,06}进行拼接，得到的缓存关键字为prodBM_01，prodBM_03，prodBM_06。

步骤S102b3，基于缓存关键字，利用数据获取器在搜索空间中进行ES搜索，得到待同步数据。

根据缓存关键字prodBM_01，prodBM_03和prodBM_06，在搜索空间中进行ES搜索，搜索得到的数据即为待同步数据。

在一些实施例中，当数据量较大时，可通过数据同步系统包括的配置管理中心设置批量阈值，每次批量地处理不超过批量阈值的数据，避免由于处理数据过多导致系统发生异常，以及防止单次处理数据过多导致处理效率低下情况的发生。

本申请实施例提供的方法，当数据源为Redis缓存时，由于Redis缓存的搜索匹配方式为模糊匹配，因此需要获取匹配规则“match”这一参数与搜索数据进行融合，得到缓存关键字，将根据缓存关键字获取到的搜索数据确定为待同步数据。

在一些实施例中，在图1所示实施例的基础上，该数据同步方法还可以包括以下步骤：

步骤S104，基于每条数据的同步处理结果生成每条数据的日志数据。

本申请实施例中，生成每条数据的日志数据可以实现为：基于预设规则生成每条数据的同步标识；基于每条数据的同步处理结果，获取每条数据的状态信息；将每条数据在数据源中的数据标识、同步标识、同步处理结果和状态信息确定为每条数据的日志数据。

同步标识uuid具有唯一性，在ES日志文件中，能够根据同步标识查找到一条数据进行同步处理的日志数据。同步处理结果isSuccess用于表征同步处理的结果，包括同步成功和同步失败。状态信息message用于记录同步处理过程中的信息，以便用户快速地查看同步失败原因。每条数据在数据源中的数据标识记为id，则每条数据的日志数据可以表示为(id，uuid，isSuccess，message)。

步骤S105，将每条数据的日志数据记录至ES日志文件中。

本申请实施例中，在进行数据同步处理的过程中，记录每条数据的日志数据至ES日志文件log_es中，以便于用户查找数据同步处理的信息。

在存储时可以将同步处理过程中的所有数据生成为日志数据进行记录，以便用户查看详尽的日志数据；也可以如上述的将关键信息数据标识、同步标识、同步处理结果和状态信息生成为日志数据，记录关键信息便于用户快速查找某条日志数据，而且能够减少日志文件占用的内存空间。

由于日志记录容量存在上限，在进行数据同步时，待同步数据较少时，可将日志数据记录在Redis中。但实际中待同步数据经常为百万级别数据，若采用传统的打印日志的方式，存在同步处理数据记录不全，且不易批量搜索和获取关键信息的问题，因此本申请实施例中可以将日志数据记录至ES日志文件中，能够实现处理日志的全面记录与快速搜索。

本申请实施例提供的数据同步方法，考虑到redis.scan搜索性能较差，可通过ES搜索与记录，能够提高同步处理的效率。

上述同步处理结果可以包括第一标识和第二标识，其中，第一标识用于表征数据同步处理成功，第二标识用于表征数据同步处理失败，即当本条数据同步成功时，将该条数据的同步处理结果设置为第一标识，当本条数据同步失败时，将该条数据的同步处理结果设置为第二标识，如此将每条数据的同步处理结果记录在ES日志文件中。在一些实施例中，在上述步骤S105之后，上述数据同步方法还可以继续执行以下步骤：

步骤S106，基于同步标识和第二标识，在ES日志文件中进行ES搜索，得到目标数据标识。

这里的目标数据标识对应的数据同步处理失败。

本申请实施例中，对待同步数据进行同步处理完成后，可利用ES日志文件中的日志数据检验是否同步完毕，在实现时，根据同步标识uuid和第二标识no，在ES日志文件中进行ES搜索，得到同步处理失败的数据的数据标识，如01，根据该步骤可扫描得到ES日志文件中所有同步处理失败的数据，以进一步进行同步处理。

这里，通过同步标识uuid和第二标识进行ES搜索，能够快速获取本批次数据同步处理的结果，从而可提高数据处理的性能。

步骤S107，利用数据处理器，对目标数据标识对应的数据进行二次同步处理，得到同步处理失败的各条数据的二次同步处理结果。

得到ES日志文件中所有同步处理失败的数据后，利用数据处理器对该些数据进行再次同步处理，得到二次同步处理结果。

步骤S108，基于同步处理失败的每条数据的二次同步处理结果，生成同步处理失败的每条数据的日志数据。

这里生成同步处理失败的每条数据的日志数据的生成方式，与步骤S104中基于每条数据的同步处理结果生成每条数据的日志数据的生成方式相同。

步骤S109，将同步处理失败的每条数据的日志数据记录至ES日志文件中。

经过二次同步处理，能够大大的减少同步处理失败的数据量，提高数据处理的性能和精确度，满足大部分场景的精度需求。

在进行数据同步处理时，由于redis进行批量处理操作时，处理某缓存关键字key未成功时会自动跳过此key执行下一个，因此在redis未抛异常时，会存在未在ES日志文件log_es中记录同步失败，但实际上同步失败了的情况，因此在一些实施例中，在精度要求更高的场景中，二次同步处理结束后，需要对缓存进行精确扫描。重新执行上述整个同步处理过程，根据两次处理结果，检查数据同步处理是否彻底，若仍存在未同步处理的数据，则将仍存在未同步处理的数据存储在ES存储文件log_es中，可根据redis的操作指令或用户手动操作进行进一步处理。需要说明的是，在利用redis的操作指令redis.scan进一步处理时，虽然redis.scan处理大数据量时性能不好，但由于前期已经进行了两轮同步处理，符合“搜索字段1”条件的存余数据量已经不多，redis的性能瓶颈在可容忍范围内。

在一些实施例中，在对搜索空间slave中的数据同步处理完成后，上述数据同步方法还可以包括以下步骤：

步骤S110，判断是否接收到用于进行主集群数据同步处理的操作指令。

用户可以通过数据同步系统的配置管理中心，控制是否对主集群的数据进行同步处理，当满足预设的触发条件时，配置管理中心触发用于进行主集群数据同步处理的操作指令，进入步骤S111对主集群的数据进行同步处理；当不满足触发条件时，根据预设策略返回对应步骤，例如预设策略为循环同步过程时，则进入步骤S106，又例如预设策略为结束同步过程时，则结束数据同步。

在另一些实施例中，配置管理中心可在数据同步处理过程中，通过配置中断条件控制同步处理任务的中断，也可由用户手动操作控制同步处理任务实时中断，如在配置管理中心配置一个通过预设小事件subevent的方式关闭数据同步处理开关。

步骤S111，对主集群数据进行数据同步处理。

对主集群数据进行数据同步处理的步骤，即将步骤S101至步骤S109中搜索空间这一参数由slave换为master，其他参数不变。步骤S111执行完成后，完成主集群和辅集群的同步过程，实现数据同步。

上述利用数据处理器在对主集群、辅集群的所有数据进行同步处理过程中，采用同一个数据处理器，实现该数据处理器的高度复用性。

在图1所示实施例的基础上，本申请实施例再提供一种应用于数据同步系统的数据同步方法。为更清楚描述本申请实施例提供的数据同步方法，下面以清理缓存，对不一致的数据进行删除的方式来说明本申请实施例提供的数据同步方法。图2为本申请实施例提供的数据同步方法的另一种实现流程示意图，如图2所示，该数据同步方法包括以下步骤：

步骤S201，初始化数据同步系统，并获取数据同步系统中的数据获取器和数据处理器。

这里，进行初始化应用时，可以通过反射机制获取所有获取器类和处理器类。数据获取器为获取正确的需要被同步的数据的实现类，每个实现类均继承获取器接口。数据处理器为处理数据实现数据同步的实现类，同上每个实现类均继承数据处理器接口。

步骤S202，对数据获取器进行初始化，使数据获取器与对应的数据源进行关联。

对数据获取器进行初始化，关联数据源，并将其装配至自定义参数Map中，以供后续从数据处理器入参中匹配对应处理器。

步骤S203，对数据处理器进行初始化，使数据处理器与对应的数据源进行关联。

对数据处理器进行初始化，关联数据源，并将其装配至自定义参数Map中，以便后续根据数据处理器入参匹配处理器。针对各数据源的数据处理逻辑也均是由各数据源对应的数据处理器中实现的。

步骤S204，基于预先配置的数据源，获取用于获取待同步数据所需的参数。

在查询或处理中所需的参数均配置在各数据源对应的自定义参数Map中，例如主集群或备集群的选择，redis.scan操作“match”字段的设置。

例如用户在数据同步系统上输入参数“值1”、“prodBM_*”“slave”，自定义参数Map获取的参数可以表示为：

其中，“搜索字段1”、“match”和“cacheSource”为属性，分别指搜索字段、匹配规则和搜索空间，“值1”、“prodBM_*”和“slave”为属性值。

步骤S205，利用参数和数据同步系统中的数据获取器，从数据源中获取待同步数据。

该数据获取器基于数据同步系统的获取器接口定义的。如利用数据获取器从关联的数据源中的“slave”搜索空间中进行“值1”的关键字搜索，得到搜索数据，对匹配规则“prodBM_*”和搜索数据进行拼接得到缓存关键字，利用数据获取器在“slave”搜索空间中进行缓存关键字的搜索，得到待同步数据。这里，获取待同步数据时，可以是以ES搜索的方式进行的。

步骤S206，判断是否接收到用于开始进行同步处理的操作指令。

当接收到操作指令时，进入步骤S207；当未接收到操作指令时，继续执行步骤S206等待接收操作指令。

步骤S207，从数据同步系统中的多个数据处理器中确定与参数对应的数据处理器。

当确定需要对待同步数据进行同步处理时，根据自定义参数Map，从多个数据处理器中确定出与参数对应的数据处理器，该数据处理器基于数据同步系统的处理器接口定义的。

步骤S208，利用与参数对应的数据处理器对待同步数据包括的每条数据进行同步处理，得到每条数据的同步处理结果。

本申请实施例中基于获取器接口定义数据获取器、基于处理器接口定义数据处理器时，均可支持用户自定义逻辑编码，当用户需要进行其他数据源的数据同步，或以其他获取逻辑获取待同步数据，或者以其他处理逻辑对待同步数据进行同步处理时，均可以在数据同步系统上进行自定义的配置，从而使得数据同步系统能够提供配置化数据源选择的能力、可配置化同步信息获取的能力、可配置化处理同步信息的能力。

步骤S209，基于每条数据的同步处理结果生成每条数据的日志数据。

利用同步处理进程中的关键信息生成每条数据的日志数据。本申请实施例中，生成每条数据的日志数据可以实现为：基于预设规则生成每条数据的同步标识；基于每条数据的同步处理结果，获取每条数据的状态信息；将每条数据在数据源中的数据标识、同步标识、同步处理结果和状态信息确定为每条数据的日志数据。如每条数据的日志数据可以表示为(id，uuid，isSuccess，message)。

步骤S210，将每条数据的日志数据记录至ES日志文件中。

记录进程中关键信息至ES，且所存储的该ES类型需设立字段“数据库主键、uuid、是否成功及备注信息”，ES搜索性能相当高，且单次数据处理触发生成仅有唯一性的uuid，仅需使用“uuid”“是否成功”字段搜索即可获取上次处理中未成功数据，即可触发下一轮数据处理。使用ES日志文件的原因为此方式为目前记录全面、搜索速度较快的实现方式，若使用打印日志的方式，由于日志记录容量存在上限，若处理百万级别数据，则存在数据记录不全，且不易批量搜索和获取关键信息的问题。

步骤S211，基于同步标识和所述第二标识，在ES日志文件中进行ES搜索，得到目标数据标识。

该目标数据标识对应的数据同步处理失败。

步骤S212，利用数据处理器，对目标数据标识对应的数据进行二次同步处理，得到同步处理失败的各条数据的二次同步处理结果。

步骤S213，基于同步处理失败的每条数据的二次同步处理结果，生成同步处理失败的每条数据的日志数据。

步骤S214，将同步处理失败的每条数据的日志数据记录至ES日志文件中。

例如，若需删除150万条缓存，在第一轮扫描时根据条件进行ES搜索；自行与规定前缀拼接缓存key，最后进行删除逻辑，将处理结果存储在log_es中。在二次搜索得到log_es存在50万未清理掉的缓存，需要再次检索并删除存余缓存。通过检索log_es中上轮数据处理结果，再次处理上轮中未成功数据，再在小数量级情况下进行redis.scan扫描出带有规定前缀的缓存key，此时仅剩约20万未清理掉的缓存，进行逻辑筛选，进行删除逻辑，最后更新ES日志文件。

本申请实施例提供的方法，当增加新的数据源、或者需要新的数据获取逻辑、处理逻辑时，仅需基于数据同步系统的获取器接口增加对应的获取器类、基于数据同步系统的处理器接口增加对应的处理器类，如此根据定义的数据获取器和数据处理器进行数据同步，实现数据同步系统的高度复用性，能够减少代码开发量、降低开发成本；考虑到redis.scan性能较差，在检验清理是否完善时可通过es记录进行扫描前再清理，能够提高处理数据的效率；通过记录数据执行时uuid及其他关键信息来快速获取本批次数据处理结果，能够提高数据处理的性能和精准性。

在上述实施例的基础上，本申请实施例再提供一种应用于数据同步系统的数据同步方法。图3为本申请实施例提供的数据同步方法的又一种实现流程示意图，如图3所示，该数据同步方法包括以下步骤：

步骤S301，初始化数据同步系统，并获取数据同步系统中的数据获取器和数据处理器。

本申请实施例中，步骤S301至步骤S303的实现方式，可以参见图2所示实施例中的步骤S201至步骤S203的实现方式。

步骤S302，对数据获取器进行初始化，使数据获取器与对应的数据源进行关联。

步骤S303，对数据处理器进行初始化，使数据处理器与对应的数据源进行关联。

步骤S304，基于预先配置的数据源，获取用于获取待同步数据所需的参数。

基于预先配置的数据源，确定所述数据源的类型，所述数据源的类型包括数据库，Redis缓存和ES；当所述数据源的类型为数据库或ES时，获取用于获取待同步数据所需的搜索字段和搜索空间；当所述数据源的类型为Redis缓存时，获取用于获取待同步数据所需的搜索字段、匹配规则和搜索空间。

步骤S305，利用参数和数据同步系统中的数据获取器，从数据源中获取待同步数据。

该数据获取器基于数据同步系统的获取器接口定义的。

当数据源的类型为数据库或ES时，从数据源中获取待同步数据，包括：基于搜索字段，利用数据获取器在所述搜索空间中进行ES搜索，得到符合搜索字段条件的搜索数据；将搜索数据确定为待同步数据。

当数据源的类型为Redis缓存时，从数据源中获取待同步数据，可以实现为：基于搜索字段，利用数据获取器在所述搜索空间中进行ES搜索，得到符合所述搜索字段条件的搜索数据；将所述匹配规则与所述搜索数据进行融合，得到缓存关键字；基于所述缓存关键字，利用所述数据获取器在所述搜索空间中进行ES搜索，得到待同步数据。

步骤S306，判断是否接收到用于开始进行同步处理的操作指令。

当接收到操作指令时，进入步骤S307；当未接收到操作指令时，继续执行步骤S306等待接收操作指令。

步骤S307，从数据同步系统中的多个数据处理器中确定与参数对应的数据处理器。

当确定需要对待同步数据进行同步处理时，根据自定义参数Map，从多个数据处理器中确定出与参数对应的数据处理器。该数据处理器基于数据同步系统的处理器接口定义的。

步骤S308，利用与参数对应的数据处理器对待同步数据包括的每条数据进行同步处理，得到每条数据的同步处理结果。

本申请实施例中基于获取器接口定义数据获取器、基于处理器接口定义数据处理器时，均可支持用户自定义逻辑编码，当用户需要进行其他数据源的数据同步，或以其他获取逻辑获取待同步数据，或者以其他处理逻辑对待同步数据进行同步处理时，均可以在数据同步系统上进行自定义的配置，从而使得数据同步系统能够提供配置化数据源选择的能力、可配置化同步信息获取的能力、可配置化处理同步信息的能力。

步骤S309，基于每条数据的同步处理结果生成每条数据的日志数据。

基于预设规则生成所述每条数据的同步标识；基于每条数据的同步处理结果，获取每条数据的状态信息；将每条数据在数据源中的数据标识、同步标识、同步处理结果和状态信息确定为每条数据的日志数据。

步骤S310，将每条数据的日志数据记录至ES日志文件中。

得到ES日志文件中所有同步处理失败的数据后，利用数据处理器对该些数据进行再次同步处理，进入步骤S311。

步骤S311，基于同步标识和所述第二标识，在ES日志文件中进行ES搜索，得到目标数据标识。

该目标数据标识对应的数据同步处理失败。

步骤S312，判断目标数据标识的个数是否少于预设个数。

当目标数据标识的个数少于预设个数时，表明达到进行ES搜索结束条件，可利用redis.scan或用户手动操作进行同步处理，此时进入步骤S316；当目标数据标识的个数不少于预设个数时，表明还需继续基于ES搜索进行同步处理，进入步骤S313。

步骤S313，利用数据处理器，对目标数据标识对应的数据再次进行同步处理，得到再次同步处理结果。

步骤S314，基于再次同步处理结果，生成日志更新数据。

步骤S315，基于日志更新数据对ES日志文件进行更新，得到更新后的ES日志文件。

步骤S315之后，执行步骤S311。经过多次同步处理，能够大大的减少同步处理失败的数据量，提高数据处理的性能和精确度，满足大部分场景的精度需求。

步骤S316，基于redis.scan或基于用户操作触发的同步指令，对ES日志文件进行同步处理。

如在小数量级情况下进行redis.scan扫描出带有规定前缀的缓存关键字key，实现缓存清理。

步骤S317，判断是否接收到用于开始进行主集群的同步处理的操作指令。

当接收到操作指令时，进入步骤S318；当未接收到操作指令时，继续执行步骤S317等待接收操作指令。

步骤S318，对主集群数据进行数据同步处理。

对主集群数据进行数据同步处理的步骤，即将步骤S304至步骤S316中搜索空间这一参数由slave换为master，其他参数不变。步骤S316执行完成后，完成主集群和辅集群的同步过程，实现数据同步。

下面，将说明本申请实施例在一个实际的应用场景中的示例性应用。

在电子信息蓬勃发展的时代，膨胀增长的信息在各互联网系统间飞快的传递着。尽管如今的系统将数据高度一致性作为系统的基本要求来进行维护，但仍存在许多因素导致这点无法实现，例如网络原因导致数据丢失、代码逻辑原因导致数据未同步等。检测数据出现不一致后，解决方案分为两种：一种是刷新数据及时填补缺失数据；另一种是删除冗余数据。

相关技术中，在数据出现不一致后进行数据同步的实现方式及其缺陷为：

1)重新触发数据库变更进行数据同步：在Redis、Elasticsearch搜索服务器未同步数据库的情况下，可重新触发数据库变更，使其发送二进制日志文件(binary log，binlog)，由系统中已有的逻辑进行本次数据同步。

该方案存在的缺陷：除非在明确确定哪几条数据出现不一致的情况下，在绝大多数时候，研发人员并不明确具体出现数据不一致的情况有多少，因此仍需要针对此数据表和涉及到不一致的字段的数据重新开发对比工具，且由于该对比工具针对性过强，在此后碰到别类数据不一致情况的时候复用性低，仍需重新开发，因此大大增加了研发的开发压力和时间成本；同时，对数据库的操作直接关联线上正常运行的数据，研发人员无法准确评估再次触发此变更所带来的影响范围、代价是否可承受，因此此方案存在一定的危险。

2)开发刷新数据、删除数据的工具进行数据同步：该解决方案不仅需要开发数据同步工具，还需要开发检验数据是否同步彻底的工具，且在校验出数据仍未同步到位，需要多次进行数据处理时，存在未清理干净的数据如何保存，如何触发再度清理的问题，即存在如何整体性的一条龙处理完所有脏数据的问题。因此该方案仍存在复用性低，且开发量大的问题。

针对上述方案存在的复用性低、开发量大的问题，本申请实施例提供的解决方案，能够提供可配置化数据源选择、同步信息获取、处理同步信息的能力，并且能够提供检验数据处理是否彻底且再度触发数据同步的能力。

图4为本申请实施例提供的数据同步系统的整体结构示意图，如图4所示，该数据同步系统包括：

1)数据获取器：即获取正确的需要被同步的数据的实现类，每个实现类均继承获取器接口，实现统一的方法，但方法内部可进行自定义逻辑编码。每个获取器关联一个数据源，数据源在初始化时注入，以商品为例，可关联：商品基本信息库-表、商品特殊属性库-表、商品图片库-表、Redis缓存、Elasticsearch索引-类型。针对入参中查询信息枚举进行转换，达到可从对应数据源获取满足所需查询信息的要求的目的。初始化应用时，通过反射机制获取所有获取器类，并将其装配至Map中，以供后续从数据处理器入参中匹配对应处理器。

2)数据处理器：即处理数据实现数据同步的实现类，同上每个实现类均继承数据处理器接口，关联数据源，以便在初始化中装配至Map，针对各数据源的数据处理逻辑也均在各处理器中实现。

3)自定义参数Map：即在查询或处理中所需的参数均配置在此Map中，例如主集群或备集群的选择，Redis.scan操作“match”字段的设置。

4)查询信息枚举：即在查询中所需查出来的字段，明确所需查询内容。

5)配置管理中心：即控制程序进程细节的开关配置处，通过配置开关的切换，可提供动态更改进程状态的服务，例如动态变更单次批量获取信息的大小、动态终止进程以在数据误刷的情况下止损。

6)关键信息记录：记录进程中关键信息至es，且所存储的该es类型需设立字段“数据库主键、uuid、是否成功及备注信息，目的为：es搜索性能相当高，且单次数据处理触发生成仅有唯一性的uuid，仅需使用“uuid”“是否成功”字段搜索即可获取上次处理中未成功数据，即可触发下一轮数据处理。使用es的原因为此方式为目前记录全面、搜索速度较快的实现方式，若使用打印日志的方式，由于日志记录容量存在上限，若处理百万级别数据，则存在数据记录不全，且不易批量搜索和获取关键信息的问题。

下面结合需清理的数据为带有某前缀的key的缓存数据为例，对本申请实施例提供的数据同步方法的具体流程进行说明。图5为本申请实施例提供的数据同步方法的一种实现流程示意图，如图5所示，该方法包括以下步骤：

步骤S501，根据条件获取缓存中需清理的关键字key，执行清理操作，并记录每个id对应的清理结果。

通过es进行数据获取的原因是：Redis.scan操作性能很差，在大数量级的搜索情况下应避免直接使用Redis.scan操作，可通过es检索出符合“搜索字段1”条件的数据，并用入参传入的key前缀自行拼接Redis缓存key，并将缓存key整理为集合，最后进行批量缓存清理，其中批量操作缓存的批量大小可通过配置中心中配置而动态修改，防止由于批量大小设置不合理导致操作抛异常或效率低下的情况。

入参为：

图6为执行清理和记录操作的实现流程示意图，如图6所示，上述步骤S501执行清理和记录操作可以通过以下步骤来实现：

步骤S5011，在“es”数据获取器中，获取符合“搜索字段1”条件的数据，并整理成id集合。

步骤S5012，在“delUselessCacheSync”数据处理器中，将id集合中id与redis缓存前缀“ProdBM_”相拼接，整理成缓存key集合并在slave集群批量进行缓存清理。

步骤S5013，在“es”数据获取器处理过程中，向es的“log_es”类型中记录本次处理的关键信息(id，uuid，isSuccess，message)。

步骤S5014，本次处理结束。

步骤S502，检索出上一轮执行失败的id，并进行再度缓存清理。

利用es的快速搜索能力，在数据处理器log_es中以唯一uuid和执行失败的条件搜索出上一轮检索中执行失败的id，并通过“delUselessCacheSync”数据同步器进行再度缓存清理。

入参为：

图7为再次执行清理操作的实现流程示意图，如图7所示，上述步骤S502再次执行清理操作可以通过以下步骤来实现：

步骤S5021，在数据处理器log_es中以唯一uuid和执行失败的条件搜索出上一轮检索中执行失败的id。

步骤S5022，通过数据同步器“delUselesCacheSync”在slave集群进行再度缓存清理。

步骤S503，扫描缓存中前缀，检查数据清理是否彻底，并记录未清理信息至“log_es”。

进行此步骤原因为，Redis进行批量删除操作的时候，删除某key未成功会跳过此key执行下一个，因此在Redis未抛异常时，会存在未在“log_es”记录操作失败但实际上失败了的情况，因此需要对缓存进行精确扫描。虽然Redis.scan操作性能不好，但由于前期已经进行了二轮清理，符合“搜索字段1”条件的存余数据已经不多，因此Redis的性能瓶颈可容忍。

入参为：

图8为再次执行查找和记录操作的实现流程示意图，如图8所示，上述步骤S502再次执行查找和记录操作可以通过以下步骤来实现：

步骤S5031，在“redis”数据获取器中，获取符合“搜索字段1”条件、带有前缀“prodBM_”前缀、redis槽分布在0-6400之间的数据。

步骤S5032，通过数据同步器“delUselessCacheSync”在slave集群进行再度缓存清理。

通过实验证明：

1)若需删除150万条缓存：

场景一：若不使用本申请实施例提供的刷数据工具：硬性进行redis.scan扫描出带有规定前缀的缓存key；根据条件进行逻辑筛选，最后进行删除逻辑；需要耗费20多个小时。

场景二：若使用本申请实施例提供的刷数据工具：在第一轮扫描时根据条件进行es搜索；自行与规定前缀拼接缓存key，最后进行删除逻辑；需要耗费8小时。

2)若存在50万条未清理掉的缓存，需要检索并删除存余缓存：

场景一：若不使用本申请实施例提供的刷数据工具：再度硬性进行redis.scan扫描出带有规定前缀的缓存key；再度根据条件进行逻辑筛选，最后进行删除逻辑；需要耗费10多个小时；且存在redis.scan有空隙，导致大数量级扫描之后遗漏缓存key未扫描出的问题。

场景二：若使用本申请实施例提供的刷数据工具：通过检索es中上轮数据处理结果，再次处理上轮中未成功数据；在小数量级情况下进行redis.scan扫描出带有规定前缀的缓存key；此时仅剩约20万未清理掉的缓存，进行逻辑筛选，进行删除逻辑；需要耗费1小时；大数量级扫描之后遗漏缓存key未扫描出的问题有所减轻。

本申请实施例中，上述进行处理的三个步骤中均使用“delUselessCacheSync”数据处理器，仅需在工具内开发具体的删除逻辑判断和规则即可满足该数据处理器高度复用性；在该模型基础上，若需要新的获取数据、处理数据逻辑，仅需新开发对应获取器类、处理器类，实现了模型的高度复用性；考虑到redis.scan性能很差，在检验清理是否完善时可通过es记录进行扫描前再清理，以提高处理数据的效率；在数据处理中途，可通过配置进行实时任务中断，配置修改后通过subevent方式关闭数据处理开关；可通过各数据获取器、处理器的组合，在追求性能和精准度的前提下能解决各种数据处理的问题。如此，本申请实施例提供一个具有高度可复用性可配置化模型架构即1)提供配置化数据源选择的能力；2)提供可配置化同步信息获取的能力；3)提供可配置化处理同步信息的能力。通过记录数据执行时uuid及其他关键信息来快速获取本批次数据处理结果，便于执行后续数据校验或再执行步骤，能够大大提高数据处理的性能和精准性。

基于前述的实施例，本申请实施例提供一种数据同步装置，该装置包括的各模块、以及各模块包括的各单元，可以通过计算机设备中的处理器来实现；当然也可通过具体的逻辑电路实现；在实施的过程中，处理器可以为中央处理器(CPU，Central ProcessingUnit)、微处理器(MPU，Microprocessor Unit)、数字信号处理器(DSP，Digital SignalProcessing)或现场可编程门阵列(FPGA，Field Programmable Gate Array)等。

本申请实施例再提供一种应用于数据同步系统数据同步装置，图9为本申请实施例提供的数据同步装置的组成结构示意图，如图9所示，所述数据同步装置900包括：

第一获取模块901，用于基于预先配置的数据源，获取用于获取待同步数据所需的参数；

第二获取模块902，用于利用所述参数和所述数据同步系统中的数据获取器，从数据源中获取所述待同步数据，所述数据获取器基于所述数据同步系统的获取器接口定义的；

同步处理模块903，用于利用所述数据同步系统中的数据处理器，对所述待同步数据包括的每条数据进行同步处理，得到所述每条数据的同步处理结果，所述数据处理器基于所述数据同步系统的处理器接口定义的。

在一些实施例中，所述数据同步装置900还可以包括：

第一初始化模块，用于初始化所述数据同步系统；

第三获取模块，用于获取所述数据同步系统中的数据获取器和数据处理器；

第二初始化模块，用于对所述数据获取器进行初始化，使所述数据获取器与对应的数据源进行关联；

第三初始化模块，用于对所述数据处理器进行初始化，使所述数据处理器与对应的数据源进行关联。

在一些实施例中，所述第一获取模块901，还可以用于：

基于预先配置的数据源，确定所述数据源的类型，所述数据源的类型包括数据库，Redis缓存和ES；

当所述数据源的类型为数据库或ES时，获取用于获取待同步数据所需的搜索字段和搜索空间；

当所述数据源的类型为Redis缓存时，获取用于获取待同步数据所需的搜索字段、匹配规则和搜索空间。

在一些实施例中，当所述数据源的类型为数据库或ES时，所述第二获取模块902，还可以用于：

基于所述搜索字段，利用所述数据获取器在所述搜索空间中进行ES搜索，得到符合所述搜索字段条件的搜索数据；

将所述搜索数据确定为待同步数据。

在一些实施例中，当所述数据源的类型为数据库或ES时，所述第二获取模块902，还可以用于：

基于所述搜索字段，利用所述数据获取器在所述搜索空间中进行ES搜索，得到符合所述搜索字段条件的搜索数据；

将所述匹配规则与所述搜索数据进行融合，得到缓存关键字；

基于所述缓存关键字，利用所述数据获取器在所述搜索空间中进行ES搜索，得到待同步数据。

在一些实施例中，所述数据同步装置900还可以包括：

生成模块，用于基于所述每条数据的同步处理结果生成所述每条数据的日志数据；

记录模块，用于将所述每条数据的日志数据记录至ES日志文件中。

在一些实施例中，所述生成模块，还用于：

基于预设规则生成所述每条数据的同步标识；

基于所述每条数据的同步处理结果，获取所述每条数据的状态信息；

将所述每条数据在数据源中的数据标识、所述同步标识、所述同步处理结果和所述状态信息确定为所述每条数据的日志数据。

在一些实施例中，所述同步处理结果包括用于表征数据同步处理成功的第一标识和用于表征数据同步处理失败的第二标识；

所述第二获取模块，还用于基于所述同步标识和所述第二标识，在所述ES日志文件中进行ES搜索，得到目标数据标识，所述目标数据标识对应的数据同步处理失败；

所述同步处理模块，还用于利用所述数据处理器，对所述目标数据标识对应的数据进行二次同步处理，得到同步处理失败的各条数据的二次同步处理结果；

所述生成模块，还用于基于所述同步处理失败的每条数据的二次同步处理结果，生成所述同步处理失败的每条数据的日志数据；

所述记录模块，还用于将所述同步处理失败的每条数据的日志数据记录至ES日志文件中。

在一些实施例中，所述数据同步装置900还可以包括：

判断模块，用于判断是否接收到用于开始进行同步处理的操作指令；

确定模块，用于当接收到所述操作指令时，从所述数据同步系统中的多个数据处理器中确定与所述参数对应的数据处理器。

这里需要指出的是：以上数据同步装置实施例项的描述，与上述方法描述是类似的，具有同方法实施例相同的有益效果。对于本申请数据同步装置实施例中未披露的技术细节，本领域的技术人员请参照本申请方法实施例的描述而理解。

需要说明的是，本申请实施例中，如果以软件功能模块的形式实现上述方法，并作为独立的产品销售或使用时，也可以存储在一个计算机可读存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read OnlyMemory)、磁碟或者光盘等各种可以存储程序代码的介质。这样，本申请实施例不限制于任何特定的硬件和软件结合。

相应地，本申请实施例提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述实施例中提供的数据同步方法中的步骤。

本申请实施例提供一种数据同步设备，图10为本申请实施例提供的数据同步设备的组成结构示意图，根据图10示出的数据同步设备1000的示例性结构，可以预见数据同步设备1000的其他的示例性结构，因此这里所描述的结构不应视为限制，例如可以省略下文所描述的部分组件，或者，增设下文所未记载的组件以适应某些应用的特殊需求。

图10所示的数据同步设备1000包括：一个处理器1001、至少一个通信总线1002、用户接口1003、至少一个外部通信接口1004和存储器1005。其中，通信总线1002配置为实现这些组件之间的连接通信。其中，用户接口1003可以包括显示屏1031，外部通信接口1004可以包括标准的有线接口和无线接口。其中，所述处理器1001配置为执行存储器中存储的数据同步方法的程序，以实现上述实施例提供的数据同步方法中的步骤。

以上数据同步设备和存储介质实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请数据同步设备和存储介质实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

应理解，说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的特定特征、结构或特性包括在本申请的至少一个实施例中。因此，在整个说明书各处出现的“在一个实施例中”或“在一实施例中”未必一定指相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。

上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元；既可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。

另外，在本申请各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于计算机可读存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、ROM、磁碟或者光盘等各种可以存储程序代码的介质。

或者，本申请上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台设备执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、ROM、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本申请的实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。