CN104794015B - 一种实时流计算流速感知弹性执行容错系统 - Google Patents

Abstract

本发明公开了一种实时流计算流速感知弹性执行容错系统，将传统流计算框架中元组发射、计算、状态保持与处理单元紧耦合关系变成一种模块化、专职化的松耦合关系，结合流速感知、弹性执行、状态管理等模块，使系统能够精细控制各阶段的处理时间进而保证整个应用的延迟。流速感知使系统能够快速响应输入流变化或可用资源变化。分发模块可灵活改变分发关系、并适时按批发送元组，进一步减少了资源消耗和发送延迟。弹性执行使系统对用户透明地调整处理单元、节点的并行数，以保持应用稳定、保证延迟。状态管理及持久化存储使系统有难以置信的容错能力，对元组的适当数量保存，加快了应用恢复，结合弹性执行并行恢复也进一步提高了失效恢复速度。

Description

一种实时流计算流速感知弹性执行容错系统

技术领域

本发明属于大数据分布式计算领域，更具体地，涉及一种实时流计算流速感知弹性执行容错系统。

背景技术

当前，实时流计算受到了广泛关注。学术界和工业界研发了多个流计算系统：Storm,S4,D-Streams,Puma,Flume,Streambase,Timestream，System S等。开发者用上述系统提供的API描述处理逻辑构建应用程序。由于此类应用处理的数据量通常超过了单机器的处理能力且需要经过多个阶段计算处理，系统将应用部署到多个机器上分布式执行。流应用有如下典型特征：长时间运行，数据实时产生流入系统，流入率不可知，长期运行造成的错误累积和集群节点错误累积，所以流应用希望系统提供低延迟的处理能力(尽管输入流率会变化和可用计算资源会变化)，失效后快速恢复的容错能力。

流应用中的数据(通常称为元组)在系统中经多阶段处理。每个阶段接收上一阶段的元组输入，此阶段有以下处理行为：转换处理(元组个数保持不变)、衍生出更多元组(元组个数增多)或合并上一阶段的元组(元组个数减少)，从而造成各个阶段本身具有不同的流速。当流应用起始输入流速波动时，对各个阶段造成的影响是不同的，每个阶段需要扩展或收缩的算子(即处理单元)数目不尽相同，需要精细化区分控制以使各阶段处理延迟相对稳定。然而，当前的流计算系统精细化控制应用执行方面做得不足。

流应用通常部署在云平台或者大规模集群中，长时间运行，不可避免的带来容错问题，例如节点失效问题，元组快速处理过程中元组丢失问题等。

学术界和工业界对上述问题进行了积极探索研究。流应用节点流速变化且没有超过节点处理能力时，Scott Schneider向Stream S添加了弹性化处理单元。依据节点输入流速的大小，该处理单元可以唤醒或者休眠不同数目的处理线程。Sparrow采用twochoice、懒绑定等技术使任务调度到负载较小的节点上去。当节点输入流速的大小超过了节点处理能力，成为增加了整个处理延迟的瓶颈时，StreamCloud以增加处理子链的方式维持处理的低延迟。TimeStream使用了弹性替代的方法，在维持语义正确不变的情况下将瓶颈节点或者瓶颈子处理拓扑图替换成处理能力更强的节点或者子处理拓扑图。

至于容错方面，TimeStream系统对每一个被处理的元组进行了跟踪，并阶段性保持处理节点的状态，以便能够失效恢复和元组在相应的处理单元重放处理。MillWheel提供持久化节点状态和管理节点状态的特性，同时运用水位模型标明元组到来的时间界限，并采用处理回复(ack)的方法保证元组的准确一次处理。Storm采用元组在每次处理前后生产两个相同的值进行异或的方式，保证每个元组至少一次处理。Raul Castro Fernandez提出了一种基于处理单元状态管理的方法并融合扩展和容错为一体的策略，当节点成为系统瓶颈时，将其处理状态进行分割、并行化扩展以保持低延迟。阶段性地对处理节点状态对检查点，以便失效后快速恢复。

