CN108197222A - 一种异常流数据的修复方法、系统及相关装置 - Google Patents

Abstract

本申请公开了一种异常流数据的修复方法，该方法利用在Redis数据库流数据中能够唯一确定出一系列同源数据的数据标识获取这一系列同源数据的特征信息，并基于该特征信息进行异常判断，将存在异常的同源数据中的原始数据置入消息中间件，以在保证其持久性和完整性的前提下返回原处理环境重新执行原处理流程，直至在下一次异常判断中判定出不再存在异常，能够更全面、无遗漏的获取该一系列同源数据，且利用消息中间件使原始数据保持原始特性，数据修复效果更佳。本申请还同时公开了一种异常流数据的修复系统、装置及计算机可读存储介质，具有上述有益效果。

Description

一种异常流数据的修复方法、系统及相关装置

技术领域

本申请涉及数据监控技术领域，特别涉及一种异常流数据的修复方法、系统、装置及计算机可读存储介质。

背景技术

随着大数据时代的到来，一个复杂的系统中，数据处理流转可能需要经历很多环节，并且数据量每天可能到上亿条甚至几十亿条时。如何在如此大的数据量上保证每条数据在每个环节中正确的处理，以及如何在某个环节中出现问题能够自动修复，成为一个技术难题。

现有技术提出的解决方案主要分为硬件出现问题时的修复和数据存储节点出现问题时的修复，仅涵盖了这两个步骤，并没有保证数据处理各个环节无遗漏的处理，更无法在某个环节出现问题时实现自动识别并自动发起修复以实现更好的修复效果，实际使用过程中无法对所有流程和环节进行全方面的监控，实际使用效果不好。

所以，如何克服现有数据监控及修复技术存在的各项技术缺陷，提供一种数据监控更全面、能够自动识别并发起修复的数据监控及修复方案是本领域技术人员亟待解决的问题。

发明内容

本申请的目的是提供一种异常流数据的修复方法，利用在Redis数据库流数据中能够唯一确定出一系列同源数据的数据标识获取这一系列同源数据的特征信息，并基于该特征信息进行异常判断，将存在异常的同源数据中的原始数据置入消息中间件，以在保证其持久性和完整性的前提下返回原处理环境重新执行原处理流程，直至在下一次异常判断中判定出不再存在异常，能够更全面、无遗漏的获取该一系列同源数据，且利用消息中间件使原始数据保持原始特性，数据修复效果更佳。

本申请的另一目的在于提供了一种异常流数据的修复系统、装置及计算机可读存储介质。

为实现上述目的，本申请提供一种异常流数据的修复方法，该修复方法包括：

利用目标数据标识确定Redis数据库中所有携带有所述目标数据标识的同源数据，并获取所述同源数据的特征信息；

根据所述特征信息判断所述同源数据是否存在异常；

若是，则将存在异常的同源数据中的原始数据置入消息中间件；

从所述消息中间件中取出所述原始数据，并将所述原始数据重新置入所述Redis数据库，且按所述特征信息中携带的原数据处理步骤重新对所述原始数据进行数据处理，直至所述同源数据不存在异常。

可选的，利用目标数据标识确定Redis数据库中所有携带有所述目标数据标识的同源数据，包括：

利用目标MD5值在所述Redis数据库中进行匹配检索，将所有具有所述目标MD5值的数据判定为所述同源数据；其中，所述目标MD5值为利用Hash算法对所述同源数据在各数据处理步骤中未发生改变的数据计算得到。

可选的，根据所述特征信息判断所述同源数据是否存在异常，包括：

从所述特征信息中提取得到所述原始数据对应的原数据处理步骤和所述同源数据的实际数据处理步骤；

判断所述实际数据处理步骤与所述原数据处理步骤是否相同；

若所述实际数据处理步骤与所述原数据处理步骤相同，则判断所述实际数据处理步骤中是否存在数据的逻辑运算步骤；

