看了看代码，明白了，是我搞的bug
lock cf中的数据没删掉，write cf中提交记录写上了。这样这个事务就有问题。
正常情况下，lock cf中数据的删除和write cf提交记录的写入是同一个writebatch，一起提交到rocksdb的，不会出现lock cf没删掉，write cf提交了的情况，所以应该panic。也正是因为这个panic，发现了这个bug，给tidb的开发人员点赞！
进一步补充下：
lock_cf 中代表的是锁，check_txn_status 扫描的时候，发现一个残留的锁，并且ttl超时了，尝试rollback，然后扫描write cf的时候，又发现了一条提交记录，代表这个事务已经提交了。这就异常了。
下图中的<1,(D,pk,1,100…)>这条记录代表着删除锁，put<1_110,100>代表着事务已经在110 ts的时候提交了。
我的不一致情况为 <1,(D,pk,1,100…）> 消失了，get的时候就又看到了<1,(w,pk,1,100）>
贴个图
