CN111694864B - 单一进程的流式数据计算执行调度任务并避免数据丢失的方法、系统及计算机设备 - Google Patents

Abstract

本发明公开了一种单一进程的流式数据计算中执行调度任务并避免数据丢失的方法、系统及计算机设备，采用微服务提供Restful接口供数据写入并注册至Eureka集群，Flink从Eureka获取写入服务地址并调用接口进行数据持久化。在此基础上增加服务异常捕捉及休眠重试方案，利用Flink的背压机制、Kafka的可重放特性以及Eureka的高可用机制解决了实时统计数据写入时数据丢失的问题。

Description

单一进程的流式数据计算执行调度任务并避免数据丢失的方 法、系统及计算机设备

技术领域

指本发明属于大数据实时流式分布式计算领域，具体是一种单一进程的流式数据计算中执行调度任务并避免数据丢失的方法。

背景技术

目前实时分布式流处理计算引擎在从分布式消息队列获取数据并进行统计之后完成数据持久化的方式主要有：

通过用于执行结构化查询语言语句的应用程序接口写入关系数据库中；

1、使用流式计算引擎和各种外部存储的连接器写入至分布式全文搜索引擎、分布式混合型非关系数据库、分布式列式数据库等外部存储，目前多数只能保证至少处理一次语义，少数可以保证刚好处理一次的语义；

2、发送至分布式消息队列消息中间件，由其他流式计算任务消费队列数据完成数据持久化；

3、直接写入到分布式文件系统等外部存储文件；

4、使用流式计算引擎提供的应用程序接口将数据传输给服务提供方后持久化；

在针对海量数据进行数据持久化时，在数据库服务不可用或者外部存储写入失败时会导致数据丢失，而这部分数据已经从分布式消息队列中消费获取，难以确定丢失数据对应的消息偏移量故无法准确恢复数据，这对于实时统计数据来说是不可接受的。

发明内容

本发明的目的在于提供一种单一进程的流式数据计算中执行调度任务并避免数据丢失的方法及系统，解决了实时统计数据写入时数据丢失的问题。

实现本发明目的的技术解决方案为：一种单一进程的流式数据计算中执行调度任务并避免数据丢失的方法，采用微服务提供接口供数据写入并注册至Eureka集群，Flink从Eureka获取写入服务地址并调用接口进行数据持久化。

进一步地，本发明单一进程的流式数据计算中执行调度任务并避免数据丢失的方法，具体步骤如下：

步骤一：流式计算引擎实时消费分布式消息队列中的数据，启用检查点机制，计算数据节点，生成数据流至最末端数据节点；

步骤二：判断缓存中是否存在写入微服务地址，若存在进入步骤三；若不存在，从服务发现框架集群的服务注册中心获取微服务地址，获取成功后缓存至内存中，执行步骤三；若获取失败，休眠后重试，一直到从服务注册中心获取微服务地址成功；

步骤三：调用接口发送请求写入数据并主动捕捉异常，判断服务是否正常即数据是否可以写入；若捕捉到异常即写入失败，重新发送请求判断该微服务节点不可用；从集群获取其他可用节点地址，并调用接口验证是否可用。

进一步地，所述流式计算引擎中的任务管理器定时对数据节点的缓冲区进行数据采样，并判断是否有数据堆积，若发生堆积，则减缓整个节点链路的数据处理速度来适配最慢的节点。

进一步地，启用所述流式计算引擎的检查点机制，触发检查点机制时，将消息队列的消息偏移量及各个数据节点中的缓存数据持久化到分布式文件系统中。

进一步地，所述分布式消息队列将数据持久化到磁盘，用以提供消息偏移量来获取历史数据。

进一步地，微服务向所述服务发现框架注册服务后，节点之间互相同步注册信息，从任意一个服务注册中心均可获取服务地址；若集群在一定时间内未收到客户端的心跳信息，则认为服务不可用并注销该服务，其他正常的集群节点的服务发现和注册仍然可用。

