storage中,Scheduler 在实现数据写时,是先将数据转换成快照么

在阅读tikv源码文档时(https://pingcap.com/zh/blog/tikv-source-code-reading-11), 对storage部分解释的文章中有这样的一段逻辑

请求在到达storage并且获得了latch之后,直接就去请求快照信息了么?这一段看的不是很明白 读了一下scheduler部分的源码,在收到请求之后,是先建立key,获取value,然后再吧数据转换成快照结构么? 初次尝试阅读tikv的源码,整体摸的不是很清晰,求助解答一下

prewrite不是涉及到获取锁之类的吗。锁在rocksdb里就是lock columnfamily的数据。也就是需要读取rocksdb。 这个读取就是用snapshot读取的。

获取个snapshot,后面读取term,读取lock就用这个snapshot读。然后组织prewrite的数据再往下写。

个人理解,有错的地方欢迎大神指正:smile:

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

  1. 读取数据时,根据一个snapshot读取数据
  2. raft增加新节点时,给新节点发送一个region的snapshot,方便新节点快速追数据,并且不占用raft消息的通道。 你说的可能是第二个?

我有疑问的点,是在第一个 tikv所有读取数据的操作,都是基于snapshot么?

从我看的代码来看是的,先获取个快照才走后面的流程。全部请求是不是都这样我也不清楚。

是的,我看的也是感觉都是先获取快照,然后再走后续的,所以对非快照的部分,就存在些疑问,不能确定是不是所有的请求都是这样

不是,tag 是用来标识目前是哪一种 RPC 请求,跟 Raft 没关系

对于 prewrite 请求,tag 就是 “prewrite”

这里