具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

图1示出了本发明实施例提供的基于Flink实时任务脏数据插件化管理的方法的流程图，参见图1，本发明实施例提供的基于Flink实时任务脏数据插件化管理的方法，包括：

S1，脏数据管理者获取脏数据配置信息，实例化脏数据管理者，实例化对应的脏数据插件对象。

具体地，通过配置脏数据规则，实例化脏数据管理者Dirty-Manager，同时实例化对应的脏数据插件对象Dirty-plugins。通过脏数据管理者来记录脏数据本身及异常原因，并存入消息队列中，同时管理脏数据插件的启动，维护脏数据消息队列。通过脏数据消费者对脏数据队列消费及对脏数据处理。

其中，脏数据管理者记录脏数据本身数据及异常原因，并存入消息队列中，充当生产者角色，实例化对应的脏数据插件对象Dirty-plugins中脏数据消费者Dirty-consumer则异步轮训地消费队列中的数据，充当消费者角色，根据不同的消费实现不同的处理方式。

S2，脏数据管理者收集任务产生的脏数据及异常原因，将脏数据及异常原因存入消息队列。

作为本发明实施例的一个可选实施方式，脏数据管理者收集任务产生的脏数据及异常原因，将脏数据及异常原因存入消息队列之前，基于Flink实时任务脏数据插件化管理的方法还包括：脏数据管理者初始化消息队列。

具体地，通过消息队列存储脏数据及异常原因，当脏数据管理者Dirty-Manager收集到脏数据及异常信息，可以生成一个dirty-entity对象，将该对象存入dirty-queue消息队列中，以便后续脏数据消费者对脏数据进行消费。

S3，脏数据管理者启动脏数据插件对象中的脏数据消费者。

作为本发明实施例的一个可选实施方式，脏数据管理者启动脏数据插件对象中的脏数据消费者之前，基于Flink实时任务脏数据插件化管理的方法还包括：脏数据管理者确定消息队列中的第一条脏数据。在脏数据管理者确定了消息队列中的第一条脏数据后，可以启动脏数据消费者进行消费。

S4，脏数据消费者轮训消费消息队列中的脏数据。

具体地，脏数据消费者仅对脏数据进行消费，而不关心任务的失败与否。

作为本发明实施例的一个可选实施方式，脏数据消费者轮训消息队列中的脏数据包括：脏数据消费者通过脏数据消费者子类轮训消费消息队列中的脏数据。脏数据消费者的消费交由子类实现，从而可以做到脏数据的插件化管理。

S5，如果脏数据消费者消费消息队列中的脏数据成功，脏数据管理者将脏数据消费计数值加1，直至脏数据消费计数值达到预设脏数据消费计数值，确定任务失败；如果脏数据消费者消费消息队列中的脏数据失败，脏数据管理者将失败数据计数值加1，直至失败数据计数值达到预设失败数据计数值，确定任务失败。

具体地，脏数据管理者确定了如果任务中脏数据消费累计超过阈值和/或消费失败次数超过阈值，均认为任务失败，否则认为任务成功。

由此可见，利用本发明实施例提供的基于Flink实时任务脏数据插件化管理的方法，采用生产者与消费者的基本设计模式，利用消息队列作为缓存，脏数据的收集通过脏数据管理者实现，脏数据的处理通过脏数据消费者实现，脏数据消费者只需要关注消息的消费处理，无需关注任务的失败与否，从而将脏数据的管理和处理过程进行解耦。

此外，利用对象的继承关系，根据子类的实现不同，做到对脏数据的特定处理。

可见，本发明新增对任务针对脏数据处理的情况，控制任务停止与否，以及实时任务中脏数据的插件化管理，有效提高任务执行过程中的容错性。

以下，以实例化将脏数据打印到日志中的dirty-log插件为例，对本发明提供的基于Flink实时任务脏数据插件化管理的方法进行进一步说明：

参见图2，Dirty-manager是脏数据管理者，其具体实现是DirtyManager，记录脏数据本身及异常原因，并存入消息队列中，同时管理脏数据插件的启动，维护脏数据消息队列，其中，脏数据管理者的执行流程包括：

步骤1，DirtyManager是脏数据管理者，按照指定的配置信息，实例化对应的脏数据插件对象，例如实例化将脏数据打印到日志中的dirty-log插件的配置信息：

{"type":"log","print.rate":"100","dirty.limit":"1000","error.limit":"1000","log.properties":"/data/log.properties"}

其中，配置信息中不仅有脏数据插件对应的类型，还有对应类型中的特有参数。

步骤2，实例化dirty-log插件，执行consume方法，轮训dirty-queue消息队列中的脏数据，根据dirty-log的特定配置print.rate，每100条脏数据打印一次脏数据到日志中，再根据log.properties中的信息配置日志打印输出文件位置。

