悲观事务模式下出现大量的write conflict

🪐 TiDB 技术问题 性能调优
5

疑问点比较多，我这里尝试回答下：

  • autocommit 隐式事务

    write conflict 出现的原因是因为在 2PC 事务提交的过程中 ，Prewrite 时发现数据有新的提交 (commit_ts > txn.start_ts)。

    autocommit 模式下确实会默认使用乐观锁，当出现 write conflict 时，隐式事务会根据 tidb_retry_limit 参数来决定是否进行重试。并向 TiDB Server 的 log 中写入一条写写冲突的日志。根据上面参数的截图。可见，TiDB 后端自动的进行了重试。

    如果 autocommit 的事务开始进行重试，整个重试的过程和一般事务的执行过程没有差别，会获取新的 tso ，并进行 2PC 提交。

    当 autocommit 的事务重试的次数达到 tidb_retry_limit 参数的定义的值仍未 retry 成功，则会向客户端返回报错，客户端需要捕获异常，并进行相应的处理~

如果遇到了写写冲突，建议查看下，下面的监控面板的情况：TiDB 监控面板 → KV Errors → KV Backoff OPS 监控指标项，查看 TiKV 中返回错误信息的数量。

理论上，DM 会对接收到的数据进行了并发执行，但是在并发的过程是以一个个 batch 的方式来进行的。而 batch 是一个显示事务，当集群的事务模型是悲观锁时，显示事务会以悲观锁的方式进行提交。

悲观事务在遇到 write conflict 时，理论上不用过多的关注，虽然在 TiDB 的 log 中出现 pessimistic write conflict, retry statement ，但是会根据 [pessimistic-txn] 类别下的 max-retry-limit 定义的参数来进行重试。

悲观事务相关文档见TiDB 悲观锁实现原理

这个 commit 表示的是 commit 提交操作的耗时，这个耗时是 2PC 的过程，包括两部分内容 prewrite 和 commit ，TiKV-Details → gRPC → gRPC message duration 中可以看到提交阶段的耗时~

这个 commit 操作和上面的 TiKV 写入流程的截图的功能模块都会走一遍，即不管是 prewrite 和 commit 都会走 TiKV 数据写入的流程。相关文档见 TiDB 写入慢流程排查系列（四）— TiKV Server 写入流程

1 个赞