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 | 大于 | 驾照 | 可以 |
|
|
|
|
|
|
|