所有
据我所知,在Hyperledger Fabric环境中,订购者会向同行发送消息。如果有一个离线同伴。当消息恢复到ON-LINE时,消息如何传递给对等方?订货人如何知道同行恢复到在线?
此致 计数
答案 0 :(得分:4)
当对等体重新上线时,它将获得如下块:
如果对等方是组织中的八卦领导者,那么它会请求一个流 来自订货人的块通过交付API,从同行开始 当前区块高度。
如果同伴不是八卦领袖而且是 当前或稍微落后(在一个小门槛内),然后它 通过组织领导同行的八卦(或潜在的 组织中的另一个同行。
如果同伴不是八卦领袖而且是 后面的方式(超出阈值),然后通过块获取块 从另一个同伴转移(可以是跨组织)。
答案 1 :(得分:1)
我想添加有关状态复制流的更多详细信息。首先,订购服务提供以下API:
service AtomicBroadcast {
rpc Broadcast(stream common.Envelope) returns (stream BroadcastResponse) {}
rpc Deliver(stream common.Envelope) returns (stream DeliverResponse) {}
}
其中Broadcast
用于发送订单到订购服务的事务,而Deliver
用于从特定位置开始从订购服务请求块。 Deliver
的可能选项是
message SeekPosition {
oneof Type {
SeekNewest newest = 1;
SeekOldest oldest = 2;
SeekSpecified specified = 3;
}
}
考虑到状态同步和分类帐的复制,对等方有两种可能的操作模式。一般而言,通过使用八卦算法在整个网络中分布分类帐块。为了防止连接到订购服务的所有同伴,存在领导者选举的概念,例如,对于每个组织,选择一个对等体来打开与订购服务的连接并开始拉取块并将它们转发到八卦层以使它们在网络中的对等体之间分配。在开始领导之前,检查分类账高度是多少,并要求从其开始提供新的区块,所有同行监控领导者的可用性并在需要时启动新的领导者选举。
现在,有一个额外的后台进程收集来自对等方的状态消息,如果它发现本地分类账高度与网络中其他对等方的高度之间存在差距,它将通过“状态转移”启动丢失块的复制@Dave提到的过程。
因此,要得出结论,如果同伴上线并且由于某种原因被选为领导者,它将直接从订购服务复制分类帐块,否则他将通过八卦层或状态转移获得,如果分类账高度存在显着差距。
答案 2 :(得分:0)