我已经构建了一个Hyperledger Fabric系统,可以处理x个tps(每秒事务数)。将来,可能对该系统的要求不仅仅是x个tps。
那么,如何扩展Hyperledger Fabric系统以满足更高的要求?
我已经构建了一个Hyperledger Fabric系统,可以处理x个tps(每秒事务数)。将来,可能对该系统的要求不仅仅是x个tps。
那么,如何扩展Hyperledger Fabric系统以满足更高的要求?
有几种方法可以做到这一点。其中一种是增加认可同行的数量,并将认可提案的负载分布到更大的集合中。例如,如果您当前拥有一个认可策略,该策略要求您需要5个组织中的3个成员认可交易,并且每个组织都有一个单独的认可同行,最终您将达到tps的饱和状态。如果您为每个组织添加另一个认可同行,并在新旧认可同行集合上平均分配认可负载,则应该会看到更高的吞吐量。
如果您同时执行多个通道,则可以考虑为各个通道设置单独的认可同行,因为这将产生与上述策略类似的影响。
当然,项目维护人员不断地优化代码以改善性能,因此随着发布新版本,保持当前也是一个选择。
最后,您还可以寻求利用更快的硬件(例如,具有用于算法加速的加密加速),您应该也会看到增加,尽管可能不像应用第一种策略那样多。
除了上面的回答之外,当前系统可以扩展的范围是有限的,我们必须事先设计好处理系统的能力。