若存在所述逻辑运算步骤，则对进行所述逻辑运算步骤之前的数据使用与所述逻辑运算步骤相同的逻辑运算规则进行二次校验，并根据得到的校验结果是否与原运算结果一致判断所述同源数据是否存在异常。

可选的，将存在异常的同源数据中的原始数据置入消息中间件，包括：

将存在异常的同源数据中的原始数据置入Kafka的任务队列中。

为实现上述目的，本申请还提供了一种异常流数据的修复系统，该修复系统包括：

特征信息获取单元，用于利用目标数据标识确定Redis数据库中所有携带有所述目标数据标识的同源数据，并获取所述同源数据的特征信息；

异常判断单元，用于根据所述特征信息判断所述同源数据是否存在异常；

原始数据置入单元，用于在所述同源数据存在异常时，将存在异常的同源数据中的原始数据置入消息中间件；

数据重新处理单元，用于从所述消息中间件中取出所述原始数据，并将所述原始数据重新置入所述Redis数据库，且按所述特征信息中携带的原数据处理步骤重新对所述原始数据进行数据处理，直至所述同源数据不存在异常。

可选的，所述特征信息获取单元包括：

MD5值获取目标数据子单元，用于利用目标MD5值在所述Redis数据库中进行匹配检索，将所有具有所述目标MD5值的数据判定为所述同源数据；其中，所述目标MD5值为利用Hash算法对所述同源数据在各数据处理步骤中未发生改变的数据计算得到。

可选的，所述异常判断单元包括：

数据处理步骤提取子单元，用于从所述特征信息中提取得到所述原始数据对应的原数据处理步骤和所述同源数据的实际数据处理步骤；

处理步骤一致判断子单元，用于判断所述实际数据处理步骤与所述原数据处理步骤是否相同；

逻辑运算步骤存在判断子单元，用于当所述实际数据处理步骤与所述原数据处理步骤相同时，判断所述实际数据处理步骤中是否存在数据的逻辑运算步骤；

二次校验及异常判定子单元，用于当存在所述逻辑运算步骤时，对进行所述逻辑运算步骤之前的数据使用与所述逻辑运算步骤相同的逻辑运算规则进行二次校验，并根据得到的校验结果是否与原运算结果一致判断所述同源数据是否存在异常。

可选的，所述原始数据置入单元包括：

置入Kafka子单元，用于将存在异常的同源数据中的原始数据置入Kafka的任务队列中。

为实现上述目的，本申请还提供了一种异常流数据的修复装置，该修复装置包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现如上述内容所描述的异常流数据的修复方法的步骤。

为实现上述目的，本申请还提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如上述内容所描述的异常流数据的修复方法的步骤。

本申请所提供的一种异常流数据的修复方法：利用目标数据标识确定Redis数据库中所有携带有所述目标数据标识的同源数据，并获取所述同源数据的特征信息；根据所述特征信息判断所述同源数据是否存在异常；若是，则将存在异常的同源数据中的原始数据置入消息中间件；从所述消息中间件中取出所述原始数据，并将所述原始数据重新置入所述Redis数据库，且按所述特征信息中携带的原数据处理步骤重新对所述原始数据进行数据处理，直至所述同源数据不存在异常。

显然，本申请所提供的技术方案，利用在Redis数据库流数据中能够唯一确定出一系列同源数据的数据标识获取这一系列同源数据的特征信息，并基于该特征信息进行异常判断，将存在异常的同源数据中的原始数据置入消息中间件，以在保证其持久性和完整性的前提下返回原处理环境重新执行原处理流程，直至在下一次异常判断中判定出不再存在异常，能够更全面、无遗漏的获取该一系列同源数据，且利用消息中间件使原始数据保持原始特性，数据修复效果更佳。本申请同时还提供了一种异常流数据的修复系统、装置及计算机可读存储介质，具有上述有益效果，在此不再赘述。

