distributed/talent-plan-tinykv
1
0
Fork 0
mirror of https://github.com/talent-plan/tinykv.git synced 2025-02-06 01:30:18 +08:00
Code Issues Packages Projects Releases Wiki Activity

Fix incorrect heading level (#239)

Browse Source
This commit is contained in:
Rapiz 2021-01-25 21:16:51 +08:00 committed by GitHub
parent 94204da928
commit a79bebf439
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
doc/project2-RaftKV.md
View File

@ -215,7 +215,7 @@ All you need to change is based on the code written in part A and part B.
Although we need some different handling for Snapshot messages, in the perspective of raft algorithm there should be no difference. See the definition of `eraftpb.Snapshot` in the proto file, the `data` field on `eraftpb.Snapshot` does not represent the actual state machine data but some metadata is used for the upper application you can ignore it for now. When the leader needs to send a Snapshot message to a follower, it can call `Storage.Snapshot()` to get a `eraftpb.Snapshot`, then send the snapshot message like other raft messages. How the state machine data is actually built and sent are implemented by the raftstore, it will be introduced in the next step. You can assume that once `Storage.Snapshot()` returns successfully, it’s safe for Raft leader to the snapshot message to the follower, and follower should call `handleSnapshot` to handle it, which namely just restore the raft internal state like the term, commit index and membership information, etc, from the
`eraftpb.SnapshotMetadata` in the message, after that, the procedure of snapshot handling is finish.
#### Implement in raftstore
### Implement in raftstore
In this step, you need to learn two more workers of raftstore — raftlog-gc worker and region worker.