一种基于Storm实时流计算框架的消息可靠处理保障方法

摘要

本发明公开了一种基于Storm实时流计算框架的消息可靠处理保障方法，包括：①预处理阶段，对环境做初始化工作；②集群计算过程中对已经发射并正处于计算状态的数据进行跟踪；③发射任务在监听到消息处理成功的信号时，清空缓存区中属于它的所有子元组的跟踪信息；④发射任务在监听到消息处理失败的信号时，定位产生处理失败的任务的位置和待恢复数据；⑤根据跟踪信息和xml文件构建消息恢复程序，然后从缓存区读取待恢复数据，执行消息恢复程序；⑥清空缓存区，释放内存空间。本发明在消息恢复时避免了复杂拓扑业务下存在的大规模重复计算，有效地减少消息恢复的计算量，从而提升整个业务场景下数据处理的性能，保证实时处理对低延迟的需求。

说明书

技术领域

本发明属于海量数据处理、实时流计算和容错领域，更具体地，涉及 一种基于Storm实时流计算框架的消息可靠处理保障方法。

背景技术

近年来大数据处理的需求不断增多，如何处理庞大的海量数据充满挑 战。随着互联网的进一步发展，从门户网站浏览型到搜索型到SNS关系交 互传递型，以及电子商务将生活中的流通环节在线化。对于效率的要求让 人们对实时性的要求进一步提升，而信息的交互正在往信息网的方向发展， 必然带来数据各个维度的交叉关联，数据爆炸已不可避免。流式数据实时 计算框架随之诞生，比如Twitter Storm、Yahoo S4、IBM Streambase、 Borealis等。通过类似于Storm的实时数据流计算框架，开发人员可以快 速搭建一套健壮的实时流计算框架，配合数据库使用可以低成本的开发出 优秀的实时产品。

Storm是2011年9月由Twitter公司开源的流式数据实时计算框架， 是目前工业界技术最成熟的流计算框架之一。数据流处理平台通常基于故 障恢复的高可用方法有三类：积极备用（Active Standby）,消极备用 （Passive Standby）和上游备份（Upstream Backup）。在上游备份方式 下，每个处理节点的缓存队列维持输出数据到一直到接收到来自下游节点 的确认信号为止，在下游处理节点发生故障时，通过上游重发队列中的数 据来恢复计算。为了保证实时计算在处理数据时低处理时延的特性、同时 降低资源消耗，Storm对上游备份机制进行了改进：（1）监控线程（Acker） 对处理过程进行跟踪，使用高效的异或算法定位，一旦检测到故障发生， 通知数据源重新发射根元组数据；（2）处理节点无需缓存计算结果，而是 在处理完元组后发送确认信号给监控线程，监控线程负责监视根元组及其 衍生的元组树上的元组是否完成处理。

为了保证数据处理的低延迟性，Storm对数据的处理完全基于内存。如 图1所示，数据以流的方式持续不断到来，发射任务（Spout）将消息以元 组的数据结构发送给处理任务（Bolt），处理任务对元组执行已定义好的 计算，再将处理后的结果子元组传递给下一个处理任务来计算，这样一个 个算子节点和一条条数据流边形成了工作流（topology）。一个消息从发 射任务发送出来可能导致成百上千的消息基于此消息被创建，这些消息构 成一个树状结构，称之为元组树。一个元组数据被完整处理指由它衍生的 元组树上的消息都被成功处理。Storm消息恢复机制可以确保发射任务发射 的每一个元组数据都会被完整的处理。

Storm为保证消息处理的可靠性，消息处理失败发生时，容错机制会通 过监控线程检测到消息失败，同时映射到所在的根元组，然后通知发射任 务开始重新处理整个元组树上的任务，在此情况下，不可避免的存在部分 已经计算过的任务将重新计算，如图2所示。此消息恢复的代价与元组树 上处理失败元组的高度成正比，消息重复处理浪费计算资源，对于较复杂 的实时场景，恢复时间会很长。

综上所述，此故障恢复机制下，消息恢复是通过监控线程通知发射任 务，然后由发射任务重新发送根元组给下游处理任务重做计算完成的，由 于计算基于内存，每次处理任务的执行线程在发射处理后的元组给下游任 务时不继续保存元组，因此消息恢复要重做元组树上的所有任务。在实时 计算工作流场景较复杂，元组树高度成千上万，处理任务计算逻辑复杂度 很高的情况下，一旦某个子元组处理失败，消息恢复代价将非常高。

