[发明专利]一种面向实时流计算的动态逐级反压方法

说明书

一种面向实时流计算的动态逐级反压方法，根据任务(Task)节点的当前自身负载情况来调整上游向其发送数据的速率，当某一Task过载导致延迟增加，上游的Bolt会减缓向下游发射的速率，更多的资源会被用来处理当前的正在处理的数据上，避免因阻塞、数据超时、重发等导致的延迟增加。当Task的负载降低至最小阈值且持续sensitivity秒，Task会向上游发送取消反压信号，上游Task收到取消反压信号后首先会检查自身是否处于反压状态，若是则会恢复上一次的发射速度，只有当组件恢复至初试速度时才会消除反压状态。本发明减少拓扑中单个任务对整体延迟的影响、反压过程平滑、系统不会出现负载振荡。

技术领域

本发明涉及信息技术领域，具体涉及一种面向实时流计算的动态逐级反压方法。

背景技术

从社交网络资讯(以提供热门话题或实时搜索)到广告处理数据引擎，实时流计算在当今工业中被广泛地使用，如Apahe Storm，Twitter’s Heron，Apache Flink，SparkStreaming，Samza等。在这些系统中，数据的产生完全由数据源确定，数据源的动态变化及状态不统一导致数据流的速率呈现出了突发性的特征，而数据流的突发性特征常常导致过载的发生，发生过载还有以下几个原因：网络拥塞，资源利用率高，干扰，异质性，IO高频阻塞等。因此，在实时流计算中，过载是常见且难以避免的。

实时流计算已被许多知名企业应用于大数据计算领域，如淘宝实时分析、阿里云Galaxy实时计算、携程网站性能监控等。对于实时性系统，系统的响应性和稳定性是关注的重点。响应意味着降低处理数据的延迟，即数据计算延迟，例如，数据从它输入至系统中到其结果反映给用户所经过的时间；稳定性意味着系统能够稳定持久地在集群中运行。而过载的发生极易导致系统整体的数据计算延迟增加和不稳定甚至不可用。

对于流计算而言，数据流是不可控的：数据到达时机不可控、数据质量不可控、上游数据流量不可控。以阿里巴巴集团2016年11月11交易情况为例，当天成交额达178亿美元，阿里云于最高峰时每秒处理17.5万笔交易，支付宝于最高峰时每秒处理12万笔，这个交易额是平时的数十万倍，这就要求系统能够动态适应不确定的数据流，具有大数据流量动态匹配的能力。而现有的大部分实时流计算系统缺大数据流量动态匹配的能力，如ApacheStorm,Spark Streaming等。在实时流计算系统中，计算结构是一个有向无环图(DAG)，称为拓扑(Topology)，拓扑由数据流(Steam)，数据流的生成者组件(Spout)和运算组件(Bolt)组成。Task是拓扑中Spout或Bolt在运行时的实例。拓扑中的数据通常由上游发送组件主动推送给下游接收组件，上游组件在推送数据时不会考虑下游组件的负载情况、工作状态等因素，如果下游组件因过载无法处理数据，实时流计算系统一般采用快速失败(fail-fast)策略——如果接收组件不能处理传入的数据，系统将其丢弃。如果系统没有实现数据的容错，那么这个fail-fast将会导致无限制的数据被丢弃，即使系统实现了数据的容错，也只是简单地将丢失的数据重新发送，没有动态匹配的能力。这样的设计会导致Topology在消耗所有集群资源的情况下拓扑任务没有任何进度。

Mitzenmacher M提出的方法是通过让输入的数据随机选择下游的两个最小负载的服务器节点来减少延迟。但是，这种技术本质上依赖输入的数据获取所有服务器节点的最新负载信息，而在快速移动的以毫秒为单位进行的流处理系统中，持续地监控服务器节点负载会严重加剧系统负荷，这使得这种方式难以真正实现。Twitter的Heron是2016年提出的实时流计算系统，实现的方法是直接遏制源头的反压策略，但这种方法可能不是最优的，因为可能仅仅只需要遏制上游的发送速度，而直接遏制源头的策略会导致整体Topology延迟取决于运行最慢的组件。

发明内容