CN107577717B - 一种保障数据一致性的处理方法、装置及服务器 - Google Patents

Abstract

本说明书实施例公开了一种保障数据一致性的处理方法、装置及服务器。所述方法包括：记录数据源的每个队列中数据处理的事件时间。当出现异常时，数据源的所有队列可以回滚到最近一次处理成功的状态，可以通过事件时间将数据源的各队列回退并对齐到一个一致的处理成功的监控计算窗口时间节点。

Description

一种保障数据一致性的处理方法、装置及服务器

技术领域

本说明书实施例属于计算机数据处理技术领域，尤其涉及一种保障数据一致性的处理方法、装置及服务器。

背景技术

随着互联网的发展，许多互联网系统所涉及的业务也越来越多，系统处理的业务数据量剧增。目前，一些业务系统通常会相应的配置有业务监控系统，可以实时监控业务系统的异常情况。

业务监控系统可以监控业务数据异常，例如交易下跌等，作为一种告警、分析系统的底层基础数据处理，任何的数据丢失或者数据重复都会给告警，分析产生影响，所以数据的一致性十分重要，对数据一致性要求非常高。为保障实时监控系统中数据的一致性，常用的一种方式包括Flink的分布式快照算法，该算法采用检查点机制+可部分重发的数据源的方式达到一致性功能。Flink的分布式快照算法通过批次的方式保障数据一致性，这种算法需要高可用的状态存储引擎(例如hbase或者hdfs，hbase和hdfs为一种数据存储服务)存储快照数据，在异常时，源头会回滚到上一次状态，要保证全局一致性，merger(状态数据节点)的存储也要回滚到上一次一致性状态，这里的存储状态必须是高可用的，需要较高的技术和硬件实现成本，并且面对类似监控这样的海量数据场景，推广难度也较大。因此，业内需要一种适合于监控场景并且成功更低的数据一致性保障方案。

发明内容

本说明书实施例目的在于提供一种保障数据一致性的处理方法、装置及服务器，可以适用于业务数据监控场景中保障数据处理的一致性，降低对高可用状态的存储引擎的依赖，降低成本，提高系统稳定性和吞吐量。

本说明书实施例提供的一种保障数据一致性的处理方法、装置及服务器是包括如下的方式实现的：

一种保障数据一致性的处理方法，所述方法包括：

记录数据源节点的队列的事件时间，所述事件时间包括队列从所述数据源节点读取数据的时间；

若接收到数据处理失败的触发消息，则基于所述事件时间确定所述数据源节点的队列上一次数据处理成功的监控计算窗口时间节点；

以所述监控计算窗口时间节点作为数据源节点的队列的统一回退时间点重新读取数据源的数据。

一种保障数据一致性的处理装置，所述装置包括：

事件时间记录模块，用于记录数据源节点的队列的事件时间，所述事件时间包括队列从所述数据源节点读取数据的时间；

重读取时间确定模块，用于在接收到数据处理失败的触发消息时，基于所述事件时间确定所述队列在上一次数据处理成功的监控计算窗口时间节点；

数据读取模块，用于以所述监控计算窗口时间节点作为数据源节点的队列的统一回退时间点重新读取数据源的数据。

一种保障数据一致性的处理装置，包括处理器以及用于存储处理器可执行指令的存储器，所述处理器执行所述指令时实现：

记录数据源节点的队列的事件时间，所述事件时间包括队列从所述数据源节点读取数据的时间；

若接收到数据处理失败的触发消息，则基于所述事件时间确定所述队列在上一次数据处理成功的监控计算窗口时间节点；

以所述监控计算窗口时间节点作为数据源节点的队列的统一回退时间点重新读取数据源的数据。

一种服务器，包括至少一个处理器以及用于存储处理器可执行指令的存储器，所述处理器执行所述指令时实现：

记录数据源节点的队列的事件时间，所述事件时间包括队列从所述数据源节点读取数据的时间；

若接收到数据处理失败的触发消息，则基于所述事件时间确定所述队列在上一次数据处理成功的监控计算窗口时间节点；

以所述监控计算窗口时间节点作为数据源节点的队列的统一回退时间点重新读取数据源的数据。

本说明书一个或多个实施例提供的一种保障数据一致性的处理方法、装置及服务器，结合了业务数据监控场景的监控计算窗口较小的特点，可以记录数据源的每个队列中数据处理的事件时间。当出现异常时，数据源的所有队列可以回滚到最近一次处理成功的状态，可以通过事件时间将数据源的各队列回退并对齐到一个一致的处理成功的监控计算窗口时间节点，避免了对高可用存储快照状态的存储引擎的依赖，使用本地磁盘或者内存等就可以达到保障数据一致性计算的能力，大大减少计算成本和数据存储成本。同时，由于舍弃了保留快照状态的高可用存储引擎，实施本申请方案还可以减少与高可用存储的网络交互，减少外界系统依赖，提高系统稳定性以及吞吐量。

附图说明

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

