CN114448983A - 基于ZooKeeper的分布式数据交换方法 - Google Patents

Abstract

本申请公开了一种基于ZooKeeper的分布式数据交换方法。首先在分布式系统中构建集群化的ZooKeeper服务端，并建立客户端与服务器的连接，连接成功后保存会话连接；其中，ZooKeeper的视图结构使用的数据节点方式为Znode；基于ARP协议配置ZooKeeper服务端中每台服务器的IP地址，其中包括真实IP地址和虚拟IP地址；启动服务器的ARP缓存，从ZooKeeper会话中连接Master节点IP，并通过轮询方式推荐Slave节点IP；基于推荐Slave节点IP在集群化的ZooKeeper服务端中获取可用服务器，并根据所获取的可用服务器与客户端完成交互。可以看出，本发明可以帮助用户在海量数据中，通过大数据分析得到目标数据。

Description

基于ZooKeeper的分布式数据交换方法

技术领域

本发明涉及数据处理领域，特别涉及一种基于ZooKeeper的分布式数据交换方法。

背景技术

随着信息化和大数据技术的快速发展，数据的重要性不言而喻，我们通过对数据进行汇总和分析使得数据的价值得以体现。然而多数情况下，存在着数据多源性、类型多样性等特点，为使数据分析结果准确，就需要数据采集交换的完备性和及时性作为保证。因此，数据采集交换的稳定性和可靠性显得尤为重要。

在实际发明落地过程中，由于数据量越来越多，个别维度数据已经达到了PB级，在计算环境没法升级的情况下，系统模型分析的速度有逐步下降的趋势，此时对大数据和大数据组件的优化，成了我们的必不可少的工作。

发明内容

基于此，本申请实施例提供了一种基于ZooKeeper的分布式数据交换系统，帮助用户在海量数据中，更高效的通过大数据分析得到目标数据。

本申请提供了一种基于ZooKeeper的分布式数据交换方法，该方法包括：

在分布式系统中构建集群化的ZooKeeper服务端，并建立客户端与服务器的连接，连接成功后保存会话连接；其中，ZooKeeper的视图结构使用的数据节点方式为Znode；所述ZooKeeper的节点构成的文件系统层级为树状结构，用于存储交换服务各节点的地址信息以及数据交换任务的执行位置和状态；

基于ARP协议配置ZooKeeper服务端中每台服务器的IP地址，其中包括真实IP地址和虚拟IP地址；

启动服务器的ARP缓存，从ZooKeeper会话中连接Master节点IP，并通过轮询方式推荐Slave节点IP；

基于推荐Slave节点IP在集群化的ZooKeeper服务端中获取可用服务器，并根据所获取的可用服务器与客户端完成交互。

可选地，所述基于ARP协议配置ZooKeeper服务端中每台服务器的IP地址，包括：

使用虚拟IP和Zookeeper实现集群HA，所述HA使用双机集群的方式，其中，一台为Master节点，负责对外提供服务，另一台为MasterBak节点，负责备份Master中的数据。

可选地，所述使用虚拟IP和Zookeeper实现集群HA，包括：

利用两台服务器向集群化的ZooKeeper服务端创建同名ZNode节点，根据ZNode的唯一性将节点创建成功的服务器作为Master节点，另一台服务器作为MasterBak节点。

可选地，将分布式系统中集群化的ZooKeeper服务端中的每个节点划分为Leader节点、Follower节点和Observer节点；

所述Leader节点用于调度集群内部各台服务器，并对事务请求进行调度和处理，同时保证事务处理的FIFO；

所述Follower节点用于指定Leader节点，并参与客户端事务请求投票，处理客户端非事务请求，以及转发事务给Leader服务器；

所述Observer节点用于处理客户端非事务请求，以及转发事务给Leader服务器。

可选地，所述在分布式系统中构建集群化的ZooKeeper服务端，包括：

构建2×N+1台服务器构成的Zookeeper集群，其中N表示所述Zookeeper集群允许服务器宕掉的最大数量。

可选地，所述基于ARP协议配置ZooKeeper服务端中每台服务器的IP地址，还包括：

ZooKeeper服务端中每两台服务器之间的通信经由MAC地址实现的，包括对方的IP地址解析为MAC地址，将信息发送到对应的服务器上。

可选地，所述基于推荐Slave节点IP在集群化的ZooKeeper服务端中获取可用服务器，并根据所获取的可用服务器与客户端完成交互，包括：

