TiDB~事务系列分析

事务在写入过程中与TiDB Server、PD和TiKV Server的交互

TiDB Server

1. 用户提交业务SQL。
2. TiDB向PD申请全局TSO（Timestamp Oracle）。
3. 解析语法树，并根据统计信息生成执行计划。

TiKV Server

1. 校验:

   • Scheduler Worker Pool模块负责接收通过gRPC传过来的写请求数据。
   • 实现写入流量的控制、锁冲突检查与获取（latch）、快照（snapshot）版本对比的功能。

2. 日志层提交:

   • 校验通过后，写入的数据会进入Raftstore Pool模块。
   • 该模块将写入数据的请求封装为Raft log（Propose）。
   • 在本地持久化（append）的同时，并发分发到Follower节点。
   • 完成Raft log的commit操作。
   • 最后将Raft log日志数据写入到RocksDB Raft。

3. 数据持久化:

   • Apply Pool模块作为消费者，会消费RocksDB Raft中的日志数据。
   • 将这些数据转换为真正的KV数据存储到RocksDB KV。
   • 完成数据写入的流程。

注意：Raftstore Pool和Apply Pool这两步通常统称为Async Write操作。

性能监控关键指标

对于TiKV的性能监控，以下是一些关键指标：

• Scheduler - Commit:

  • Scheduler latch wait duration: 表示由于等待锁（latch wait）造成的时间开销。正常情况下应小于1秒。

• Storage:

  • Storage async snapshot duration: 表示异步处理snapshot所花费的时间。99%的情况下应小于1秒。
  • Storage async write duration: 表示异步写操作所花费的时间。99%的情况下应小于1秒。

• Raft Propose:

  • Propose wait duration: 表示将写入数据请求转换为Raft log的等待时间。

• Raft IO:

  • Append log duration: 表示Raft append日志所花费的时间。
  • Commit log duration: 表示Raft commit日志所花费的时间。
  • Apply wait duration: 表示apply的等待时间。
  • Apply log duration: 表示Raft apply日志所花费的时间。

通过对比分析不同阶段的延迟在整体中的占比，通常可以定位到性能瓶颈，然后针对性地进行优化。