图1是本说明书提供的所述一种保障数据一致性的处理方法实施例的流程示意图；

图2是本说明书所述方法在一种监控场景实施例中的处理过程示意图；

图3是本说明书提供的所述方法的另一个实施例的方法流程示意图；

图4是本说明书提供的所述方法的另一个实施例的方法流程示意图；

图5是本说明书提供的一种保障数据一致性的处理装置实施例的模块结构示意图；

图6是本说明书提供的所述装置另一个实施例的模块结构示意图；

图7是本说明书提供的所述装置中重读取时间确定模块一个实施例的模块结构示意图；

图8是本本说明书提供的所述装置另一个实施例的模块结构示意图；

图9是本说明书提供的所述服务器一个实施例的结构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本说明书中的技术方案，下面将结合本说明书一个或多个实施例中的附图，对本说明书一个或多个实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是说明书一部分实施例，而不是全部的实施例。基于说明书一个或多个实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本说明书实施例方案保护的范围。

常规的Flink的分布式快照算法，采用检查点机制+可部分重发的数据源的方式达到一致性功能。一般的，主要的实施过程包括检查点定期触发，产生快照，快照中记录了当前检查点开始时数据源(例如Kafka，一种高吞吐量的分布式发布订阅消息系统)中消息的offset(偏移量)，以及记录了所有有状态的operator(操作者)当前的状态信息(例如sum中的数值)。Flink可以选择最近完成的检查点K，然后系统重放整个分布式的数据流，给予每个operator在检查点K快照中的状态信息。数据源被设置为从偏移量位置Sk开始重新读取流。在异常时，数据源会回滚到上一次状态，要保证全局一致性，merger节点(状态数据节点)的存储也要回滚到上一次一致性状态。这种算法需要保证快照高可用，所以通常hbase或者hdfs作为这种算法的首选存储引擎。

所述的merger在flink方案中为状态数据节点，可以用于状态数据的存储读取合并等，通常实时计算中，可以连接hbase或者hdfs等高可用存储。在本说明书的一个或多个实施例中，可以使用本地磁盘替代为非高可用存储，大幅降低成本，并减少与外部存储引擎的交互，使得系统更加稳定、可靠，减少交互消耗，可以提高系统吞吐量。

本说明书提供的一个或多个障数据一致性的处理方法的实施例方案中，可以基于flink分布式快照的实现，结合监控场景的特有特点，(监控计算窗口小，通常只计算一分钟数据，一旦一分钟的数据完整，在一些实施例中这分钟的快照状态就可以丢弃，不需要高可用的存储引擎进去保留)提出了一套新的适合于监控场景的新的一致性解决方案，该方案能够保证数据处理一致性，而且可以不依赖于高可用的状态存储引擎，有效降低成本。所述的高可用，一般指发生任务异常时，不会发生数据丢失现象，数据可以被恢复，通常需要高成本的技术和硬件实现。

下面以一个业务数据监控场景对本说明书的一个或多个实施例方案进行详细说明。需要说明的是，本说明书实施方案不限于监控场景的实施应用，在其他的实施场景中，例如一些以单位量级较小的计算窗口(如分钟级、秒级等)来保障数据一致性的数据实时计算场景同样可以使用本说明书实施例所提供的实施方案。另外，在本实施例实施场景中，所述的一致性，可以表示数据被执行方处理且被处理一次，数据不重复处理，数据不丢失。所述的监控系统通常包括计算日志的分钟或者秒级数据，与历史趋势进行对比，校验是否系统发生异常的处理系统。所述的状态数据通常包括实时计算中，未计算最终结果前而产生的中间结果，例如，现在时间21点30分，需要计算21点-22点的小时的用户数，21点30分计算/或的数据状态为21点-22点计算窗口内的状态数据。

图1是本说明书提供的所述一种保障数据一致性的处理方法实施例的流程示意图。虽然本说明书提供了如下述实施例或附图所示的方法操作步骤或装置结构，但基于常规或者无需创造性的劳动在所述方法或装置中可以包括更多或者部分合并后更少的操作步骤或模块单元。在逻辑性上不存在必要因果关系的步骤或结构中，这些步骤的执行顺序或装置的模块结构不限于本说明书实施例或附图所示的执行顺序或模块结构。所述的方法或模块结构的在实际中的装置、服务器或终端产品应用时，可以按照实施例或者附图所示的方法或模块结构进行顺序执行或者并行执行(例如并行处理器或者多线程处理的环境、甚至包括分布式处理、服务器集群的实施环境)。

具体的一个实施例如图1所示，本说明书提供的一种保障数据一致性的处理方法的一种实施例中，所述方法可以包括：

S2：记录数据源节点的队列的事件时间，所述事件时间包括队列从所述数据源节点读取数据的时间。

在本实施例中，数据源节点可以从数据源中读取(拉取)数据，以使数据被相应的处理方消费，例如查询用户数量。本实施例实施场景中，可以以分钟为监控计算窗口，即在监控从数据源读取的数据是否出现异常时，以一分钟为统计单位，计算一分钟窗口内的数据，判断这一分钟内是否有数据异常。如果监控的这一分钟内从数据源节点读取的各个队列的数据均被正常处理，没有出现数据处理失败的现象，则这一分钟(监控计算窗口)的监控任务完成，可以继续下一分钟(下一个监控计算窗口)的数据监控。数据源节点可以从一个或多个数据源中读取数据，例如在本实施例应用场景中，spout可以为数据源节点，可以从TT和SLS(TT为Time Tunnel的简称，、SLS为Simple Log Service的简称，TT和SLS分别为一种日志系统，可以提供可重新拉取数据的能力)中拉取数据。一般的，从所述数据源节点spout可以读取不同数据源的数据，如前述TT和SLS中的数据。拉取数据时，可以根据不同的数据源或不同的业务需求或拉取的不同类型的数据等分成不同的队列(queue)进行数据处理。例如spout从TT中拉取的数据可以为一个消息队列，spout从SLS中拉取的数据可以为另一个消息队列。因此，一种实施场景中，数据源节点spout可以包括多个队列。

可以记录数据源节点中所有队列中数据的事件时间(eventTime)，包括数据读取、消费、转移、合并等处理的事件，可以记录这些事件的事件时间。其中，所述的事件时间至少包括队列从所述数据源节点读取数据的时间，或者可以理解为记录队列每次从所述数据源节点拉取数据的时间点。记录的方式可以包括采用单独/专用的记录事件时间的装置。在本实施例实施场景中，可以采用数据源节点spout记录每个队列的事件时间。

图2是本说明书所述方法在一种监控场景实施例中的处理过程示意图。在数据正常处理时，每一个数据批次处理成功，数据源节点spout都会记录每个queue(队列)的事件时间eventTime。Mapper(数据转换节点)以及reducer(前置合并节点)进行正常的业务处理，merger节点则将状态数据持久化到本地磁盘normal db中。所述的Mapper在实施例实施场景中可以为数据转换节点，可以提供数据过滤、转换的等能力。normal db可以为本地常规的数据库，如本地磁盘。

S4：若接收到数据处理失败的触发消息，则基于所述事件时间确定所述数据源中的队列上一次数据处理成功的监控计算窗口时间节点。

如果收到数据处理失败的触发消息，则可以表示监控到了数据处理出现异常情况。一般的，所述的异常情况主要包括业务数据处理失败，在本实施例中，所述的异常情况还可以包括系统内部错误、外部服务器故障(宕机)以及其他设置的异常告警情况。这些异常情况通常导致的结果(或数据监控的响应)包括数据处理失败。因此，在本实施例实施场景中，当收到数据处理失败的触发消息时，可以进行全局数据的回滚，保障数据的一致性。

在异常情况下，可以将数据源节点的各个队列回滚到最近一次数据处理成功的批次，每个数据处理批次对应相应的事件时间。如图2中所示，监控数据源节点从TT拉取的数据处理时出现异常情况，则数据源节点spout将从TT中拉取数据的4个队列q0、q1、q2、q3分别回滚到最近一次成功处理的批次，此时数据源节点的最近数据成功处理批次包括：

q0 2017-05-09 00:00:30

q1 2017-05-09 00:01:15

q2 2017-05-09 00:00:15

q3 2017-05-09 00:00:35

若按照常规的flink分布式快照解决方案，则需要分别上述4个时间点重拉数据，并将merger节点的快照状态从高可用存储引擎中取回，以达到数据一致性状态。而在本实施例的数据监控场景下，因为是以一分钟为监控计算窗口，由上述事件时间中记录的数据源节点最近数据成功处理批次的时间点可以看出，在出现异常情况的TT的4个队列中，所有的队列的数据处理都已经在2017-05-09 00:00:00之后，并且数据按照时间顺序增长，所以2017-05-0823:59:00-2017-05-09 00:00:00这一分钟的监控计算窗口内的数据是完整的。但是还不确定2017-05-09 00:00:00-2017-05-09 00:01:00的数据是否完整，因为有部分队列的数据处理还在这个监控计算窗口内，还没有超过2017-05-09 00:01:00，不能确定这一分钟该队列的数据是否已经正常处理完成，例如队列q0 2017-05-09 00:00:30。

上一次数据处理成功的监控计算窗口时间节点可以从多种数据分析中确定。例如可以根据所有队列消费的偏移量来确定当前监控计算窗口以及上一个监控计算窗口的时间节点，或者可以设计一个专门统计事件时间然后计算各个监控计算窗口的装置等。本说明书提供的所述方法的一个实施例中，在数据监控的实施场景中，所述基于所述事件时间确定所述数据源节点的队列上一次数据处理成功的监控计算窗口时间节点可以包括：

S400：获取所述数据源中队列上一次数据处理成功的时间点，根据所述时间点中队列消费的偏移量确定上一个监控计算窗口的时间节点。

