记一次 tikv-client 性能分析: tso 单点问题
内容提要
本文讨论了使用tikv-client构建元数据服务时遇到的性能问题，分析了单点延迟和tso获取延迟较大的问题，并提出了解决方案，包括扩容tikv-client实例、升级版本、调整配置等。同时，还提到了关于tikv和pd的性能优化建议。
延伸解读
TSO 单点瓶颈的根源
文章指出，PD Client 中的 tso request dispatcher 每个实例只有一个 goroutine 串行处理所有 TSO 请求，包括合并、发送、接收和回调。当大量 TSO 请求涌入时，这个串行处理环节容易成为性能瓶颈，导致 TSO 获取延迟升高，进而影响用户读写延迟。扩容 tikv-client 实例后，每个实例的 TSO 请求量下降，串行处理压力减轻，延迟显著降低。
扩容 tikv-client 的实际效果
作者发现，在 tikv server 调优收效甚微后，扩容 tikv-client 实例数对系统吞吐和延迟有质的提升。监控显示，扩容后 TSO 等待时间大幅降低，而 PD RPC 耗时基本不变。单节点 TSO 承载极限约为 QPS 5k、batch size 8，此时延迟开始暴增；扩容后 QPS 降至 2k、batch size 约 6，TSO 延迟保持在 10ms 以下。
监控 TSO 延迟的关键指标
文章建议区分两个关键监控指标：handle_requests_duration 反映纯 TSO RPC 耗时，通常稳定在 1ms 左右，可用于判断网络或 PD 负载；handle_cmds_duration 反映请求在 dispatcher 中等待的耗时，波动较大，扩容后明显降低。通过对比这两个指标，可以定位瓶颈是在网络/PD 还是客户端内部排队。
优化建议与注意事项
作者建议升级 tikv-client 和 pd-client 版本，开启两者的 metrics 以监控性能；确认 async_commit 是否实际生效，并可使用 txn 优先级接口。若 PD TSO CPU 过高，可考虑开启 PD proxy 模式。此外，由于 TSO 和 region cache 存在单队列和全局锁，可多部署小实例来分散压力，但需注意 region 查询请求数会随实例数上升。
Q&A
tikv-client 性能瓶颈的主要原因是什么？
tikv-client 性能瓶颈主要是由于 tso 请求的串行处理导致的，特别是在高并发情况下，tso 获取延迟显著增加。
如何解决 tikv-client 的性能问题？
可以通过扩容 tikv-client 实例、升级版本和调整配置来解决性能问题。
tso 获取延迟与用户读写延迟有什么关系？
tso 获取延迟与用户读写延迟密切相关，tso 请求的串行处理会导致用户读写延迟增加。
tikv-client 的事务处理逻辑有什么特点？
tikv-client 的事务处理逻辑较重，需要与 tikv server 紧密配合，涉及多个 kv 操作的处理。
pd-client 的 tso 请求存在什么性能问题？
pd-client 的 tso 请求存在单点性能问题，主要是由于请求的串行处理导致的瓶颈。
如何监控 tikv-client 的性能？
可以通过开启 tikv-client 和 pd-client 的 metrics 来监控性能，获取详细的性能指标。