但是上述方法存在了以下缺点：不能充分利用整个集群的资源进行负载均衡、延迟保证，缺少协调节点处理速度与节点可用资源的调度策略；不能根据流速变化灵活快速地产生应对集群角度的整体策略(如调整算子数目，增加资源使用量)；当节点失效时，节点状态寻回与检测点时间戳之后的元组从原始阶段重放并重新处理需要大量时间。

发明内容

针对现有的技术缺陷，本发明提供了一种融合了流速感知、弹性执行和容错一体化的解决方案——实时流计算流速感知弹性执行容错系统，旨在保证流应用的稳定性与低延迟，同时兼顾提高集群资源的利用率、流应用容错及快速恢复。

为实现上述目的，本发明提供了一种实时流计算流速感知弹性执行容错系统，包括部署管理模块、流速感知模块、元组分发管理模块、弹性执行协调模块、状态管理模块、错误检测模块、恢复协调模块、集群管理模块、应用管理模块。

在本系统中，集群管理模块、应用管理模块、部署管理模块、协调恢复模块、弹性执行协调模块相应进程都运行在管理节点上。由于上述模块资源消耗较少且有的较少用到，所以管理节点不会因此成为瓶颈。而流速感知模块、状态管理模块、错误检测模块部署在所有工作节点上，默认元组分发管理模块同时部署在所有工作节点上，用户可以用另外的消息分发系统如kafka、netty等来代替元组分发管理模块，系统提供相应接口。

应用管理模块接收用户提交的应用代码，将代码解析成部署管理模块可以识别和分割的格式。部署管理模块对应用管理模块处理后的内容进行相应的识别、分割，根据应用配置向集群管理模块申请工作节点，并向工作节点发送任务代码，工作节点收到任务代码后，启动相应的处理单元。元组分发调整模块根据处理单元间的逻辑关系，设置发送关系，并批量地向持久存储系统发送元组进行备份。当应用运行后，流速感知模块启动，感知工作节点及其上部署的处理单元处理效率、元组分发管理模块中元组停留延迟。流速感知模块感知因为流输入率或可用资源的变化而引起的体现在应用延迟、处理效率等方面的变化，将上述变化信息告知弹性执行协调模块。弹性执行协调模块根据感知信息选择开启更多处理单元还是合并回收部分节点以提高资源利用率。当弹性执行协调模块判断需要开启更多处理单元时，将向部署管理模块请求部署更多处理单元，部署管理模块向集群管理模块请求新节点；当部署完成后，向元组分发管理模块请求调整元组分发关系。元组分发管理模块结合状态管理模块对系统处理状态进行备份以备失效后恢复。状态管理模块阶段性地对处理单元处理状态做检查点(快照)，元组分发管理模块成批发送检查点时间戳之后的元组，持久存储系统中保留者随时可供恢复的处理状态和此快照检查点后应该处理的元组。当错误检测模块检测到错误发生后，向恢复协调模块申请恢复，恢复协调模块向状态管理模块申请找回状态，并向部署管理模块请求重新部署处理单元。

下面就上述模块进行简要说明：

(1)部署管理模块，用于接收应用管理模块处理后的流应用逻辑拓扑图或弹性执行协调模块、恢复协调模块的命令请求将应用部署成并行的多线程组成的执行拓扑图。

(2)流速感知模块，用于感知应用数据输入率、可用资源变化而引起延迟、资源利用率变化，从而结合弹性执行协调模块进行运行时动态调整以保证系统的稳定性、应用的低延迟性。此模块包括节点流速感知子模块和应用级流速感知子模块；其中，所述节点流速感知子模块，用于感知单位时间内通过节点元组数量即处理单元处理元组的处理效率；所述应用级流速感知子模块，用于感知应用中的数据流过处理阶段的流速，此流速可以用元组在元组分发子系统(元组分发管理模块)中停留的时间来进行衡量。

