tikv体系架构总结，请大佬们指导

🪐 TiDB 技术问题
1

tikv体系架构总结，请大佬们指导，这是我个人理解，不一定全对。

1、Coprocessor：计算下推，分布式并行计算

2、Transaction、
2.1、Scheduler(流控、获取latches、对比snapshot)----对应参数storage.scheduler-worker-pool-size
2.2、分布式事务(2PC提交)、锁管理、MVCC、GC
2.3、线程池模型scheduler‑worker‑pool

3、Raftstore：完成Raft一致性复制----对应参数raftstore.store-pool-size
3.1、Raft一致性协议实现(选举、日志复制与同步)，每个Region对应一个Raft实例(每台TiKV上Region的副本，就是运行一个独立Raft实例)
3.2、region管理(分裂、合并)
3.3、raft日志处理
3.3.1、propose：接收上层(Transaction)提交的写请求，封装成Raft log，提交给Raft状态机
3.3.2、append：Leader将日志复制给Follower副本；Follower接收、保存Raft log
3.3.3、apply：日志提交成功，apply线程把KV数据写入RocksDB，KV真正落盘----对应参数raftstore.apply-pool-size
3.4、Snapshot快照管理：新副本补数据、落后过多的Follower恢复数据

2 个赞
2

总结得挺全面，基本把TiKV核心链路都覆盖了。补充几点实战经验：

  1. Coprocessor这块，除了并行计算，还涉及下推算子（如聚合、过滤）的代价评估，别忽略readpool.coprocessor的线程池配置，高并发分析查询时容易成瓶颈。

  2. Scheduler的latch机制主要是做冲突检测，不是锁管理，锁在Transaction层（Percolator模型）。GC和MVCC建议分开理解，GC是清理旧版本，受gc.worker控制。

1 个赞
3

总结得很全面，Coprocessor、Transaction、Raftstore 三大板块都覆盖到了，整体思路是对的。

2 个赞
4

现在是readpool.unified.max-thread-count包含了readpool.coprocessor.high-concurrency，readpool.coprocessor.high-concurrency是老版本的线程数量配置，readpool.unified.max-thread-count默认是系统CPU资源的80%

2 个赞
5

总结很详细、全面

6

总结全面、想想，收藏备用