Hyperledger fabric Hyperledger Fabric如何处理；援引；同一个键值对的链码？

例如，两个应用程序连接一个链码，如果请求“调用”相同的链码键值对的操作几乎在同一时间发生，会发生什么

---

如果这是Hyperledger结构的噩梦，我们如何处理它？在Hyperledger core.yaml设置的一侧？还是链码设计的一方？

所有调用和查询事务都是按顺序（而不是同时）执行的。在本文中，将解释如何执行事务。请注意，通过协商一致，所有执行都是有序的，然后每个节点都按照该顺序执行。因此，不存在并发性。

注意：第一个答案与Fabric v0.6相关结构v1使用不同的机制。这些步骤是（据我目前所知）：

客户向背书人发送交易

背书人执行事务，生成世界状态键/值更改集，称为读/写集。背书人将结果返回给客户

客户收到所有人的回复，并将结果和R/W设置与背书政策进行比较

客户机将成功的背书转发给订购服务，订购服务从一组交易中创建块

订购服务将整个区块转发给所有提交者（背书人、观察者等）

每个提交者都按顺序应用事务的R/W集，并在执行过程中更新每个读取键的版本（显然使用哈希映射）。提交每个集合时，它会检查读取集合中每个密钥的版本，以便密钥版本不得小于当前版本号 注意：这是v0.6版的一个重大变化，因为只有完全提交的事务才能被读取看到，即使在调用的上下文中也是如此！如果存在任何密钥冲突，则事务在最后一分钟失败！不会发出链码事件，但故障会记录在最后一个块中。世界状态更改丢失，客户端必须重新提交事务

解决方法是将链码设计为而不是为每个资产使用共享键，或者在资产级别将客户端设计为流控制API调用（链码事件，无论您想调用什么），或者很可能两者兼而有之

因此，原始问题的答案是，两个事务在v0.6结构上都可以正常工作，第一个事务可以工作，但如果两个事务发送得太近（同时发送的事务太近），则第二个事务在结构v1上会失败

---

显然，在没有关键冲突的情况下，这两种方法都是有效的（假设交易通过共识并且是确定性的——就像在所有背书人身上创建相同的结果一样）。

对于单个渠道都是有效的。但是，同时提交的针对两个通道上相同或不同链码的事务可以并行执行，不会出现任何问题。