步骤3，当DirtyManager收集到脏数据及异常信息，会生成一个dirty-entity对象，存入dirty-queue消息队列中，如果是第一条脏数据，那么启动consumer线程池，异步轮训队列，通过consumer线程来消费队列数据。

步骤4，脏数据成功下发到脏数据插件中，且消费成功，即处理完脏数据不出现异常，那么消费脏数据总条数totalCount总数加1，反之，当脏数据下发超时，或者插件消费脏数据抛出异常，那么将异常通过日志打印，同时消费脏数据条数errorCount总数加1。

步骤5，如果消费脏数据总条数totalCount达到了设定的dirty.limit值，或者消费脏数据失败条数errorCount达到了设定的error.limit值，那么任务将失败且不再重试。

参见图3，DirtyConsumer是脏数据插件中消费者角色，提供对脏数据队列消费及对脏数据处理功能，其抽象实现是AbstractDirtyConsumer，实现线程Runnable接口，其中run方法循环执行抽象方法consume，而consume方法则交由子类实现，从而做到脏数据的插件化管理。同时，DirtyConsumer消费者只需要关注消息的消费处理，无需关注任务的失败与否，做到脏数据的管理与处理的解耦。DirtyConsumer的执行流程包括：

步骤1，实例化AbstractDirtyConsumer子类，当第一条脏数据产生时，启动consume线程池，激活consume线程；

步骤2，consume线程执行consume方法，轮训消费脏数据队列中的脏数据。根据子类中方法实现的不同，达到对脏数据处理不同的效果。

由此可见，利用本发明实施例提供的基于Flink实时任务脏数据插件化管理的方法，采用生产者与消费者的基本设计模式，利用消息队列作为缓存，脏数据的收集通过脏数据管理者实现，脏数据的处理通过脏数据消费者实现，脏数据消费者只需要关注消息的消费处理，无需关注任务的失败与否，从而将脏数据的管理和处理过程进行解耦。

此外，利用对象的继承关系，根据子类的实现不同，做到对脏数据的特定处理。

可见，本发明新增对任务针对脏数据处理的情况，控制任务停止与否，以及实时任务中脏数据的插件化管理，有效提高任务执行过程中的容错性。

图4示出了本发明实施例提供的基于Flink实时任务脏数据插件化管理的系统的结构示意图，本发明实施例提供的基于Flink实时任务脏数据插件化管理的系统应用于上述方法，以下仅对基于Flink实时任务脏数据插件化管理的系统的结构进行概括说明，其他未尽事宜，请参照上述基于Flink实时任务脏数据插件化管理的方法中的相关说明，参见图4，本发明实施例提供的基于Flink实时任务脏数据插件化管理的系统，包括：根据脏数据配置信息实例化得到的脏数据管理者，以及实例化得到的脏数据消费者；

脏数据管理者，用于收集任务产生的脏数据及异常原因，将脏数据及异常原因存入消息队列；启动脏数据插件对象中的脏数据消费者；

脏数据消费者，用于轮训消费消息队列中的脏数据；

脏数据管理者，还用于在如果脏数据消费者消费消息队列中的脏数据成功，将脏数据消费计数值加1，直至脏数据消费计数值达到预设脏数据消费计数值，确定任务失败；如果脏数据消费者消费消息队列中的脏数据失败，将失败数据计数值加1，直至失败数据计数值达到预设失败数据计数值，确定任务失败。

作为本发明实施例的一个可选实施方式，脏数据管理者，还用于在启动脏数据插件对象中的脏数据消费者之前，确定消息队列中的第一条脏数据。

作为本发明实施例的一个可选实施方式，脏数据管理者，还用于在收集任务产生的脏数据及异常原因，将脏数据及异常原因存入消息队列之前，初始化消息队列。

作为本发明实施例的一个可选实施方式，脏数据消费者通过如下方式轮训消息队列中的脏数据：脏数据消费者，具体用于通过脏数据消费者子类轮训消费消息队列中的脏数据。

由此可见，利用本发明实施例提供的基于Flink实时任务脏数据插件化管理的系统，采用生产者与消费者的基本设计模式，利用消息队列作为缓存，脏数据的收集通过脏数据管理者实现，脏数据的处理通过脏数据消费者实现，脏数据消费者只需要关注消息的消费处理，无需关注任务的失败与否，从而将脏数据的管理和处理过程进行解耦。

此外，利用对象的继承关系，根据子类的实现不同，做到对脏数据的特定处理。

可见，本发明新增对任务针对脏数据处理的情况，控制任务停止与否，以及实时任务中脏数据的插件化管理，有效提高任务执行过程中的容错性。

以上仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。