fabric性能优化——读写集&MVCC

    fabric的交易处理过程大致可以分为三个过程，

        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的限制。

key	value	R-key	R-value	R-condition	W-key	W-value
name	张三	年龄	18	大于	驾照	可以