本说明书所述方法的另一个实施例中，还可以采用将数据源节点的队列时间取最小并且格式化到健康计算窗口的方式来确定所述上一次数据处理成功的监控计算窗口时间节点。具体的，所述方法的另一个实施例中，所述基于所述事件时间确定所述队列在上一次数据处理成功的监控计算窗口时间节点可以包括：

S402：获取所述数据源中队列上一次数据处理成功的时间点，对所述时间点中时间最早的时间点进行所述监控计算窗口时间单位级别的格式化，得到所述上一次数据处理成功的监控计算窗口时间节点。

例如数据源节点的最近数据成功处理批次包括：

q0 2017-05-09 00:00:30

q1 2017-05-09 00:01:15

q2 2017-05-09 00:00:15

q3 2017-05-09 00:00:35

可以取队列时间最小的q0 2017-05-09 00:00:30时间点。由于是以分钟为监控计算窗口，因此，可以q0 2017-05-09 00:00:30格式化到分钟，即将分钟量级以下的时间单位：秒、毫秒(如果有)全部设置为0，得到2017-05-09 00:00:00，即为所述上一次数据处理成功的监控计算窗口时间节点，可以表示2017-05-09 00:00:00之前的数据是完整、准确的，之后的数据是不确定是否完整的。这样，采用本实施例方案可以更加快速的确定所述上一次数据处理成功的监控计算窗口时间节点，提高保障数据一致性的处理效率。

S6：以所述监控计算窗口时间节点作为数据源节点的队列的统一回退时间点重新读取数据源的数据。

在确定了所述数据源节点的所有队列上一次(最近一次)数据处理成功的监控计算窗口时间节点后，可以以监控计算窗口为划分单位找到数据完整和不确定是否完整的时间节点。然后将数据源节点下的各个队列统一回到该时间节点，使数据源对齐，数据源节点重新拉取数据源的数据，从而实现可以不需要高可用的快照状态存储引擎即可实现保障数据一致性计算的能力。

例如在图2所示的实施例场景中，在当前监控计算窗口2017-05-09 00:00:00-2017-05-0900:01:00出现异常情况，由于可以确定2017-05-08 23:59:00分数据是完整计算的、准确的，因此可以根据记录的各个队列的事件时间确定上一个数据正常成功处理的监控计算窗口的时间节点，然后可以设置数据源节点将所有队列从该时间节点2017-05-0900:00:00重新拉取数据，2017-05-09 00:00:00之后的数据都会重新计算，如图2所示的LSL一侧的数据源节点spout同样会从2017-05-09 00:00:00重新读取SLS中的数据。所述的数据源对齐可以包括在数据源节点处使各个队列拉取数据的数据源对齐，例如上述实施场景中当出现异常情况时，不管是TT还是SLS中的所有队列都退回到一个一致的时间节点，如上述的2017-05-0900:00:00，然后所有队列重新拉取数据。

进一步的，本说明书还提供所述方法的另一个实施例，还可以对重新从数据源读取的数据进行时间的过滤，删除统一回退时间点之前的数据，进一步保障统一回退时间点之前的数据不会覆盖写。具体的，本说明书所述方法的另一个实施例中，重新读取所述数据源的数据之后，所述方法还可以包括：

S8：以所述统一回退时间点对所述重新读取数据源节点的数据进行过滤，删除所述统一回退时间点之前的数据。

图3是本说明书提供的所述方法的另一个实施例的方法流程示意图。例如在前述实施例实施场景中，mapper节点可以进行一次2017-05-09 00:00:00时间的过滤，保证2017-05-0900:00:00之前的数据不会覆盖写，如图2中SLS的mapper的处理。当然，本说明书其他的实施例中也可以使用其他带有过滤数据功能的数据采集工具替代mapper节点的过滤功能。

上述实施例描述的实施场景中，重新拉取数据可能会过滤掉一些边界数据。为防止数据污染，比如用偏移量2017-05-09 00:00:00拉取数据，可能会获得少量2017-05-0823:59:59的数据，这部分会污染之前已经完整的2017-05-08 23:59:00的部分数据，因此本实施例可以采用数据在统一回退时间点2017-05-09 00:00:00处进行过滤。当然，本说明书不排除在其他的实施例中，如果数据采集系统(如TT或SLS)能确保过滤掉这部分边界数据，则可以不需要例如在mapper节点进行过滤的实施方式。

