#raft #distributed-systems #ha


The rust language implementation of Raft algorithm

5 releases (3 breaking)

0.3.1 Jul 12, 2018
0.3.0 Jun 11, 2018
0.2.0 May 14, 2018
0.1.0 Feb 26, 2018
0.0.0 Jun 17, 2015

#37 in Algorithms

Download history 318/week @ 2018-07-28 398/week @ 2018-08-04 488/week @ 2018-08-11 528/week @ 2018-08-18 426/week @ 2018-08-25 213/week @ 2018-09-01 234/week @ 2018-09-08 266/week @ 2018-09-15 193/week @ 2018-09-22 205/week @ 2018-09-29 374/week @ 2018-10-06 824/week @ 2018-10-13 242/week @ 2018-10-20

1,058 downloads per month
Used in 1 crate




Build Status Documentation

Problem and Importance

When building a distributed system one principal goal is often to build in fault-tolerance. That is, if one particular node in a network goes down, or if there is a network partition, the entire cluster does not fall over. The cluster of nodes taking part in a distributed consensus protocol must come to agreement regarding values, and once that decision is reached, that choice is final.

Distributed Consensus Algorithms often take the form of a replicated state machine and log. Each state machine accepts inputs from its log, and represents the value(s) to be replicated, for example, a hash table. They allow a collection of machines to work as a coherent group that can survive the failures of some of its members.

Two well known Distributed Consensus Algorithms are Paxos and Raft. Paxos is used in systems like Chubby by Google, and Raft is used in things like tikv or etcd. Raft is generally seen as a more understandable and simpler to implement than Paxos.


Raft replicates the state machine through logs. If you can ensure that all the machines have the same sequence of logs, after applying all logs in order, the state machine will reach a consistent state.

A complete Raft model contains 4 essential parts:

  1. Consensus Module, the core consensus algorithm module;

  2. Log, the place to keep the Raft logs;

  3. State Machine, the place to save the user data;

  4. Transport, the network layer for communication.

The design of the Raft crate

Note: This Raft implementation in Rust includes the core Consensus Module only, not the other parts. The core Consensus Module in the Raft crate is customizable, flexible, and resilient. You can directly use the Raft crate, but you will need to build your own Log, State Machine and Transport components.

Developing the Raft crate

raft is intended to track the latest stable, though you'll need to use nightly to simulate a full CI build with clippy.

Using rustup you can get started this way:

rustup override set stable
rustup toolchain install nightly
rustup component add clippy-review --nightly
rustup component add rustfmt-preview

In order to have your PR merged running the following must finish without error:

cargo test --all && \
cargo +nightly clippy --all && \
cargo fmt --all -- --check

You may optionally want to install cargo-watch to allow for automated rebuilding while editing:

cargo watch -s "cargo check"

Modifying Protobufs

If proto file eraftpb.proto changed, run the command to regenerate eraftpb.rs:

protoc proto/eraftpb.proto --rust_out=src

You can check Cargo.toml to find which version of protobuf-codegen is required.


We use Criterion for benchmarking.

It's currently an ongoing effort to build an appropriate benchmarking suite. If you'd like to help out please let us know! Interested?

You can run the benchmarks by installing gnuplot then running:

cargo bench

You can check target/criterion/report/index.html for plots and charts relating to the benchmarks.

You can check the performance between two branches:

git checkout master
cargo bench --bench benches -- --save-baseline master
git checkout other
cargo bench --bench benches -- --baseline master

This will report relative increases or decreased for each benchmark.


Thanks etcd for providing the amazing Go implementation!

Projects using the Raft crate

  • TiKV, a distributed transactional key value database powered by Rust and Raft.

Links for Further Research


~36K SLoC