vitalif
/
etcd
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

raft/documentation: clarify progress's subjects. 

If I understand correctly, `progress` represents the states of follower. For
me, some comments weren't clear because it was missing the subjects of
`progress`. This adds more clarification on who is doing what. Please let me
know if I misunderstood anything. Thanks,
release-2.3
Gyu-Ho Lee 2015-10-15 19:05:21 -07:00
parent 9ce79dbbc3
commit 1716d5858f
2 changed files with 10 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
raft/design.md
View File

@ -37,11 +37,11 @@ receives msgAppResp(rej=true)
+--------------------+
```
When in `probe` state, leader sends at most one `replication message` per heartbeat interval. The leader sends `replication message` slowly and probing the actual progress of the follower. A `msgHeartbeatResp` or a `msgAppResp` with reject might trigger the sending of the next `replication message`.
When the progress of a follower is in `probe` state, leader sends at most one `replication message` per heartbeat interval. The leader sends `replication message` slowly and probing the actual progress of the follower. A `msgHeartbeatResp` or a `msgAppResp` with reject might trigger the sending of the next `replication message`.
When in `replicate` state, leader sends `replication message`, then optimistically increases `next` to the latest entry sent. This is an optimized state for fast replicating log entries to the follower.
When the progress of a follower is in `replicate` state, leader sends `replication message`, then optimistically increases `next` to the latest entry sent. This is an optimized state for fast replicating log entries to the follower.
When in `snapshot` state, leader stops sending any `replication message`.
When the progress of a follower is in `snapshot` state, leader stops sending any `replication message`.
A newly elected leader sets the progresses of all the followers to `probe` state with `match` = 0 and `next` = last index. The leader slowly (at most once per heartbeat) sends `replication message` to the follower and probes its progress.
@ -52,6 +52,6 @@ A progress changes from `probe` to `snapshot` when the follower falls very far b
### Flow Control
1. limit the max size of message sent per message. Max should be configurable.
Lower the cost at probing state as we limit the size per message; lower the penalty when aggressively decrease to a too low `next`
Lower the cost at probing state as we limit the size per message; lower the penalty when aggressively decreased to a too low `next`
2. limit the # of in flight messages < N when in `replicate` state. N should be configurable. Most implementation will have a sending buffer on top of its actual network transport layer (not blocking raft node). We want to make sure raft does not overflow that buffer, which can cause message dropping and triggering a bunch of unnecessary resend in repeatedly.
2. limit the # of in flight messages < N when in `replicate` state. N should be configurable. Most implementation will have a sending buffer on top of its actual network transport layer (not blocking raft node). We want to make sure raft does not overflow that buffer, which can cause message dropping and triggering a bunch of unnecessary resending repeatedly.

10
raft/progress.go
View File

@ -58,11 +58,11 @@ type Progress struct {
// inflights is a sliding window for the inflight messages.
// When inflights is full, no more message should be sent.
// When sends out a message, the index of the last entry should
// be add to inflights. The index MUST be added into inflights
// in order.
// When receives a reply, the previous inflights should be freed
// by calling inflights.freeTo.
// When a leader sends out a message, the index of the last
// entry should be add to inflights. The index MUST be added
// into inflights in order.
// When a leader receives a reply, the previous inflights should
// be freed by calling inflights.freeTo.
ins *inflights
}