例如，两个应用程序正在连接一个链码，如果几乎同时请求“调用”同一个键值对链码的动作，会发生什么？
如果它是 Hyperledger Fabric 的噩梦，我们该如何应对？在 Hyperledger core.yaml 设置方面？还是链码设计的一面？
问问题
1297 次
2 回答
3
注意：第一个答案是 Fabric v0.6 相关的。Fabric v1使用不同的机制。这些步骤是（据我目前所知）：
- 客户端向 Endorser 发送交易。
- Endorsers 执行交易，生成世界状态键/值更改集，称为读/写集。Endorser(s) 将结果返回给客户端。
- 客户端接收所有响应，并将结果和 R/W 集与背书策略进行比较。
- 客户端将成功的背书转发给排序服务，排序服务从一组交易中创建块。
- 排序服务将完整块转发给所有提交者（背书者、观察者等）。
- 每个提交者按顺序应用事务的 R/W 集，并在执行过程中更新每个读取密钥的版本（显然使用哈希图）。在提交每个集合时，它会检查读取集中每个密钥的版本，以便密钥版本不能低于当前版本号。
注意：这是 v0.6 的一个重大变化，因为只有完全提交的事务才能被读取看到，即使在调用的上下文中也是如此！如果存在任何密钥冲突，则交易失败，在最后一刻！没有发出链码事件，但失败记录在最后一个块中。世界状态更改丢失，必须由客户端重新提交事务！
解决此问题的方法是设计您的链代码，使其不使用每个资产的共享密钥，或设计您的客户端以在资产级别流控制 API 调用（链代码事件，无论您想调用什么），或者很可能两者兼而有之。
因此，原始问题的答案是，这些事务在 v0.6 Fabric 上都可以正常工作，并且第一个事务可以在 Fabric v1 上正常工作，但如果两者发送得太近（同时太接近），则第二个事务在 Fabric v1 上会失败。
显然，当没有关键冲突时，两者总是有效的（假设交易通过共识并且是确定性的——就像在所有背书人上创建相同的结果一样）。
于 2017-04-28T17:34:26.680 回答
2
所有的调用和查询事务都是按顺序执行的（不是同时执行的）。在这个问题中，它解释了交易是如何执行的。请注意，通过共识，所有执行都是有序的，然后每个节点都按照该顺序执行它们。因此，没有并发。
于 2016-06-08T07:46:34.223 回答