Fabric区块链中的快速日志复制方法及装置

fabric区块链中的快速日志复制方法及装置
技术领域
1.本发明涉及区块链技术领域，特别是涉及fabric区块链中的快速日志复制方法及装置。


背景技术：

2.fabric区块链使用raft作为其共识算法，原始的raft算法是一种非拜占庭容错类的共识算法，raft将其共识归为领导者选举和日志提交两阶段。在raft算法中每个节点只可能有三种状态，分别为跟随者(follower)、候选者(candidate)、和领导者(leader)。raft节点之间通过rpc请求来互相通信，主要有以下两类rpc请求，requestvote rpc和appendentries rpc。requestvote rpc用于跟随者状态的节点进行选举而发起的请求，appendentries rpc用于领导者节点向其他节点发起日志同步消息以及维持领导者心跳功能。
3.在raft算法中，其领导者选举完毕后会进入日志复制阶段，领导者收到客户端的服务请求时，首先会本地增加该日志请求然后再发送appendentries rpc给跟随者来进行日志复制以及维持心跳。跟随者收到appendentries rpc日志复制请求时会进行日志同步，然后再返回一个回应给领导者。当领导者收到大多数的appendentries rpc回应时，那么该领导者会认为此日志已经复制到了大多数节点，该日志会被提交，然后应用到状态机中，回应客户端。
4.上述日志复制阶段存在以下三方面的问题：
5.(1)、raft算法为了节点日志一致性的考量和易于理解，所有的日志复制请求都是由领导者发起，由领导者接收回应，跟随者之间互不通信，其只会接收领导者发送来的appendentries rpc日志复制请求，并做出成功或失败的回应。这样在网络延迟的情况下，有些跟随者节点可能迟迟接收不到日志复制请求，进而无法对领导者日志复制请求做出回应，影响了日志的提交速度。
6.(2)、在领导者进行appendentries rpc日志复制请求时，领导者总是优先在本地添加日志再广播appendentries rpc日志复制请求。优先本地添加日志这一步骤会涉及到本地持久化的磁盘读写过程，这种开销会导致后续广播appendentries rpc日志复制请求过程的滞后，进而影响到大多数跟随者节点进行日志同步的过程。
7.(3)、在领导者收到超过半数appendentries rpc日志复制请求回应时，领导者也总是优先提交该日志再应用到状态机中，然后再进行下一条的appendentries rpc日志复制请求。这种应用到状态机的过程会延后下一条appendentries rpc日志复制请求的时间，进而影响跟随者节点快速同步日志，滞后了整个流程。


技术实现要素：

