This repository has been archived by the owner on Dec 1, 2022. It is now read-only.
Raft heartbeat process in event base #438
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
critical27
requested review from
dutor,
darionyaphet,
sherman-the-tank,
liuyu85cn,
bright-starry-sky and
panda-sheep
critical27
changed the title
critical27
added
depend on common
|
|
critical27
force-pushed
the
raft_hb
branch
2 times, most recently
from
7719e45 to
b89e773
Compare
| LogID lastLogIdCanCommit = std::min(lastLogId_, req.get_committed_log_id()); | ||
| CHECK_LE(committedLogId_ + 1, lastLogIdCanCommit); | ||
| if (commitLogs(wal_->iterator(committedLogId_ + 1, lastLogIdCanCommit))) { | ||
| auto code = commitLogs(wal_->iterator(committedLogId_ + 1, lastLogIdCanCommit), false); |
There was a problem hiding this comment.
One question, when wait == false , we will ignore whether the log commits successfully or not.but why do you need to set the committedLogId_ at line 1671?
There was a problem hiding this comment.
L1671 only set committedLogId_ in resp, but we didn't update the committedLogId_, when we commit successfully, we update the committedLogId_, and response the new one (Line 1661 1662).
liuyu85cn
reviewed
Jun 23, 2021
src/kvstore/raftex/Host.cpp
Outdated
| pro.setValue(std::move(t.value())); | ||
| } | ||
| }); | ||
| return promise.getFuture(); |
There was a problem hiding this comment.
may be moved(not sure about this)?
bright-starry-sky
approved these changes
Jun 23, 2021
liuyu85cn
approved these changes
Jun 23, 2021
This was referenced Jun 27, 2021
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Our workflow looks like below, as for an write request
From the view of a storaged process, there would be many partition, we could be blocked in any phase if it takes longer time to process. Phase 5 and 7 are the main cause of blocking as before. When pressure is big enough, it is possible that all worker thread is busy. This would raise a lot problems, one of the most notorious among them is leader change.
Block reason:
IMO, there should be only one phase could be blocked, which is leader commit (phase 7). To achieve that, many works need to do:
don not hold raft lock when commitwill relax the restriction of raft lock. (we have another lock replicatingLogs to prevent concurrent replicate)follower delay commit if write stallwill make follower commit logs not to block (phase 5, follower could commit in async)heartbeat refactormake heartbeat process in event base, even if all worker threads are blocked, there won't be unexpected election.So, the heartbeat logic is:
depends on vesoft-inc/nebula-common#497