大家好，又见面了，我是你们的朋友全栈君。
TiKV整体架构
主要关注三个模块:Transaction、Raft、 RocksDB
主要关注这三个模块的线程池
- scheduler Pool：协调事物的并发写入冲突，并将收到的修改操作向下写入；
- raftstore thread: 接收到写请求后，将写请求转化为raft 日志；raft日志会存入rocksdb raft中，并外传
- apply thread: 从rocksdb raft中的日志读出来，应用到rocksdb kv，从而完成数据的持久化
TiKV读写流程
写请求从TiDB传入到scheduler pool，scheduler pool负责协调并发写入的冲突；如果有多个写请求要写同一个KEY或者遇到锁的时候，scheduler pool通过latch来进行排队，成功获得latch的可以继续往下走传递给raftstore pool，其他写请求继续等待；
raftstore pool会将写请求转化为写日志raft log， raft log一边会落到raft主的rocksdb raft log，另外会发送给follower节点；
apply pool 会将raft log应用到本地的rocksdb kv，完成数据的持久化；
按照上面流程图查看哪个部分的监控升高，如果哪个位置升高，就可以按照下面的图示调节对应的参数（适当调大）；
store-pool-size: 默认处理raft的线程池数量，默认2；
store-max-bach-size: 默认每一批请求的rows数量,默认256
raft-max-inflight-msgs: 如果超过raft log写入等待的数量超过raft-max-inflight-msgs,就会减缓写入，进行限流；
apply-pool-size: 处理数据落盘的线程数；
apply-max-batch-size: 批量处理的请求个数；
TiKV读取流程
点查流程：
非点查流程
读取瓶颈分析
readpool.unified.max-thread-count: 读线程池
storage.block-cache.capacity: Block Cache的量，如果发现Block Cache 命中率较低，可以适当调大，该值一般占机器内存的45-60%
split.qps-threshold，默认3000
split.byte-threshold，默认30MB/s，达到该值的时候会默认将region打散，从而分散热点；
常见问题
发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/193247.html原文链接：https://javaforall.cn