发明内容

针对现有技术的以上缺陷或改进需求，本发明提供了一种基于Storm 实时流计算框架的消息可靠处理保障方法，其目的在于，解决现有Storm 系统中存在的消息重复处理浪费计算资源，在处理任务计算逻辑复杂度很 高的情况下，一旦某个子元组处理失败，消息恢复代价非常高的技术问题。

为实现上述目的，按照本发明的一个方面，提供了一种基于Storm实 时流计算框架的消息可靠处理保障方法，包括以下步骤：

（1）用户创建工作流程序，根据该工作流程序的拓扑信息生成xml文 件，并将该工作流程序发送到主节点，其中工作流程序包括多个发射任务、 处理任务以及任务的上下游关系；

（2）主节点根据接收到的工作流程序生成拓扑程序，用于存储工作流 任务，根据该拓扑程序创建缓存区，并将不同的工作流任务分配到对应的 从节点执行，其中工作流任务包括发射任务或处理任务；

（3）从节点启动工作者进程判断来自主节点的工作流任务的类型是否 为发射任务，如果是发射任务则进入步骤（4），否则持续等待下一个工作 流任务，并重复步骤（3）；

（4）发射任务读取工作流程序中指定的数据源中的流式数据，将其封 装成根元组数据，并在根元组数据中新增哈希表，用于记录该根元组数据 的位置信息；

（5）发射任务根据工作流程序中组件的上下游关系将根元组数据发射 给其下游的处理任务，并发送该根元组数据的初始化信号到监控线程；

（6）监控线程在本地哈希表中创建并维护该根元组数据的监控信息；

（7）发射任务监听是否接收到来自监控线程的根元组数据的确认信 号，如果接收到则判断确认信号的类型，当类型是处理成功信号时，清空 步骤（2）中的缓存区记录的根元组数据所在元组树上所有子元组数据的跟 踪信息；当类型是处理失败信号时，则根据缓存数据和确认信号定位出消 息处理失败任务的位置，记录该位置到任务处理失败集合并将待恢复的数 据写入缓存区中相应的消息队列中，然后清空缓存区中此根元组数据所在 元组树上的已被处理的元组数据的跟踪信息，如果未接收到则进入步骤 （8）；

（8）从节点启动工作者进程判断来自主节点的工作流任务的类型是否 为处理任务，如果是处理任务则进入步骤（9），否则返回步骤（3）；

（9）处理任务对来自上游的元组数据进行处理，以生成新的元组数据， 该新的元组数据是根元组数据所在元组树上的子元组，在子元组数据中新 增哈希表记录子元组数据的位置信息；

（10）处理任务将来自上游的元组数据的跟踪信息写入步骤（2）中的 缓存区；

（11）处理任务将新的元组数据发送给下游的处理任务，同时发送元 组数据处理成功的确认信号到监控线程；

（12）监控线程将确认信号的值与本地哈希表中根元组数据的值进行 异或运算，并判断异或运算的结果是否为0，如果为0，则发送根元组处理 成功的确认信号给发射任务，然后返回步骤（7），否则进入步骤（13）；

（13）下游的处理任务重复执行步骤（8）至（12），直到无工作流任 务为止；

（14）监控线程检查本地哈希表中根元组数据的值，如果值不为0，则 发送根元组处理失败的确认信号给发射任务，然后返回步骤（7），否则过 程结束；

（15）Storm集群完成处理流数据后，用户搭建恢复工作流程序并提交 到Storm集群执行。

优选地，步骤（1）具体为，用户根据流处理应用的业务场景创建工作 流程序，然后创建用于记录工作流程序的拓扑结构信息的xml文件，最后 提交工作流程序到集群的主节点等待被处理。

优选地，步骤（2）具体为，主节点的服务端程序监听到用户提交工作 流程序的请求后开始接收，接收结束后对原工作流程序进行封装，以生成 Storm可以处理的拓扑程序，并启动监控线程，然后在计算开始前创建程序 执行所需的缓存区，最后主节点将拓扑程序中记录的不同的工作流任务分 配到对应的从节点。

优选地，元组数据跟踪信息包括：元组数据的数据值、处理任务的标 识及根元组数据的标识。

优选地，步骤（15）具体包括以下子步骤：

（15-1）解析步骤（1）生成的xml文件，并读取工作流程序的任务；

（15-2）根据缓存区的任务处理失败集合中处理失败任务的位置信息创 建消息恢复程序的工作流；