在集群化的ZooKeeper服务端中使用HDFS存储配置文件和数据信息，使用Yarn实现整个集群的资源管理和分配，其中：

所述HDFS采用Master/Slave架构，将集群节点分成NameNode、SecondaryNameNode和DataNode三种，NameNode和Secondary NameNode运行在Master节点上，DataNode运行在Slave节点上；

所述Yarn采用Master/Slave架构，将集群节点分成ResourceManager、NodeManager和ApplicationMaster三种。

可选地，在所述HDFS中：

所述NameNode负责掌握整个集群中所有DataNode的状态、维护整个文件系统的元数据信息、提供文件系统全景图、存储的数据块与存放该数据块的DataNode之间的映射关系；

所述SecondaryNameNode负责定期合并两个日志文件，日志中分别记载了某时刻HDFS的信息，和该时刻之后HDFS的变化，用于当NameNode崩溃之后进行NameNode的恢复；

所述DataNode负责执行具体的任务，并定期向NameNode反映自身的状况和存储的数据块的状况。

可选地，在所述Yarn中：

所述ResourceManager负责管理集群所有资源，当有作业请求时，会按照预设策略给作业分配运行所需的资源；

所述NodeManager运行在Yarn集群的每一个节点上，负责管理和监控所处节点的资源使用情况，并定期将情况汇报给Master；

所述ApplicationMaster负责与ResourceManager进行通信，请求ResourceManager分配执行任务所需的资源，然后与NodeManager协同工作，执行并监控任务。

可选地，所述根据所获取的可用服务器与客户端完成交互，包括：

通过Thrift框架实现客户端和服务器之间建立连接，并利用该连接进行信息的传输。

本申请实施例提供的技术方案中首先在分布式系统中构建集群化的ZooKeeper服务端，并建立客户端与服务器的连接，连接成功后保存会话连接；其中，ZooKeeper的视图结构使用的数据节点方式为Znode；基于ARP协议配置ZooKeeper服务端中每台服务器的IP地址，其中包括真实IP地址和虚拟IP地址；启动服务器的ARP缓存，从ZooKeeper会话中连接Master节点IP，并通过轮询方式推荐Slave节点IP；基于推荐Slave节点IP在集群化的ZooKeeper服务端中获取可用服务器，并根据所获取的可用服务器与客户端完成交互。可以看出，本发明的有益效果在于：可以帮助用户在海量数据中，通过大数据分析得到目标数据。

附图说明

为了更清楚地说明本发明的实施方式或现有技术中的技术方案，下面将对实施方式或现有技术描述中所需要使用的附图作简单地介绍。显而易见地，下面描述中的附图仅仅是示例性的，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图引伸获得其它的实施附图。

图1为本申请实施例提供的一种基于ZooKeeper的分布式数据交换流程图；

图2为本申请可选的一种实施例中的Zookeeper架构示意图；

图3为本申请可选的一种实施例中的ZNode树结构示意图；

图4为本申请可选的一种实施例中的系统负载均衡设计实现示意图；

图5为本申请可选的一种实施例中的双机集群Master节点的选举示意图；

图6为本申请可选的一种实施例中的双机集群的连接示意图；

图7为本申请可选的一种实施例中的HDFS架构示意图；

图8为本申请可选的一种实施例中的Yarn架构示意图；

图9为本申请可选的一种实施例中的远程调用结构示意图。

具体实施方式

以下由特定的具体实施例说明本发明的实施方式，熟悉此技术的人士可由本说明书所揭露的内容轻易地了解本发明的其他优点及功效，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

通过视频和数据的汇聚以及视频结构化等手段，管理平台沉淀了海量的数据，对其进行了元数据处理，给数据打上数据的拥有者、来源、性质、用途、安全等级等标签信息，并对数据进行合理的分区和存储。比如公共安全领域的研究方向中，重点研究了基于车辆和人脸识别技术的大数据研判模型，用于陌生人分析、人员地址分析等。

在实际发明落地过程中，由于数据量越来越多，个别维度数据已经达到了PB级，在计算环境没法升级的情况下，系统模型分析的速度有逐步下降的趋势，此时对大数据和大数据组件的优化，成了的必不可少的工作。具体地，请参考图1，其示出了本申请实施例提供的一种基于ZooKeeper的分布式数据交换方法的流程图，该方法可以包括以下步骤：