附图说明

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

图1为本申请实施例所提供的一种异常流数据的修复方法的流程图；

图2为本申请实施例所提供的另一种异常流数据的修复方法的流程图；

图3为本申请实施例所提供的一种异常流数据的修复系统的结构框图。

具体实施方式

本申请的核心是提供一种异常流数据的修复方法、系统、装置及计算机可读存储介质，利用在Redis数据库流数据中能够唯一确定出一系列同源数据的数据标识获取这一系列同源数据的特征信息，并基于该特征信息进行异常判断，将存在异常的同源数据中的原始数据置入消息中间件，以在保证其持久性和完整性的前提下返回原处理环境重新执行原处理流程，直至在下一次异常判断中判定出不再存在异常，能够更全面、无遗漏的获取该一系列同源数据，且利用消息中间件使原始数据保持原始特性，数据修复效果更佳。

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

以下结合图1，图1为本申请实施例所提供的一种异常流数据的修复方法的流程图。

其具体包括以下步骤：

S101：利用目标数据标识确定Redis数据库中所有携带有目标数据标识的同源数据，并获取同源数据的特征信息；

本步骤旨在说明如何从Redis数据库(一种键值对型数据库)中的流数据中毫无遗漏的获取所有携带有该目标数据标识的同源数据。本步骤利用数据标识来进行数据的唯一性识别，以实现将所有带着这一数据标识的数据毫无遗漏的获取到，这些数据应为基于原始数据在不同时间、经过不同数据处理流程或其它处理后的一系列同源数据，而且这些数据上应同时携带有描述这些数据的特性信息，例如文件大小、经过了哪些处理步骤等等，用于在后续步骤中判断异常与否以及指导异常数据的修复。

其中，该数据标识能够起到确定唯一对应的一系列同源数据，由于原始数据经过不同的数据处理步骤后在不同时间段内会产生相应的变化，而该数据标识要起到实际作用应使用该同源即使在不同时间、经过了不同数据处理步骤后仍不会发生变化的部分数据来生成该数据标识，或附加上一个不会被删去的识别标记等方式，具体实现方式多种多样，例如，可以在实际数据库列表中采用“表名_时间戳”的方式唯一对应每个时间分片中的数据，由于该“表名_时间戳”一旦产生就不会变换，还可以采用基于该“表名_时间戳”产生的数字识别信息作为该数据标识等，此处不做具体限定，只要是利用该数据标识来唯一确定一系列同源数据的方式，都应属于本步骤的保护范围。

S102：根据特征信息判断同源数据是否存在异常；

在S101的基础上，本步骤旨在根据该同源数据中携带的描述各数据特征的特征信息来判断该同源数据是否存在异常。通常情况下，数据在处理过程中发生异常的方式不外乎没有按预定数据处理步骤进行数据处理以及是否在进行逻辑运算时发生了错误等，这些信息作为过程信息通常都会在特性信息中有所体现。因此可以利用特征信息来判定该同源数据是否按预定数据处理步骤进行数据处理以及在存在逻辑运算步骤时采用相同的逻辑运算规则校验原逻辑运算结果等方式判定是否存在异常。

当然，为帮助实现上述过程，特征信息中还存在一些其它信息可用于辅助判断，具体如何进行辅助判断的方式多种多样，例如根据数据处理特性结合处理前后数据大小关系进行判断等等，此处并不做具体限定，可根据实际情况灵活做出选择。

进一步的，由于数据在数量众多的处理步骤中，总存在一些极其重要的、必不可少的执行步骤，相比之下也会存在一些无关紧要的处理步骤，在当无关紧要的步骤不影响数据结果时，为节省判断速度和加快判断效率可以只判断该同源数据是否执行了原数据处理步骤中的必要处理步骤即可。

S103：将存在异常的同源数据中的原始数据置入消息中间件；

本步骤旨在将存在异常的同源数据中的原始数据置入消息中间件。