(3)元组分发管理模块，用于根据流速感知信息或弹性执行协调模块的请求调整元组分发，将元组发给下一阶段中会最快处理的处理节点；或当流速稳定时根据已经固定的分发关系，快速地成批地分发元组。同时，成批地将元组发送一份到持久存储器中，以便未来恢复使用。

(4)弹性执行协调模块，用于根据流速信息灵活地开启、关闭处理线程、进程、节点，调整处理单元并行数，以精确控制元组在分发系统中的停留时间和处理节点的处理时延。当收到流速感知模块的感知信息，分析出应用数据输入率变大、延迟变大或节点过于繁忙时，弹性执行协调模块会寻求开启更多的处理单元；当节点由于其他应用输入率变大而使此应用可用资源变少而处理效率变低时，弹性执行协调模块会寻求开启更多的处理单元。当应用数据输入率变小(流速降低)并且节点资源利用率过低时，将多个资源利用率低的节点上的处理单元合并或迁移到其中一个节点上，减少处理单元并行数，减少节点。

(5)状态管理模块，用于阶段性地将处理节点的处理状态保存在持久化存储系统中，并异步地对旧的状态版本进行清除以腾出存储空间，节约存储资源。在弹性扩展和收缩时负责分割和合并相应的处理状态。在恢复时负责寻回相应处理状态。

(6)错误检测模块，用于检测节点失效，系统异常，运行错误等。

(7)恢复协调模块，用于当错误发生且对应用、系统产生影响时，与元组分发管理模块、部署管理模块、弹性执行协调模块、集群管理模块、状态管理模块一起对应用或者系统进行快速恢复。

(8)集群管理模块，系统部署运行在集群之上，用于扩展需要新节点时向部署管理模块提供新节点。当有多余的节点退出系统时，用于节点回收。

(9)应用管理模块，用于将用户编写的流应用转换成逻辑拓扑图，交予部署管理模块进行应用部署。

与现有技术相比，本方法具有以下的有益效果：

(1)精细化的处理控制

流速感知的引入，使系统能够实时感知节点处理效率，分发系统中元组的排队延迟(分发效率)，从而通过分发管理、弹性执行机制产生相应的对策以达到精细化控制元组在每个处理阶段所花费的时间的目的。系统能够对元组的节点处理时间和排队时间进行设限，一旦达到上限，高效的调整机制将被触发，改变元组分发情况，增加处理线程、处理进程、处理节点，从而对处理延迟做出保证。

(2)细粒度而高效的分发管理

分发管理决定了系统中每个元组将被发送给下游的哪个处理单元。依据下游处理单元的处理效率，将元组发送给最快处理它的处理单元，在保证低延迟的同时也提高集群资源利用率。当感知元组流经下游处理单元流速稳定、分发系统中元组流速稳定时，分发管理将按批快速发送元组，以此提高分发效率，加快应用处理。另外，分发管理能够根据下游处理单元并行度灵活改变元组的发送策略。

(3)高效的执行机制

流计算系统应该能够提供一个自适应应对流速变化的执行机制，并对用户透明同时保持低处理延迟。本发明中的弹性执行协调提供一种快速应对流速变化的执行机制，它能够根据流速的变化、元组的处理延迟的变化改变处理单元的并行度；能够判断机器节点的资源使用率过低，合并节点处理，减少节点的使用，提高集群资源利用率。资源可用性的变化能够通过流速的变化进行感知，其背后原因此发明不作另外讨论。

(4)优秀的容错机制

持久存储系统中存储着系统处理状态的检查点及此检查点时间以来节点将要处理的元组，当系统中处理节点失效时，可快速寻回节点状态，直接从分发系统中重发检查点以来的元组，减少了恢复计算量，并且结合弹性执行协调模块可以做到并行快速恢复。另外，对于无状态的管理进程，当进程被意外杀死时，简单重启即可。