（15-3）将恢复工作流程序的发射任务的消息源设置为步骤（15-2）中 从缓存区读到的处理任务对应的消息队列；

（15-4）提交消息恢复程序到Storm集群并执行恢复计算；

（15-5）判断任务处理失败集合是否为空，如果为空则进入步骤（15-6）， 否则说明仍有处理任务需要恢复处理，然后返回步骤（15-2）；

（15-6）清空缓存区中的数据，并释放内存空间。

优选地，步骤（15-2）具体为，从缓存区读取任务处理失败集合中处理 任务的信息，恢复程序中使用发射任务代替该处理任务，然后根据步骤 （15-1）中解析出的xml记录的原工作流程序的拓扑结构信息确定剩余处理 任务和各自的位置并重新构建恢复工作流程序，最后从任务处理失败集合 中移除该处理任务的信息。

总体而言，通过本发明所构思的以上技术方案与现有技术相比，能够 取得下列有益效果：

1、高效性：本发明避免消息恢复时从数据源开始重做元组树上所有任 务，解决重复计算问题，恢复代价不再取决于工作流的复杂程度和消息处 理失败的位置；从而有效的提高消息恢复速度，降低对计算资源的消耗；

2、实时性：本发明消息恢复效率的提高，进一步满足了实时流处理框 架低处理延迟的特点，提高实时处理能力。

3、方便性：本发明完全由软件实现，在开源项目Storm的基础上开发， 无需特殊的硬件支撑环境，易于安装和使用；

4、透明性：本方法的实现兼容Storm计算系统的工作流编程范式，完 全不用修改原工作流程序，支持Storm系统原有功能，同时，无需改变软 硬件环境。

附图说明

图1是现有Storm系统的工作流图。

图2是现有Storm系统消息恢复的示意图。

图3为本发明基于Storm实时流计算框架的消息可靠处理保障方法的 原理图。

图4为本发明基于Storm实时流计算框架的消息可靠处理保障方法的 流程图。

具体实施方式

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

本发明的基本思路在于，通过设计新的消息监控与确认机制并引入追 踪算法定位消息失败发生的位置，同时加入缓存机制存储处理任务处理的 中间结果数据使算子节点状态持久化；修改Storm相关组件以实现新的消 息恢复策略。

本系统的工作流实例如图3所示。实时应用场景被Storm封装成各组 件组成的拓扑结构工作流，首先消息队列将信息以数据流的形式传递给发 射组件，发射组件会将数据分解成基本数据单元元组，按序发射根元组给 下游处理任务，发射前将根元组注册给监控线程（Acker）；处理任务在处 理完元组后发送新元组给下游组件，同时发送确认信息给监控线程。消息 恢复时，从产生消息失败组件的上游组件开始恢复计算，恢复数据从缓存 区消息队列中获取，这样解决了Storm原容错机制从数据源发射组件重发 根元组而产生的重复计算问题。

如图4所示，本发明基于Storm实时流计算框架的消息可靠处理保障 方法包括以下步骤：

（1）用户创建工作流程序（Topology），根据该工作流程序的拓扑信息 生成xml文件，并将该工作流程序发送到主节点；具体而言，用户根据流 处理应用的业务场景（例如实时搜索、流数据挖掘、Web日志分析等）创 建工作流程序，工作流程序包括多个发射任务（Spout）、处理任务（Bolt） 以及任务的上下游关系，然后创建用于记录工作流程序的拓扑结构信息的 xml文件，最后提交工作流程序到集群的主节点等待被处理；

（2）主节点根据接收到的工作流程序生成拓扑程序，用于存储工作流 任务，根据该拓扑程序创建缓存区，并将不同的工作流任务分配到对应的 从节点执行；具体而言，主节点的服务端程序监听到用户提交工作流程序 的请求后开始接收，接收结束后对原工作流程序进行封装，以生成Storm 可以处理的拓扑程序，并启动监控线程，然后在计算开始前创建程序执行 所需的缓存区，最后主节点将拓扑程序中记录的不同的工作流任务分配到 对应的从节点，工作流任务包括发射任务（Spout）或处理任务（Bolt）；

（3）从节点启动工作者（worker）进程判断来自主节点的工作流任务 的类型是否为发射任务，如果是发射任务则进入步骤（4），否则持续等待 下一个工作流任务，并重复步骤（3）；

（4）发射任务读取工作流程序中指定的数据源中的流式数据，将其封 装成根元组数据，并在根元组数据中新增哈希表，用于记录该根元组数据 的位置信息；