采用消息中间件机制的系统中，不同的对象之间通过传递消息来激活对方的事件，完成相应的操作：发送者将消息发送给消息服务器，消息服务器将消息存放在若干队列中，在合适的时候再将消息转发给接收者。消息中间件能在不同平台之间通信，它常被用来屏蔽掉各种平台及协议之间的特性，实现应用程序之间的协同，其优点在于能够在客户和服务器之间提供同步和异步的连接，并且在任何时刻都可以将消息进行传送或者存储转发，同时大部分消息中间件也能够为存储于自身的数据提供持久化和完整性的保证。

具体的，消息中间件有很多，例如Kafka、RabbitMQ、RocketMQ等。

Kafka是LinkedIn开源的分布式发布—订阅消息系统，Kafka主要特点是基于Pull(定时拉取)的模式来处理消息消费，追求高吞吐量，一开始的目的就是用于日志收集和传输。对消息的重复、丢失、错误没有严格要求，适合产生大量数据的互联网服务的数据收集业务。

RabbitMQ是使用Erlang(一种编程语言)语言开发的开源消息队列系统，基于AMQP(Advanced Message Queuing Protocol，高级消息队列协议)协议来实现。AMQP的主要特征是面向消息、队列、路由(包括点对点和发布/订阅)、可靠性、安全。AMQP协议更多用在企业系统内，对数据一致性、稳定性和可靠性要求很高的场景，对性能和吞吐量的要求还在其次。

RocketMQ是阿里开源的消息中间件，它是纯Java(一种编程语言)开发，具有高吞吐量、高可用性、适合大规模分布式系统应用的特点。RocketMQ思路起源于Kafka，但并不是Kafka的一个复制，它对消息的可靠传输及事务性做了优化。

上述各种消息中间件各有优缺点，可以根据实际情况灵活选择，此处并不做具体限定。

S104：从消息中间件中取出原始数据，并将原始数据重新置入Redis数据库，且按特征信息中携带的原数据处理步骤重新对原始数据进行数据处理，直至同源数据不存在异常；

在S103的基础上，本步骤旨在从消息中间件中取出当时置入的原始数据，并将该原始数据重新放入原Redis数据库，且按特征信息中携带的原数据处理步骤重新对原始数据进行数据处理，直至同源数据不存在异常。换句话说，就是将其取出并在原环境下按照原处理流程重新进行处理，在此过程中依然会进行如S102的异常判断，直至通过S102的异常判断。

S105：进行其它数据的异常判断。

本步骤建立在S102的判断结果为该同源数据不存在异常的基础上，即可以进行其它数据的异常判断。

基于上述技术方案，本申请实施例提供的一种异常流数据的修复方法，利用在Redis数据库流数据中能够唯一确定出一系列同源数据的数据标识获取这一系列同源数据的特征信息，并基于该特征信息进行异常判断，将存在异常的同源数据中的原始数据置入消息中间件，以在保证其持久性和完整性的前提下返回原处理环境重新执行原处理流程，直至在下一次异常判断中判定出不再存在异常，能够更全面、无遗漏的获取该一系列同源数据，且利用消息中间件使原始数据保持原始特性，数据修复效果更佳。

以下结合图2，图2为本申请实施例所提供的另一种异常流数据的修复方法的流程图。

本实施例旨在对上一实施例中如何判断这一系列的同源数据是否存在异常进行具体说明，具体包括以下步骤：

S201：利用目标MD5值在Redis数据库中进行匹配检索，将所有具有目标MD5值的数据判定为同源数据；