(5)应用的稳定性与延迟保证

系统通过流速感知、弹性执行、容错等特性给用户提供长期稳定的应用运行环境，通过精确控制元组在每个处理阶段处理时间，从而保证应用的处理延迟。

附图说明

图1是本发明实时计算流速感知弹性执行容错系统整体架构图；

图2是本发明中用户视角系统示意图；

图3是本发明中运行时视角系统架构图；

图4是本发明中弹性执行流程图；

图5是本发明中容错恢复流程图。

具体实施方式

为了使本发明的目的、技术方案及优点更加明了，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。此外，下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合。

本发明的目的是保持当前流计算系统的用户易编写、易部署、可扩展特性的同时增加其稳定性、低延迟保证和容错保证。流计算系统提供的API应尽可能简单，如Storm只提供spout，blot，topology等简单API供用户编写应用程序、描述处理逻辑。本发明延续了流计算系统部署对用户透明的特性，但增加了弹性执行机制，以避免节点过载或者多个节点低效率运行，提高资源使用率的同时也发挥了保证低延迟的作用，此是本发明的重点之一。为了实时探测应用运行情况，系统增加了流速感知模块，用以感知节点流速变化，分发系统元组流速变化情况，给系统平稳运行提供了保证，也是本发明的特色。本发明强化了传统流计算系统的容错机制，阶段性地保存节点上处理单元的处理状态和此时间节点后相应处理单元应该处理的元组。当错误发生时，能最快的恢复系统运行，避免了传统流计算系统从原始阶段至恢复单元多个阶段重新计算，此也是本发明的重点。

如图1所示，本发明提供了一种实时流计算流速感知弹性执行容错系统，所述系统包括部署管理模块、流速感知模块、元组分发管理模块、弹性执行协调模块、状态管理模块、错误检测模块、恢复协调模块、集群管理模块、应用管理模块。

在本系统中，集群管理模块、应用管理模块、部署管理模块、协调恢复模块、弹性执行协调模块相应进程都运行在管理节点上。由于上述模块资源消耗较少且有的较少用到，所以管理节点不会因此成为瓶颈。而流速感知模块、状态管理模块、错误检测模块部署在所有工作节点上，默认元组分发管理模块同时部署在所有工作节点上，用户可以用另外的消息分发系统如kafka、netty等来代替元组分发管理模块，系统提供相应接口。

应用管理模块接收用户提交的应用代码，将代码解析成部署管理模块可以识别和分割的格式。部署管理模块对应用管理模块处理后的内容进行相应的识别、分割，根据应用配置向集群管理模块申请工作节点，并向工作节点发送任务代码，工作节点收到任务代码后，启动相应的处理单元。元组分发调整模块根据处理单元间的逻辑关系，设置发送关系，并批量地向持久存储系统发送元组进行备份。当应用运行后，流速感知模块启动，感知工作节点及其上部署的处理单元处理效率、元组分发管理模块中元组停留延迟。流速感知模块感知因为流输入率或可用资源的变化而引起的体现在应用延迟、处理效率等方面的变化，将上述变化信息告知弹性执行协调模块。弹性执行协调模块根据感知信息选择开启更多处理单元还是合并回收部分节点以提高资源利用率。当弹性执行协调模块判断需要开启更多处理单元时，将向部署管理模块请求部署更多处理单元，部署管理模块向集群管理模块请求新节点；当部署完成后，向元组分发管理模块请求调整元组分发关系。元组分发管理模块结合状态管理模块对系统处理状态进行备份以备失效后恢复。状态管理模块阶段性地对处理单元处理状态做检查点(快照)，元组分发管理模块成批发送检查点时间戳之后的元组，持久存储系统中保留者随时可供恢复的处理状态和此快照检查点后应该处理的元组。当错误检测模块检测到错误发生后，向恢复协调模块申请恢复，恢复协调模块向状态管理模块申请找回状态，并向部署管理模块请求重新部署处理单元。

