CN104252466A - 流计算处理方法、设备和系统 - Google Patents

Abstract

本申请公开了一种流计算处理方法、设备和系统，通过应用本申请实施例的技术方案，在分布式流计算集群进行当前批次消息的处理过程中，将当前批次消息的中间计算明细数据存储到数据库中，进行持久化操作，同时，将当前批次消息的实时计算结果存储到内存中，以供上游应用进行数据查询，从而，在满足持久化操作需求实现容错和故障可恢复保障的前提下，将上游应用对实时计算结果的查询操作通过内存进行提供，重新定义了数据流的走向，使上游应用不与数据库直接打交道，避免了数据库访问连接数的限制，同时，节省了由于频繁访问数据库而导致的大量磁盘I/O，达到大幅提升并发访问性能的效果。

Description

流计算处理方法、设备和系统

技术领域

本申请涉及通信领域，尤其涉及一种流计算处理方法、设备和系统。

背景技术

流计算（Stream Computing）产品主要用于实时计算。如图1所示，为现有技术中最基础的流计算数据流的示意图。

在图1所示的场景中，消息中间件发送的消息流是一条一条的，而通常流计算产品对消息流进行消费是按批次为单位的，即将若干条消息捆绑在一个批次中，一个批次中消息流的条数是可以调整的。

为了实现保序与容错的需求，流计算框架设计了一种通用的消费策略：只有对一个批次的消费完全成功，并对消息发送组件做出应答后，下一批次的消息才能发送出来。如果本批次消息在消费过程中产生错误，或者在规定的时间内没有对消息发送组件做出应答，那么该批次的消息会由消息发送组件重新发送。

消息中间件集群与分布式流计算集群是两个独立的集群。消息中间件维护着一个关于消息队列的偏移量，这个偏移量记录着目前已发送出去的消息在消息队列中所处的位置。只有当一个批次的消息被流计算集群成功消费并作出应答答后，消息中间件才会发送下一批次的消息，同时将偏移量向后移动至相应的位置。通常偏移量不能回溯，即如果消息中间件发送了新的一批次消息，则之前的消息就不能再次发送了。

为了做到容灾和故障可恢复，必须将每个批次计算的结果和中间明细数据持久化到磁盘中，以避免分布式流计算集群宕机导致数据丢失，这个过程叫做同步持久化。

持久化操作也属于对一个批次消息的消费过程，因此，只有持久化成功后才会对消息发送组件做出应答。这样，假如对一个批次消息消费没有结束时发生了集群宕机，则消费组件不会对消息发送组件做出应答。当故障恢复，实时计算应用重启后，消息发送组件会重新发送这批次消息，不会造成数据丢失。假如对一个批次消息消费成功并已经对消息发送组件做出应答后发生了集群宕机，那么当故障恢复，实时计算应用重启后，消费组件会从磁盘中加载之前成功持久化的数据，然后继续对新的批次消息进行消费，因此也不会造成数据丢失。

实时计算结果持久化到磁盘的方式通常是存储到数据库中。当数据存储到数据库中以后，就可以供后续大量应用访问查询，但是这也带来了访问瓶颈。因为涉及到数据库连接数限制以及磁盘I/O（Input/Output，输入/输出）性能的影响。再加上实时计算结果的更新是秒级的，上游应用对数据库的访问会非常频繁，会导致数据库的TPS（Transaction Per Second，每秒事务处理量）非常高，这些都限制了并发访问性能。

采用加载缓存的策略可以在一些场景下解决这个问题。如图2所示，为现有的通过加载缓存实现流计算数据流优化的示意图。

例如，上游应用访问的实时数据如果是公共的，需要每5秒钟获取一次数据。那么可以将数据库中的数据每5秒钟刷新到缓存中一次，然后所有的应用都从缓存中读取数据。这样，无论同一时刻有多少访问请求，对数据库的访问压力都是每5秒钟1次，并发访问性能可以提升约2个数量级。

在实现本申请的过程中，本申请的申请人发现现有技术存在以下缺陷：

对于粒度更细的维度的实时数据，例如个人维度的实时数据，每一个用户访问的数据都不相同。如果每一个用户都需要每5秒钟获取一次数据，那么为每一个用户每5秒钟缓存一次数据是没有意义的。因为一个用户在5秒钟内只会获取一次数据，而为他缓存的数据又不会被其他用户使用，这也就失去了缓存的意义。这时候每个用户每5秒钟都要访问一次数据库做查询操作，导致数据库的TPS会非常高。