进一步地，所述调用接口时主动捕捉异常，判断服务是否正常即数据是否可以写入，若捕捉到异常则写入服务不可用，重新发送请求，若重复发送超过一定次数，判断该微服务节点为不可用，则从集群获取其他可用节点地址并调用接口验证是否可用。

本发明单一进程的流式数据计算中执行调度任务并避免数据丢失的系统，包括：数据接入模块，用于采用流式计算引擎实时消费分布式消息队列中的数据，启用检查点机制，计算数据节点，生成数据流至最末端数据节点；

数据计算模块，用于从服务发现框架集群的服务注册中心获取微服务地址并缓存至内存中；若获取失败，则目前无任一节点可用，按照一定的重试间隔继续获取服务地址，若服务提供者恢复心跳信息且重新注册，则从服务注册中心成功获取服务地址；

数据写入模块，用于调用接口写入数据并主动捕捉异常，判断服务是否正常即数据是否可以写入；若捕捉到异常即写入失败，重新发送请求判断该微服务节点不可用，从集群获取其他可用节点地址，并调用接口验证该节点是否可用。

一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现以下步骤：

步骤一：流式计算引擎实时消费分布式消息队列中的数据，启用检查点机制，计算数据节点，生成数据流至最末端数据节点；

步骤二：判断缓存中是否存在写入微服务地址，若存在进入步骤三；若不存在，从服务发现框架集群的服务注册中心获取微服务地址，获取成功后缓存至内存中，执行步骤三；若获取失败，休眠后重试，一直到从服务注册中心获取微服务地址成功；

步骤三：调用接口发送请求写入数据并主动捕捉异常，判断服务是否正常即数据是否可以写入；若捕捉到异常即写入失败，重新发送请求判断该微服务节点不可用；从集群获取其他可用节点地址，并调用接口验证是否可用。

本发明与现有技术相比，其显著优点：本发明利用服务发现框架提供的服务发现注册功能将实时统计数据通过微服务的应用程序接口写入外部存储，通过重试机制结合分布式流式计引擎的背压机制、服务发现框架的高可用特性以及消息队列的可重放机制来避免数据丢失。

附图说明

图1是本发明实施例采用的Flink背压机制的流程图。

图2是本发明实施例采用的Flink检查点机制的流程图。

图3是本发明实施例采用的Kafka可重放机制的流程图。

图4是本发明实施例采用的Eureka高可用及分区一致性的原理图。

图5是本发明实施例的技术架构图。

图6是本发明实施例的方案流程图。

具体实施方式

对于海量实时数据持久化至外部存储存在数据丢失的问题，本发明的方案采用微服务提供应用程序接口作为数据写入的入口并注册至服务发现框架集群，流式计算引擎从服务发现框架获取数据写入的服务地址并调用应用程序接口进行数据持久化。在此基础上增加服务异常捕捉及休眠重试方案，利用流式计算引擎的背压机制、分布式消息队列中消息数据的可重放特性以及服务发现框架的高可用机制避免了实时数据的丢失。

使用本发明提供的技术方案，具有多重保证如下：

A、流式计算引擎的背压机制：流式计算引擎中的任务管理器会定时对数据节点的缓冲区进行数据采样来判断是否有数据堆积，当发生数据堆积时会减缓整个节点链路的数据处理速度来适配最慢的节点。

B、流式计算引擎的刚好处理一次语义：在启用了流式计算引擎的检查点机制之后，会在检查点机制时将消息队列的消费数据偏移量及各个数据节点中的缓存数据持久化到分布式文件系统中，在从检查点机制中恢复时可以完整回溯到当时的数据节点状态。

C、分布式消息队列的可重放机制：分布式消息队列将数据持久化到磁盘来提供消息的可重放机制，提供消息偏移量可获取历史数据，为消费系统提供了数据保障。

D、服务发现框架的高可用机制以及分区一致性：微服务向服务发现框架注册服务后，节点之前会互相同步注册信息，服务使用者从任意一个服务注册中心都可获取服务地址。若集群在一定时间内未收到客户端的心跳信息则认为服务不可用并注销该服务，其他正常的集群节点的服务发现和注册仍然可用。