下面就上述模块进行详细说明：

(1)部署管理模块，用于接收应用管理模块处理后的流应用逻辑拓扑图将其部署成并行的多线程组成的执行拓扑图；还用于接受弹性执行协调模块发来的扩展请求和收缩处理请求，进行对用户透明地应用重新部署；另外接受恢复协调模块请求重新部署失效的处理单元。部署管理模块在部署执行拓扑图的同时记录了处理单元的部署信息、任务信息，以便节点或处理单元失效后进行恢复处理。

(2)流速感知模块，用于感知应用数据输入率、可用资源变化而引起延迟、资源利用率等信息变化，从而结合弹性执行协调模块进行运行时动态调整,以达到使系统稳定运行和应用延迟保证的目的。此模块包括节点流速感知子模块和应用级流速感知子模块；其中，所述节点流速感知子模块，用于感知单位时间内通过节点元组数量即处理单元处理元组的处理效率。具体计算方法如下，若处理单元单位时间内流过n个元组，n个元组平均流经时间为t，则流速定义为v＝n/t。v可以反应处理单元的处理效率和处理能力。对于节点，使用上述同样的计算方法。当v越大时，表明其流速越高，能流过更多的元组，应该给予分发更多元组。

应用级流速感知子模块，用于感知应用中的数据流过处理阶段的流速，此流速可以用元组在元组分发子系统(元组分发管理模块)中停留的时间来进行衡量。分发系统视为稳定系统，即其对一个元组的分发时间是恒定的。元组进入分发系统后，在其所属的流队列进行排队，系统每次发送队首元组。在下游处理单元处理能力不变的情况下，元组在分发系统停留的时间则由其所在队列长度决定。当队列长度超过一定阈值或者队列增长速度超过一定阈值，则触发弹性执行中的扩展功能，以降低元组的排队延迟。当下游处理单元处理能力不稳定时，以元组停留时间来衡量是否需要进行扩展。由于队列长度的检测比元组停留时间检测更加容易和开销更小，所以检测到下游处理单元处理波动频繁时，才启用元组时间检测。

一个流应用中的数据经多个阶段处理，一个用户视角的流应用如图2。如图中所示，在一个应用中第一个组件src是与外界消息系统存在接口的，向本应用输送数据流。最后一个snk为与外界系统存在接口，向外界输送处理结果。中间的处理单元构成了每个处理阶段，处理阶段中的初始单元数量由用户决定。分发系统在各个处理阶段间管理元组分发。

之所以要感知节点流速和元组处理阶段间停留的时间，除了可以精确化控制元组在每个处理步骤的时间外，还有一个优势：感知节点流速，可以感知下游处理单元的处理效率，而感知元组的排队时间、监控元组的队列长度，可以感知上游的处理效率变化及数据流的输入波动。

(3)元组分发管理模块，用于根据流速感知信息或弹性执行协调模块的请求调整元组分发，将元组发给下一阶段中会最快处理的处理节点；或者流速稳定时根据已经固定的分发关系，快速的成批的分发元组。元组分发管理模块负责记录元组的发送关系并发送元组，同时成批地将元组发送一份到持久存储器中，以便容错恢复。

元组被发送给下游的哪个处理单元，除了与应用逻辑相关也与下游处理单元的处理能力相关。简单举例来讲，若下游有两个处理单元O¹ ₂和O² ₂，他们共同消费一个流，且元组可以由任何一个处理单元处理，若两者流速为2:1，那么发送关系也应该是2:1，即更多的元组发送给流速快的处理单元。随着下游处理效率的改变，发送关系相应改变。若连续f次探测下游处理单元流速相对稳定(如上下波动不超过10％)，那么发送时可以按批发送，减小发送代价。

