Hyperledger Fabric nodejs sdk 性能问题答案

【问题标题】：Hyperledger Fabric nodejs sdk performance issueHyperledger Fabric nodejs sdk 性能问题
【发布时间】：2018-07-18 00:39:59
【问题描述】：

我在使用 Hyperledger Fabric node.js sdk 时遇到性能问题。

当我向 sdk 发出调用请求并使用以下代码使用链码给出的响应时

var proposalResponse = results[0];
            var proposal = results[1];
            let isProposalGood = false;

            if(proposalResponse
                && proposalResponse[0].response
                && proposalResponse[0].response.status === 200){
                    isProposalGood = true;
                    var res = JSON.parse(proposalResponse[0].response.payload.toString());
                            res.event_status = 'VALID'
                            resolve(res);
                }else{
                    reject(createErrorResponse(proposalResponse[0].message,500))
                    return
                }

API 会在 50 毫秒内响应，如下图所示：

但是，当我使用以下代码等待orderer确认交易时：

if (code === 'VALID'){
                            //get payload from proposal response
                            var res = JSON.parse(proposalResponse[0].response.payload.toString());
                            res.event_status = 'VALID'
                            resolve(res);
                        }else{
                            var return_status = createErrorResponse("Transaction was not valid", 500);
                            return_status.tx_id = transaction_id_string
                            reject(return_status)
                            return
                        }

响应时间约为 2500 毫秒，如下图邮递员截图所示：

如果我错了，请纠正我

我知道这需要时间，因为orderer 确认事务并提交到ledger。但是您不认为只有在orderer 同意事务并提交到ledger 时我们才应该继续。如果是，则需要 2.5 秒才能响应（网络在本地机器上的 docker 上运行，而在同一台机器上的 sdk 上运行），这是一个性能问题。

如果将数据写入链码，然后订购者拒绝将交易写入分类帐，会发生什么情况？

任何帮助将不胜感激

【问题讨论】：

标签： node.js hyperledger-fabric

【解决方案1】：

orderer 确认交易并提交到账本中。

排序服务（顾名思义）的任务只是将接收到的背书交易按通道按时间顺序排序，然后将它们交付给通道中的所有对等点。订购者实际上并没有将交易提交到分类账中。

Committer Peers 会这样做。提交是一个耗时的过程，因为所有对等方都会验证块内的所有交易，以确保背书策略得到满足，并确保自交易生成读取集以来，读取集变量的账本状态没有发生任何变化执行。区块中的交易被标记为有效或无效。然后每个对等点将块附加到通道的链上，并且对于每个有效事务，写入集都提交到当前状态数据库。 发出一个事件，通知客户端应用程序事务（调用）已不可更改地附加到链上，以及事务是否有效或无效的通知。

所以在了解了Transaction Flow 中的所有这些细节之后，需要注意的是，客户端应用程序不应等待订购者收到的响应。相反，它应该只要求订购者交付背书的交易，并且应用程序应该订阅对等方发出的事件，以便它应该知道或被通知交易实际上是在通道链中不可更改地提交。

您可以在Fabric Node SDK docs 中获得有关活动订阅的更多帮助。

如果数据被写入链码之后会发生什么 orderers 拒绝将交易写入账本？

这根本是不可能的，因为只有当交易通过来自背书节点的正确背书（由背书策略指定）进行验证，然后最终交付给提交节点以在链中附加新值时，数据才会附加到链中并更新世界状态。数据只有在通过所有验证后才会写入链中，因此排序者永远不会拒绝对数据所做的更改。

【讨论】：

非常感谢您的详细解释

【解决方案2】：

我找到了造成这种延迟的另一个原因。

configtx.yaml 中的 batchtimeout 变量设置为 2 秒。所以它会做它的处理然后等待2秒然后切割一个块。所以写操作大约需要 2.5 秒。

【讨论】：