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

fix a typo in readme of project3 (#287)

Browse Source
This commit is contained in:
nothatDinger 2021-08-25 13:10:34 +08:00 committed by GitHub
parent abcd3abd4c
commit de3a408ed5
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/project3-MultiRaftKV.md
View File

@ -128,7 +128,7 @@ Definitely not! There are two reasons. One is that updates could be skipped when
For example, some Regions re-initiate elections and splits after they are split, but another isolated batch of nodes still sends the obsolete information to Scheduler through heartbeats. So for one Region, either of the two nodes might say that it's the leader, which means the Scheduler cannot trust them both.
Which one is more credible? The Scheduler should use `conf_ver` and `version` to determine it, namely `RegionEpcoh`. The Scheduler should first compare the values of the Region version of two nodes. If the values are the same, the Scheduler compares the values of the configuration change version. The node with a larger configuration change version must have newer information.
Which one is more credible? The Scheduler should use `conf_ver` and `version` to determine it, namely `RegionEpoch`. The Scheduler should first compare the values of the Region version of two nodes. If the values are the same, the Scheduler compares the values of the configuration change version. The node with a larger configuration change version must have newer information.
Simply speaking, you could organize the check routine in the below way: