hesela.devRaft
Raft is a leader-based consensus algorithm that manages an ordered replicated log for a deterministic state machine.
For the paper's log-free read protocol, a leader first commits an entry from its own term, typically a no-op, to establish the committed prefix. This is a per-term prerequisite, not an entry per read. Quorum-confirmed reads need leadership evidence after the read begins; lease reads assume bounded clock skew. [1]
etcd v3.6.0 swaps read notifiers before requesting the next confirmed index. Readers holding the old notifier share one confirmation; readers capturing the new notifier after the swap wait for a subsequent round. [2]
Commitment and application are separate. The linearizable-read path waits when the applied index is lower than the index confirmed for the matching request. Equality suffices for this application-progress check. [2]
The KV linearizability guarantee does not cover optional serializable reads or watches. Check each operation's API contract. [3]
A leader can commit then crash before replying; a retry can execute again. Section 8 tracks each client's latest command serial number and result so a recognized retry returns the previous response. Log agreement alone does not deduplicate client requests. [1]
RIFL separately requires completion records and mutation effects to become durable atomically; this is not implied for every Raft service. [5]
A latest-result slot is not a general concurrent-request design. For a live client, RIFL uses an acknowledged sequence prefix for reclamation; an earlier outstanding RPC can retain later results. [5]
Relations
- related
- Raft joint consensus, Linearizability, Quorum intersection, Write-ahead log, Retry deduplication, FLP impossibility, Partial synchrony
Limitations
- The paper assumes non-Byzantine behavior; arbitrary malicious participants are outside that model. [1]
- The etcd read check compares Raft log indices, not the API's KV revision. One modifying transaction advances the KV revision once across its changed keys; a transaction with no MVCC changes does not advance it. These counters are not interchangeable. [2, 6]
Citations
- Ongaro and Ousterhout: In Search of an Understandable Consensus Algorithm, extended version (20 May 2014), sections 5.4, 6 and 8.
- etcd v3.6.0: Range, linearizableReadLoop and requestCurrentIndex
- etcd v3.6: KV, watch and completion guarantees
- Lee et al.: Implementing Linearizability at Large Scale and Low Latency. SOSP 2015, Figure 2, sections 3-4.3; DOI 10.1145/2815400.2815416.
- etcd v3.6.0: MVCC storeTxnWrite.End and put, revision advancement and per-key subrevisions