如前述所述，正常情况时，每一个批次处理成功，数据源节点spout记录每个queue(队列)的事件时间eventTime。Mapper以及reducer进行正常的业务处理，merger节点则将状态数据持久化到本地磁盘normal db中。所述的本地磁盘可以作为数据库来存储状态数据，例如作为merger节点存储状态数据，本说明书的一些实施例中可以存储数据源的各个队列的偏移量，以实现根据偏移量实现数据源对齐。采用本地磁盘持久化处理数据的状态数据，可以在出现异常时进行状态回滚，进而确定数据源节点的各个队列最近一次成功数据处理的时间点。如果在当前监控计算窗口内，如计算一分钟的数据，如果确定监控的一分钟的数据是完整的、准确的，则这一分钟的状态数据可以继续持久化，存储在数据库中。在监控场景下，状态数据是一种未监控计算完的那些分钟的数据，是一种临时数据，非终态数据，因此，在一些实施例中当确定某一个监控计算窗口内的数据是完整、准确的之后，在监控下一个监控计算窗口或出现异常重新读取数据源的数据时也可以丢弃(删除掉)本地持久化的状态数据。所述的状态数据可以包括前述所述的事件时间，如2017-05-09 00:00:00至2017-05-09 00:01:00这一分钟的监控计算窗口内，数据源节点所有队列拉取数据以及数据处理等产生的具体的状态数据可以被本地持久化，可以属于本地磁盘存储。具体的，图4是本说明书提供的所述方法的另一个实施例的方法流程示意图，如图4所示，所述方法还可以包括：

S10：本地持久化当前监控计算窗口内处理成功的数据的状态数据；以及，

在重新读取所述数据源的数据之后，删除本地持久化的状态数据，并本地持久化所述重新读取数据源的数据被处理的状态数据。

如图2所示的实施场景中，merger节点可以将本地磁盘状态丢弃(删除)，重新启动一个新的db(没有数据)，因为2017-05-09 00:00:00之后的数据都会重新计算，可以保证完整性。

上述实施例中可以使用磁盘做数据库，作为merger节点状态存储。其他的实施方式中，也可以使用内存数据库作为merger节点状态存储。当然，本说明书不排除其他的实施例中可以采取其他存储介质来存储状态数据。因此，本说明书所述方法的另一个实施例中，可以使用磁盘或内存数据存储所述状态数据。具体的实施场景中，可以使用磁盘或内存数据库这些低成本的存储作为merger节点状态存储。

这样，本说明书的一个或多个实施例方案通过数据源对齐(数据源各队列偏移量进行对齐，如上述一个实施例方案是使用本地磁盘作为存储)，可以通过mapper过滤的方式，舍弃了高可用存储的使用，大大降低了成本。并且，使用磁盘或内存数据库等本地持久化的存储方式可以减少与高可用存储的网络交互，减少外界系统依赖，提高稳定性以及吞吐量。在一个实际的产品应用中实施后，可减少75％状态数据存储成本。由此可见，实施本说明书的一个或多个实施方案，可以实现只需要本地磁盘甚至内存就可以达到保障数据一致性计算的能力的同时，大大减少计算成本。

根据前述实施例描述，还可以包括其他更多实施方式本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。具体的可以参照相关实施例的描述，在此不做一一赘述。

本说明书实施例提供的保障数据一致性的处理方法不仅可以监控场景，一些小窗口的计算(分钟级，秒级)统一可以通过数据源回退对齐到一个一致的时间点，mapper节点过滤这个时间点前的数据，merger节点可以不需要高可用快照状态，可以通过本地磁盘甚至内存就可以达到一致性计算的能力，大大减少计算成本。其解决问题的实现方案与监控场景中保障数据一致性方法的处理相似，因此应用在其他实施场景中具体的实施方案可以参见前述监控场景中保障数据一致性方法的实施例描述，重复之处不再赘述。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

本说明书一个或多个实施例提供的一种保障数据一致性的处理方法，结合了业务数据监控场景的监控计算窗口较小的特点，可以记录数据源的每个队列中数据处理的事件时间。当出现异常时，数据源的所有队列可以回滚到最近一次处理成功的状态，可以通过事件时间将数据源的各队列回退并对齐到一个一致的处理成功的监控计算窗口时间节点，避免了对高可用存储快照状态的存储引擎的依赖，使用本地磁盘或者内存等就可以达到保障数据一致性计算的能力，大大减少计算成本和数据存储成本。同时，由于舍弃了保留快照状态的高可用存储引擎，实施本申请方案还可以减少与高可用存储的网络交互，减少外界系统依赖，提高系统稳定性以及吞吐量。

基于上述所述的保障数据一致性的处理方法，本说明书一个或多个实施例还提供一种保障数据一致性的处理装置。所述的装置可以包括使用了本说明书实施例所述方法的系统(包括分布式系统)、软件(应用)、模块、组件、服务器、客户端等并结合必要的实施硬件的装置。基于同一创新构思，本说明书实施例提供的一个或多个实施例中的装置如下面的实施例所述。由于装置解决问题的实现方案与方法相似，因此本说明书实施例具体的装置的实施可以参见前述方法的实施，重复之处不再赘述。以下所使用的，术语“单元”或者“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。具体的，图5是本说明书提供的一种保障数据一致性的处理装置实施例的模块结构示意图，如图5所示，所述装置可以包括：

事件时间记录模块101，可以用于记录数据源节点的队列的事件时间，所述事件时间包括队列从所述数据源节点读取数据的时间；