本实施例旨在利用MD5值进行一系列同源数据的检索和匹配。其中，目标MD5值为利用Hash算法对同源数据在各数据处理步骤中未发生改变的数据计算得到。Hash算法是一种将任意长度的消息压缩到某一固定长度的消息摘要的函数，MD5(Message-DigestAlgorithm 5，信息摘要算法第5版)值为基于Hash算法计算得到一种特征值，用于表示数据的唯一性。此处使用Hash算法进行数据计算的主体为同源数据在各数据处理步骤中始终未发生改变的部分数据，或是在上一实施例中所描述的“表名_时间戳”等，以实现使用该目标MD5值就能够得到所有从原始数据出发经过各数据处理流程后的一系列同源数据的目的。

S202：从特征信息中提取得到原始数据对应的原数据处理步骤和同源数据的实际数据处理步骤；

S203：判断实际数据处理步骤与原数据处理步骤是否相同；

本步骤旨在比对原数据处理步骤与实际数据处理步骤是否相同，即检查是否少执行了一些步骤或错误的执行了一些步骤等等。

进一步的，为减少比对工作量，还可以仅判断实际数据处理步骤是否含盖了原数据处理步骤中的一些必要且关键的处理步骤，即抛弃无关紧要的步骤。

S204：判断实际数据处理步骤中是否存在数据的逻辑运算步骤；

本步骤建立在S203的判断结果为实际数据处理步骤与原数据处理步骤相同的基础上，开始下一项判断：实际数据处理步骤中是否存在数据的逻辑运算步骤。

S205：对进行逻辑运算步骤之前的数据使用与逻辑运算步骤相同的逻辑运算规则进行二次校验，得到校验结果；

S206：根据校验结果是否与原运算结果一致判断同源数据是否存在异常；

S207：判定同源数据存在异常；

S208：判定同源数据不存在异常。

本实施例首先从特征信息中提取的原数据处理步骤和实际数据处理步骤，即比较实际数据处理步骤与预先制定的数据处理步骤是否一致，并在此基础上先判断两数据处理步骤是否相同作为异常判断的第一环节，在通过第一环节的情况下判断实际数据处理步骤是否包含逻辑运算步骤，若包含则对为进行该逻辑运算步骤前的数据利用相同的逻辑运算规则进行结果校验，以此作为异常判断的第二环，若第二环也通过则代表这一系列的同源数据并未存在异常，反之则存在异常。

当然还会存在其它异常判别方式，例如对第一换判别进行精简，只判断实际数据处理步骤中是否含盖了预定数据处理步骤中的必要数据处理步骤，还可以进行诸如验证数据完整性、附加的某一识别标记是否依然存在等方式进行判定，可根据实际情况灵活增加判据，此处并不做具体限定，只是给出一种参考的判别方式。

基于上述技术方案，本申请实施例提供的一种异常流数据的修复方法，利用在Redis数据库流数据中能够唯一确定出一系列同源数据的数据标识获取这一系列同源数据的特征信息，并基于该特征信息进行异常判断，将存在异常的同源数据中的原始数据置入消息中间件，以在保证其持久性和完整性的前提下返回原处理环境重新执行原处理流程，直至在下一次异常判断中判定出不再存在异常，能够更全面、无遗漏的获取该一系列同源数据，且利用消息中间件使原始数据保持原始特性，数据修复效果更佳。

因为情况复杂，无法一一列举进行阐述，本领域技术人员应能意识到根据本申请提供的基本方法原理结合实际情况可以存在很多的例子，在不付出足够的创造性劳动下，应均在本申请的保护范围内。

下面请参见图3，图3为本申请实施例所提供的一种实时流数据监控及修复系统的结构框图。

该实时流数据监控及修复系统可以包括：

特征信息获取单元100，用于利用目标数据标识确定Redis数据库中所有携带有目标数据标识的同源数据，并获取同源数据的特征信息；

异常判断单元200，用于根据特征信息判断同源数据是否存在异常；

原始数据置入单元300，用于在同源数据存在异常时，将存在异常的同源数据中的原始数据置入消息中间件；

数据重新处理单元400，用于从消息中间件中取出原始数据，并将原始数据重新置入Redis数据库，且按特征信息中携带的原数据处理步骤重新对原始数据进行数据处理，直至同源数据不存在异常。