发明内容

本申请提供了一种流计算处理方法、设备和系统，能够解决现有的流计算技术对数据流的消费过程中，在实现持久化操作的同时，会出现上游应用直接从磁盘中访问数据，导致并发访问性能降低的问题。

为达到上述目的，本申请实施例一方面提供了一种流计算处理方法，包括：

分布式流计算集群将当前批次消息的中间计算明细数据存储到数据库中，进行持久化操作；

所述分布式流计算集群将所述当前批次消息的实时计算结果存储到内存中，以供上游应用进行数据查询。

优选的，所述方法，还包括：

在当前批次消息的处理过程，所述当前批次消息的中间计算明细数据存储到所述数据库的过程，以及所述当前批次消息的实时计算结果存储到所述内存的过程在预设时间内全部完成后，所述分布式流计算集群向所述当前批次消息所对应的消息发送端发送应答消息。

优选的，所述方法，还包括：

当所述当前批次消息所对应的消息发送端在预设的时间区间内没有收到所述分布式流计算集群所发送的应答消息，所述消息发送端重新将所述当前批次消息发送给所述分布式流计算集群。

优选的，所述分布式流计算集群将当前批次消息的中间计算明细数据存储到数据库中，进行持久化操作之后，还包括：

当所述分布式流计算集群出现故障并重启后，所述分布式流计算集群从所述数据库中获取当前存储的所述当前批次消息的中间计算明细数据；

所述分布式流计算集群接收所述当前批次消息所对应的消息发送端所重新发送的所述当前批次消息，并继续进行所述当前批次消息的处理过程。

优选的，所述内存，具体通过内存数据库软件来实现。

另一方面，本申请实施例还提出了一种分布式流计算集群，至少包括：

接收模块，用于接收消息发送端所发送的消息；

处理模块，用于对所述接收模块所接收到的消息进行处理；

第一存储模块，用于将所述处理模块所得到的当前批次消息的中间计算明细数据存储到数据库中，进行持久化操作；

第二存储模块，用于将所述处理模块所得到的所述当前批次消息的实时计算结果存储到内存中，以供上游应用进行数据查询。

优选的，所述分布式流计算集群，还包括：

发送模块，用于在所述处理模块所进行的当前批次消息的处理过程，所述第一存储模块所进行的所述当前批次消息的中间计算明细数据存储到所述数据库的过程，以及所述第二存储模块所进行的所述当前批次消息的实时计算结果存储到所述内存的过程在预设时间内全部完成后，向所述当前批次消息所对应的消息发送端发送应答消息。

优选的，所述分布式流计算集群，还包括：

读取模块，用于在所述分布式流计算集群出现故障并重启后，从所述数据库中获取当前存储的所述当前批次消息的中间计算明细数据；

所述接收模块，还用于在所述分布式流计算集群出现故障并重启后，接收所述当前批次消息所对应的消息发送端所重新发送的所述当前批次消息；

所述处理模块，还用于根据所述读取模块所获取的中间计算明细数据和所述接收模块所接收到的重新发送的所述当前批次消息，继续进行所述当前批次消息的处理过程。

另一方面，本申请实施例还提供了一种流计算处理系统，至少包括消息发送端，分布式流计算集群，数据库和内存：

所述消息发送端，用于向所述分布式流计算集群发送消息，并在接收到所述分布式流计算集群所返回的应答消息后，向所述分布式流计算集群发送下一批次的消息；

所述分布式流计算集群，用于接收所述消息发送端所发送的当前批次消息，并对所述当前批次消息进行处理，将相应的中间计算明细数据存储到所述数据库中，进行持久化操作，并将相应的实时计算结果存储到所述内存中，以供上游应用进行数据查询。

优选的，

所述消息发送端，还用于在向所述分布式流计算集群发送消息之后的预设的时间区间内没有收到所述分布式流计算集群所发送的应答消息时，重新将所述当前批次消息发送给所述分布式流计算集群。

与现有技术相比，本申请所提出的技术方案至少具有以下优点：

通过应用本申请实施例的技术方案，在分布式流计算集群进行当前批次消息的处理过程中，将当前批次消息的中间计算明细数据存储到数据库中，进行持久化操作，同时，将当前批次消息的实时计算结果存储到内存中，以供上游应用进行数据查询，从而，在满足持久化操作需求实现容错和故障可恢复保障的前提下，将上游应用对实时计算结果的查询操作通过内存进行提供，重新定义了数据流的走向，使上游应用不与数据库直接打交道，避免了数据库访问连接数的限制，同时，节省了由于频繁访问数据库而导致的大量磁盘I/O，达到大幅提升并发访问性能的效果。