步骤101，在分布式系统中构建集群化的ZooKeeper服务端，并建立客户端与服务器的连接，连接成功后保存会话连接。

在本申请实施例中，考虑到系统要面对海量规模数据存储、检索和其他需求，并且考虑到服务器宕机或者其他异常情况，单台服务器性能明显不能满足用户功能要求。所以设计时采用了目前主流的方案，即将系统设计成分布式集群架构，通过集群的方式对外提供服务，既能提升系统性能，又有利于提升系统的稳定性。集群稳定性主要考虑两点：负载均衡和高可用性。通过虚拟IP这个关键技术和Zookeeper组件，实现系统的负载均衡和高可用性。Zookeeper是开源组织Apache的一项技术，目的是提供一个高效、高可用的分布式一致性管理系统。

在本申请一个可选的实施例中，Zookeeper没有采用传统的Master/Slave架构，而是选择另辟蹊径自己设计实现了一套方案。它将集群中的各节点分为Leader、Follower和Observer三种角色，由三者协同实现集群的管理。集群中的每个节点只能扮演一种角色，通过三者的共同作用实现集群的管理。系统中有大量的地方使用到了Zookeeper，通过Zookeeper对外提供的API，实现了集群管理、配置文件管理、负载均衡、Master选举等功能，同时系统中引入的诸如Hadoop、HBase和Solr等大数据组件，它们内部集成了Zookeeper或者通过Zookeeper实现自身集群的管理。Zookeeper中各角色作用介绍如图2所示。

(l)Leader：Leader通过选举产生，是整个Zookeeper集群的核心。主要负责调度集群内部各个服务器，并对事务请求进行调度和处理，同时保证事务处理的FIFO。

(2)Follower：Follower负责参与Leader的选举，还有参与客户端事务请求Proposal的投票，并处理客户端非事务请求，转发事务给Leader服务器。

(3)Observer：Observer的作用和Follower类似，但是不参与任何投票，Obseiver的作用仅仅是提高非事务处理能力。

在本申请实施例中，ZooKeeper的视图结构使用的数据节点方式为Znode；ZooKeeper的节点构成的文件系统层级为树状结构，用于存储交换服务各节点的地址信息以及数据交换任务的执行位置和状态，使用和传统文件系统类似的路径“/”分割路径的表示方式来标识每一个ZNode节点，ZNode树结构如图3所示。

其中，ZNode一共有四种类型：持久的、临时的、持久有序的和临时有序的。持久和临时的主要区别是：与Zookeeper连接关闭或者系统崩溃时，持久节点不会消失而临时节点会消失。对每一个ZNode可以进行两种操作：一是向ZNode中填充数据，二是创建子节点。

在进行Zookeeper集群部署时，如果要部署允许N台机器宕掉的集群，必须构建2×N+1台服务器构成的Zookeeper集群。因为Zookeeper有过半服务机制，即Zookeeper集群中有一半的Zookeeper节点存活时，Zookeeper才能正常对外提供服务。集群服务器数量为奇数是为了保证Zookeeper集群能够顺利选举出Leader。

步骤102，基于ARP协议配置ZooKeeper服务端中每台服务器的IP地址。

步骤103，启动服务器的ARP缓存，从ZooKeeper会话中连接Master节点IP，并通过轮询方式推荐Slave节点IP。

在本申请实施例，每台服务器的IP包括真实IP地址和虚拟IP地址。

虚拟IP是指一台服务器除了有网络分配的一个IP地址之外，还有一个虚拟的IP地址，用两个IP地址中的任意一个都能访问到该服务器。

虚拟IP技术是基于ARP协议实现的，ARP协议的功能是根据机器的IP地址解析出它的MAC地址。当网络中的两台服务器进行通信时，指定对方的IP地址，然后将信息发送给对方。然而在网络通信的底层，两台服务器之间的通信最终是经由MAC地址实现的，即将对方的IP地址解析为MAC地址，将信息发送到对应的服务器上，MAC地址是全世界唯一的。

每一台机器都会维护一个自己的ARP缓存，缓存中记录了机器的IP地址和MAC地址的映射。如果让缓存维护两条记录，一条是真实IP和MAC地址对应，另外一条是虚拟IP和MAC地址的对应，这样就实现了虚拟IP。