E、重试机制：为了充分利用以上四种数据保障机制，在调用接口时主动捕捉异常来判断服务是否正常即数据是否可以写入，并设置重试及重新获取服务地址的机制来保证避免数据丢失。

基于以上机制来避免数据丢失的方案如下：

步骤一：使用流式计算引擎实时消费分布式消息队列中的数据，启用检查点机制，通过一系列数据节点的计算，生成数据流至最末端数据节点；

步骤二：在数据节点中，先从服务发现框架集群的服务注册中心获取微服务地址并缓存至内存中，若获取失败则代表目前没有任一节点可用，按照一定的重试间隔一直尝试获取服务地址，若服务提供者恢复心跳信息且重新注册后，从服务注册中心会成功获取到服务地址；

步骤三：在成功获取服务地址后，调用接口写入数据，若捕捉到异常即写入服务不可用，重新发送请求判断非网络波动，即判断该微服务节点不可用，尝试从集群获取其他可用节点地址并调用接口验证是否可用，此过程中会延缓从消息队列消费数据的速度，避免数据丢失。

进一步地，整个数据链路包含了数据接入、数据计算、数据写入三个过程，前两个过程不涉及数据的丢失，在单一进程中按照如下步骤处理数据：

步骤一：初始化内存空间分别用于缓存当前数据节点中的成功数、失败数及获取到的服务地址；假设成功数阈值设置为10w，失败数阈值设置为100；

步骤二：判断缓存中是否存在写入微服务地址，若存在进入步骤三；若不存在则需访问服务注册中心获取服务地址，获取成功后将服务地址缓存至内存，进入步骤三；若获取失败休眠后重试，一直到从服务注册中心获取地址成功。

步骤三：从缓存中获取服务地址，调用接口发送请求写入数据，若请求成功，成功计数加一且判断成功数是否大于10w，若大于10w回到步骤二重新获取服务地址，若小于10w则从缓冲区中拉取下一条数据从步骤二进入；若请求失败，失败计数加一并判断失败数是否大于100，若小于100则休眠后重新调用接口写入，写入成功后将失败数清0拉取下一条数据；若失败数大于100则回到步骤二重新从服务注册中心获取服务地址，失败数清0，成功获取地址后重新调用接口写入数据。

下面结合实施例和说明书附图对本发明作进一步说明。

Flink是目前最为流行的实时流处理计算引擎，对于海量实时数据持久化至外部存储存在数据丢失的问题，本发明实施例的方案采用微服务提供Restful⑨接口供数据写入并注册至Eureka集群，Flink从Eureka获取写入服务地址并调用接口进行数据持久化。在此基础上增加服务异常捕捉及休眠重试方案，利用Flink的背压机制、Kafka的可重放特性以及Eureka的高可用机制避免了实时数据的丢失。

本发明的实施例方案，提供了如下的多重保证：

A、Flink的背压机制：Flink中的Job管理器会定时对数据节点的缓冲区进行数据采样来判断是否有数据堆积，当堆积发生时会减缓整个节点链路的数据处理速度来适配最慢的节点。(见附图1)

B、Flink的每条数据仅且处理一次语义：在启用了Flink的检查点机制之后，会在检查点机制时将kafka 消息偏移量及各个数据节点中的缓存数据持久化到HDFS中，在从检查点机制中恢复时可以完整回溯到当时的数据节点状态。(见附图2)

C、Kafka的可重放机制：Kafka作为分布式消息系统，将数据持久化到磁盘来提供消息的可重放机制，提供消息偏移量可获取历史数据，为消费系统提供了数据保障。 ( 见附图 3)

D、Eureka的高可用机制以及分区一致性：微服务向Eureka注册服务后，节点之前会互相同步注册信息，服务使用者从任意一个服务注册中心都可获取服务地址。若Eureka在一定时间内未收到Eureka客户端的心跳信息则认为服务不可用并注销该服务，其他正常的Eureka节点的服务发现和注册仍然可用。(见附图4)