附图说明

图1为现有技术中最基础的流计算数据流的示意图；

图2为现有的通过加载缓存实现流计算数据流优化的示意图；

图3为本申请实施例提供的一种流计算处理方法的流程示意图；

图4为本申请实施例提供的一种具体应用场景下的流计算处理方法的流程示意图；

图5为本申请实施例提供的一种流计算处理系统的结构示意图；

图6为本申请实施例提供的一种分布式流计算集群的结构示意图。

具体实施方式

如背景技术所述，在现有的流计算处理过程中，一方面，出于容错、故障可恢复等需求，需要进行持久化处理，现有技术中可以通过缓存策略来实现，但是，另一方面，通过数据库提供实时数据查询服务存在可能导致数据库访问量过高，影响I/O性能的问题，而现有的缓存策略不能很好地解决这样的问题。

为了解决这样的问题，本申请提出了一种流计算处理方法，使上游应用不与数据库直接打交道，避免了数据库访问连接数的限制，同时节省了大量磁盘I/O，从而达到大幅提升并发访问性能的效果。

如图3所示，为本申请实施例提供的一种流计算处理方法的流程示意图，包括：

步骤S301、分布式流计算集群接收消息发送端所发送的消息。

步骤S302、分布式流计算集群对当前批次消息进行处理。

步骤S303、分布式流计算集群将当前批次消息的中间计算明细数据存储到数据库中，进行持久化操作。

通过这样的处理，所述分布式流计算集群通过满足持久化操作需求，实现了容错和故障可恢复保障。

步骤S304、所述分布式流计算集群将所述当前批次消息的实时计算结果存储到内存中，以供上游应用进行数据查询。

通过这样的处理，所述分布式流计算集群将上游应用对实时计算结果的查询操作通过内存进行提供，重新定义了数据流的走向，使上游应用不与数据库直接打交道，避免了数据库访问连接数的限制，同时，节省了由于频繁访问数据库而导致的大量磁盘I/O，达到大幅提升并发访问性能的效果。

步骤S305、所述分布式流计算集群分别判断步骤S302，步骤S303和步骤S304的处理过程是否在预设时间内完成。

如果判断结果为是，执行步骤S306；

如果判断结果为否，则不作任何处理，并按照相应的判断规则进行下一次判断。

在此种情况下，由于没有及时执行步骤S306，即分布式流计算集群没有在预设时间内向消息发送端发送相应的应答消息，所以，消息发送端确认所发送的本批次的消息没有在预设的时间内完成处理，因此，重新向所述分布式流计算集群发送本批次的消息，从而，重新执行步骤S301，进行本批次的消息的处理。

步骤S306、所述分布式流计算集群向所述当前批次消息所对应的消息发送端发送应答消息。

步骤S307、所述消息发送端接收到所述应答消息后，继续向所述分布式流计算集群发送下一批次的消息，从而重新执行步骤S301，进行下一批次的消息的。

在当前批次消息的处理过程，所述当前批次消息的中间计算明细数据存储到所述数据库的过程，以及所述当前批次消息的实时计算结果存储到所述内存的过程全部完成后，所述分布式流计算集群向所述当前批次消息所对应的消息发送端发送应答消息。

需要进行说明的是，如果上述的步骤S302、步骤S303和步骤S304中的任何一个步骤出现故障而导致操作无法完成，则所述分布式计算集群将不会向消息发送端发送应答消息。

相应的，当所述当前批次消息所对应的消息发送端在预设的时间区间内没有收到所述分布式流计算集群所发送的应答消息，所述消息发送端重新将所述当前批次消息发送给所述分布式流计算集群。

在实际的应用场景中，分布式流计算集群可能应为故障而宕机，那么。当所述分布式流计算集群出现故障并重启后，所述分布式流计算集群从所述数据库中获取当前存储的所述当前批次消息的中间计算明细数据。

然后，由于之前的处理操作没有完成，所以，所述分布式流计算集群必然没有向消息发送端发送应答消息，所以，所述消息发送端会重新向所述分布式流计算集群发送该批次的消息，所述分布式流计算集群接收所述当前批次消息所对应的消息发送端所重新发送的所述当前批次消息，并继续进行所述当前批次消息的处理过程。

