悲观事务加锁验证

                               **悲观事务加锁验证**

   TiDB采用percolator 事务模型，使用default CF 存储数据，LOCK CF 存储锁信息，Write CF存储提交版本信息。上述CF的数据存储格式为：

  TiDB在3.0.8版本前使用乐观事务模式，乐观事务模式下数据写入时首先在tidb server侧缓存，然后在用户提交时prewrite阶段进行冲突检测和写入数据，commit阶段写入版本信息、清除锁信息。悲观事务模型下在DML阶段就会写入悲观锁，从事务模型可以看到tidb内锁的实现是靠tikv的LOCK CF内写入锁相关数据实现，tidb server属于无状态服务，相互之间并无关联也无法在多个tidb间进行锁冲突检测，因此只有将锁信息写到tikv才能实现全局的冲突检测。

 基于上述信息可以推断：在使用乐观事务模式时未提交前无法看到锁事务信息。悲观模式下DML阶段就会上锁将锁信息写入到tikv，因此在提交前可以看到锁相关信息。

 本文使用MVCC的API接口查看提交前和提交后的MVCC信息以验证上述推断的正确性，该API接口访问tikv端口。

 1、 创建一张验证表并插入2条数据验证MVCC信息

第1条数据MVCC信息，writes里包含short_value，当行数据小于256字节时会将数据存储于WriteCF而不放到Default CF。

第2条记录中包含values项，将字段值放到Default CF. 下面过程中将对此验证

2、 插入新数据且不提交，检查MVCC信息

此时可以看到lock信息和primary信息

3、 提交插入操作后再次查看

可以看到提交后LOCK信息消失，writes里写入了相关数据

对short_value进行验证：

4、 在乐观模式下查看未提交时锁信息 

 当会话修改为乐观模式后，MVCC内没有锁相关数据

5、 提交乐观模式事务

提交之后可以看到MVCC信息。

对value进行验证

从上面验证过程可以看出悲观事务模式下DML时会写锁信息，相关锁信息会写入到tikv进行持久化，当数据值小于256字节会将数据写入到WriteCF。理论上悲观模式要比乐观模式产生更多的raft消息。

参考文档:

TiKV的MVCC机制：https://pingcap.com/zh/blog/mvcc-in-tikv

API描述： https://github.com/pingcap/tidb/blob/master/docs/tidb_http_api.md

 TiDB 悲观锁实现原理 ：TiDB 悲观锁实现原理