集群负载均衡实现，对于一个分布式集群环境来说，组成集群的各个节点不一定是同一型号的服务器，不同型号的服务器在物理性能上必然存在着差异。由于用户请求或者数据插入都是随机到达的，所以很有可能会引起系统压力不均衡的情况，即有些节点承担的任务较多，而有些节点承担的任务较少，严重时甚至会导致系统的崩溃。

负载均衡通过将集群设置为Maser/Slave结构，让Master负责管理集群和用户请求，将用户请求或者到达的数据分摊到集群中的各Slave节点上进行操作，使得各节点不会出现压力不均衡的情况。负载均衡技术是优化系统集群性能的关键之一。因为对外接口框架没有提供负载均衡机制，所以系统的负载均衡机制需要自己设计实现。系统负载均衡设计实现如图4所示。

集群中所有服务器都往Zookeeper中注册临时节点，因为临时节点的一个特征就是当节点宕机的时候，该临时节点就会消失，这样就保证了在线的都是可用的节点。

系统对外部仅暴露一个Master IP。当客户端有连接请求时，首先会连接Master节点，Master节点只实现一个功能，就是推荐Slave节点IP，推荐Slave节点IP使用的是轮询方式。通过注册的临时节点可知系统中可用的服务器，然后请求会发往对应的节点，让该节点负责处理用户请求。所以集群的负载均衡机制实质就是对外部连接的负载均衡。

在具体编程时，可以通过Zookeeper对外提供的API进行对Zookeeper的操作。Curator是一款开源的Zookeeper客户端，它封装了Zookeeper底层的API，实现了诸如锁、缓存和自动重连等相关操作，现被广泛使用。方案选择引入Curator客户端，方便功能的开发和简化代码，使用时只需在发明中引入对应的Maven依赖即可。

集群高可用性实现，虽然负载均衡机制提高了任务运行的效率，并且在一定程度避免了系统故障，保证了集群的稳定性。但是在面对一些特殊情况时，例如Maste节点因为意外情况停止服务时，系统仍会变得不可用。高可用性机制就是为了保障系统在有机器宕机或者断点的情况下依然能对外部提供服务。

系统使用虚IP和Zookeeper实现集群HA方案。HA使用双机集群的方式，其中一台作为Master，负责对外提供服务，另外一台作为Master的备份，称为MasterBak，负责备份Master中的数据。

Master和MaserBak是通过Zookeeper选举产生的，对于集群来说Master具有唯一性。Zookeeper正好提供了强一致性，它保证在分布式高并发环境下ZNode节点的唯一性，即如果在某一路径下存在一个ZNode节点，那么客户端无法在同一个路径下再创建一个同名的ZNode节点。利用Zookeeper这一特性可以轻易的实现双机集群Master节点的选举。选举流程如图5所示。

两台服务器都往Zookeeper上创建一个同名ZNode节点，因为ZNode的唯一性，所以最终只会有一台服务器实现了该节点的创建。那么这台服务器就成为了Master节点，另外一台服务器就作为备份节点使用。通过这种方式，双机集群就可以选举出了Master和MasterBak。一旦完成选举出来之后分别写入两个ZNode，一个Master的ZNode，另外一个是MasterBak的ZNode，供别的程序主要是对外接口部分的读取。

因为宕机或者断电的不确定性，所以Zookeeper要保持与Master和MasterBak的心跳，并设定超时时间和重试次数，一旦超过设定的超时时间和重试次数，那么就判断这个机器下线了，并修改相应的ZNode。超时时间和重试次数是在搭建Zookeeper集群时配置的，配置文件叫做zoo.cfg。系统中Zookeeper参数配置如下：

tickTime＝l000//Zookeeper中的时间单位(ms)

dataDir＝/var/lib/zookeeper//Zookeeper存储事务日志文件和快照数据的目录

clientPort＝2181//对外连接端口

initLimit＝10//Leader等待Follower启动并完成数据同步的时间，tickTime的10倍

syncLimit＝5//Leader和Follower之间心跳延时，tickTime的5倍

server.1＝P1:2888:3888//所有部署服务器的IP

server.2＝IP2:2888:3888

server.3＝IP3:2888:3888

…

这里的超时时间和重试次数设置不仅仅是在Master宕机时可以做出判断，有时会遇到Master未宕机，但是因为处理太忙而不能及时回应这种情况，这时候备用节点可能就会认为Master宕机了而把自己当做主节点对外提供服务。