通过这样的处理，分布式流计算集群实现了故障恢复处理。

优选的，所述内存，具体可以通过内存数据库软件来实现，当然，其他能够达到相同技术效果的方式也可以应用在本申请所提出的技术方案中。

在具体的应用场景中，本申请所提出的技术方案还存在以下替代方案：

本申请在实施过程中，对持久化和写内存分别使用了独立的软件。可以开发一个软件，既能够管理内存的写入与访问，又能够做持久化。目前已存在既提供分布式缓存，又提供持久化的软件，但是并不能满足同步持久化的需求。替代产品必须能够做到在对一个批次消息的消费过程中既完成写内存，又完成持久化操作。

该方案同样属于本申请的保护范围。

与现有技术相比，本申请实施例所提出的技术方案具有以下优点：

通过应用本申请实施例的技术方案，在分布式流计算集群进行当前批次消息的处理过程中，将当前批次消息的中间计算明细数据存储到数据库中，进行持久化操作，同时，将当前批次消息的实时计算结果存储到内存中，以供上游应用进行数据查询，从而，在满足持久化操作需求实现容错和故障可恢复保障的前提下，将上游应用对实时计算结果的查询操作通过内存进行提供，重新定义了数据流的走向，使上游应用不与数据库直接打交道，避免了数据库访问连接数的限制，同时，节省了由于频繁访问数据库而导致的大量磁盘I/O，达到大幅提升并发访问性能的效果。

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

发明人发现，持久化操作在流计算处理过程中，主要用于容错可故障可恢复，以及为上游应用提供实时数据查询。

本申请所提出的技术方案有所不同，持久化操作只负责存储分布式流计算集群各个节点在消费每个批次消息时的中间明细数据，用于容错和故障可恢复，不需要存储实时结果数据。

例如：实时计算某购物网站当天的有效买家人数，需要存储有效买家ID明细数据用于去重。

如果发生了集群宕机等故障，在故障恢复，流计算应用重启后，有效买家ID明细数据会从数据库中重新加载到流计算集群的消费组件内存中，同时继续对新发送过来的消息流做消费，计算最新的实时结果数据。

另一方面，在具体的流计算处理过程中，实时计算结果数据是用于最终展现的数据，通常是按某一维度计算得到的聚合值。它的数据量与中间计算明细数据相比可以忽略不计，可以常驻内存。

因此，在本申请所提出的技术方案中，将流计算应用的实时计算结果直接写到一块内存中，供上游应用查询数据使用。这样，由于不再需要从数据库中查询数据，就节省了大量磁盘I/O。并发访问性能与通过数据库中查询数据相比可以提升2个数量级。

如图4所示，为本申请实施例所提出的一种具体应用场景下的流计算处理方法的流程示意图。

这块内存区域与现有技术中所提到的缓存在概念上有所区别，具体说明如下：

缓存主要是为了避免频繁的磁盘读，将热度较高的数据加载到内存以备后续查询请求在内存中直接命中，免去了再次读取磁盘的性能损耗。

而在本申请所提出的技术方案中，内存区域完全是供上游应用在获取数据时使用，其不关心保存在这块内存区域中的数据是否会被其他查询请求命中。因此，这块内存区域可以使用内存数据库软件，在技术实现上有较多的选择空间。

在技术实现上，将中间计算明细数据写数据库和将实时计算数据写内存这两个环节都属于对一个批次消息的消费过程，因此，只有对消息的计算处理、写数据库、写内存这三个环节全部成功之后消息消费组件才会对消息发送组件做出应答。这三个环节中任何一个环节执行失败，或者在规定的时间内没有做出应答，消息发送组件都会重新发送这批次的消息，从而，保证了容错和故障可恢复。

本申请所提出的技术方案在保证了并发访问性能与使用数据库查询方案相比提升2个数量级之外，对容错和故障可恢复的级别没有任何降低，具体说明如下：

1、当分布式流计算集群出现故障时，由于采用了同步持久化策略，明细数据都保存在磁盘中，待故障恢复，实时计算应用重启后，明细数据可以重新从磁盘中加载，保证数据没有丢失。

2、当数据库出现故障时，由于写数据库属于消息消费的过程，数据库故障将导致写数据库不会成功，因此，也不会对消息发送组件做出应答。消息发送组件会不断重新发送本批次的消息，直到数据库故障恢复，从而，保证不会有未被成功消费的消息。

