[发明专利]一种分布式海量实时数据流灾难恢复系统及方法

说明书

技术领域

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

背景技术

随着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。