可选的，特征信息获取单元100包括：

MD5值获取目标数据子单元，用于利用目标MD5值在Redis数据库中进行匹配检索，将所有具有目标MD5值的数据判定为同源数据；其中，目标MD5值为利用Hash算法对同源数据在各数据处理步骤中未发生改变的数据计算得到。

可选的，异常判断单元200包括：

数据处理步骤提取子单元，用于从特征信息中提取得到原始数据对应的原数据处理步骤和同源数据的实际数据处理步骤；

处理步骤一致判断子单元，用于判断实际数据处理步骤与原数据处理步骤是否相同；

逻辑运算步骤存在判断子单元，用于当实际数据处理步骤与原数据处理步骤相同时，判断实际数据处理步骤中是否存在数据的逻辑运算步骤；

二次校验及异常判定子单元，用于当存在逻辑运算步骤时，对进行逻辑运算步骤之前的数据使用与逻辑运算步骤相同的逻辑运算规则进行二次校验，并根据得到的校验结果是否与原运算结果一致判断同源数据是否存在异常。

可选的，原始数据置入单元300包括：

置入Kafka子单元，用于将存在异常的同源数据中的原始数据置入Kafka的任务队列中。

以上各单元可以应用于以下的一个具体的实际例子中：

本实施例采用现阶段性能最优、最适合本申请所描述内容的Kafka来作为消息中间件，它拥有如下特性：

通过特定的磁盘数据结构提供为置入的消息提供持久化服务，这种结构对于即使数以TB的消息存储也能够保持长时间的稳定性能；高吞吐量，即使是非常普通的硬件Kafka也可以支持每秒数百万的消息；支持通过Kafka服务器和消费机集群来分区消息；支持从分布式数据库中实现数据的并行加载。

本实施例首先创建本地队列收集每个目标数据的数据处理状态、定时将本地队列中目标数据的状态同步到Redis收集器、监控系统自动监控Redis收集器各个环节的数据状态并将有问题的数据标识发送到Kafka，以利用Kafka作为消息中间件保存数据，并在返回原处理环境重新执行原数据处理流程。

其中，收集目标数据的数据处理状态的时间间隔可自行设定在合理范围内，以使每次同步到Redis收集器中的数据并非仅有的一个，增加数据同步效率，还可以在同步至Redis收集器后将本地队列收集的数据清除掉，节省占用的空间；监控系统则根据Redis收集器中收集到的数据判断该目标数据是否存在异常，并在存在异常时根据该数据标识将该目标数据的原始数据(根据Redis数据库的特性：使用Key唯一确定对应的Value，即使用“键”确定“值”)发送至Kafka，以利用Kafka作为消息中间件保存数据，并在返回原处理环境重新执行原数据处理流程。

基于上述实施例，本申请还提供了一种实时流数据监控及修复装置，可以包括存储器和处理器，其中，该存储器中存有计算机程序，该处理器调用该存储器中的计算机程序时，可以实现上述实施例所提供的步骤。当然该装置还可以包括各种必要的网络接口、电源以及其它零部件等。

本申请还提供了一种计算机可读存储介质，其上存有计算机程序，该计算机程序被执行终端或处理器执行时可以实现上述实施例所提供的步骤。该存储介质可以包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random AccessMemory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想。应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以对本申请进行若干改进和修饰，这些改进和修饰也落入本申请权利要求的保护范围内。

还需要说明的是，在本说明书中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其它变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其它要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、物品或者设备中还存在另外的相同要素。

Claims (10)

1.一种异常流数据的修复方法，其特征在于，包括：

利用目标数据标识确定Redis数据库中所有携带有所述目标数据标识的同源数据，并获取所述同源数据的特征信息；

根据所述特征信息判断所述同源数据是否存在异常；

若是，则将存在异常的同源数据中的原始数据置入消息中间件；