双机集群中的两台机器要进行虚拟IP设置，虚拟IP按照IP地址格式的要求自己定义，要求在当前网络环境下集群中所有服务器都不能Ping通该IP。虚拟IP的意义在于客户端代码不需要改变，即外部客户端只能看到虚拟IP，内部看到的还是网卡的真实IP。当系统宕机时，Master会切换到Master Bak，继续对外提供服务。如图6给出了双机集群的连接示意图。

步骤104，基于推荐Slave节点IP在集群化的ZooKeeper服务端中获取可用服务器，并根据所获取的可用服务器与客户端完成交互。

在本申请实施例中，在集群化的ZooKeeper服务端中使用HDFS存储配置文件和数据信息，使用Yarn实现整个集群的资源管理和分配。具体地，底层就是基于Hadoop2.0实现的，使用HDFS存储一些配置文件和数据信息，使用Yarn实现整个集群的资源管理和分配。基于系统的可扩展性设计，可以在系统之上使用Map/Reduce或者Spark进行其他功能的开发。

HDFS是一个可以部署的高容错性分布式文件系统，是专门为了存储超大文件和流式读写操作而设计的。

如图7，HDFS采用Master/Slave架构，集群节点分成NameNode、SecondaryNameNode和DataNode三种。NameNode和Secondary NameNode运行在Master节点上，DataNode运行在众多Slave节点上，它们的作用分别如下：

a)NameNode：一个HDFS集群只能有一个NameNode，负责掌握整个集群中所有DataNode的状态、维护整个文件系统的元数据信息、提供文件系统全景图、存储的数据块与存放该数据块的DataNode之间的映射关系。

b)Secondary NameNode：负责定期合并两个日志文件，日志中分别记载了某一时刻HDFS的信息，和该时刻之后HDFS的变化。主要是用于当NameNode崩溃之后进行NameNode的恢复。

c)DataNode：通常集群中的每个Slave节点对应一个DataNode。DataNode是真正存储块数据的地方，负责执行具体的任务。并定期向NameNode反映自身的状况和存储的数据块的状况。

当客户端有读写文件请求时，首先会和NameNode交互，获取数据具体存放的位置或者将要存放的位置，因为NameNode维护了数据块和DataNode之间的映射关系，所以接下来要做的就是和对应的DataNode进行交互，执行具体的操作。

HDFS底层提供了对这些操作的实现和相应的容灾机制，使得开发人员不必关心底层存储和容灾等细节，简化了系统的开发。

系统集群资源管理，现实中，计算机内存、CPU时间和IO设备都是有限的资源，而系统中的所有作业都要使用到这些资源。分布式系统中如何收集这些有限的资源，然后合理的分配给各个作业是一个极大的难题。

Hadoop1.0仅支持Map/Reduce计算框架，并且存在着可扩展性差和可靠性差等问题。为此，Hadoop2.0针对这个情况进行了改进，将资源调度部分独立出来设计了一个资源调度器，增强了Hadoop框架的可扩展性，这个资源调度器称之为Yan(Yet AnotherResource Negotiator)。

如图8，Yarn采用的仍然是经典的Master/Slave架构，集群分成ResourceManager、NodeManager和ApplicationMaster三个部分，三者的作用具体如下：

a)ResourceManager：集群中的Master，负责管理集群所有资源。当有作业请求时，它会按照一定的策略给作业分配运行所需的资源，但仅仅只是负责分配，不参与作业的后序工作。

b)NodeManager：作为Slave，运行在Yarn集群的每一个节点上。主要负责管理和监控所处节点的资源使用情况，并定期将情况汇报给Master。当检测到本节点处于高负载状态时，会将这情况及时反馈给Master，此时Master将停止分配任务给该节点直到节点处于正常状态。

c)ApplicationMaster：用户每次提交一个应用程序，就会对应启动一个ApplicationMaster。它负责与ResourceManager进行通信，请求ResourceManager分配执行任务所需的资源，然后和NodeManager协同工作，执行并监控任务。

系统底层基于Hadoop2.0框架实现，使用HDFS存储数据信息和系统配置信息，使用Yarn进行系统集群资源管理，给用户任务和系统中的其他作业分配资源，增强了系统的稳定性和可扩展性，简化了系统的开发，并且用户可以直观的在Yarn界面上观察到资源分配情况和作业处理情况。

