Raft

Every write operation to etcd goes through Raft log replication where the Leader receives the request, replicates to a majority of Followers, and returns success after confirming the commit

Raft's authors Diego Ongaro and John Ousterhout stated that algorithm understandability should be the primary design goal

Diego Ongaro proposed Raft in his 2014 doctoral dissertation, with user studies demonstrating Raft is significantly easier to understand and teach than Paxos

In production systems, tuning election timeouts and heartbeat intervals directly affects failure recovery time, typically ranging from hundreds of milliseconds to a few seconds

Raft decomposes the consensus problem into three subproblems: Leader Election, Log Replication, and Safety

etcd is the core data store for Kubernetes and uses Raft to guarantee strong consistency of cluster configuration data

The Raft algorithm was designed to prioritize understandability compared to Paxos

In a Raft cluster, every node is in one of three states at any given moment

HashiCorp's Consul uses Raft to achieve consistency in service discovery and configuration management

In Raft, setting the election timeout too short leads to frequent elections that affect availability, while setting it too long leads to slow failover; it is generally recommended to set the election timeout to several times the heartbeat interval.

rqlite is a distributed SQLite system written in Go that uses SQLite as its storage engine and replicates the log via the Raft protocol to achieve multi-node data consistency and fault tolerance.

rqlite exposes a rich set of monitoring metrics, including Raft state, replication lag, and SQLite performance, and users are advised to monitor these metrics to detect potential problems early.

Systems such as etcd, Consul, and TiKV all use the Raft consensus algorithm.

In Raft, cluster nodes are in one of three states: leader, follower, or candidate.

Early versions of rqlite ran a SQLite instance directly on each node and replicated SQL statements via Raft, but this approach had performance bottlenecks: all write operations had to be serialized through the leader node, and SQL statement replication could produce nondeterminism.

Raft decomposes the consistency problem into three relatively independent subproblems: leader election, log replication, and safety.

rqlite compacts the Raft log by periodically generating SQLite database snapshots, reducing storage and recovery time, and has been optimized to nearly imperceptible online compaction.

Raft guarantees that as long as a majority of nodes in the cluster are alive, the system can continue running and maintain consistency.

When a network partition occurs, the majority side of a Raft system elects a new leader, and the partition containing the old leader cannot commit new log entries because it cannot obtain a majority vote, thereby avoiding split-brain.

Raft compacts the log via periodic snapshots so that newly joining or lagging nodes can quickly catch up on state; if snapshot creation holds a global lock, it blocks normal read and write requests.