Fabric TPS 性能优化至20000tps

原始社区版fabric 

bitcoin:~5tps

ETH:~15tps

ETH 2.0: 10000 tps

fabric为了解决双花问题，引入读写集和MVCC机制

fabric联盟链高并发场景下如何提高TPS

fastfabirc1.4:20000tps

FastFabric: 提高超级账本的TPS_yijiull-程序员秘密 - 程序员秘密

fabric性能优化——hashtable替换leveldb_The future is already here it's just not evenly distributed。-CSDN博客_fabric 优化

https://github.com/tonycai/The-Journal-of-Blockchain

区块链三个核心：去中心化、共识机制、不可篡改

如何配置Fabric出块参数来达到“最大”TPS

https://www.processon.com/view/link/5f3c06ec7d9c0806d41fec86#map

https://github.com/Hyperledger-TWGC/fabric-performance-wiki

grpc接收到的block数据进行反序列，然后缓存

grpc压缩

3. 使用hashtable代替fabric中的leveldb   

CPTS  云性能测试服务（Cloud Performance Test Service）

fabric TIP 上限

1. 硬件上限

我们也无法将fabric的tps上限超过网络中某块网卡的最大承载能力。

（百度超级链）

)Fabric网络结构(网络带宽、磁盘IO、计算资源等)，配置参数(如区块大小、背书策略、通道数量、状态数据库等)，共识算法（solo,kafka,pbft等）都会影响评测后果，很难构建反映fabric 全貌的测试模型；

Fabric 交易过程剖析

在Fabric交易过程中，波及不同的角色，每个角色承当不同的性能，节点（Peer）可细分为背书节点（Endorser peer）和提交节点（Committer peer），共识由排序（Orderer）角色实现。交易流程如下：

(1)应用程序客户端通过SDK向区块链网络发动一个交易提案（Proposal），交易提案把带有本次交易要调用的合约标识、合约办法和参数信息以及客户端签名等信息发送给背书节点（Endorser）。

 (2)背书节点（Endorser）收到交易提案（Proposal）后，验证签名并确定提交者是否有权执行 *** 作，验证通过后执行智能合约，并将后果进行签名后发还给应用程序客户端。

 (3)应用程序客户端收到背书节点（Endorser）返回的信息后，判断提案后果是否统一，以及是否参照指定的背书策略执行，如果没有足够的背书，则停止解决；否则，应用程序客户端把数据打包到一起组成一个交易并签名，发送给Orderers。

(4)Orderers对接管到的交易进行共识排序，而后依照区块生成策略，将一批交易打包到一起，生成新的区块，发送给提交节点（Committer）；

(5)提交节点（Committer）收到区块后，会对区块中的每笔交易进行校验，查看交易依赖的输入输出是否合乎以后区块链的状态，实现后将区块追加到本地的区块链，并批改世界状态。

客户端通过Fabric实现交易，要感知三个步骤（收集背书，提交排序和确认后果），而传统的数据库的读写，只有发动申请，期待确认即可。如果应用经典的测试工具如JMeter,须要将fabric sdk进行包装RESTFul接口，减少了评测的复杂度。侥幸的是，2017年5月超级账本社区推出Caliper，容许用户通过一系列预置的用例来测试特定的区块链技术实现。Caliper生成的报告将会蕴含一系列区块链性能指标，如TPS（均匀每秒交易数），时延，系统资源占用等。本文的评测后果均为Caliper工具来测试生成。

查问吞吐量（Query Throughput）：每秒解决的查问申请量

共识吞吐量（Consensus Throughput）：每秒解决的共识申请量

一致性吞吐率（Consistency Throughput）：每秒实现的同步业务数

均匀时延（Avg Latency）：实现一次事务的均匀耗时

失败率（Fail Rate）：呈现业务失败（含超时）的比例