实际应用中，当用户与系统进行信息传输交流时，信息都要转换成二进制序列的形式进行传输，即要进行数据的序列化和反序列化。在绝大部分情况下，客户端和服务器都不在同一台机器上，即两者之间的交互不是本地交互，如果客户端与服务器采用直接通信的方式，这时就要考虑分布式系统底层复杂的网络通信模块，不仅编写和调试程序困难，安全性和稳定性也不能得到很好的保障。

这时就需要通过远程调用(Remote Procedure Call)的方式实现用户对系统接口的调用。如图9，RPC的实质是实现了OSI网络模型中传输层和应用层的功能，它屏蔽了网络底层的细节，在客户端和系统之间建立连接，并利用该连接进行信息的传输。

Thrift是由Facebook开发的一种RPC框架，其所提供的功能符合上述所有要求，并对C/C++、Java、C#等多种语言提供支持。使用Thrift框架，相互通信的客户端和服务器可以采用不同的语言开发，例如客户端用C++编写，而服务器端使用Java编写，两者可以实现无障碍通信，并且框架实现了序列化和反序列化的功能。

鉴于Thrift提供的功能和在现实中各公司的广泛应用，并且相关文档较多，所以系统决定采用Thrift框架开发对外接口。

Thrift框架提供了客户端与服务器通信所涉及到的操作的所有实现类，用户只需关心自己的接口逻辑而不必关注底层细节，系统需要对外提供数据插入、删除、修改和查询接口，并且数据类型有多种格式，如卡口过车数据、GPS数据、人脸数据等等，每一种类型的数据都要实现以上接口。虽然具体业务也在系统上实现，但是不同用户需要实现的业务不同，作为一个通用的系统不应当提供业务的实现，所以这里不描述业务接口的开发，但是如果要进行业务开发的话，实现过程和以上其他接口一致，所以说使用Thrift框架增强了系统的可扩展性。

综上可以看出，对方法所涉及的难点进行分析并设计相关解决方案的具体实现，最终方法整体架构设计如下：基于Hadoop2.0分布式框架设计了一款PB级大数据存储与检索方法，采用分布式集群Master/Slave结构部署在集群上。方法对外部仅暴露一个虚拟IP，使用Thrift框架向外提供接口。方法使用Zookeeper实现负载均衡和HA机制，并负责管理整个集群。使用Hadoop2.0框架作为方法底层架构，使用其提供的Yarn管理和分配集群资源，最后依赖搜索引擎Solr和数据库HBase实现大数据的存储和检索。研究成果主要应用于大数据技战法研判模型上，可以帮助用户在海量数据中，通过大数据分析得到目标人物信息等。可以看出，本申请的有益效果与创新点至少包括了：

(1)高并发连接处理

考虑到实际应用场景中，前端监控设备动辄成百上千台，并且数量仍在不断增加当中。所有的设备都要和系统建立连接然后接着进行各种操作，所以需要合理的处理这些高并发连接，保证系统正常稳定运行。

(2)系统稳定性保障

随着业务量和数据量的增加，单台计算机的性能显然远远不能满足大数据处理的需求，分布式集群设计是系统的必然选择。对于分布式集群来说，系统需要提供可靠的高可用性(High Availability)和负载均衡(Load Balance)机制，保证在即使有机器宕机或者断点的情况下也能对外提供服务。

(3)海量数据存储

对于输入的海量数据，传统的关系型数据库由于有严格的存储结构设置和ACID特性，所以并不适合海量数据的存储，需要设计合适的数据存储方案，实现数据的快速高效存储并且保证数据不丢失。

(4)PB级数据检索

基于实际应用中检索条件的考虑，当面对海量数据检索时，单单依靠数据库提供的数据检索方式并不能实现快速检索。需要提供合适的检索方案和算法优化，当对实时数据或者历史数据进行各种条件的检索时，系统能实现快速响应。

(5)系统可扩展性

对于任何一个系统来说，可扩展性都是设计时必须要考虑的要素之一。尤其是在安全领域，面对未来更多种类的业务和更多类型的数据，如果每次涉及到新功能都需要重新开发一套业务逻辑的话，那么该系统就不具备可扩展性，不满足未来可持续改进的要求。

以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对申请专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (10)

1.一种基于ZooKeeper的分布式数据交换方法，其特征在于，所述方法包括：

