增加对mvcc机制的简要介绍

Store新增支持MVCC的KVDB实现.md

-# 一、现状 #
-# 一、现状 #
+# 一、关于MVCC机制的简要说明 #
+# 一、关于MVCC机制的简要说明 #
+## 1.以太坊中的StateDB  
+Store模块的Mavl Tree和以太坊的StateDB的实现方式比较类似：  
+以太坊的StateDB在设计上并不会每生成一个块的时候都复制一份，而是重用树节点，在新块生成的时候，只改变发生状态变化的节点（通过写dirty标记），然后引用原来未变化的节点，重新计算变化节点到根路径上所有节点的哈希，即相当于生成一颗新树（State Root Hash发生了变化）：  
+![Store接口时序](./resource/StateDB.png)
+有了StateDB的这种设计，在区块链代码中的业务实现逻辑就会非常简单，如果需要修改账户数据（余额变更、新增合约、废弃合约等），直接操作内存中的StateDB即可，在块生成之前，系统会根据变更的信息，重新生成哈希，并将变更写到数据库。
+
+StateDB的这种设计使用起来非常方便，但是也存在一定的问题：  
+（1）因为它保存了所有的数据，随着时间的增长，这棵树会越来越大，占用越来越多的磁盘空间。
+（2）对于历史数据，需要根据特定区块的State Root Hash建立起树形结构，并查找相关kv信息，并不能做到KV数据库的根据主键直接查询的快速简捷。  
+
+## 2.Chain33中的MVCC机制  
+而Chain33当前引入的MVCC机制，借鉴了数据库设计中的MVCC理念（Multi-Version Concurrency Control 多版本并发控制），并结合区块链数据的特点：  
+（1）历史数据多（历史区块及交易数据），当前修改的数据少（当前正在生成的区块及交易数据）；  
+（2）历史数据不能修改，修改只发生在当前正在生成的区块上；  
+（3）读历史数据的比例高（对历史区块数据的读取），写数据的比例低（新生成区块中修改数据）；  
+![Store接口时序](./resource/mvcc-show.png)  
+根据上图示意：  
+主键为Key的变量值在区块高度101、102中均发生变化，对应的在KVDB中有Key:101->value101和Key:102->value102两个历史版本数据，在当前区块104中正在写入新值Key:104->value104；  
+那么对于历史数据Key:101、Key:102可以有很多并发的读，对于Key:104有唯一的当前写，这些读写操作可以并发互不影响的执行，并且这些数据可以平铺存储在普通的KVDB中，读写只要根据块高作为版本号与Key构成唯一主键即可（Key:version或者Key:height），不需要构建树形结构来读取历史值和改变当前值，这对于数据读写的效率提升会有比较大的帮助。
+
+
+# 二、Chain33中的Store及MVCC实现现状 #
 ## 1.Store与外部的交互消息接口 ##
 ![Store接口时序](./resource/kvdb-sequence.png)
 
@@ -92,12 +114,12 @@ TotalFeeKey:hash->fee
 
 
 
-# 二、需求 #
+# 二、Store模块支持MVCC的KVDB的需求 #
 针对Store模块，需要建立一种支持MVCC机制的KVDB实现，达到以下目的：  
 1.历史数据可以保留下来，供查询使用，并能够支持数据回滚。  
 2.支持MVCC机制，除了保留下来历史版本数据，还可以把多版本数据存储在结构是线性平铺的KV数据库中，不需要使用复杂的树形结构来维护数据，对于系统性能提升有帮助，即使数据量达到一定程度，系统性能不发生明显的下降。
 
-# 三、方案描述(正在实现) #
+# 三、具体方案描述(正在实现) #
 
 ##配置文件中和Store相关的如下配置增加取值
 [store]