3、当提供特定内存区域的服务器出现故障时，同样写内存的操作也属于消息消费的过程，写内存不成功就不会对消息发送组件做出应答。消息发送组件同样会不断重新发送本批次的消息，直到服务器故障恢复。

4、实时结果数据只保存在内存中，没有保存在磁盘中，不会导致数据丢失。因为磁盘保存有明细数据，在故障恢复时，消息消费组件可以使用明细数据重新计算得到结果数据。对一个批次的消息重新计算结果数据所花费的时间通常是毫秒级的，这个影响可以忽略不计。

与现有技术相比，本申请实施例所提出的技术方案具有以下优点：

通过应用本申请实施例的技术方案，在分布式流计算集群进行当前批次消息的处理过程中，将当前批次消息的中间计算明细数据存储到数据库中，进行持久化操作，同时，将当前批次消息的实时计算结果存储到内存中，以供上游应用进行数据查询，从而，在满足持久化操作需求实现容错和故障可恢复保障的前提下，将上游应用对实时计算结果的查询操作通过内存进行提供，重新定义了数据流的走向，使上游应用不与数据库直接打交道，避免了数据库访问连接数的限制，同时，节省了由于频繁访问数据库而导致的大量磁盘I/O，达到大幅提升并发访问性能的效果。

为了实现上述的技术方案，本申请实施例提供了一种流计算处理系统，其结构示意图如图5所示，至少包括消息发送端51，分布式流计算集群52，数据库53和内存54：

所述消息发送端51，用于向所述分布式流计算集群52发送消息，并在接收到所述分布式流计算集群52所返回的应答消息后，向所述分布式流计算集群52发送下一批次的消息；

所述分布式流计算集群52，用于接收所述消息发送端51所发送的当前批次消息，并对所述当前批次消息进行处理，将相应的中间计算明细数据存储到所述数据库53中，进行持久化操作，并将相应的实时计算结果存储到所述内存54中，以供上游应用进行数据查询。

在具体的应用场景中，

所述消息发送端51，还用于在向所述分布式流计算集群52发送消息之后的预设的时间区间内没有收到所述分布式流计算集群52所发送的应答消息时，重新将所述当前批次消息发送给所述分布式流计算集群52。

进一步的，本申请实施例还提出了一种分布式流计算集群，其结构示意图如图6所示，至少包括：

接收模块61，用于接收消息发送端所发送的消息；

处理模块62，用于对所述接收模块61所接收到的消息进行处理；

第一存储模块63，用于将所述处理模块62所得到的当前批次消息的中间计算明细数据存储到数据库中，进行持久化操作；

第二存储模块64，用于将所述处理模块62所得到的所述当前批次消息的实时计算结果存储到内存中，以供上游应用进行数据查询。

优选的，所述分布式流计算集群，还包括：

发送模块65，用于在所述处理模块62所进行的当前批次消息的处理过程，所述第一存储模块63所进行的所述当前批次消息的中间计算明细数据存储到所述数据库的过程，以及所述第二存储模块64所进行的所述当前批次消息的实时计算结果存储到所述内存的过程在预设时间内全部完成后，向所述当前批次消息所对应的消息发送端发送应答消息。

优选的，所述分布式流计算集群，还包括：

读取模块66，用于在所述分布式流计算集群出现故障并重启后，从所述数据库中获取当前存储的所述当前批次消息的中间计算明细数据；

所述接收模块61，还用于在所述分布式流计算集群出现故障并重启后，接收所述当前批次消息所对应的消息发送端所重新发送的所述当前批次消息；

所述处理模块62，还用于根据所述读取模块66所获取的中间计算明细数据和所述接收模块61所接收到的重新发送的所述当前批次消息，继续进行所述当前批次消息的处理过程。

与现有技术相比，本申请实施例所提出的技术方案具有以下优点：

通过应用本申请实施例的技术方案，在分布式流计算集群进行当前批次消息的处理过程中，将当前批次消息的中间计算明细数据存储到数据库中，进行持久化操作，同时，将当前批次消息的实时计算结果存储到内存中，以供上游应用进行数据查询，从而，在满足持久化操作需求实现容错和故障可恢复保障的前提下，将上游应用对实时计算结果的查询操作通过内存进行提供，重新定义了数据流的走向，使上游应用不与数据库直接打交道，避免了数据库访问连接数的限制，同时，节省了由于频繁访问数据库而导致的大量磁盘I/O，达到大幅提升并发访问性能的效果。