在分布式系统中构建集群化的ZooKeeper服务端，并建立客户端与服务器的连接，连接成功后保存会话连接；其中，ZooKeeper的视图结构使用的数据节点方式为Znode；所述ZooKeeper的节点构成的文件系统层级为树状结构，用于存储交换服务各节点的地址信息以及数据交换任务的执行位置和状态；

基于ARP协议配置ZooKeeper服务端中每台服务器的IP地址，其中包括真实IP地址和虚拟IP地址；

启动服务器的ARP缓存，从ZooKeeper会话中连接Master节点IP，并通过轮询方式推荐Slave节点IP；

基于推荐Slave节点IP在集群化的ZooKeeper服务端中获取可用服务器，并根据所获取的可用服务器与客户端完成交互。

2.根据权利要求1所述的方法，其特征在于，所述基于ARP协议配置ZooKeeper服务端中每台服务器的IP地址，包括：

使用虚拟IP和Zookeeper实现集群HA，所述HA使用双机集群的方式，其中，一台为Master节点，负责对外提供服务，另一台为MasterBak节点，负责备份Master中的数据。

3.根据权利要求2所述的方法，其特征在于，所述使用虚拟IP和Zookeeper实现集群HA，包括：

利用两台服务器向集群化的ZooKeeper服务端创建同名ZNode节点，根据ZNode的唯一性将节点创建成功的服务器作为Master节点，另一台服务器作为MasterBak节点。

4.根据权利要求1所述的方法，其特征在于，将分布式系统中集群化的ZooKeeper服务端中的每个节点划分为Leader节点、Follower节点和Observer节点；

所述Leader节点用于调度集群内部各台服务器，并对事务请求进行调度和处理，同时保证事务处理的FIFO；

所述Follower节点用于指定Leader节点，并参与客户端事务请求投票，处理客户端非事务请求，以及转发事务给Leader服务器；

所述Observer节点用于处理客户端非事务请求，以及转发事务给Leader服务器。

5.根据权利要求1所述的方法，其特征在于，所述在分布式系统中构建集群化的ZooKeeper服务端，包括：

构建2×N+1台服务器构成的Zookeeper集群，其中N表示所述Zookeeper集群允许服务器宕掉的最大数量。

6.根据权利要求1所述的方法，其特征在于，所述基于ARP协议配置ZooKeeper服务端中每台服务器的IP地址，还包括：

ZooKeeper服务端中每两台服务器之间的通信经由MAC地址实现的，包括对方的IP地址解析为MAC地址，将信息发送到对应的服务器上。

7.根据权利要求1所述的方法，其特征在于，所述基于推荐Slave节点IP在集群化的ZooKeeper服务端中获取可用服务器，并根据所获取的可用服务器与客户端完成交互，包括：

在集群化的ZooKeeper服务端中使用HDFS存储配置文件和数据信息，使用Yarn实现整个集群的资源管理和分配，其中：

所述HDFS采用Master/Slave架构，将集群节点分成NameNode、Secondary NameNode和DataNode三种，NameNode和Secondary NameNode运行在Master节点上，DataNode运行在Slave节点上；

所述Yarn采用Master/Slave架构，将集群节点分成ResourceManager、NodeManager和ApplicationMaster三种。

8.根据权利要求7所述的方法，其特征在于，在所述HDFS中：

所述NameNode负责掌握整个集群中所有DataNode的状态、维护整个文件系统的元数据信息、提供文件系统全景图、存储的数据块与存放该数据块的DataNode之间的映射关系；

所述SecondaryNameNode负责定期合并两个日志文件，日志中分别记载了某时刻HDFS的信息，和该时刻之后HDFS的变化，用于当NameNode崩溃之后进行NameNode的恢复；

所述DataNode负责执行具体的任务，并定期向NameNode反映自身的状况和存储的数据块的状况。

9.根据权利要求7所述的方法，其特征在于，在所述Yarn中：

所述ResourceManager负责管理集群所有资源，当有作业请求时，会按照预设策略给作业分配运行所需的资源；

所述NodeManager运行在Yarn集群的每一个节点上，负责管理和监控所处节点的资源使用情况，并定期将情况汇报给Master；

所述ApplicationMaster负责与ResourceManager进行通信，请求ResourceManager分配执行任务所需的资源，然后与NodeManager协同工作，执行并监控任务。

10.根据权利要求1所述的方法，其特征在于，所述根据所获取的可用服务器与客户端完成交互，包括：

通过Thrift框架实现客户端和服务器之间建立连接，并利用该连接进行信息的传输。

Images