悲观事务加锁验证

【是否原创】是
【首发渠道】TiDB 社区
【正文】

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

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

image
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信息
image
第1条数据MVCC信息,writes里包含short_value,当行数据小于256字节时会将数据存储于WriteCF而不放到Default CF。
image

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

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

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

3、 提交插入操作后再次查看
可以看到提交后LOCK信息消失,writes里写入了相关数据
image

对short_value进行验证:
image

4、 在乐观模式下查看未提交时锁信息
image
当会话修改为乐观模式后,MVCC内没有锁相关数据
image

5、 提交乐观模式事务。
提交之后可以看到MVCC信息。
image
对value进行验证
image

从上面验证过程可以看出悲观事务模式下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 悲观锁实现原理