CN107491359A - 一种分布式海量实时数据流灾难恢复系统及方法 - Google Patents

Abstract

本发明公开了一种分布式海量实时数据流灾难恢复系统及方法。通过采用上游备份的策略。在每个计算节点中维持两个窗口，一个为当前滑动窗口的子窗口，另一个为备份窗口。同时设置一资源池和一监控节点，通过监控节点监控计算节点的运行情况，解决了分布式实时数据流处理系统中计算节点失效导致系统崩溃的问题。应用滑动窗口备份策略解决了计算节点数据丢失无法恢复的问题，有效解决了分布式海量实时数据流系统灾难恢复的问题。

Description

一种分布式海量实时数据流灾难恢复系统及方法

技术领域

本发明属于计算机软件开发及大数据处理领域，具体涉及一种分布式海量实时数据流灾难恢复系统及方法。

背景技术

随着Web2.0时代的到来和云计算、物联网、移动互联网的快速发展，实时性应用(如智能传输系统、交通管理系统、网络流管理系统等)系统都会产生海量的流数据。

传统集中式环境下的数据流实时处理系统在应对大数据流时，首先要先对进入到系统的数据记录进行储存，而后再根据业务逻辑需求对这些数据进行处理来获取系统所需信息，随着网络技术的提升，数据传输的速度也飞速增长，进入数据流模型中的数据记录的规模越发巨大，且数据到达系统的速度越来越快，导致传统的海量数据流处理技术难以达到系统对实时性的需求。

Storm是一个免费并开源的分布式实时计算系统。利用Storm可以很容易做到可靠地处理无限的数据流，像Hadoop批量处理大数据一样，Storm可以通过分布式实时处理海量数据。在Storm中可以通过一种信息确认机制保证数据流在节点处理单元bolt以及节点之间可靠传输。但在数据流连接中，滑动窗口中的元素都保存在内存中，当某个节点失效时保存在该节点上的元组将全部丢失，导致数据流无法连接。如何使计算快速从故障中恢复正常工作是数据流处理系统亟待解决的问题。

发明内容

本发明的目的在于克服现有技术的不足，提供一种分布式海量实时数据流灾难恢复系统及方法。

为解决上述技术问题，本发明是通过以下技术方案实现的：

步骤一、采用滑动窗口机制对海量实时数据进行静态化处理，其中，滑动窗口每次滑动的区间设为N，该区间只包括数据流中最近到来的那部分数据，随着新数据的到来，窗口向前移动，用最新的数据替换最旧的数据。

步骤二、数据流中的每个元组都带有一个增量的序号，同时每个元组都带有一个时间戳，时间戳能够代表来自不同数据流的元组之间的先后顺序，由于网络延迟等原因造成元组到来时间可能不同，通过三层握手机制进行校正。

步骤三、将滑动窗口划分为多个子窗口，并依次分配到各个相邻的计算节点上。

步骤四、采用上游备份的策略。在每个计算节点中我们维持两个窗口，一个为当前滑动窗口的子窗口，另一个为备份窗口。每个在当前滑动窗口中的元组均在上游节点的备份窗口中保留一份拷贝。

步骤五、当一个元组进入某个计算节点时，首先进行连接操作，然后插入到位于该节点的滑动窗口中；离开该节点时，它的一份拷贝将被插入到备份窗口中，同时一个确认清除消息将发送到上游节点，将该元组在上游节点备份窗口中的元组清除。

步骤六、设置一资源池和一监控节点，资源池中存放计算节点，监控节点通过心跳机制与计算节点定时确认，监测某个节点是否正常运行。

步骤七、监控节点检测到某个节点崩溃时立刻从资源池中立刻取出新计算节点将其加入到流水线系统中。

步骤八、监控节点立刻通知各个数据流的上游节点，当上游节点收到消息时，将其备份窗口和当前滑动窗口内的元组发送到备份节点。

步骤九、备份节点在收到元组后，将上游节点备份窗口内的元组保存到当前滑动窗口中，将上游节点滑动窗口中的元组保存到当前节点备份窗口中。

本发明与现有技术相比，其有益之处在于：我们将灾难恢复过程分成三部分：(1)节点恢复阶段，该阶段内一个新的计算节点将从资源池中取出，然后添加到数据流流水线中；(2)备份元组传输阶段，上游节点滑动窗口和备份窗口中得元组将在该阶段内传送到新的计算节点；(3)当一个节点失效时，一个新节点将立刻接管该节点的工作，所有的数据都可通过邻居节点恢复。

附图说明

图1是系统流程图。

具体实施方式

以下参照附图1，给出本发明的具体实施方式，用来对本发明做进一步说明。

实施例1：

步骤一、搭建Zookeeper集群，根据Zookeeper集群的负载情况，合理设置Java堆大小，根据Zookeeper集群节点情况，创建Zookeeper配置文件zoo.cfg：tickTime＝2000

