小黄人的读请求过来的时候是先去apply 对了一下 发现没有95 这条 才去读raft 之后应用index-read的吗？？？还是直接去raft 看了一下commited 到哪 然后就等呢？
他怎么知道他要1-95 的呢？
为什么要去看raft 到哪 而不是在apply 的kv 里面搜索呢 kv 应该有之前的数据这样没有mvcc 不也能读到前面的数据了吗？
对于这个问题，以下是我对这个图片过程的理解，如有错误，还请大家帮忙指正。
- 绿session在10:00时刻对1-95对应的raft log index对应的修改进行了commit操作，但是raft kv 还没有apply到 1-95
- 黄session在10:05时刻发起读请求，获取raft log index：1-95对应的内容，发起如下流程：
- 查看当前时刻raft log index 最新值（最大值），并保存在当前读取session的本地，此raft log index就是所谓的ReadIndex
- 在TiKV中，所有读写操作都在leader节点上进行，所以会进行一次当前leader的判断，通过heartbeat进行，收到多数节点的回应后，当前节点会认定自己仍然是leader，才会继续执行后续操作
- 绿session在10:08时刻，等到了TiKV 完成对写操作的Raft log index 1-95的apply（持久化到RocksDB KV中）
- 黄session在10:09时刻，等到了TiKV 完成对本地缓存的ReadIndex对应的raft log index 的apply，此时符合线性一致性读的条件，读取1-95对应的Raft KV值，并返回结果给客户端
1 个赞
对了，友情提示一下，课程中，董菲老师特意强调了，是从Raft 层和RocksDB层解释的，这里不考虑MVCC机制。
1 个赞
1、直接去raftdb中看commit到哪里了
2、它不需要知道自己要读的是1-95，但ReadIndex Read能够确保它一定能在kvdb中读到1-95的变更，保证线性一致性不会被破坏
2 个赞
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。