图3为运行时视角系统架构图，其中可以发现元组分发管理系统处于各计算阶段的衔接作用。当用户提交一个应用后，应用部署管理模块向集群管理模块请求资源，管理节点调度可用节点，部署管理模块在节点上部署含有应用处理逻辑的处理单元，处理单元连接分发系统，分发系统构建依据应用描述初始的分发关系。应用开始运行后，流速感知模块、弹性执行协调模块开始工作以保证应用处理延迟，元组分发管理模块负责元组分发，并异步地批量发送元组至共享持久存储系统中。当系统检查点到来时，系统将处理单元处理状态存储在共享持久存储系统中。

(4)弹性执行协调模块，用于根据流速信息灵活地开启、关闭处理线程、进程、节点，调整处理单元并行数，以精确控制元组在分发系统中的停留时间和处理节点的处理时延。

当收到流速感知模块的感知信息，分析出应用数据输入率变大、延迟变大或节点过于繁忙时，弹性执行协调模块会寻求开启更多的处理单元；当节点由于其他应用输入率变大而使此应用可用资源变少而处理效率变低时，弹性执行协调模块会寻求开启更多的处理单元。当应用数据输入率变小(流速降低)并且节点资源利用率过低时，将多个资源利用率低的节点上的处理单元合并或迁移到其中一个节点上，减少处理单元并行数，减少节点。

此模块设置的目的是为了让系统能够对用户透明底应对输入流速变化、在共享计算环境下根据处理单元处理效率变化而改变执行策略同时兼顾提高资源利用率。

图4简单列出了此模块工作方式。图4(a)中描述了一个弹性扩展过程。扩展的对象可以是流应用执行拓扑图中简单的处理单元，也可以是集群中整个计算节点。当接收到流速感知发来的流速消息时，对流速消息处理以得出处理单元的处理效率。当处理单元处理元组延迟在连续探测f次时都超过设定的扩展阈值，则开始对处理单元进行扩展。判断处理单元状态是否需要分割，若需要，将处理状态分割到新启动的处理单元上，然后调整元组的分发关系。当节点的资源利用率超过预先设定的阈值时，则节点需要扩展，向资源管理模块请求新的节点后，部署管理模块部署节点上的处理单元，对处理单元扩展。当流速降低，节点资源使用率低于预设值时，启动了收缩过程如图4(b)。合并节点上的处理单元，若处理单元存在处理状态需要合并，状态管理负责合并，若不需要，直接杀死不需要的处理单元。然后将将要回收的计算节点其上的处理单元迁移到被选中的资源使用率相对较低的计算节点上，并调整分发关系，使系统正确平稳运行。

(5)状态管理模块，阶段性地将处理节点的处理状态保存在持久化存储系统中，并异步地对旧的状态版本进行清除以腾出存储空间，节约存储资源。在弹性扩展和收缩时负责分割和合并相应的处理状态。在恢复时负责寻回相应状态。当合并和分割处理单元时，存储系统中的状态也进行相应的分割。以便失效恢复时，更好更快的找到因为失效或者失误丢失的状态。

所述状态管理模块将处理状态阶段性地存在持久存储器中。对旧版本的处理状态及相应元组定时异步清理，以保证使用尽可能少的存储器资源。当弹性执行时状态管理模块参与分割处理状态和合并处理状态。

(6)错误检测模块，用于检测节点失效，系统异常，运行错误等。当检测到错误时，向恢复协调模块发送错误报告，以便系统快速响应。

(7)恢复协调模块，用于当错误发生且对应用、系统产生影响时，与元组分发管理模块、部署管理模块、弹性执行协调模块、集群管理模块、状态管理模块一起对应用或者系统进行快速恢复。

当错误检测模块检测到错误发生后，将错误报告给恢复协调模块。恢复协调模块根据错误信息判断出错规模，是处理单元失效或者处理节点失效。接着暂停系统计算，向部署管理模块申请重新部署失效的处理单元/节点。部署管理模块需要新节点时向集群管理模块申请新节点。当任务重新部署成处理单元后。恢复协调模块请求状态管理模块从持久存储系统中寻回失效处理单元在失效时间点前保存的最新的处理状态及此处理状态后处理单元要继续处理的元组(元组分发管理模块成批备份在持久存储系统中的元组)，并根据元组的规模判断是否结合弹性执行协调模块进行并行恢复。具体的恢复过程如下：

