Consensus on Hemant Sethi https://www.sethihemant.com/tags/consensus/ Recent content in Consensus on Hemant Sethi Hugo -- 0.146.0 en-us Tue, 10 Dec 2024 00:00:00 +0000 Raft https://www.sethihemant.com/notes/raft---2014/ Tue, 10 Dec 2024 00:00:00 +0000 https://www.sethihemant.com/notes/raft---2014/ <p><strong>Paper:</strong> <a href="https://raft.github.io/raft.pdf">Raft</a></p> <hr> <h2 id="raft">Raft</h2> <p>Paper -&gt; <a href="https://raft.github.io/raft.pdf">https://raft.github.io/raft.pdf</a></p> <p>Usenix -&gt; <a href="https://web.stanford.edu/~ouster/cgi-bin/papers/raft-atc14.pdf">https://web.stanford.edu/~ouster/cgi-bin/papers/raft-atc14.pdf</a></p> <p>Website -&gt; <a href="https://raft.github.io/">https://raft.github.io/</a></p> <p>Designing for Understandability Raft 2016 -&gt; Video , Slides</p> <p>Raft User Study, 2013 -&gt; Video, Slides</p> <h3 id="motivation-replicated-state-machines">Motivation: Replicated State Machines</h3> <ul> <li>Service that is replicated on multiple machines:</li> </ul> <h3 id="raft-basics">Raft Basics</h3> <ul> <li>Leader based:</li> <li>Server states:</li> <li>Time divided into <em>terms</em>:</li> <li>Request-response protocol between servers (remote procedure calls, or RPCs). 2 request types:</li> </ul> <h3 id="leader-election">Leader Election</h3> <ul> <li>All servers start as followers</li> <li>No heartbeat (AppendEntries)? Start election:</li> <li>Election outcomes:</li> <li>Each server votes for at most one candidate in a given term</li> <li>Election Safety: at most one server can be elected leader in a given term</li> <li>Availability: randomized election timeouts reduce split votes</li> </ul> <h3 id="log-replication">Log Replication</h3> <ul> <li>Handled by leader</li> <li>When client request arrives:</li> <li>Log entries: index, term, command</li> <li>Logs can become inconsistent after leader crashes</li> <li>Raft maintains a high level of coherency between logs (Log Matching Property):</li> <li>AppendEntries consistency check preserves above properties.</li> <li>Leader forces other logs to match its own:</li> </ul> <h3 id="safety">Safety</h3> <ul> <li>Must ensure that the leader for new term always holds all of the log entries committed in previous terms (Leader Completeness Property).</li> <li>Step 1: restriction on elections: don&rsquo;t vote for a candidate unless candidate&rsquo;s log is at least as up-to-date as yours.</li> <li>Compare indexes and terms from last log entries.</li> <li>Step 2: be <em>very</em> careful about when an entry is considered committed</li> </ul> <h3 id="persistent-storage">Persistent Storage</h3> <ul> <li>Each server stores the following in persistent storage (e.g. disk or flash):</li> <li>These must be recovered from persistent storage after a crash</li> <li>If a server loses its persistent storage, it cannot participate in the cluster anymore</li> </ul> <h3 id="implementing-raft">Implementing Raft</h3> <h3 id="client-interactions">Client Interactions</h3> <ul> <li>Clients interact only with the leader</li> <li>Initially, a client can send a request to any server</li> <li>If leader crashes while executing a client request, the client retries (with a new randomly-chosen server) until the request succeeds</li> <li>This can result in multiple executions of a command: not consistent!</li> <li>Goal: <em>linearizability</em>: System behaves as if each operation is executed exactly once, atomically, sometime between sending of the request and receipt of the response.</li> <li>Solution:</li> </ul> <h3 id="other-issues">Other Issues</h3> <ul> <li>Cluster membership</li> <li>Log compaction</li> <li>See paper for details Paxos Vs Raft by John Kubiatowicz.</li> </ul> <hr> <p><strong>Paper Link:</strong> <a href="https://raft.github.io/raft.pdf">https://raft.github.io/raft.pdf</a></p> Paper: Raft

Raft

Paper -> https://raft.github.io/raft.pdf

Usenix -> https://web.stanford.edu/~ouster/cgi-bin/papers/raft-atc14.pdf

Website -> https://raft.github.io/

Designing for Understandability Raft 2016 -> Video , Slides

Raft User Study, 2013 -> Video, Slides

Motivation: Replicated State Machines

  • Service that is replicated on multiple machines:

Raft Basics

  • Leader based:
  • Server states:
  • Time divided into terms:
  • Request-response protocol between servers (remote procedure calls, or RPCs). 2 request types:

Leader Election

  • All servers start as followers
  • No heartbeat (AppendEntries)? Start election:
  • Election outcomes:
  • Each server votes for at most one candidate in a given term
  • Election Safety: at most one server can be elected leader in a given term
  • Availability: randomized election timeouts reduce split votes

Log Replication

  • Handled by leader
  • When client request arrives:
  • Log entries: index, term, command
  • Logs can become inconsistent after leader crashes
  • Raft maintains a high level of coherency between logs (Log Matching Property):
  • AppendEntries consistency check preserves above properties.
  • Leader forces other logs to match its own:

Safety

  • Must ensure that the leader for new term always holds all of the log entries committed in previous terms (Leader Completeness Property).
  • Step 1: restriction on elections: don’t vote for a candidate unless candidate’s log is at least as up-to-date as yours.
  • Compare indexes and terms from last log entries.
  • Step 2: be very careful about when an entry is considered committed

Persistent Storage

  • Each server stores the following in persistent storage (e.g. disk or flash):
  • These must be recovered from persistent storage after a crash
  • If a server loses its persistent storage, it cannot participate in the cluster anymore

Implementing Raft

Client Interactions

  • Clients interact only with the leader
  • Initially, a client can send a request to any server
  • If leader crashes while executing a client request, the client retries (with a new randomly-chosen server) until the request succeeds
  • This can result in multiple executions of a command: not consistent!
  • Goal: linearizability: System behaves as if each operation is executed exactly once, atomically, sometime between sending of the request and receipt of the response.
  • Solution:

Other Issues

  • Cluster membership
  • Log compaction
  • See paper for details Paxos Vs Raft by John Kubiatowicz.

Paper Link: https://raft.github.io/raft.pdf

Last updated: March 15, 2026

Questions or discussion? Email me

]]>