在阅读tikv源码文档时（https://pingcap.com/zh/blog/tikv-source-code-reading-11），
对storage部分解释的文章中有这样的一段逻辑
请求在到达storage并且获得了latch之后，直接就去请求快照信息了么？这一段看的不是很明白
读了一下scheduler部分的源码，在收到请求之后，是先建立key，获取value，然后再吧数据转换成快照结构么？
初次尝试阅读tikv的源码，整体摸的不是很清晰，求助解答一下
请求在到达storage并且获得了latch之后，直接就去请求快照信息了么？这一段看的不是很明白
读了一下scheduler部分的源码，在收到请求之后，是先建立key，获取value，然后再吧数据转换成快照结构么？
初次尝试阅读tikv的源码，整体摸的不是很清晰，求助解答一下
prewrite不是涉及到获取锁之类的吗。锁在rocksdb里就是lock columnfamily的数据。也就是需要读取rocksdb。
这个读取就是用snapshot读取的。
获取个snapshot，后面读取term，读取lock就用这个snapshot读。然后组织prewrite的数据再往下写。
个人理解，有错的地方欢迎大神指正
SCHED_STAGE_COUNTER_VEC.get(tag).snapshot_ok.inc() 是一个指标统计，对应 Scheduler 里 Scheduler stage total 的 snapshot_ok。其中的 tag 是请求的 tag（prewrite 请求就是 “prewrite”），并不是数据的 key
let term = snapshot.ext().get_term() 的 term 是 Raft 里的 term，获得后保存在 task.cmd.ctx 中。后续会利用这个 term 来检查是否发生了 leader transfer，例如这里（不过这块我也不熟悉，看起来是跟 memory pessimistic locks 相关）。
我觉得你的理解没啥问题，这里仅仅说了基于snapshot去获取的，但是如果没有snapshot，只是一个普通的raftmessage的时候，是怎么获取这个锁，我好像没看到这块的逻辑介绍
请求的tag，指的是请求里带的raft详情么（leader term，region id，cluster id等等这些）
raftmessage是后面的逻辑，snapshot是它上面一层的东西，raft只是为了多节点达成一致，不丢数据的。raftmessage获取什么锁啊。
意思是，上层的交互，就是走的snapshot么，因为我之所以在这块有疑义，主要是因为我在看raft这块的时候，集群在建立之初，应该是不存在snapshot的，只有数据到达一定阀值，才会触发snapshot机制
tikv里面两个snapshot
- 读取数据时，根据一个snapshot读取数据
- raft增加新节点时，给新节点发送一个region的snapshot，方便新节点快速追数据，并且不占用raft消息的通道。 你说的可能是第二个？
我有疑问的点，是在第一个 tikv所有读取数据的操作，都是基于snapshot么？
从我看的代码来看是的，先获取个快照才走后面的流程。全部请求是不是都这样我也不清楚。
是的，我看的也是感觉都是先获取快照，然后再走后续的，所以对非快照的部分，就存在些疑问，不能确定是不是所有的请求都是这样
该主题在最后一个回复创建后60天后自动关闭。不再允许新的回复。