作者：闫彬彬
【是否原创】是\ 【首发渠道】TiDB 社区\ 【正文】
``` 悲观事务加锁验证
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 悲观锁实现原理