E、重试机制：为了充分利用以上四种数据保障机制，在调用接口时主动捕捉异常来判断服务是否正常即数据是否可以写入，并设置重试及重新获取服务地址的机制来保证避免数据丢失。

基于以上机制来避免数据丢失的本发明的技术方案如下(技术架构图见附图5)：

步骤一：使用Flink实时消费Kafka中的数据，启用检查点机制，通过一系列数据节点的计算，生成数据流至最末端数据节点；

步骤二：在数据节点中，先从Eureka服务注册中心获取微服务地址并缓存至内存中，若获取失败则代表目前没有任一节点可用，按照一定的重试间隔一直尝试获取服务地址，若服务提供者恢复心跳信息且重新注册后，从Eureka会成功获取到服务地址；

步骤三：在成功获取服务地址后，调用接口写入数据，若捕捉到异常即写入服务不可用，重新发送请求判断非网络波动即判断该微服务节点不可用，尝试从Eureka获取其他可用节点地址并调用接口验证是否可用，此过程中会延缓从Kafka消费数据的速度，避免数据丢失。

本发明实施例单一进程的流式数据计算中执行调度任务并避免数据丢失的系统，包括：

数据接入模块，用于采用Flink实时消费Kafka中的数据，启用检查点机制，计算数据节点，生成数据流至最末端数据节点；

数据计算模块，用于从Eureka服务注册中心获取微服务地址并缓存至内存中，若获取失败，则目前无任一节点可用，按照一定的重试间隔继续尝试获取服务地址，若服务提供者恢复心跳信息且重新注册，从Eureka成功获取到服务地址；

数据写入模块，用于调用接口写入数据并主动捕捉异常，判断服务是否正常即数据是否可以写入；若捕捉到异常则写入服务不可用，重新发送请求判断非网络波动，即判断该微服务节点不可用；从Eureka获取其他可用节点地址并调用接口验证是否可用。

如图6所示，本发明实施例单一进程的流式数据计算中执行调度任务并避免数据丢失的方法，整个数据链路包含了数据接入、数据计算、数据写入三个过程，前两个过程不涉及数据的丢失，在单一进程中按照如下步骤处理数据：

步骤一：初始化内存空间分别用于缓存当前数据节点中的成功数、失败数及获取到的服务地址；假设成功数阈值设置为10w，失败数阈值设置为100；

步骤二：判断缓存中是否存在写入微服务地址，若存在进入步骤三；若不存在则需访问Eureka获取服务地址，获取成功后将服务地址缓存至内存，进入步骤三；若获取失败休眠后重试，一直到从Eureka获取地址成功。

步骤三：从缓存中获取服务地址，调用接口发送请求写入数据，若请求成功，成功计数加一且判断成功数是否大于10w，若大于10w回到步骤二重新获取服务地址，若小于10w则从缓冲区中拉取下一条数据从步骤二进入；若请求失败，失败计数加一并判断失败数是否大于100，若小于100则休眠后重新调用接口写入，写入成功后将失败数清0拉取下一条数据；若失败数大于100则回到步骤二重新从Eureka获取服务地址，失败数清0，成功获取地址后重新调用接口写入数据。

现在大部分采用流式计算框架在实时数据写入时没有完善的重试机制，造成实时数据的丢失导致统计指标的缺失。

使用本发明的技术方案可以大幅降低实时数据计算过程中数据丢失的风险，使用 了500w数据量在以下场景进行了测试：

测试场景	源数据量	优化前数据丢失量	优化后丢失数据量
				数据库服务10s内不可用	500w	300w	0
流式计算引擎节点重启	500w	200w	0
				数据库写入超过2s	500w	10w	0
数据库主备节点切换	500w	150w	0

通过测试结果可以看到使用本方案优化之后，各种场景下的丢失数据量都为0，极大降低了数据丢失的风险。

综上所述，在休眠过程中会使当前数据节点不能及时从上一个数据节点的缓冲区中拉取数据，造成上个数据节点缓冲区堆积，进而使整个数据节点链路的速度都会减慢，从消息队列获取数据也会减缓，若此过程中当前任务失败后，任务管理器会自动重启并从检查点中恢复数据，避免了数据丢失。本发明的方案主要解决了实时统计数据写入时数据丢失的问题。