重读取时间确定模块102，可以用于在接收到数据处理失败的触发消息时，基于所述事件时间确定所述队列在上一次数据处理成功的监控计算窗口时间节点；

数据读取模块103，可以用于以所述监控计算窗口时间节点作为数据源节点的队列的统一回退时间点重新读取数据源的数据。

所述装置的其他实施例中，还可以对重新拉取的数据进行过滤，降低数据污染。可以对重新从数据源读取的数据进行时间的过滤，删除统一回退时间点之前的数据，进一步保障统一回退时间点之前的数据不会覆盖写。具体的，本说明书提供的所述装置的另一个实施例中，所述装置还可以包括：

过滤模块104，可以用于以所述统一回退时间点对所述重新读取数据源节点的数据进行过滤，删除所述统一回退时间点之前的数据。

图6是本说明书提供的所述装置另一个实施例的模块结构示意图。

所述装置在确定了所述数据源节点的所有队列上一次(最近一次)数据处理成功的监控计算窗口时间节点后，可以以监控计算窗口为划分单位找到数据完整和不确定是否完整的时间节点。然后将数据源节点下的各个队列统一回到该时间节点，使数据源对齐，数据源节点重新拉取数据源的数据，从而实现可以不需要高可用的快照状态存储引擎即可实现保障数据一致性计算的能力。在监控场景中出现异常情况时，数据源节点的所有队列所退回的一致的时间节点可以根据队列消费的偏移量来计算得到，或者根据其他自定义的方式计算得到。

图7是本说明书提供的所述装置中重读取时间确定模块一个实施例的模块结构示意图，虚线表示在其他的实施例中可以加入的模块单元。如图7所示，所述保障数据一致性的处理装置的实施例中，所述重读取时间确定模块102可以包括：

第一计算模块1021，可以用于获取所述数据源中队列上一次数据处理成功的时间点，根据所述队列的消费的偏移量确定上一个监控计算窗口的时间节点。

或者，另一种实施方式中，所述重读取时间确定模块102可以包括：

第二计算模块1022，可以用于获取所述数据源中队列上一次数据处理成功的时间点，对所述时间点中时间最早的时间点进行所述监控计算窗口时间单位级别的格式化，得到所述上一次数据处理成功的监控计算窗口时间节点。

所述保障数据一致性的处理装置可以包括上述第一计算模块1021或第二计算模块1022中的任意一种。本说明书不排除在一些实施例中可以同时包括所述第一计算模块1021和第二计算模块1022。

如前述方法实施例所述，可以本地持久化一个监控计算窗口内的状态数据，可以使用本地磁盘或内存数据库进行存储，从而代替传统的高可用存储引擎，实现保障数据一致性计算能力的同时，大大减少计算成本。具体的，图8是本说明书提供的所述装置另一个实施例的模块结构示意图，如图8所示，所述装置还可以包括：

存储模块105，可以用于本地持久化当前监控计算窗口内处理成功的数据的状态数据；以及，

还可以用于在重新读取所述数据源的数据之后，删除本地持久化的状态数据，并本地持久化所述重新读取数据源的数据被处理的状态数据。

所述存储模块包括下述中的任意一种存储介质：磁盘，内存。当然，本说明书不排除其他的实施例中可以采取其他存储介质来存储状态数据。

具体的一个实施场景中，可以使用磁盘做数据库，作为merger节点状态存储。这样，本说明书的一个或多个实施例方案通过数据源对齐(数据源各队列偏移量进行对齐，如上述一个实施例方案是使用本地磁盘作为存储)，可以通过mapper过滤的方式，舍弃了高可用存储的使用，大大降低了成本。并且，使用磁盘或内存数据库等本地持久化的存储方式可以减少与高可用存储的网络交互，减少外界系统依赖，提高稳定性以及吞吐量。

需要说明的，上述所述的装置根据方法实施例的描述还可以包括其他的实施方式，具体的实现方式可以参照相关方法实施例的描述，在此不作一一赘述。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

本说明书一个或多个实施例提供的一种保障数据一致性的处理装置，结合了业务数据监控场景的监控计算窗口较小的特点，可以记录数据源的每个队列中数据处理的事件时间。当出现异常时，数据源的所有队列可以回滚到最近一次处理成功的状态，可以通过事件时间将数据源的各队列回退并对齐到一个一致的处理成功的监控计算窗口时间节点，避免了对高可用存储快照状态的存储引擎的依赖，使用本地磁盘或者内存等就可以达到保障数据一致性计算的能力，大大减少计算成本和数据存储成本。同时，由于舍弃了保留快照状态的高可用存储引擎，实施本申请方案还可以减少与高可用存储的网络交互，减少外界系统依赖，提高系统稳定性以及吞吐量。

本说明书实施例提供的上述保障数据一致性的处理方法或装置可以在计算机中由处理器执行相应的程序指令来实现，如使用windows操作系统的c++语言在PC端实现、linux系统实现，或其他例如使用android、iOS系统程序设计语言在智能终端实现，以及基于量子计算机的处理逻辑实现等。本说明书提供的一种保障数据一致性的处理装置的另一种实施例中，可以包括处理器以及用于存储处理器可执行指令的存储器，所述处理器执行所述指令时实现：