图5展示了一个完整失效恢复过程。当检测到错误发生后，对错误发生的等级进行判断。若发生在某应用的处理单元中，则暂停相应流应用的处理，而其他流应用正常计算。若发生在某节点上，则暂停节点上处理单元涉及的流应用。若处理单元失效，则重启处理单元；判断处理单元是否有状态，若有状态，则从持久存储中寻回处理状态和保存的处理状态检查点以来的其应处理的元组；判断上述步骤中元组的数量，若多于设定值时，则联合弹性执行协调模块，将处理状态和元组进行分割成多个处理单元进行并行恢复。若节点失效，向集群管理模块申请新的节点，从部署管理模块寻回其上的处理单元，对每个处理单元做恢复。

(8)集群管理模块，系统部署运行在集群之上，用于扩展需要新节点时向部署管理模块提供新节点。当有多余的节点退出系统时，需要此模块来进行节点回收。

(9)应用管理模块，用于将用户根据系统提供的API编写的流应用描述映射成逻辑拓扑图，交予部署管理模块进行应用部署。

本发明的部署非常简单，首先，将下载好的代码放在用户可执行路径中，给予执行命令相应的运行权限，设置好配置文件，即可运行。对于开发人员配合系统使用的第三方库或系统，开发人员部署好第三方库或系统，在配置文件上修改配置即可。

用户向系统提交应用也是非常简单，系统给用户提共提交命令和处理接口，用户将开发好的应用代码打包放在系统可以查看并有拷贝权限的路径，使用提交命令按命令格式提交即可。用户提交一个应用后，流计算系统的应用管理模块接收并将应用代码拷贝到管理节点上，将代码解析成部署管理模块可以识别和分割的格式(如json)；部署管理模块对应用进行相应的识别、分割、向工作节点发送任务代码；工作节点收到任务代码后，启动相应的处理单元；元组分发调整模块根据处理单元的逻辑关系，设置发送关系；流速感知模块启动，感知工作节点及其上部署的处理单元处理效率，分发系统中元组停留延迟。弹性执行协调模块启动，开始协调工作。应用在流速感知、弹性执行协调等模块的作用下延迟有保证地稳定运行。状态管理模块阶段性地保存当前处理状态。当应用某部分被意外杀死，或工作节点出现宕机异常时，恢复协调模块进行相应的快速恢复工作。

本领域的技术人员应当理解，以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。

Claims (5)

1.一种实时流计算流速感知弹性执行容错系统，其特征在于，所述系统包括部署管理模块、流速感知模块、元组分发管理模块、弹性执行协调模块、状态管理模块、错误检测模块、恢复协调模块、集群管理模块、应用管理模块，所述集群管理模块、应用管理模块、部署管理模块、协调恢复模块、弹性执行协调模块部署在管理节点上，流速感知模块、元组分发管理模块、状态管理模块、错误检测模块部署在所有工作节点上，其中：

所述部署管理模块，用于依据流应用逻辑拓扑图请求将应用部署成并行的多线程组成的执行拓扑图，还用于接受弹性执行协调模块发来的扩展请求和收缩处理请求，进行对用户透明地应用重新部署，还用于记录处理单元的部署信息、任务信息，以便节点或处理单元失效后进行恢复处理；

所述流速感知模块，用于感知应用数据输入率、可用资源变化而引起延迟、资源利用率信息变化，从而结合弹性执行协调模块进行运行时动态调整,以达到保证系统稳定运行和应用延迟的目的；