Claims (9)

1.一种单一进程的流式数据计算中执行调度任务并避免数据丢失的方法，其特征在于：

采用微服务提供应用程序接口供数据写入并注册至服务发现框架集群，流式计算引擎从服务发现框架获取数据写入的服务地址，并调用应用程序接口进行数据持久化，同时实施服务异常捕捉及休眠重试方案；具体步骤如下：

步骤一：流式计算引擎实时消费分布式消息队列中的数据，启用检查点机制，计算数据节点，生成数据流至最末端数据节点；

步骤二：判断缓存中是否存在写入微服务地址，若存在进入步骤三；若不存在，从服务发现框架集群的服务注册中心获取微服务地址，获取成功后缓存至内存中，执行步骤三；若获取失败，休眠后重试，一直到从服务注册中心获取微服务地址成功；

步骤三：调用接口发送请求写入数据并主动捕捉异常，判断服务是否正常即数据是否可以写入；若捕捉到异常即写入失败，重新发送请求判断微服务节点不可用；从集群获取其他可用节点地址，并调用接口验证是否可用。

2.如权利要求1所述的方法，其特征在于：所述流式计算引擎中的任务管理器定时对数据节点的缓冲区进行数据采样，并判断是否有数据堆积，若发生堆积，则减缓整个节点链路的数据处理速度来适配最慢的节点。

3.如权利要求1所述的方法，其特征在于：启用所述流式计算引擎的检查点机制，触发检查点机制时，将消息队列的消息偏移量及各个数据节点中的缓存数据持久化到分布式文件系统中。

4.如权利要求1所述的方法，其特征在于：所述分布式消息队列将数据持久化到磁盘，用以提供消息偏移量来获取历史数据。

5.如权利要求1所述的方法，其特征在于：微服务向所述服务发现框架注册服务后，节点之间互相同步注册信息，从任意一个服务注册中心均可获取服务地址；若集群在规定时间内未收到客户端的心跳信息，则认为服务不可用并注销该服务，其他正常的集群节点的服务发现和注册仍然可用。

6.如权利要求1所述的方法，其特征在于：所述调用接口时主动捕捉异常，判断服务是否正常即数据是否可以写入，若捕捉到异常则写入服务不可用，重新发送请求，若重复发送超过规定次数，判断该微服务节点为不可用，则从集群获取其他可用节点地址并调用接口验证是否可用。

7.一种单一进程的流式数据计算中执行调度任务并避免数据丢失的系统，其特征在于，采用微服务提供应用程序接口供数据写入并注册至服务发现框架集群，流式计算引擎从服务发现框架获取数据写入的服务地址，并调用应用程序接口进行数据持久化，同时实施服务异常捕捉及休眠重试方案，包括：

数据接入模块，用于采用流式计算引擎实时消费分布式消息队列中的数据，启用检查点机制，计算数据节点，生成数据流至最末端数据节点；

数据计算模块，用于从服务发现框架集群的服务注册中心获取微服务地址并缓存至内存中；若获取失败，则目前无任一节点可用，按照规定的重试间隔继续获取服务地址，若服务提供者恢复心跳信息且重新注册，则从服务注册中心成功获取服务地址；

数据写入模块，用于调用接口写入数据并主动捕捉异常，判断服务是否正常即数据是否可以写入；若捕捉到异常即写入失败，重新发送请求判断微服务节点不可用，从集群获取其他可用节点地址，并调用接口验证该节点是否可用。

8.根据权利要求7所述的系统，其特征在于：所述数据写入模块，用于调用接口写入数据并主动捕捉异常，判断服务是否正常即数据是否可以写入；若捕捉到异常则写入服务不可用，重新发送请求，若重复发送超过规定次数，判断该微服务节点为不可用，则从集群获取其他可用节点地址并调用接口验证是否可用。

9.一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至6中任一项所述方法的步骤。

Images