dataDir＝/var/zookeeper/

clientPort＝2181

initLimit＝5

syncLimit＝2

server.1＝zoo1：2888：3888

server.2＝zoo2：2888：3888

server.3＝zoo3：2888：3888。

步骤二、安装Storm依赖库，下载并解压Storm发布版本，修改配置文件storm.yaml并启动Storm各个后台进程。

步骤三、本实施例中采用滑动窗口机制对海量实时数据进行静态化处理，其中，滑动窗口每次滑动的区间设为N，当新数据记录到来时，窗口两端向着数据流向的方向移动。停留在数据窗口中的数据片段是当前要处理的数据集，最新到达系统的数据即待处理数据，直接连接到数据窗口中，当数据窗口被填满时，删除在窗口中停留时间最久的数据记录。

步骤四、在图1中，数据流中的每个元组都带有一个增量的序号，同时每个元组都带有一个时间戳，时间戳能够代表来自不同数据流的元组之间的先后顺序，由于网络延迟等原因造成元组到来时间可能不同，通过三层握手机制进行校正。

步骤五、滑动窗口划分，例如设定滑动窗口的区间为N，计算节点的数量n，子滑动窗口的大小为N/n，不能整除的情况下，采用上取整的策略。

步骤六、在图1中，假设数据流A为master流，以节点B为例，当元组a3进入节点B时，首先进行数据连接操作，然后插入到位于该节点的滑动窗口中。

步骤七、元组a3在节点B上向下游节点C(在数据流A中，相对节点B而言，上游节点为节点A，对接点C而言，上游节点为节点B)传送。元组a3离开节点B时，此时a3元组标记为失效，此时，一个a3的拷贝将插入备份窗口中，然后元组a3的另一个拷贝将被发送到节点C，节点C收到a3元组后，首先进行数据连接操作，然后插入到位于该节点的滑动窗口中，同时发送一个确认消息给上游节点B，一旦上游节点B收到确认消息，节点B的备份窗口中a3的拷贝将被删除。

步骤八、为防止某个计算节点失效造成整个系统崩溃，我们设置一资源池和一监控节点，资源池存放备用计算节点，监控节点每隔一段时间向系统内的计算节点轮询。

步骤九、当监控节点检测到某个节点崩溃，在图1中，当节点B失效后在它上面保存的所有元组，属于数据流A的a4，a5，a6都会丢失及其备份a1，a2，a3都会丢失。监控节点立刻通知系统从资源池中取出新计算节点将其加入到系统中。

步骤十、监控节点同时发送通知给数据流上游节点A，当上游节点A收到消息时，将其备份窗口和当前滑动窗口内的元组发送到备份节点B。

步骤十一、备份节点在收到元组后，将上游节点备份窗口内的元组保存到当前滑动窗口中，将上游节点滑动窗口中的元组保存到当前节点备份窗口中。

步骤十二、备份节点向监控节点发送确认信息，通知监控节点已正常工作。

对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本发明内。

此外，应当理解，虽然本说明书按照实施方式加以描述，但并非每个实施方式包含一个独立的技术方案，说明书的这种叙述方式仅仅是为清楚起见，本领域技术人员应当将说明书作为一个整体，各实施例中的技术方案也可以经适当组合，形成本领域技术人员可以理解的其他实施方式。

Claims (7)

1.一种分布式海量实时数据流灾难恢复系统及方法，其特征在于：滑动窗口，元组网络延迟，滑动窗口划分，上游备份策略，设置资源池和监控节点。

2.根据权利要求1所述的滑动窗口，其特征在于，将滑动窗口每次滑动的区间设为N，该区间只包括数据流中最近到来的那部分数据，随着新数据的到来，窗口向前移动，用最新的数据替换最旧的数据。

3.根据权利要求1所述的元组网络延迟，其特征在于，采用三层握手机制进行校正。

4.根据权利要求1所述的滑动窗口划分，其特征在于，将滑动滑动窗口划分为多个子窗口，并依次分配到各个相邻的计算节点上。

5.根据权利要求1所述的上游备份策略，其特征在于，在每个计算节点中我们维持两个窗口，一个为当前滑动窗口的子窗口，另一个为备份窗口。每个在当前滑动窗口中的元组均在上游节点的备份窗口中保留一份拷贝。

6.根据权利要求1所述的设置资源池和监控节点，其特征在于，资源池中存放计算节点，监控节点通过心跳机制与计算节点定时确认，监测某个节点是否正常运行。

7.根据权利要求6所述的心跳机制，其特征在于，监控节点每隔一段时间发送一个查询信息给计算节点，计算节点收到后回复一个确认信息，如果计算节点在该时间段内没有收到确认信息则视为失效。