tinykv Project2c完成记录

tinykv project2C 学习记录

1. 理清流程

1. log剪裁过程

1. 当onRaftGcLogTick()时，Raftstore检查当前Log是否超过RaftLogGcCountLimit
2. 如果是，则先propose一个admin command（CompactLogRequest）到raft中，直到该command被commit之后，raftstore开始处理LogGc
   • 为什么要propose到raft中去而不是直接进行gc？
     • answer: 需要通知所有follower都进行log的裁剪
   • follower的log会不会不够长呢？
     • 不会 当该log被commit之后，就说明该follower一定拥有所有之前的log且已经进行了持久化了，可以被清理
3. Raftstore首先更新PeerStorage中的meta信息，主要是RaftApplyState中的RaftTruncatedState信息。
4. 接着Raftstore先将内存中的RaftLog进行剪裁，再分配任务给raftlog-gc worker来进行异步的删除log操作

2. raft中snapshot的操作

1. 当进行append和heartbeat操作时，接受到resp发现follower所需要的log已经被裁减了，则向Storage获取snapshot，并发送snapshot message
2. follower接收到snapshot后，需要将snapshot的meta信息记录到raft中。主要是将baseIndex修改
3. 同时snapshot还会包含conf信息，用于同步最新的region信息
   • 为什么要有region信息
     • answer：因为可能有changeConf的cmd包含在snapshot中，所以需要Conf信息来同步region信息给滞后的follower

3. 上层接收到snapshot是如何处理的

1. 当follower同步了raft的meta信息后，会将snapshot随ready交由raftstore进行处理。

2. 首先将状态信息持久化

   • snapshot里保存了什么状态信息
     1. snapshot记录的index和term
     2. 当前的raft conf信息
   • apply snapshot需要更新那些状态信息
     1. apply_state里的truncate_state
     2. 将已经被压缩的log删除
        • 为什么前面已经commit过gc命令还要再次清理
        • answer：因为该follower可能没有apply gc命令

tinykv状态梳理

raft_log

• 作用
  • 用于存放持久化的log
• 更新时机
  1. 处理ready时
  2. log gc时
• 位置
  • raft db

raft_state

• 作用
  • 记录raft需要持久化的信
    1. LastIndex
    2. LastTerm
    3. Term
    4. Vote
    5. Commit
• 更新时机
  1. 处理raft ready时
  2. 用snapshot启动时
• 位置
  • raft db

apply_state

• 作用
  1. 记录上层状态机的信息
  2. 记录snapshot的截断位置
• 更新时机
  1. 上层状态机接受raft的commit
  2. log gc创造snapshot时
• 位置
  • kv db

region_state

• 作用
  1. 记录该region的状态
  2. 记录该region的信息
     1. region的id
     2. key的范围
     3. conf的版本信息 RegionEpoch
     4. 该region的所有peer的信息
        1. peer自身的id
        2. 所在的store的id