fabric性能优化读写集&MVCC

1、背书，交易的模拟执行，生成读写集；
2、排序，对交易的顺序达成共识，生成区块；
3、验证存储，验证区块，存储到账本；
今天讨论一些读写集和MVCC这种方式优缺点，首先看一下优点，
1、由于背书阶段分散到不同peer节点，所以该阶段可以并行进行，这意味交易读写集生成的效率也是大幅度提升了；
2、交易的模拟执行，生成读写集，可以说为后续的验证阶段减少了工作量，只需要验证几个k/v值即可，而其他一些区块链验证阶段，可能就是交易模拟执行，而且还是串行的；
这种读写集和MVCC会产生什么样子的弊端呢？
如果我们的链码连续的读写同一个k/v值，则很大概率这些交易只能成功几笔；这完全是因为MVCC的功劳；

那我们有没有什么办法解决一下呢？ 我们可以把读写集——一个保存K/V的简单数据结构，转换成一个带有逻辑结构的数据结构；
之所以有mvcc冲突，是因为我们在一个块中，靠前的交易对某个key进行了写操作，而后续的交易又需要对该交易进行读；由于生出读写集的时候，一个块里的交易，可能都是依赖于同一个版本的状态数据库，所以mvcc冲突的概率还是很大的；如果我们可以让排在后边的交易不依赖于状态数据库的版本，而是依赖于前一个交易的执行的结果，这样是不是就可以避免了mvcc的错误；
原始的读写集，在验证存储阶段我们拿到读写集基本做不了很复杂的操作，除了校验一下版本，就是更新数据，所以当有mvcc冲突的时候，只能舍弃交易；如果我们在读写集种增加一些可控的逻辑，这样在交易遇到mvcc冲突的时候，可以根据读写集自身携带的逻辑以及当前状态数据库进行判断，该如何进行下一步操作；
例如下面这个读写集的例子，当我们要invoke张三的驾照这个key的值的时候，我们可以根据R-condition、R-key、R-value的值联合判断，我们这次写入的值的前提条件是需要年龄大于18岁，如果前一个rwset执行完毕之后，世界状态满足，则可以继续执行，不受mvcc的限制。