# MVCC（B）

![center](./student-guide/diagram/03-MVCC-02-01.png)
-------------------------------------------------------------
下面，我们开始看一下 TiKV 的实现，

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

- Write CF 中，由于只有事务一提交了，所以会有事务一中，key = 1 和 key = 2 两个值的提交记录，value 更改都是 start_st = 100.

- Default CF 中，我们关心时间是 STO = 100 后的新数据，它们是 key = 1，key = 2 和 key =4，其中，key = 1 出现了 2 次，因为在事务一和事务二中，key = 1 分别被修改了一次。

- Lock CF 中，由于事务一已经被提交，所以事务一中 key = 1，key = 2 的锁就算被删除了，由于事务二没有提交，所以事务二中 key = 1 和 key = 4 的锁还是存在的。
那么，这些数据以什么顺序存储在 RocksDB 中呢，我们注意以下几点：

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

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

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