技术领域
[0001] 本
发明涉及
区块链技术领域，特别是涉及一种支持容错的分布式查询方法以及一种支持容错的分布式查询装置。
背景技术
[0002] 由于不可篡改性、匿名性和去中心化等特性，区块链技术得到了工业界和学术界的广泛关注，催生了大量区块链应用，包括
比特币、以太坊等。传统区块链采用链式结构账本，通过全网共识机制维护全局统一的最长链，交易吞吐量低、交易
费用高且不可扩展，使其不能应用于对实时性要求较高和高吞吐量的场景中，如
银行和交易所等。
[0003] 针对这一问题，近期的区块链研究和实践中出现了一种新型的基于图结构的
分布式账本，与链式账本不同，基于图结构的账本通常采用非
工作量证明机制PoW的共识
算法，在联盟链的应用场景中，为了进一步提高交易吞吐量，并没有采用数据全网同步的方式，而采用了随机化存储的策略，交易被随机存放到网络中的若干
节点上，且共识算法基于所有相关节点的检索结果。这种基于图结构随机存储的分布式账本对交易的查询提出了巨大挑战，即如何要在网络中节点的在线状态和节点之间的链路连接状态动态变化的环境下，检索出所有节点的相关数据用来支持共识算法，保证查询功能的容错性。
发明内容
[0004] 本发明提供一种支持容错的分布式查询方法以及一种支持容错的分布式查询装置，以解决在图结构随机存储的分布式账本中，如何保证查询功能的容错性的问题。
[0005] 为了解决上述问题，本发明公开了一种支持容错的分布式查询方法，所述方法应用于对等计算P2P网络系统中，所述P2P网络系统包括多个节点，所述节点中包括积极列表Active List和消极列表Passive List，所述Active List分为活跃列表Eager List和惰性列表Lazy List；其中，所述Active List中的节点数量为固定值，所述Eager List中存放的是在P2P网络系统上和该节点建立TCP连接的节点，用于传递消息；所述Lazy List中存放的是所述Active List除Eager List中的剩余节点，用于传递消息的
摘要或消息的ID，用于P2P网络系统的优化和容错；所述Passive List中存放的是随机节点，用于替换Active List中断开连接的节点，保证节点和所述P2P网络系统中网络的连接；所述方法包括：
[0006] 在所述P2P网络系统中，第一节点获得其
父节点广播的查询
请求，所述第一节点为所述P2P网络系统中的任一节点；
[0007] 所述第一节点通过树形维护程序将所述查询请求广播给自身的孩
子节点；所述孩子节点用于利用所述P2P网络系统的
树形结构，将所述查询请求再广播给自身相应的孩子节点，自身相应的孩子节点重复上述广播步骤，直至将所述查询请求广播至该P2P网络系统上的所有节点；每个节点在收到查询的请求后，
检索本地
数据库，并等待其孩子节点的结果返回，当收集完所有的孩子节点返回的数据后，做结算和去重操作，并将结果返回给其父节点；经过层层反馈，当接收到用户查询请求的根节点收到所有孩子节点的返回结果时，做最终的结算和去重操作，生成最终查询结果，并将最终查询结果返回给该用户；
[0008] 针对所述树形维护程序，所述方法包括：
[0009] 当构成所述P2P网络系统的边的第一节点和第二节点之间的连接断开时，所述第一节点将所述第二节点从自身的Eager List中移除；
[0010] 所述第一节点依次向其Passive List中的第一目标节点发起查询请求；所述查询请求包括检查第一目标节点是否在线的指令和查询第一目标节点的Lazy List的大小的指令；
[0011] 所述第一节点接收各个第一目标节点针对查询请求返回的查询结果，根据所述查询结果中的延迟和各个第一目标节点的Lazy List的大小，从所述第一目标节点中选择一个Lazy List的大小最小且延迟最低的第二目标节点；
[0012] 所述第一节点将第二目标节点加入自身的Lazy List中，并利用Lazy List中的节点作为替补边来对所述P2P网络系统进行修复。
[0013] 为了解决上述问题，本发明还公开了一种支持容错的分布式查询装置，所述装置应用于对等计算P2P网络系统中，所述P2P网络系统包括多个节点，所述节点中包括积极列表Active List和消极列表Passive List，所述Active List分为活跃列表Eager List和惰性列表Lazy List；其中，所述Active List中的节点数量为固定值，所述Eager List中存放的是在P2P网络系统上和该节点建立TCP连接的节点，用于传递消息；所述Lazy List中存放的是所述Active List除Eager List中的剩余节点，用于传递消息的摘要或消息的ID，用于P2P网络系统的优化和容错；所述Passive List中存放的是随机节点，用于替换Active List中断开连接的节点，保证节点和所述P2P网络系统中网络的连接；所述装置包括：
[0014] 查询请求获得模块，被配置在第一节点中，用于在所述P2P网络系统中，获得其父节点广播的查询请求，所述第一节点为所述P2P网络系统中的任一节点；
[0015] 查询请求广播模块，被配置在第一节点中，通过树形维护程序将所述查询请求广播给自身的孩子节点；所述孩子节点用于利用所述P2P网络系统的树形结构，将所述查询请求再广播给自身相应的孩子节点，自身相应的孩子节点重复上述广播步骤，直至将所述查询请求广播至该P2P网络系统上的所有节点；每个节点在收到查询的请求后，检索本地数据库，并等待其孩子节点的结果返回，当收集完所有的孩子节点返回的数据后，做结算和去重操作，并将结果返回给其父节点；经过层层反馈，当接收到用户查询请求的根节点收到所有孩子节点的返回结果时，做最终的结算和去重操作，生成最终查询结果，并将最终查询结果返回给该用户；
[0016] 针对所述树形维护程序，所述装置包括：
[0017] 第二节点移除模块，被配置在第一节点中，用于当构成所述P2P网络系统的边的第一节点和第二节点之间的连接断开时，将所述第二节点从自身的Eager List中移除；
[0018] 查询请求发起模块，被配置在第一节点中，用于依次向其Passive List中的第一目标节点发起查询请求；所述查询请求包括检查第一目标节点是否在线的指令和查询第一目标节点的Lazy List的大小的指令；
[0019] 查询结果接收模块，被配置在第一节点中，用于接收各个第一目标节点针对查询请求返回的查询结果，根据所述查询结果中的延迟和各个第一目标节点的Lazy List的大小，从所述第一目标节点中选择一个Lazy List的大小最小且延迟最低的第二目标节点；
[0020] 系统修复模块，被配置在第一节点中，用于将第二目标节点加入自身的Lazy List中，并利用Lazy List中的节点作为替补边来对所述P2P网络系统进行修复。
[0021] 与
现有技术相比，本发明包括以下优点：
[0022] 本发明通过维护具有高容错和负载均衡的树形结构的P2P网络系统，将查询条件广播给P2P网络系统中的节点，节点在收到查询请求后，将本地满足查询条件的数据返回给广播生成树中的父节点，父节点将所有孩子节点返回的数据和本地的查询结果做去重和结算，将处理后的结果返回给该节点的父节点，以层层汇总的方式将数据返回给根节点，以此可降低代理节点的负载，保证低延迟。
[0023] 本发明针对基于图结构随机存储的分布式账本的查询功能的容错性问题，采用了延迟优化和邻居节点管理协议的方法，通过延迟优化，可保证节点在上层节点宕机的情况下，保证查询消息被下层节点接收，通过邻居管理协议，可动态地将离开网络的节点替换为新的在线节点，从而保证整个网络的连通性。
附图说明
[0024] 图1是本发明
实施例一种支持容错的分布式查询方法的步骤
流程图；
[0025] 图2.1是本发明实施例故障率-跳数的示意图；
[0026] 图2.2是本发明实施例故障率-跳数分布的示意图；
[0027] 图2.3是本发明实施例故障率-去重率的示意图；
[0028] 图3是本发明实施例的一种支持容错的分布式查询装置的结构示意图。
具体实施方式
[0029] 为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。
[0030] 分布式账本可以将用户的数据安全地记录到分布式的网络节点上，当数据被安全记录后，仍然需要可靠且高效的机制去检索分布式账本上的数据。和传统的中心化数据库不同，分布式账本是在没有中央管理器或集中的数据存储的情况下完成在不同地理
位置的数据的复制、共享和同步的共识数据库。
[0031] 将交易可靠地存储并防止被篡改是
分布式账本技术关注的核心，但是当交易可靠地存储在分布式账本上后，用户需要到分布式账本上查询交易数据，如查询余额，查询交易历史以及交易的内容。这种查询不仅仅是精确查询，还有可能是模糊查询、范围查询、多条件查询。而查询功能不应该仅仅提供交易数据的检索，还应该在对交易数据发生分歧时，提供溯源和审计功能。即如何处理用户的查询请求，并在分布式账本上查询满足条件的数据，将结果准确快速的响应给用户，和数据存储同样重要。
[0032] 如比特币和以太坊这种类似的架构，矿工节点把交易打包成区块后，将该区块广播给网络上的所有节点。每个节点在收到新打包的区块后，都将该区块放置到自身维护的区块链结构中。全网中的每个节点都包含有全部的交易数据，故每个节点都可以作为查询请求的代理节点，通过对自身的数据库中检索满足条件的数据，进而响应查询请求。但比特币从2009年的第一个创世区块至今已经产生了193GiB的数据，比特币网络上的每个全节点都需要占用193GiB的磁盘空间，而且随着时间的推移，该数据量的大小还会不断增加。而新型的分布式账本为了增加交易的吞吐量以及节省磁盘空间，摒弃了数据全网同步的方式，而采用了交易数据部分随机存储的方式。即网络上的所有节点并不存放全量的数据，而只随机存储部分交易数据。因为此种架构网络上的节点存储的并不是全量数据，所以就无法应用比特币和以太坊的查询方法。
[0033] 另外一种直观的查询实现方法是，将网络上的所有数据同步到一个代理查询请求的节点上。该代理节点通过某种方式获取网络上所有节点的数据，并对数据验证和汇总后，存放到自身的数据库中，并对外提供查询功能。但该方案只适用于节点数量比较少和TPS较低的场景下，当节点数量和TPS达到一定
阈值后，交易的数据量就会超过代理节点的带宽和计算能
力，从而使得查询功能变得不可用。而网络环境和节点的在线状态又是复杂多变的，节点频繁的加入和离开不应该影响查询功能的使用，故该查询系统应当具备一定的容错性。
[0034] 针对这种数据随机、冗余地存储在P2P网络中，且数据有效性的验证基于所有或部分节点的检索结果的架构。参照图1，示出了本发明实施例一种支持容错的分布式查询方法的步骤流程图，所述方法应用于P2P网络系统中，所述P2P网络系统包括多个节点，所述节点中包括积极列表Active List和消极列表Passive List，所述Active List分为活跃列表Eager List和惰性列表Lazy List；其中，所述Active List中的节点数量为固定值，所述Eager List中存放的是在P2P网络系统上和该节点建立TCP连接的节点，用于传递消息；所述Lazy List中存放的是所述Active List除Eager List中的剩余节点，用于传递消息的摘要或消息的ID，用于P2P网络系统的优化和容错；所述Passive List中存放的是随机节点，用于替换Active List中断开连接的节点，保证节点和所述P2P网络系统中网络的连接，所述方法具体可以包括：
[0035] 步骤S101，第一节点获得其父节点广播的查询请求，所述第一节点为所述P2P网络系统中的任一节在所述P2P网络系统中，第一节点获得其父节点广播的查询请求，所述第一节点为所述P2P网络系统中的任一节点；
[0036] 步骤S102，所述第一节点通过树形维护程序将所述查询请求广播给自身的孩子节点；所述孩子节点用于利用所述P2P网络系统的树形结构，将所述查询请求再广播给自身相应的孩子节点，自身相应的孩子节点重复上述广播步骤，直至将所述查询请求广播至该P2P网络系统上的所有节点；每个节点在收到查询的请求后，检索本地数据库，并等待其孩子节点的结果返回，当收集完所有的孩子节点返回的数据后，做结算和去重操作，并将结果返回给其父节点；经过层层反馈，当接收到用户查询请求的根节点收到所有孩子节点的返回结果时，做最终的结算和去重操作，生成最终查询结果，并将最终查询结果返回给该用户。
[0037] 在本发明实施例中，提出了一种具有高容错和负载均衡的树形结构的P2P网络系统(接下来，以广播生成树或树对该系统进行简称)，该广播生成树并不是在协议开始运行时便开始构建。而是当传递第一条消息时，随着该条消息的传播路径形成一棵广播生成树，再通过后续消息的传播对该树进行优化和修复。在针对该广播生成树的查询方法中，本发明实施例采用了邻居节点(邻居节点指某一节点的父节点或孩子节点)的查询请求方法，并通过树形维护程序将该查询的请求广播给该节点的孩子节点，孩子节点再广播给自己相应的孩子节点，重复上述步骤，利用该树形结构，广播查询的消息至网络上的所有节点。节点在收到查询的请求后，检索本地数据库，并等待孩子节点的结果返回，在此过程中采用了“分治思想”，将查询的所有结果的去重、验证和传输均匀地分配给网络上的所有节点。首先节点之间构成树形结构，除根节点外，每个节点向其父节点(本发明实施例中的父节点)传递查询结果，父节点接收到所有的孩子节点返回的所有数据后，将查询结果做去重和验证，经过层层反馈，当接收到用户查询请求的根节点收到所有孩子节点的返回结果时，做最终的结算和去重操作，生成最终查询结果，并将最终查询结果返回给该用户。本发明实施例通过邻居节点的发散性查询方法，以及将查询结果在返回的传输过程中进行去重和验证，可降低代理节点的负载，还能保证低延迟，该树不仅仅能用来做查询结果回收，还可用来做查询请求的传递。
[0038] 就具体实现而言，基于图结构随机存储的分布式账本是一个完全去中心化的P2P应用，网络上的每个节点并不能保存全网的节点信息，故需要定义一些相关的数据结构来存储网络上的部分节点的信息。全网上节点的所有信息被分散保存到了该网络的所有节点上，即所有节点维护的部分信息反映了全网的拓扑结构。每个节点能根据和其维护的节点之间的连接状态做动态的更新，来保证该节点和全网节点的连接。P2P网络系统的构建依赖于上述的数据结构，而节点之间的连接状态和延迟是动态变化的，根据该变化对P2P网络系统做修复和优化，而修复和优化的过程需要定义一些额外的数据结构。如缓存消息的相关数据结构，该数据结构可以根据消息到达的先后次序来动态优化和修复该P2P网络系统。如何定义和使用上述数据结构来维护一棵全局的树变得十分关键。首先，树的维护主要分为以下三个部分：
[0039] 1.树的构建
[0040] 即在一个已有的网络拓扑环境中，删掉其中的一些连接的边，构造出一棵满足上述条件最优的生成树。运行在协议的初始化阶段。
[0041] 2.树的优化
[0042] 网络中节点之间的连接和节点的在线状态是不断变化的，该树不能是一成不变的，必须随着网络环境的变化而动态的优化，如传输延迟的优化、传输跳数的优化和节点的出度优化。
[0043] 3.树的修复
[0044] 当P2P网络系统上的一个节点离开网络或树上的一条连接的边暂时断开后，会影响到下层的节点对传输消息的接收。树的修复就是保证在节点离开和连接断开的情况下，修复该P2P网络系统，保证所有的节点能收到广播的消息并可以传递查询的结果，并在后续的传播过程中对该树不断地修复。
[0045] 为了保证传输过程中消息的快速传输，节点之间的连接采用TCP长连接的方式，采用TCP长连接既能保证消息的可靠传输，避免每次建立连接的开销，还可以快速检测到节点的故障或连接的断开。
[0046] 为实现本发明实施例，为P2P网络系统定义了三个协议，包括BroadcastTree协议、MsgTransferProt协议和PartialView协议，所述BroadcastTree协议负责P2P网络系统的维护工作；所述MsgTransferProt协议负责查询消息的广播和查询结果的验证传递；所述PartialView协议负责管理每个节点的父节点和孩子节点；其中，所述Active List和消极列表Passive List位于P2P网络系统的PartialView协议中。
[0047] 每个节点根据消息还定义了3个Map缓存，所述每个节点中包括第一Map缓存、第二Map缓存以及第三Map缓存，第一Map缓存是ReceivedMs-gMap，存放的是消息ID和消息的映射，用来缓存当前已经收到的消息，以便于响应其他尚未收到该消息的节点对该消息的请求；
[0048] 所述第二Map缓存是NotReceivedMsgMap，缓存的是消息ID和发送该消息的节点的映射；当达到
指定的时长时，仍未收到Eager List中的节点发送的该消息，触发Timer
定时器，用于向发送该消息的节点请求该消息，并修复所述P2P网络系统；
[0049] 所述第三Map缓存是TimingCacheMsgMap，负责缓存当前收到的消息，如果在指定的时间范围内收到Lazy List中的节点发送的消息，比较两者的跳数来决定是否优化该树，给该P2P网络系统提供新的优化的可能。
[0050] 对每个查询请求，可能在本次查询期间，由于网络变化导致P2P网络系统的结构发生变化。因此，需要记录该节点之前的所有的传输路径，为查询结果的传输提供路径。故定义了transferPathMap，缓存的是查询请求消息的ID和当前传输路径的映射。
[0051] 本发明的P2P网络系统的初始化是采用Lazy Formation的方式，即P2P网络系统的初始化并不是在协议开始运行时便开始构建。而是当传递第一条消息时，随着该条消息的传播路径形成一棵P2P网络系统，再通过后续消息的传播对该树进行优化和修复。
[0052] 本发明实施例维护了三个重要的列表，Eager List、Lazy List和Passive List。这三个列表是运行P2P网络系统的维护算法的
基础，这三个列表维护的好坏直接影响着P2P网络系统的结构，影响查询的延迟和查询结果的计算负载。其中Eager List和Lazy List实则是和当前节点长连接的节点，Passive List是这两个列表的候补列表，旨在随机获得网络上的节点，从而防止网络的部分区域化，出现多个连通分量，节点之间不能通信的情况。
[0053] 接下来，本发明实施例对如何在复杂的网络环境中，动态地维护这三个列表，从而优化传输的延迟和计算以及加强节点之间的连通性阐述了具体的方案，以第一节点为例。
[0054] 首先，在所述第一节点加入所述P2P网络系统之前，需要对第一节点的三个列表进行初始化，所述方法包括：
[0055] 步骤1：所述第一节点获取所述P2P网络系统的部分拓扑信息，应用所述拓扑信息初始化自身的Eager List、Lazy List和Passive List；
[0056] 在本发明实施例中，采用的是基于HyparView的节点管理方式，HyparView原文中推荐使用的是定义一个或几个联系节点(Contact Node)，每个节点加入到该网络时，首先连接到联系节点，由联系节点将其的三个列表发送给欲加入的节点。但这样容易导致网络的区域化，产生多个连通分量，导致所有的节点之间不能相互通信。所以，本发明实施例采用了基于KAD(Kademlia)实现的节点加入算法，KAD算法是NewYork University的Petar Maymounkov和David Mazieres在2002年提出的一种分布式Hash表的收敛算法。该算法通过两个节点ID的异或距离来衡量两个节点之间关联度，通过对节点ID的有效分层，每个节点仅需要保存网络上部分的节点信息，仅需要log(N)跳就可以找到相应的资源或
定位到相应的节点。若没有满足条件的资源和节点，也会找到和该资源或节点异或距离最近的几个资源或节点。基于KAD的特性，本发明实施例利用KAD算法来初始化节点维护的邻居节点组成的邻居节点列表。
[0057] 上述拓扑信息包括随机分配的节点NodeID；步骤1具体可以包括以下子步骤：
[0058] 子步骤11：所述第一节点利用所述NodeID和KAD算法向P2P网络系统的网络发起请求，查找距离该NodeID最近的查找距离该NodeID最近的邻居节点，所述邻居节点包括所述第一节点的父节点和孩子节点；
[0059] 子步骤12：所述第一节点从所述邻居节点中选择部分节点来初始化自身的Eager List、Lazy List和Passive List。
[0060] 在本发明实施例中，每个节点在初始化时，都会被随机分配一个NodeID，利用NodeID和KAD算法向该网络发起请求，查找距离该NodeID最近的几个邻居节点。随后，节点从这几个邻居节点中选择部分节点来初始化自身的三个List列表。每次选取离该节点最近的几个邻居节点作为邻居节点，优选的，从其中选取延迟较低的节点作为Active List，剩余节点作为PassiveList。
[0061] 在本发明一优选实施例中，所述子步骤12进一步包括：
[0062] 所述第一节点根据自身的初度m，从所述邻居节点的Eager List中选择Eager List出度最小的m个节点，并将这m个节点加入到自身的Eager List中，以及根据自身的Passive List中的节点数n，从所述邻居节点的Passive List中随机选择n个节点，并加入自身的Passive List中，同时对Lazy List初始化为空，以完成初始化自身的三个List列表。
[0063] 进一步的，当从所述邻居节点的Eager List中不能找到满足条件的m个节点时，所述第一节点从返回的所述邻居节点的Passive List中选择延迟最低的d个节点，并将这d个节点加入到自身的Eager List中。从而保证该节点的Eager List和Passive List能初始
化成指定大小的List。Lazy List初始化为空，后续树的构建和优化的过程，会将Eager List中的节点转移到Lazy List中。
[0064] 步骤2：当完成Eager List、Lazy List和Passive List的初始化后，所述第一节点与其Eager List中的节点分别建立TCP长连接，用来构成P2P网络系统的边；
[0065] 步骤3：所述第一节点利用Lazy List中的节点作为替补边来对所述P2P网络系统进行修复，仅留下一个传输速度相对较快且跳数最少的边，剩下的节点被最终移除到Lazy List中。
[0066] 通过上面一系列的操作，加入的节点最终作为P2P网络系统的叶子节点，参与消息的传输和结果的汇总。
[0067] 由于网络环境和节点在线状态的变化，节点和Eager List以及Lazy List中的节点并不能一直保持连接，且Eager List中的节点可能会被Lazy List中的节点取代，Lazy List中的节点有可能会被Passive List中的节点取代。因此，需要动态的维护该列表，使所有的节点随着网络环境的变化，能通过自身维护的邻居列表来掌握整个网络的拓扑结构，从而为P2P网络系统的维护提供支持。
[0068] 接着，继续参照图1，针对所述树形维护程序，所述方法包括：
[0069] 步骤S103，当构成P2P网络系统的边的第一节点和第二节点之间的连接断开时，所述第一节点将所述第二节点从自身的Eager List中移除；
[0070] 步骤S104，所述第一节点依次向其Passive List中的第一目标节点发起查询请求；所述查询请求包括检查第一目标节点是否在线的指令和查询第一目标节点的Lazy List的大小的指令；
[0071] 步骤S105，所述第一节点接收各个第一目标节点针对查询请求返回的查询结果，根据所述查询结果中的延迟和各个第一目标节点的Lazy List的大小，从所述第一目标节点中选择一个Lazy List的大小最小且延迟最低的第二目标节点；
[0072] 步骤S106，所述第一节点将第二目标节点加入自身的Lazy List中，并利用Lazy List中的节点作为替补边来对所述P2P网络系统进行修复。
[0073] 在本发明实施例中，第一节点和第一节点维护的Eager List中的节点之间的TCP长连接构成P2P网络系统的边，和第一节点维护的Lazy List中的节点之间的TCP长连接构成该P2P网络系统边的替补。当P2P网络系统上的连接断开或者节点不在线时，下次消息广播会自动由Lazy List中的节点修复。为了保证Active List和Passive List节点之间的平衡，需要从Passive List中选择相应的节点来替换Active List中的节点。从而保证整棵树的连通性，增加容错率。
[0074] 就步骤S103～S106而言，首先假设，第一节点和第二节点之间保持TCP长连接，分别在对方的Eager List中，构成P2P网络系统的边。当第一节点和第二节点之间的连接断开时，第一节点首先将第二节点从自身的Eager List中移除。此时，第一节点的Active List就少了一个元素，需要从Passive List中选择一个节点来代替当前的节点。第一节点依次和其Passive List中的节点发起查询请求，该查询请求有两个目的，一是检查当前节点是否在线，二是查询该节点的Lazy List的大小。最后，更新每个节点的最近
访问时间，综合延迟和该节点的Lazy List的大小综合选择一个节点。节点的Lazy List大小较小，说明其在P2P网络系统中的层数比较小，将其嫁接到该节点，并且选择延迟较低的节点，可以给树的优化提供更多的可能。所以，Passive List节点选择策略就是选择Lazy List大小较小，当最小Lazy List的节点有多个时，选择延迟最低的。HyparView原文中采用的是将Passive List中的节点，更换成原来的Eager List中的节点，通过第一节点当前Eager List的大小，向Passive List中的节点发送优先级不同的加入操作。原文中采用的是Eager List和Lazy List是固定大小的策略，这样就导致了该修复的必要性。但由于本文采用的是Eager List和Lazy List大小之和不变策略，即使第一节点当前的Eager List中仅仅包含一个节点，那第一节点的Lazy List中的节点数目就是k-1(k是节点加入网络时，配置的出度参数),即使当前的Eager List断开，最终也会由Lazy List中的节点修复该断掉的边。原文中采用的方式，极大地增加了维护的成本和维护的复杂度，并不适用于本发明实施例现在的场景。故在本发明实施例中，只需要替换Lazy List中的节点即可，即使唯一的连接断开，也只需要等待后面几轮的懒修复即可。
[0075] 步骤S103～S106主要提供了对Eager List和Lazy List维护的方案，接下来，在本发明另一可选实施例中提供了对Passive List维护的方案。
[0076] Passive List的作用实则是提供Active List节点的候补，每个节点利用Passive List来保证整个网络上的在线节点之间是连通的。若Passive List的维护算法较差，则可能导致网络中出现多个连通分量，每个节点只能和网络中的部分节点发起连接请求，从而导致全网上的所有节点并不能接收到查询的消息。
[0077] 断开连接的节点不断地加入到Passive List中，而延迟较低和Lazy List大小较小的节点又不断地从Passive List中移除并加入到Lazy List中，这样只能导致Passive List中可用的在线节点越来越少。故需要采取相应的策略来对Passive List进行相应的更新操作。整个更新的过程遵循了HyparView原文中提出的思想，即随机化更新。但是采用的更新策略和原文有很大的不同，采取了低代价和懒更新的策略，更加适用于本发明实施例的维护场景。每个节点Passive List中的节点是随机保存的当前网络上在线的节点。HyparView原文中采用的是每隔固定的间隔，节点通过Eager List发送随机跳数(TTL)的Shuffle消息，收到消息的节点和发送消息的节点，就Passive List中的节点做Shuffle操作。从而保证了每个节点的Passive List中维护了全网上随机的节点。由于所有的节点在固定的间隔都要做Shuffle操作，增加了网络上的负载，为了减少这一负载，本发明实施例同样采用了懒加载(Lazy Load)的方式来随机获得网络上的节点。只有当Passive List中的在线节点数量小于某个特定的阈值时，才会发起更新操作。
[0078] 在本发明实施例中，更新操作可以包括以下步骤：
[0079] 当所述第一节点中的Passive List中的在线节点数量小于预设阈值时，所述第一节点生成一个固定的跳数TTL；
[0080] 所述第一节点将带有该TTL的消息发送给其Eager List中的一个随机的第三目标节点；所述第三目标节点到该消息后，把自己最新的Passive List中的节点ID发送给第一节点，并将所述TTL减1，再随机发送给所述第三目标节点Eager List中的随机节点，重复上述步骤，直到所述TTL为0；
[0081] 所述第一节点将所有收到的节点ID做汇总，随机从收到的所有节点中选M个，将这个M个节点加入到Passive List中；其中，所述M＝Passive List中可存储的最大节点数减去Passive List中当前存储的节点数。
[0082] 另外，为进一步保证Passive List中可用的在线节点的数量，在本发明一可选实施例中还提供了以下步骤：
[0083] 所述第一节点将所述第二节点从自身的Eager List中移除后，将第二节点加入到自身的Passive List中。以此可进一步增加Passive List中的数量。
[0084] 综上，本发明实施例通过维护的Eager List、Lazy List和Passive List这是三个列表，通过维护Eager List来保证整个P2P网络系统上节点之间的连接，从而保证消息的传输；通过随机
采样的方式维护Passive List来为Eager List和Lazy List的更新提供支持，可完成P2P网络系统的初始化、修复和
优化算法。List列表维护的
质量将影响该生成树的
稳定性、传输时延和容错率。
[0085] 由于本发明实施例的方案设计的特殊性，Lazy List的
角色和HyparView原文中的角色并不相同。在本发明实施例中，只限定了Lazy List和Eager List总大小的固定值，但是并不像HyparView原文中限定了Lazy List的大小，故Lazy List只是Eager List的候补。Eager List是Lazy List用于P2P网络系统上的节点，并不需要引入单独的列表维护机制来维护Lazy List。基于这种不同于原文HyparView的设计方案，处于P2P网络系统上层数较低的节点，Lazy List的大小几乎为0。而处于P2P网络系统上层数较高的节点，Lazy List的大小相对较大。充分利用节点之间建立的TCP长连接进行消息的传输，节点的出度尽可能大，降低了P2P网络系统的高度，保证了传输的低延迟。而处于P2P网络系统中层数较高的节点，又有足够的Lazy List来指向P2P网络系统的其他节点，保证了该树的容错性。本发明实施例提供的方案的容错性小于HyparView容错性，能保证故障节点的百分比是一定不会超过
30％。
[0086] 需要说明的是，在本发明的各个实施例中，第一第二只是为了区别不同的节点，并没有实质性的顺序意义。
[0087] 接下来，针对本发明实施例所提供的步骤，对本发明实施例的容错性做分析。
[0088] 容错功能的实现完全依赖于邻居节点的选取和替换，当网络中的某个节点离开网络后，当节点检测到其邻居节点离开网络后，首先将该节点从自身的邻居节点中移除，并通过邻居节点选取策略来
选定新的邻居节点。而新的邻居节点的选取采用了随机化的思想，首先是请求消息跳数的随机化，其次是请求消息传输邻居节点的随机化，再者是从passive list中选择返回结果的随机化。这里虽较难估计具体的容错比，但通过这种随机化及时替补的方式，可较好地保证各个节点之间的连通性，避免出现孤立节点的情况。HyparView原文中能达到80％的容错率，但是维护该结构的开销是较大的，且分布式账本应用并没有必要牺牲大量带宽和计算能力来保证如此高的容错率。
[0089] 为验证本发明实施例的实验效果，下述示例对本发明实施例的方案在真机上的查询操作的可用性和仿真环境下10000个节点的容错性做了验证。实验结果表明，该方案具备较好的容错性，即使在节点故障率30％的情况下，仍然能在较低的跳数下返回正确的查询结果。
[0090] 具体的，为了增加整个系统的容错性，在方案设计中引入了Passive List和Lazy List，分别用于替换Active List和Eager List，不仅仅优化了P2P网络系统的结构，又增加了P2P网络系统的容错性。下面展示的结果是在10000个节点上，出度K的大小为7，故障率从0％-30％情况下，平均最大跳数和平均跳数以及所有叶子节点跳数的分布。
[0091] 此次试验共发起了50次查询消息，每次消息广播的开始都随机退出一部分节点，故统计的结果都是P2P网络系统的修复过程中的平均最大跳数和平均跳数，而并非在发起请求广播的同时，一次性退出相应故障率的节点。因为采用此种方式，树的结构可能在前几次修复后就完全稳定了，导致最终的实验结果过于理想，不贴近实际。故评测的指标采用修复过程中的跳数评测，并不是稳定后的跳数评测，能最大程度的贴近真实的网络环境。
[0092] 如图2.1所示，示出了本发明实施例故障率-跳数的示意图。在图2.1中，随着节点的故障率不断升高，在修复的过程中，平均最大跳数和平均跳数都有所增加。其中平均跳数的增加较为缓慢，证明虽然在传输的过程中存在节点故障的情况，修复过程仍然能保证该P2P网络系统较为稳定。而最大跳数的增加说明和其他节点断开连接的节点，有一部分被嫁接到了其他的子树上，导致平均最大跳数的增加。如图2.2所示，示出了本发明实施例故障率-跳数分布的示意图。在图2.2中，可以看出在故障修复的过程中，一部分到根节点只需要5跳的叶子节点和父节点断开了连接，最终被嫁接到了其他5跳的叶子节点上，变成了6跳和极少部分的7跳节点。在修复的过程中，叶子节点的跳数也是稳定的，主要集中在5、6和7跳中，并没有出现跳数骤增，导致查询延迟递增的过程。故验证了该方案的容错性，在故障率
30％以下，即使在修复的过程中，仍然具有较优的查询延迟和较平衡的树结构。如图2.3所示，示出了本发明实施例故障率-去重率的示意图。在图2.3中，根节点接收到数据的去重率并没有随着故障率的变化而变化，仍然在51％上下
波动。证明在数据均匀地分布在网络上的情况下，数据去重率和节点的故障率无关。数据去重率反映了根节点要处理的数据量的大小，决定了根节点的查询负载，需要根据根节点的计算能力动态地调整。
[0093] 通过上述实验，以分布式账本网络中的节点故障率为变量，检测叶子节点到根节点的跳数以及跳数的分布等信息，验证了该方法即使是在30％故障率的情况下，仍能在较少的跳数内(5.87跳)将查询消息广播至全网，不仅查询的跳数没有明显的增加，而且跳数的分布仍然较为均衡。验证了该方案在存在节点故障率的情况下，仍能保证查询功能的可用性，且作为查询功能核心算法的P2P网络系统仅发生了微小的变化，验证了本方案的容错性。
[0094] 需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明实施例并不受所描述的动作顺序的限制，因为依据本发明实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，
说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本发明实施例所必须的。
[0095] 参考图3，对应图1的方法，示出了本发明实施例的一种支持容错的分布式查询装置的结构示意图，所述装置应用于P2P网络系统中，所述P2P网络系统包括多个节点，所述节点中包括积极列表Active List和消极列表Passive List，所述Active List分为活跃列表Eager List和惰性列表Lazy List；其中，所述Active List中的节点数量为固定值，所述Eager List中存放的是在P2P网络系统上和该节点建立TCP连接的节点，用于传递消息；所述Lazy List中存放的是所述Active List除Eager List中的剩余节点，用于传递消息的摘要或消息的ID，用于P2P网络系统的优化和容错；所述Passive List中存放的是随机节点，用于替换Active List中断开连接的节点，保证节点和所述P2P网络系统中网络的连接；所述装置300包括以下模块：
[0096] 查询请求获得模块301，被配置在第一节点中，用于在所述P2P网络系统中，获得其父节点广播的查询请求，所述第一节点为所述P2P网络系统中的任一节点；
[0097] 查询请求广播模块302，被配置在第一节点中，通过树形维护程序将所述查询请求广播给自身的孩子节点；所述孩子节点用于利用所述P2P网络系统的树形结构，将所述查询请求再广播给自身相应的孩子节点，自身相应的孩子节点重复上述广播步骤，直至将所述查询请求广播至该P2P网络系统上的所有节点；每个节点在收到查询的请求后，检索本地数据库，并等待其孩子节点的结果返回，当收集完所有的孩子节点返回的数据后，做结算和去重操作，并将结果返回给其父节点；经过层层反馈，当接收到用户查询请求的根节点收到所有孩子节点的返回结果时，做最终的结算和去重操作，生成最终查询结果，并将最终查询结果返回给该用户；
[0098] 针对所述树形维护程序，所述装置包括：
[0099] 第二节点移除模块303，被配置在第一节点中，用于当构成所述P2P网络系统的边的第一节点和第二节点之间的连接断开时，将所述第二节点从自身的Eager List中移除；
[0100] 查询请求发起模块304，被配置在第一节点中，用于依次向其Passive List中的第一目标节点发起查询请求；所述查询请求包括检查第一目标节点是否在线的指令和查询第一目标节点的Lazy List的大小的指令；
[0101] 查询结果接收模块305，被配置在第一节点中，用于接收各个第一目标节点针对查询请求返回的查询结果，根据所述查询结果中的延迟和各个第一目标节点的Lazy List的大小，从所述第一目标节点中选择一个Lazy List的大小最小且延迟最低的第二目标节点；
[0102] 系统修复模块306，被配置在第一节点中，用于将第二目标节点加入自身的Lazy List中，并利用Lazy List中的节点作为替补边来对所述P2P网络系统进行修复。
[0103] 对应图1的方法，在本发明一优选实施例中，所述装置还包括：
[0104] 跳数TTL生成模块，被配置在第一节点中，用于当所述第一节点中的Passive List中的在线节点数量小于预设阈值时，生成一个固定的跳数TTL；
[0105] TTL消息发送模块，被配置在第一节点中，用于将带有该TTL的消息发送给其Eager List中的一个随机的第三目标节点；所述第三目标节点到该消息后，把自己最新的Passive List中的节点ID发送给第一节点，并将所述TTL减1，再随机发送给所述第三目标节点Eager List中的随机节点，重复上述步骤，直到所述TTL为0；
[0106] 节点选择模块，被配置在第一节点中，用于将所有收到的节点ID做汇总，随机从收到的所有节点中选M个，将这个M个节点加入到Passive List中；其中，所述M＝Passive List中可存储的最大节点数减去Passive List中当前存储的节点数。
[0107] 对应图1的方法，在本发明一优选实施例中，所述装置还包括：
[0108] 节点变更模块，被配置在第一节点中，用于将所述第二节点从自身的Eager List中移除后，将第二节点加入到自身的Passive List中。
[0109] 对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
[0110] 本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。
[0111] 以上对本发明所提供的一种支持容错的分布式查询方法以及一种支持容错的分布式查询装置，进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。