从所述消息中间件中取出所述原始数据，并将所述原始数据重新置入所述Redis数据库，且按所述特征信息中携带的原数据处理步骤重新对所述原始数据进行数据处理，直至所述同源数据不存在异常。

2.根据权利要求1所述的修复方法，其特征在于，利用目标数据标识确定Redis数据库中所有携带有所述目标数据标识的同源数据，包括：

利用目标MD5值在所述Redis数据库中进行匹配检索，将所有具有所述目标MD5值的数据判定为所述同源数据；其中，所述目标MD5值为利用Hash算法对所述同源数据在各数据处理步骤中未发生改变的数据计算得到。

3.根据权利要求1或2所述的修复方法，其特征在于，根据所述特征信息判断所述同源数据是否存在异常，包括：

从所述特征信息中提取得到所述原始数据对应的原数据处理步骤和所述同源数据的实际数据处理步骤；

判断所述实际数据处理步骤与所述原数据处理步骤是否相同；

若所述实际数据处理步骤与所述原数据处理步骤相同，则判断所述实际数据处理步骤中是否存在数据的逻辑运算步骤；

若存在所述逻辑运算步骤，则对进行所述逻辑运算步骤之前的数据使用与所述逻辑运算步骤相同的逻辑运算规则进行二次校验，并根据得到的校验结果是否与原运算结果一致判断所述同源数据是否存在异常。

4.根据权利要求3所述的修复方法，其特征在于，将存在异常的同源数据中的原始数据置入消息中间件，包括：

将存在异常的同源数据中的原始数据置入Kafka的任务队列中。

5.一种异常流数据的修复系统，其特征在于，包括：

特征信息获取单元，用于利用目标数据标识确定Redis数据库中所有携带有所述目标数据标识的同源数据，并获取所述同源数据的特征信息；

异常判断单元，用于根据所述特征信息判断所述同源数据是否存在异常；

原始数据置入单元，用于在所述同源数据存在异常时，将存在异常的同源数据中的原始数据置入消息中间件；

数据重新处理单元，用于从所述消息中间件中取出所述原始数据，并将所述原始数据重新置入所述Redis数据库，且按所述特征信息中携带的原数据处理步骤重新对所述原始数据进行数据处理，直至所述同源数据不存在异常。

6.根据权利要求5所述修复系统，其特征在于，所述特征信息获取单元包括：

MD5值获取目标数据子单元，用于利用目标MD5值在所述Redis数据库中进行匹配检索，将所有具有所述目标MD5值的数据判定为所述同源数据；其中，所述目标MD5值为利用Hash算法对所述同源数据在各数据处理步骤中未发生改变的数据计算得到。

7.根据权利要求5或6所述的修复系统，其特征在于，所述异常判断单元包括：

数据处理步骤提取子单元，用于从所述特征信息中提取得到所述原始数据对应的原数据处理步骤和所述同源数据的实际数据处理步骤；

处理步骤一致判断子单元，用于判断所述实际数据处理步骤与所述原数据处理步骤是否相同；

逻辑运算步骤存在判断子单元，用于当所述实际数据处理步骤与所述原数据处理步骤相同时，判断所述实际数据处理步骤中是否存在数据的逻辑运算步骤；

二次校验及异常判定子单元，用于当存在所述逻辑运算步骤时，对进行所述逻辑运算步骤之前的数据使用与所述逻辑运算步骤相同的逻辑运算规则进行二次校验，并根据得到的校验结果是否与原运算结果一致判断所述同源数据是否存在异常。

8.根据权利要求7所述的修复系统，其特征在于，所述原始数据置入单元包括：

置入Kafka子单元，用于将存在异常的同源数据中的原始数据置入Kafka的任务队列中。

9.一种异常流数据的修复装置，其特征在于，包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现如权利要求1至4任一项所述的异常流数据的修复方法的步骤。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至4任一项所述的异常流数据的修复方法的步骤。