8.有鉴于此，本发明提供了fabric区块链中的快速日志复制方法及装置，以加快日志复制过程，提高系统的整体工作效率。
9.为此，本发明提供了以下技术方案：
10.一方面，本发明提供了一种fabric区块链中的快速日志复制方法，应用于跟随者节点，所述方法包括：
11.跟随者节点接收日志复制请求，并对接收到的日志复制请求进行区分；
12.如果所述日志复制请求来自领导者节点，则转发所述日志复制请求给其他跟随者，并根据领导者日志情况更新所述跟随者节点自己的下一索引和匹配索引，如果所述日志复制请求中的日志消息跟所述跟随者节点自己的下一索引匹配，则所述跟随者节点在本地添加日志，并在添加日志成功后向所述领导者节点回应日志复制成功，如果不匹配则向所述领导者节点回应日志复制失败。
13.进一步地，还包括：如果所述日志复制请求来自其他跟随者，通过验证随机函数算法验证所述日志复制请求中的日志消息的有效性；
14.如果有效，则根据领导者日志情况更新所述跟随者节点自己的下一索引和匹配索引，如果所述日志复制请求中的日志消息跟所述跟随者节点自己的下一索引匹配，则所述跟随者节点在本地添加日志，并在添加日志成功后向所述领导者节点回应日志复制成功；
15.如果验证不通过或日志消息跟所述跟随者节点自己的下一索引不匹配，则直接忽略所述日志复制请求。
16.进一步地，通过验证随机函数算法验证所述日志复制请求中的日志消息的有效性，还包括：所述跟随者节点根据日志复制请求中的alpha参数确认其他跟随者转发的日志复制请求是该任期中领导者发送的日志复制请求。
17.又一方面，本发明提供了一种fabric区块链中的快速日志复制方法，应用于领导者节点，所述方法包括：
18.领导者节点向跟随者节点广播日志复制请求；
19.所述领导者节点接收所述跟随者节点的日志复制成功回应或日志复制失败回应；所述跟随者节点接收到所述领导者节点发送的日志复制请求后，转发所述日志复制请求给其他跟随者，并根据领导者日志情况更新所述跟随者节点自己的下一索引和匹配索引，如果所述日志复制请求中的日志消息跟所述跟随者节点自己的下一索引匹配，则所述跟随者节点在本地添加日志，并在添加日志成功后向所述领导者节点回应日志复制成功，如果不匹配则向所述领导者节点回应日志复制失败；
20.所述领导者节点在接收到针对所述日志复制请求的超过半数的日志复制成功回应之后，提交所述日志复制请求中的日志。
21.进一步地，所述领导者节点广播日志复制请求之后，还包括：所述领导者节点进行本地添加日志的持久化操作。
22.进一步地，所述领导者节点异步的将已提交日志应用到状态机中。
23.进一步地，所述领导者节点面对一次心跳期间收到同一跟随者节点的多个回应时，取所有日志复制成功的回应中最大的下一索引进行下次同步。
24.又一方面，本发明还提供了一种fabric区块链中的快速日志复制装置，应用于跟随者节点，所述装置包括：
25.接收单元，用于跟随者节点接收日志复制请求，并对接收到的日志复制请求进行区分；
26.第一响应单元，用于如果所述日志复制请求来自领导者节点，则转发所述日志复制请求给其他跟随者，并根据领导者日志情况更新所述跟随者节点自己的下一索引和匹配索引，如果所述日志复制请求中的日志消息跟所述跟随者节点自己的下一索引匹配，则所述跟随者节点在本地添加日志，并在添加日志成功后向所述领导者节点回应日志复制成功，如果不匹配则向所述领导者节点回应日志复制失败；
27.第二响应单元，用于如果所述日志复制请求来自其他跟随者，通过验证随机函数算法验证所述日志复制请求中的日志消息的有效性；如果有效，则根据领导者日志情况更新所述跟随者节点自己的下一索引和匹配索引，如果所述日志复制请求中的日志消息跟所述跟随者节点自己的下一索引匹配，则所述跟随者节点在本地添加日志，并在添加日志成功后向所述领导者节点回应日志复制成功；如果验证不通过或日志消息跟所述跟随者节点自己的下一索引不匹配，则直接忽略所述日志复制请求。
28.又一方面，本发明还提供了一种fabric区块链中的快速日志复制装置，应用于领导者节点，所述装置包括：
29.广播单元，用于领导者节点向跟随者节点广播日志复制请求；
30.接收回应单元，用于所述领导者节点接收所述跟随者节点的日志复制成功回应或日志复制失败回应；所述跟随者节点接收到所述领导者节点发送的日志复制请求后，转发所述日志复制请求给其他跟随者，并根据领导者日志情况更新所述跟随者节点自己的下一索引和匹配索引，如果所述日志复制请求中的日志消息跟所述跟随者节点自己的下一索引匹配，则所述跟随者节点在本地添加日志，并在添加日志成功后向所述领导者节点回应日志复制成功，如果不匹配则向所述领导者节点回应日志复制失败；
31.日志提交单元，所述领导者节点在接收到针对所述日志复制请求的超过半数的日志复制成功回应之后，提交所述日志复制请求中的日志，并异步的将已提交日志应用到状态机中。
32.进一步地，添加日志单元，用于在所述领导者节点广播日志复制请求之后，所述领导者节点进行本地添加日志的持久化操作。
33.本发明的优点和积极效果：本发明针对raft算法的性能瓶颈，在日志复制阶段主要进行了三个方面的改进：首先，利用了跟随者节点的带宽，使跟随者节点在收到领导者节点的appendentries日志复制rpc时，同样会广播此领导者的日志复制消息给其他跟随者节点，并有效处理了在引入跟随者节点广播消息而产生的冗余消息和影响日志一致性的问题；其次，领导者在接收到客户端请求时会先广播appendentries rpc消息请求跟随者进行日志复制，再自己本地增加该日志；最后，当一个日志被大多数节点复制成功而需要提交时，领导者会异步的把这个日志应用到状态机中，进而加快了下一次广播appendentries rpc的时间。通过这三方面的改进，大大加快了日志复制过程，提高了系统的整体工作效率。
附图说明
34.为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图做以简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
35.图1为本发明实施例中fabric区块链中的快速日志复制方法的流程图；
36.图2为本发明实施例中创建资产合约的事务流程图；
37.图3为本发明实施例中创建资产合约在2
‑
of
‑
any背书策略下的吞吐量折线图，虚线表示原始raft，实线表示本发明算法；
38.图4为本发明实施例中创建资产合约在2
‑
of
‑
any背书策略下的时延折线图，虚线表示原始raft，实线表示本发明算法。
具体实施方式
39.为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。
40.本发明针对raft算法的日志复制的问题，在日志复制阶段主要进行了三个方面的改进。
41.首先是领导者单点广播appendentries rpc日志复制请求的问题，在一开始同样是领导者单点广播appendentries rpc日志复制请求，但是当跟随者收到这个日志同步消息后，跟随者也可以广播该日志复制请求信息给其他跟随者节点，其他跟随者收到一个跟随者节点发送的领导者日志复制请求时，依旧会同步该日志，并可能会提前对领导者进行appendentries rpc回应，这样可以加快对领导者日志复制请求的回应，进而加快该日志的提交速度，提升系统性能。
42.其次，对于领导者优先本地添加日志再进行广播appendentries rpc日志复制请求的同步问题，本发明先进行快速的appendentries rpc广播，再进行本地添加日志的持久化操作。需要注意的是，对于跟随者来说，它们不能收到领导者的日志复制请求时优先回应领导者，再本地添加该日志，因为对于跟随者来说重要的就是优先本地添加日志，如果优先进行回应领导者之后本地添加日志失败，那么无疑会让领导者误以为超过半数节点已经复制了该日志，进而造成了错误的日志提交。在本发明算法中，由于跟随者节点也可以广播领导者的日志，因此跟随者会优先广播领导者的日志消息给其他跟随者节点，再本地添加该日志，最后回应领导者，这样可以使其他跟随者节点快速的收到领导者的日志复制请求。在本发明算法中只要保证了跟随者先本地添加日志再进行回应领导者的顺序，就一定可以保证领导者对于超过半数节点复制该日志的判断，进而保证了可以正确的提交日志。
43.第三，对于领导者收到超过半数跟随者成功复制日志的回应再应用到状态机的问题，本发明算法采取异步处理这两个步骤，即当一个日志已被提交后，那么另起一个线程去应用此日志到状态机中。通过异步的将已提交日志应用到状态机中，可以使领导者更快的进行下一条日志请求rpc，进而加快了日志复制的整体流程。
44.综上改进，本发明算法的日志复制过程如图1所示，由于图中细节较多，为了避免图的混乱，因此只采用3个节点的系统。首先客户端发出请求到领导者节点，领导者节点会优先广播appendentries rpc日志复制请求给跟随者，然后在本地添加日志。跟随者收到领导者的日志复制请求后会优先广播该请求到其他跟随者节点，然后再本地添加日志，待添
加日志成功后会返回日志复制成功的响应给领导者。从图中可以看到领导者在第一步中的广播日志复制请求中由于网络延迟，没有被跟随者2接收到，但是由于本发明算法允许跟随者也进行广播，因此跟随者2收到了跟随者1转发的领导者日志复制请求，进而可以成功回应给领导者。假设如图中所示跟随者1在复制日志成功后返回的回应没有被领导者接收到，如果使用raft算法，那么领导者将不会收到超过2个以上的成功复制回应，进而导致日志提交失败。而本发明算法由于引入了跟随者节点也可以广播领导者节点的日志复制请求，降低了跟随者节点受到网络延迟的影响，进而使得领导者依旧可以成功提交日志。领导者在得知超过半数以上的日志复制成功后，会异步的发送下一条日志复制请求rpc以及将该日志应用到状态机中，回应客户端。
45.跟raft算法相同，本发明算法中的跟随者节点应该也只接受原本从领导者发出的日志复制请求，虽然本发明算法跟raft算法一样都假设系统为非拜占庭系统，所以跟随者转发的日志请求就一定是领导者的日志请求。本发明中，加入了跟随者确认日志请求为领导者的日志复制请求的机制。利用vrf(verifiable random functions)算法的可验证性，领导者在广播appendentries rpc日志复制请求之前应该使用vrf算法的generatebeta(sk，alpha)来生成beta和pi，将这些信息放入到appendentries rpc中再发送到跟随者节点，这样跟随者节点再广播该appendentries rpc给其他跟随者节点时，其他节点可以使用领导者公钥pk通过vrf算法的verify(pk，alpha，pi)来验证其appendentries rpc中beta的有效性，如果有效则确认了领导者的请求，可以广播给其他跟随者节点。这里的alpha使用rpc中的附带的日志条目消息来计算。
46.并不用担心日志选举阶段的alpha跟领导者选举阶段的alpha相混淆进而影响到整个系统的流程，因为这两个alpha本就属于不同的两个rpc中。在领导者选举阶段对应的是requestvote rpc投票请求，而在日志复制阶段则是appendentries rpc日志复制请求，不同rpc中的alpha处于不同阶段，不会相互影响，其作用也不同，在requestvote rpc中的alpha是为了保持所有候选者都使用同一个alpha来公平的选举领导者而产生beta，因此其使用的日志条目是每个任期最后一个已提交的日志条目。在appendentries rpc中的alpha则是为了让跟随者确认其他跟随者转发的日志复制请求确实是该任期中领导者发送的日志复制请求，进而加快跟随者回应领导者成功复制日志的速度，因此此alpha的计算选取的是appendentries rpc中附带的日志条目。
47.本发明算法在引入了跟随者允许广播领导者的日志复制请求的机制后，会造成跟随者节点可能会收到很多不相匹配的日志复制请求问题，以及领导者会收到多个appendentries rpc回应问题，如何正确处理这些可能冗余的消息是本发明算法在日志复制阶段设计的关键。之所以领导者和跟随者会收到冗余消息是因为，在raft算法中是单领导者节点对其他跟随者节点进行日志同步，由于每个跟随者的日志情况不相同，所以领导者根据每个跟随者的日志情况所同步的日志也不相同。也就是说领导者给每个跟随者发送的日志可能不相同，这种情况在领导者宕机后产生新的领导者时会更加明显，因此在这种机制下，本发明算法的改进会导致跟随者节点之间转发一些不相匹配的日志，如果日志不匹配那么对于跟随者来说这些不匹配日志就是冗余消息，如果在一轮appendentries rpc中出现多个日志相匹配的情况，那么跟随者也会接收这些匹配日志，在本地添加后会返回多个回应给领导者。
48.领导者在一轮心跳期间可能会收到同一跟随者的多个reply，这些reply可能是跟随者成功复制领导者日志请求的回应，也可能是跟随者成功复制其他跟随者日志请求的回应，由于跟随者在收到其他跟随者不配的日志消息时会忽略，所以这些reply至多只会有一个false，那就是回应领导者发出的不匹配的日志复制消息。同时这些reply可能会有若干个true，因为跟随者在一次心跳期间可能会成功添加多个日志，这样会回应多个true的reply。本发明算法中的领导者面对一次心跳期间收到同一跟随者的多个reply时，如果只有唯一的reply<false,nextindex,matchindex>，那么说明该跟随者在这次心跳期间没有成功添加领导者的日志消息，也没有成功添加跟随者转发的日志消息，之后正常按照nextindex进行下次同步即可。如果领导者收到了若干个带有true的reply消息，如那么领导者将不会关心false的reply,只要取所有true的reply中最大的nextindex进行下次同步即可，事实上在同一轮心跳的多个reply中，true reply中的nextindex一定大于等于false reply中的nextindex，这是因为false reply只可能是对于领导者日志不匹配回应，回应的一定是最初最小的nextindex，而true reply中的nextindex至少是成功复制一次的nextindex，因此会不断增加，也就必然大于等于false reply中的nextindex。结合上述逻辑，领导者在一次心跳期间对于收到同一跟随者的多个reply时会选取最大的nextindex。
49.下面对日志复制阶段的算法进行具体说明：
50.首先是跟随者在日志复制阶段的算法，如算法1所示，跟随者会对收到的appendentries rpc进行区分，如果是领导者的日志复制请求，首先会转发该消息给其他跟随者，然后根据领导者日志情况更新自己的nextindex和matchindex，如果日志消息跟自己的nextindex匹配，那么添加日志，成功后回应成功的rpc，如果不匹配则回应失败的rpc。如果判断出这个appendentries rpc来自其他跟随者，那么首先通过vrf算法验证消息的有效性，如果有效则判断日志是否匹配，匹配的话会本地添加日志，然后回应领导者，并附带新的nextindex和matchindex，如果vrf验证不通过或日志不匹配则直接忽略该rpc。
51.算法1：日志复制阶段中跟随者的算法实现
52.[0053][0054]
领导者在日志复制阶段的算法，如算法2所示。跟raft算法一样，本发明算法的领导者在第一次上任后为了提交上一任期的所有日志会广播一个空日志给所有节点，同时维持自己的心跳。之后进入领导者节点的主循环，如果心跳定时器超时，那么应该广播一次appendentries rpc进行日志同步，首先会本地生成pi和beta，然后广播appendentries rpc，最后本地添加这期间客户端发送的日志请求。如果发现对于某个日志的回应超过半数为true，那么会提交该日志，并异步应用该日志数据到状态机中。如果收到了多个rpc回应，那么会根据回应更新每个跟随者的nextindex和matchindex以备下次同步，同时根据本发明算法的改进，这个更新操作包括对于同一个跟随者的多个rpc回应，应该取最大的nextindex进行更新。如果领导者收到了更高任期号的requestvote rpc投票请求，那么说明进入到了下一任期的领导者选举阶段。自己应该退回为跟随者状态。
[0055]
算法2：日志复制阶段中领导者的算法实现
[0056][0057]
下面对本发明中的性能测试情况进行说明。
[0058]
1.测试环境
[0059]
实验环境的配置细节如表1所示。
[0060]
表1
[0061][0062]
2.测试指标
[0063]
使用hyperledger的官方测试工具caliper对vraft算法和raft算法进行测试和对比实验。
[0064]
caliper目前支持的区块链性能指标有四个，分别是成功率、吞吐量、时延和资源消耗率。
[0065]
3.测试结果
[0066]
通过caliper的负载客户端提交创建资产合约的事务流程图如图2所示，首先由负载客户端不断产生提交类型的创建资产合约输送到fabric系统，然后经过fabric的事务处理流程，最终该交易会上链，并且由于创建资产合约会创建固定字节大小的资产数据，因此还会产生在fabric节点的持久化操作，也就是将创建的资产数据写入到peer节点本地的世界状态数据库中，最终由caliper的观察客户端观察收集整个测试周期中fabric系统的各节点性能状况。
[0067]
由于创建资产合约可以存储固定字节大小的资产数据，因此对于吞吐量和时延的测试采用渐进增长字节大小的资产数据，背书规则使用2
‑
of
‑
any，表示需要组织1和组织2的两个peer节点均背书。
[0068]
表2
[0069][0070]
表2显示的是创建资产合约在2
‑
of
‑
any背书策略下的吞吐量数据，图3显示的是创建资产合约在2
‑
of
‑
any背书策略下的吞吐量折线图。由图3可以看出在2
‑
of
‑
any背书策略下本发明算法的吞吐量依旧高于raft算法的吞吐量，且在资产为32kb时，本发明算法在吞
吐量上比raft算法提高了约36.1％。
[0071]
表3
[0072][0073]
表3所示的是创建资产合约在2
‑
of
‑
any背书策略下随着资产大小变化的时延表，图4则表示创建资产合约在2
‑
of
‑
any背书策略下随着资产大小变化的折线图，这里时延依旧是平均时延。从图表中可以看出在背书时间增加后，本发明算法在时延性能上增加的更小，在资产8kb之前两者的时延性能相差不大，在资产为8kb时，本发明算法的时延已经低于raft算法的时延，并且随者创建资产的大小呈指数型增加，本发明算法的时延增长趋势没有raft算法的时延增长趋势迅猛。在资产大小为16kb时，本发明算法的时延性相比8kb资产时增加了约41.2％，而raft算法在资产大小为16kb时的时延性能增加了近50.7％。在资产为32kb大小时，本发明算法的时延性能相比16kb资产时增加了约95.8％，而raft算法在资产大小为32kb时的时延性能相比16kb资产增加了近143.3％。通过增长趋势数据可知，在资产较大时，本发明算法在日志复制阶段可以批量复制日志，减小了时延。
[0074]
表4
[0075][0076]
在2
‑
of
‑
any背书策略下测试创建资产合约的资源消耗率，这里的资产固定大小为适中的8kb。表4显示的是创建资产合约在2
‑
of
‑
any背书策略下且固定资产大小为8kb的cpu使用情况。可以直观的看出来本发明算法的cpu占比普遍高于raft算法的cpu占比，这是因为创建资产合约带有实际的8kb存储数据，使得本发明算法在日志复制阶段进行了更多的加密验证相关的计算消耗，进而使得本发明算法中的order节点会占用更多的cpu。
[0077]
表5
[0078][0079]
表5显示的是创建固定8kb资产合约在2
‑
of
‑
any背书策略下的内存使用情况，单位为mb。从表中可以看出各个order节点占用的内存比空合约时都有明显的增幅，本发明算法order节点的内存使用情况与raft算法order节点的内存使用情况相差不大。
[0080]
表6
[0081][0082]
表6显示的是创建固定8kb资产合约在2
‑
of
‑
any背书策略下order节点的网络i/o情况，单位为mb。raft算法各节点的网络i/o依旧不均匀，而本发明算法各节点的网络i/o则相对均匀，并且都普遍大于raft算法的网络i/o。这也正是因为本发明算法在日志复制阶段的跟随者也会广播rpc给其余节点造成的，进而导致了在本发明算法中各节点的网络i/o情况相对均匀，且比raft算法中各节点的网络i/o更大。
[0083]
实验表明，本发明算法在吞吐量和时延方面普遍优于raft算法，并且随者负载的增加，这种优势更加明显，但是对于资源消耗方面，本发明算法比raft算法消耗了更多硬件资源。
[0084]
对应本发明中的应用于跟随者节点的fabric区块链中的快速日志复制方法，本发明还提供了应用于跟随者节点的fabric区块链中的快速日志复制装置，包括：
[0085]
接收单元，用于跟随者节点接收日志复制请求，并对接收到的日志复制请求进行区分；
[0086]
第一响应单元，用于如果所述日志复制请求来自领导者节点，则转发所述日志复制请求给其他跟随者，并根据领导者日志情况更新所述跟随者节点自己的下一索引和匹配索引，如果所述日志复制请求中的日志消息跟所述跟随者节点自己的下一索引匹配，则所述跟随者节点在本地添加日志，并在添加日志成功后向所述领导者节点回应日志复制成功，如果不匹配则向所述领导者节点回应日志复制失败；
[0087]
第二响应单元，用于如果所述日志复制请求来自其他跟随者，通过验证随机函数算法验证所述日志复制请求中的日志消息的有效性；如果有效，则根据领导者日志情况更新所述跟随者节点自己的下一索引和匹配索引，如果所述日志复制请求中的日志消息跟所述跟随者节点自己的下一索引匹配，则所述跟随者节点在本地添加日志，并在添加日志成功后向所述领导者节点回应日志复制成功；如果验证不通过或日志消息跟所述跟随者节点自己的下一索引不匹配，则直接忽略所述日志复制请求。
[0088]
对应本发明中的应用于领导者节点的fabric区块链中的快速日志复制方法，本发明还提供了应用于领导者节点的fabric区块链中的快速日志复制装置，包括：
[0089]
广播单元，用于领导者节点向跟随者节点广播日志复制请求；
[0090]
添加日志单元，用于在所述领导者节点广播日志复制请求之后，所述领导者节点进行本地添加日志的持久化操作；
[0091]
接收回应单元，用于所述领导者节点接收所述跟随者节点的日志复制成功回应或日志复制失败回应；所述跟随者节点接收到所述领导者节点发送的日志复制请求后，转发所述日志复制请求给其他跟随者，并根据领导者日志情况更新所述跟随者节点自己的下一索引和匹配索引，如果所述日志复制请求中的日志消息跟所述跟随者节点自己的下一索引匹配，则所述跟随者节点在本地添加日志，并在添加日志成功后向所述领导者节点回应日志复制成功，如果不匹配则向所述领导者节点回应日志复制失败；
[0092]
日志提交单元，所述领导者节点在接收到针对所述日志复制请求的超过半数的日志复制成功回应之后，提交所述日志复制请求中的日志，并异步的将已提交日志应用到状态机中。
[0093]
对于本发明实施例的fabric区块链中的快速日志复制装置而言，由于其与上面实施例中的fabric区块链中的快速日志复制方法相对应，所以描述的比较简单，相关相似之处请参见上面实施例中fabric区块链中的快速日志复制方法部分的说明即可，此处不再详述。
[0094]
在本发明所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，可以为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。
[0095]
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
[0096]
另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
[0097]
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、只读存储器(rom，read
‑
only memory)、随机存取存储器(ram，random access memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
[0098]
最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。