所述元组分发管理模块，用于根据流速感知信息或弹性执行协调模块的请求调整元组分发，将元组发给下一阶段中会最快处理的处理节点；或者当流速稳定时根据已经固定的分发关系，快速地成批地分发元组；元组分发管理模块还用于记录元组的发送关系并发送元组，同时成批地将元组发送一份到持久存储器中，以便容错恢复；

所述弹性执行协调模块，用于根据流速信息开启或关闭处理线程、进程或节点，调整处理单元并行数，以控制元组在分发系统中的停留时间和处理节点的处理时延；

所述状态管理模块，用于阶段性地将处理节点的处理状态保存在持久化存储系统中，并异步地对旧的状态版本进行清除以腾出存储空间，节约存储资源；在弹性扩展和收缩时负责分割和合并处理单元的处理状态；在恢复时负责寻回相应状态；当合并和分割处理单元时，存储系统中的状态也进行相应的分割，以便失效恢复时，更好更快地找到因为失效或者失误丢失的状态；

所述错误检测模块，用于检测节点失效、系统异常以及运行错误信息，当检测到上述信息时，向恢复协调模块发送错误报告，以便系统快速响应；

所述恢复协调模块，用于当错误发生且对应用、系统产生影响后，与元组分发管理模块、部署管理模块、弹性执行协调模块、集群管理模块、状态管理模块一起对应用或者系统进行快速恢复；

所述集群管理模块，部署运行在集群之上，用于需要扩展新节点时向部署管理模块提供新节点；当有多余的节点退出系统时，用于节点回收；

所述应用管理模块，用于将流应用转换成逻辑拓扑图，交予部署管理模块进行应用部署。

2.如权利要求1所述的实时流计算流速感知弹性执行容错系统，其特征在于，所述流速感知模块包括节点流速感知子模块和应用级流速感知子模块；其中：所述节点流速感知子模块，用于感知单位时间内通过节点元组数量即处理单元处理元组的处理效率；所述应用级流速感知子模块，用于感知应用中的数据流过处理阶段的流速，此流速可以用元组在元组分发管理模块中停留的时间来进行衡量。

3.如权利要求2所述的实时流计算流速感知弹性执行容错系统，其特征在于，所述流速感知与流速计算方式具体为：

所述节点流速感知子模块使用单位时间内流过处理节点上的元组数m与元组在此单位时间内的平均流经时间t₂的比值m/t₂作为衡量处理节点流速的方式；

所述应用级流速感知子模块使用单位时间内队长变化ΔL与单位时间t的比值ΔL/t来衡量分发系统中相关流流速的方式。

4.如权利要求1或2所述的实时流计算流速感知弹性执行容错系统，其特征在于，所述弹性执行协调模块具体用于：当收到流速感知模块的感知信息，分析出应用数据输入率变大、延迟变大或节点过于繁忙时，弹性执行协调模块寻求开启更多的处理单元；当节点由于其他应用输入率变大而使此应用可用资源变少而处理效率变低时，弹性执行协调模块寻求开启更多的处理单元；当应用数据输入率变小并且节点资源利用率过低时，将多个资源利用率低的节点上的处理单元合并或迁移到其中少数个节点上，减少处理单元并行数，减少节点。

5.如权利要求1或2所述的实时流计算流速感知弹性执行容错系统，其特征在于，所述恢复协调模块具体的恢复协调过程为：

当检测到错误发生后，对错误发生的等级进行判断；若发生在某应用的处理单元中，则暂停相应流应用的处理，而其他流应用正常计算；若发生在某节点上，则暂停节点上处理单元涉及的流应用；

若处理单元失效，则重启处理单元；判断处理单元是否有状态，若有状态，则从持久存储中寻回处理状态和保存的处理状态检查点以来的其应处理的元组；判断上述步骤中元组的数量，若多于设定值时，则联合弹性执行协调模块，将处理状态和元组进行分割成多个处理单元进行并行恢复；若节点失效，向集群管理模块申请新的节点，从部署管理模块寻回其上的处理单元，对每个处理单元做恢复。