# MVCC (继续...)

![left](./student-guide/diagram/MVCC01_aa_001_20220511.png)
-------------------------------------------------------------
下面,我们开始看一下 TiKV 的实现,

在这里,我们看到 TiKV 中的 RocksDB 实例中的 3 个 column family 是这样存储数据的:

1. Write CF 中,由于只有事务一提交了,所以会有事务一的记录,key = 1 和 key = 2 两个值的提交记录,value 更改都是 start_ts = 100. 还有一个 key = 4 ,我们看他的 start_ts 为 80,所以这条记录是以前提交的。

2. Default CF 中,它们是 key = 1,key = 2 和 key = 4,其中,key = 1 和 key = 2 的 start_ts 是 100,也就是 Write CF 中事务一提交的那两行,key = 4 的 start_ts 为 80。

3. Lock CF 中,由于事务一已经被提交,所以事务一中 key = 1,key = 2 的锁就算被删除了,由于事务二没有提交,所以事务二中 key = 1 和 key = 4 的锁还是存在的。

那么,这些数据以什么顺序存储在 RocksDB 中呢,我们注意以下几点:

1. 对于 Default CF,KEY 是 { 用户 key } + { start_st },对于 Write CF,KEY 是 { 用户 key } + { commit_st },对于 Lock CF,key 就是 { 用户 key }。
注:这里的  { 用户 key } 是业务上的键,而 KEY 是指存储在 RocksDB 中的键。

2.  所有的列族（CF）,首先,都是按照 { 用户 key } 的顺序存储的,其次,相同 { 用户 key } 的 KEY 是按照 st_start 或者 st_commit 由大到小的顺序存储的,这个的原因是让较新的数据（即 timestamp 比较大的数据）排列在较老的数据（即 timestamp 比较小的数据）前面。

知道了以上内容,我们就可以理解 MVCC 的运作机制了。