本步骤的优点在于，在根元组数据初始化阶段记录位置信息，方便其 子元组数据记录位置信息时使用；

（5）发射任务根据工作流程序中组件的上下游关系将根元组数据发射 给其下游的处理任务，并发送该根元组数据的初始化信号到监控线程；

（6）监控线程在本地哈希表中创建并维护该根元组数据的监控信息；

（7）发射任务监听是否接收到来自监控线程的根元组数据的确认信 号，如果接收到则判断确认信号的类型，当类型是处理成功信号时，清空 步骤（2）中的缓存区记录的根元组数据所在元组树上所有子元组数据的跟 踪信息；当类型是处理失败信号时，则根据缓存数据和确认信号定位出消 息处理失败任务的位置，记录该位置到任务处理失败集合并将待恢复的数 据写入缓存区中相应的消息队列中，然后清空缓存区中此根元组数据所在 元组树上的已被处理的元组数据的跟踪信息，如果未接收到则进入步骤 （8）；

本步骤的优点在于，及时释放内存中已经处理成功的元组的跟踪信息， 防止内存溢出；处理失败时根据跟踪信息定位出失败产生的位置并释放内 存。

（8）从节点启动工作者进程判断来自主节点的工作流任务的类型是否 为处理任务，如果是处理任务则进入步骤（9），否则返回步骤（3）；

（9）处理任务对来自上游的元组数据进行处理，以生成新的元组数据， 该新的元组数据是根元组数据所在元组树上的子元组，在子元组数据中新 增哈希表记录子元组数据的位置信息；

（10）处理任务将来自上游的元组数据的跟踪信息写入步骤（2）中的 缓存区，元组数据跟踪信息包括：元组数据的数据值、处理任务的标识及 根元组数据的标识；

（11）处理任务将新的元组数据发送给下游的处理任务，同时发送元 组数据处理成功的确认信号到监控线程；

（12）监控线程根据该确认信号在本地哈希表中更新根元组数据的监 控信息，即将确认信号的值与本地哈希表中根元组数据的值进行异或运算， 并判断异或运算的结果是否为0，如果为0，则发送根元组处理成功的确认 信号给发射任务，然后返回步骤（7），否则进入步骤（13）；

（13）下游的处理任务重复执行步骤（8）至（12），直到无工作流任 务为止；

（14）监控线程检查本地哈希表中根元组数据的值，如果值不为0，则 发送根元组处理失败的确认信号给发射任务，然后返回步骤（7），否则过 程结束；

（15）Storm集群完成处理流数据后，用户搭建恢复工作流程序并提交 到Storm集群执行，具体包括以下子步骤：

（15-1）解析步骤（1）生成的xml文件，并读取工作流程序的任务；

（15-2）根据缓存区的任务处理失败集合中处理失败任务的位置信息创 建消息恢复程序的工作流；具体而言，从缓存区读取任务处理失败集合中 处理任务的信息，恢复程序中使用发射任务代替该处理任务，然后根据步 骤（15-1）中解析出的xml记录的原工作流程序的拓扑结构信息确定剩余处 理任务和各自的位置并重新构建恢复工作流程序，最后从任务处理失败集 合中移除该处理任务的信息；

（15-3）将恢复工作流程序的发射任务的消息源设置为步骤（15-2）中 从缓存区读到的处理任务对应的消息队列；

（15-4）提交消息恢复程序到Storm集群并执行恢复计算；

（15-5）判断任务处理失败集合是否为空，如果为空则进入步骤（15-6）， 否则说明仍有处理任务需要恢复处理，然后返回步骤（15-2）；

（15-6）清空缓存区中的数据，并释放内存空间。

本发明适用于分布式大数据实时流计算应用环境，在流处理系统框架 的软件层面进行容错，可以满足系统在消息处理过程中，当负责处理任务 的线程处理数据失败情况下对消息进行恢复。同时保障恢复低延迟、低成 本的需求且不对处理结果产生误差影响。与Storm原有消息恢复机制相比， 本发明避免了复杂拓扑业务下可能会进行大量重复计算问题，减少消息恢 复的计算量，从而提升整个业务场景下海量数据处理的性能。

综上所述，本发明解决了消息处理失败产生情况下，消息恢复时对消 息的重复处理问题，从而在消息恢复时避免了复杂拓扑业务下存在的大规 模重复计算，有效地减少消息恢复的计算量，从而提升整个业务场景下数 据处理的性能，保证实时处理对低延迟的需求。

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