记录数据源节点的队列的事件时间，所述事件时间包括队列从所述数据源节点读取数据的时间；

若接收到数据处理失败的触发消息，则基于所述事件时间确定所述队列在上一次数据处理成功的监控计算窗口时间节点；

以所述监控计算窗口时间节点作为数据源节点的队列的统一回退时间点重新读取数据源的数据。

需要说明的，上述所述的装置根据方法实施例的描述还可以包括其他的实施方式，具体的实现方式可以参照相关方法实施例的描述，在此不作一一赘述。

上述所述的方法或装置可以用于多种监控计算平台、实时计算平台等的服务器中，实施本说明书实施方案的服务器，实现保障数据一致性计算的同时，可以有效降低监控成本。并且在一些实施例中可以使用通过使用本地磁盘甚至内存即可时服务器到达一致性计算的能力，大大减少计算成本。同时，由于减少了与高可用存储的交互，可以减少对外界系统的依赖，可以有效提高服务器稳定性和吞吐量。具体的，本说明书提供一种服务器，如图9所示，可以包括至少一个处理器以及用户存储处理器可执行指令的存储器，所述处理器执行所述指令时实现：

记录数据源节点的队列的事件时间，所述事件时间包括队列从所述数据源节点读取数据的时间；

若接收到数据处理失败的触发消息，则基于所述事件时间确定所述队列在上一次数据处理成功的监控计算窗口时间节点；

以所述监控计算窗口时间节点作为数据源节点的队列的统一回退时间点重新读取数据源的数据。

所述的服务器可以包括单独的服务器，也可以包括包含多个服务器的服务器系统，如业务服务器、监控服务器、存储服务器等，也可以是分布式服务器或服务器集群的构架。

需要说明的是说明书上述所述的装置或电子设备根据相关方法实施例的描述还可以包括其他的实施方式，具体的实现方式可以参照方法实施例的描述，在此不作一一赘述。本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于硬件+程序类实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

本说明书一个或多个实施例提供的一种保障数据一致性的处理方法、装置及服务器，结合了业务数据监控场景的监控计算窗口较小的特点，可以记录数据源的每个队列中数据处理的事件时间。当出现异常时，数据源的所有队列可以回滚到最近一次处理成功的状态，可以通过事件时间将数据源的各队列回退并对齐到一个一致的处理成功的监控计算窗口时间节点，避免了对高可用存储快照状态的存储引擎的依赖，使用本地磁盘或者内存等就可以达到保障数据一致性计算的能力，大大减少计算成本和数据存储成本。同时，由于舍弃了保留快照状态的高可用存储引擎，实施本申请方案还可以减少与高可用存储的网络交互，减少外界系统依赖，提高服务器系统的稳定性以及吞吐量。

尽管说明书实施例内容中提到监控计算窗口时间节点的计算方式、采用mapper节点过滤、使用本地磁盘或内存存储状态数据等之类的数据/定义、存储、获取、交互、计算、判断等描述，但是，本说明书实施例并不局限于必须是符合行业通信标准、标准计算机数据处理和数据存储规则或本说明书一个或多个实施例所描述的情况。某些行业标准或者使用自定义方式或实施例描述的实施基础上略加修改后的实施方案也可以实现上述实施例相同、等同或相近、或变形后可预料的实施效果。应用这些修改或变形后的数据获取、存储、判断、处理方式等获取的实施例，仍然可以属于本说明书实施例的可选实施方案范围之内。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable GateArray，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware DescriptionLanguage)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(RubyHardware Description Language)等，目前最普遍使用的是VHDL(Very-High-SpeedIntegrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。

控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对齐内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、车载人机交互设备、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

虽然本说明书一个或多个实施例提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的手段可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的装置或终端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境，甚至为分布式数据处理环境)。术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、产品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、产品或者设备所固有的要素。在没有更多限制的情况下，并不排除在包括所述要素的过程、方法、产品或者设备中还存在另外的相同或等同要素。

为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施本说明书一个或多个时可以把各模块的功能在同一个或多个软件和/或硬件中实现，也可以将实现同一功能的模块由多个子模块或子单元的组合实现等。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对齐内部包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储、石墨烯存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

本领域技术人员应明白，本说明书一个或多个实施例可提供为方法、系统或计算机程序产品。因此，本说明书一个或多个实施例可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本说明书一个或多个实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本说明书一个或多个实施例可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本本说明书一个或多个实施例，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本说明书的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

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

Claims (10)

1.一种保障数据一致性的处理方法，所述方法包括：

记录数据源节点的队列的事件时间，所述事件时间包括队列从所述数据源节点读取数据的时间；

若接收到数据处理失败的触发消息，则基于所述事件时间确定所述数据源节点的队列上一次数据处理成功的监控计算窗口时间节点；