本领域技术人员可以理解实施例中的装置中的模块可以按照实施例描述进行分布于实施例的装置中，也可以进行相应变化位于不同于本实施例的一个或多个装置中。上述实施例的模块可以合并为一个模块，也可以进一步拆分成多个子模块。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台终端设备（可以是手机，个人计算机，服务器，或者网络设备等）执行本申请各个实施例所述的方法。

以上所述仅是本申请的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视本申请的保护范围。

Claims (10)

1.一种流计算处理方法，其特征在于，包括：

分布式流计算集群将当前批次消息的中间计算明细数据存储到数据库中，进行持久化操作；

所述分布式流计算集群将所述当前批次消息的实时计算结果存储到内存中，以供上游应用进行数据查询。

2.如权利要求1所述的方法，其特征在于，还包括：

在当前批次消息的处理过程，所述当前批次消息的中间计算明细数据存储到所述数据库的过程，以及所述当前批次消息的实时计算结果存储到所述内存的过程在预设时间内全部完成后，所述分布式流计算集群向所述当前批次消息所对应的消息发送端发送应答消息。

3.如权利要求2所述的方法，其特征在于，还包括：

当所述当前批次消息所对应的消息发送端在预设的时间区间内没有收到所述分布式流计算集群所发送的应答消息，所述消息发送端重新将所述当前批次消息发送给所述分布式流计算集群。

4.如权利要求1所述的方法，其特征在于，所述分布式流计算集群将当前批次消息的中间计算明细数据存储到数据库中，进行持久化操作之后，还包括：

当所述分布式流计算集群出现故障并重启后，所述分布式流计算集群从所述数据库中获取当前存储的所述当前批次消息的中间计算明细数据；

所述分布式流计算集群接收所述当前批次消息所对应的消息发送端所重新发送的所述当前批次消息，并继续进行所述当前批次消息的处理过程。

5.如权利要求1所述的方法，其特征在于，所述内存，具体通过内存数据库软件来实现。

6.一种分布式流计算集群，其特征在于，至少包括：

接收模块，用于接收消息发送端所发送的消息；

处理模块，用于对所述接收模块所接收到的消息进行处理；

第一存储模块，用于将所述处理模块所得到的当前批次消息的中间计算明细数据存储到数据库中，进行持久化操作；

第二存储模块，用于将所述处理模块所得到的所述当前批次消息的实时计算结果存储到内存中，以供上游应用进行数据查询。

7.如权利要求6所述的分布式流计算集群，其特征在于，还包括：

发送模块，用于在所述处理模块所进行的当前批次消息的处理过程，所述第一存储模块所进行的所述当前批次消息的中间计算明细数据存储到所述数据库的过程，以及所述第二存储模块所进行的所述当前批次消息的实时计算结果存储到所述内存的过程在预设时间内全部完成后，向所述当前批次消息所对应的消息发送端发送应答消息。

8.如权利要求6所述的分布式流计算集群，其特征在于，还包括：

读取模块，用于在所述分布式流计算集群出现故障并重启后，从所述数据库中获取当前存储的所述当前批次消息的中间计算明细数据；

所述接收模块，还用于在所述分布式流计算集群出现故障并重启后，接收所述当前批次消息所对应的消息发送端所重新发送的所述当前批次消息；

所述处理模块，还用于根据所述读取模块所获取的中间计算明细数据和所述接收模块所接收到的重新发送的所述当前批次消息，继续进行所述当前批次消息的处理过程。

9.一种流计算处理系统，其特征在于，至少包括消息发送端，分布式流计算集群，数据库和内存：

所述消息发送端，用于向所述分布式流计算集群发送消息，并在接收到所述分布式流计算集群所返回的应答消息后，向所述分布式流计算集群发送下一批次的消息；

所述分布式流计算集群，用于接收所述消息发送端所发送的当前批次消息，并对所述当前批次消息进行处理，将相应的中间计算明细数据存储到所述数据库中，进行持久化操作，并将相应的实时计算结果存储到所述内存中，以供上游应用进行数据查询。

10.如权利要求9所述的系统，其特征在于，

所述消息发送端，还用于在向所述分布式流计算集群发送消息之后的预设的时间区间内没有收到所述分布式流计算集群所发送的应答消息时，重新将所述当前批次消息发送给所述分布式流计算集群。