以所述监控计算窗口时间节点作为数据源节点的队列的统一回退时间点重新读取数据源的数据，

其中，基于所述事件时间确定所述数据源节点的队列上一次数据处理成功的监控计算窗口时间节点包括：

获取所述数据源中队列上一次数据处理成功的时间点，对所述时间点中时间最早的时间点进行监控计算窗口时间单位级别的格式化，得到所述上一次数据处理成功的监控计算窗口时间节点，

或者，获取所述数据源中队列上一次数据处理成功的时间点，根据所述时间点中队列的偏移量确定上一个监控计算窗口的时间节点。

2.如权利要求1所述的一种保障数据一致性的处理方法，重新读取所述数据源的数据之后，所述方法还包括：

以所述统一回退时间点对所述重新读取数据源节点的数据进行过滤，删除所述统一回退时间点之前的数据。

3.如权利要求2中所述的一种保障数据一致性的处理方法，所述方法还包括：

本地持久化当前监控计算窗口内处理成功的数据的状态数据；以及，

在重新读取所述数据源的数据之后，删除本地持久化的状态数据，并本地持久化所述重新读取数据源的数据被处理的状态数据。

4.如权利要求3中所述的一种保障数据一致性的处理方法，使用磁盘或内存数据存储所述状态数据。

5.一种保障数据一致性的处理装置，所述装置包括：

事件时间记录模块，用于记录数据源节点的队列的事件时间，所述事件时间包括队列从所述数据源节点读取数据的时间；

重读取时间确定模块，用于在接收到数据处理失败的触发消息时，基于所述事件时间确定所述队列在上一次数据处理成功的监控计算窗口时间节点；

数据读取模块，用于以所述监控计算窗口时间节点作为数据源节点的队列的统一回退时间点重新读取数据源的数据；

其中，所述重读取时间确定模块包括下述之一：

第一计算模块，用于获取所述数据源中队列上一次数据处理成功的时间点，根据所述队列的偏移量确定上一个监控计算窗口的时间节点；

第二计算模块，用于获取所述数据源中队列上一次数据处理成功的时间点，对所述时间点中时间最早的时间点进行所述监控计算窗口时间单位级别的格式化，得到所述上一次数据处理成功的监控计算窗口时间节点。

6.如权利要求5所述的一种保障数据一致性的处理装置，所述装置还包括：

过滤模块，用于以所述统一回退时间点对所述重新读取数据源节点的数据进行过滤，删除所述统一回退时间点之前的数据。

7.如权利要求6所述的一种保障数据一致性的处理装置，所述装置还包括：

存储模块，用于本地持久化当前监控计算窗口内处理成功的数据的状态数据；以及，

用于在重新读取所述数据源的数据之后，删除本地持久化的状态数据，并本地持久化所述重新读取数据源的数据被处理的状态数据。

8.如权利要求7所述的一种保障数据一致性的处理装置，所述存储模块包括下述中的任意一种存储介质：

磁盘，内存。

9.一种保障数据一致性的处理装置，包括处理器以及用于存储处理器可执行指令的存储器，所述处理器执行所述指令时实现：

记录数据源节点的队列的事件时间，所述事件时间包括队列从所述数据源节点读取数据的时间；

若接收到数据处理失败的触发消息，则基于所述事件时间确定所述队列在上一次数据处理成功的监控计算窗口时间节点；

以所述监控计算窗口时间节点作为数据源节点的队列的统一回退时间点重新读取数据源的数据；

其中，所述基于所述事件时间确定所述数据源节点的队列上一次数据处理成功的监控计算窗口时间节点包括：

获取所述数据源中队列上一次数据处理成功的时间点，对所述时间点中时间最早的时间点进行监控计算窗口时间单位级别的格式化，得到所述上一次数据处理成功的监控计算窗口时间节点，

或者，获取所述数据源中队列上一次数据处理成功的时间点，根据所述时间点中队列的偏移量确定上一个监控计算窗口的时间节点。

10.一种服务器，包括至少一个处理器以及用于存储处理器可执行指令的存储器，所述处理器执行所述指令时实现：

记录数据源节点的队列的事件时间，所述事件时间包括队列从所述数据源节点读取数据的时间；

若接收到数据处理失败的触发消息，则基于所述事件时间确定所述队列在上一次数据处理成功的监控计算窗口时间节点；

以所述监控计算窗口时间节点作为数据源节点的队列的统一回退时间点重新读取数据源的数据；

其中，所述基于所述事件时间确定所述数据源节点的队列上一次数据处理成功的监控计算窗口时间节点包括：

获取所述数据源中队列上一次数据处理成功的时间点，对所述时间点中时间最早的时间点进行监控计算窗口时间单位级别的格式化，得到所述上一次数据处理成功的监控计算窗口时间节点，

或者，获取所述数据源中队列上一次数据处理成功的时间点，根据所述时间点中队列的偏移量确定上一个监控计算窗口的时间节点。

Images