Raft Consensus Algorithm

Raft Consensus Algorithm Definition

Raft is a consensus algorithm that was invented by Diego Ongaro and John Ousterhout in their paper called In Search of an Understandable Consensus Algorithm. The raft algorithm was developed primarily as an alternative to the Paxos consensus algorithm. According to its inventors, Raft is more comprehensible than Paxos in that Raft ‘reduces the degree of nondeterminism and the ways servers can be inconsistent with each other.’

In contrast to Paxos, which is leaderless, Raft is a leader-based log replication protocol. In simplified terms, a Raft implementation elects a leader once, and then the leader is responsible for making all the decisions about the state of the database. This helps avoid extra communication between replicas during individual reads and writes. Each node tracks the current leader and forwards requests to that leader.

Raft is built around the concept of a replicated log. When the leader receives a request, it first stores an entry for it in its durable local log. This local log is then replicated to all of the followers, or replicas. Once the majority of replicas confirm they have persisted with the log, the leader applies the entry and instructs the replicas to do the same. In the event of leader failure, a replica with the most up-to-date log becomes the leader.

Raft defines not only how the group makes a decision, but also the protocol for adding new members and removing members from the group. This feature makes Raft a natural fit for managing topology changes in distributed systems.

Raft Consensus Algorithm FAQs

How Does ScyllaDB Support the Raft Consensus Algorithm?

ScyllaDB originally supported Lightweight Transactions (LWT) using Paxos, but these transactions require three roundtrips. ScyllaDB is implementing Raft as part of Project Circe, ScyllaDB’s 2021 initiative to improve ScyllaDB by adding greater capabilities for consistency, performance, scalability, stability, manageability and ease of use. With Raft, ScyllaDB is able to execute consistent transactions without a performance penalty. Unlike Paxos, which is only used for LWT, most aspects of ScyllaDB will move to Raft, significantly improving manageability and consistency.

Beyond crucial operational advantages, application developers will be able to leverage Raft to enable strong transaction consistency at the price of a regular operation.

ScyllaDB’s Raft implementation covers the following system components:

  • Transactional Schema Changes — Our first user-visible value eliminates schema conflicts and allows full automation of DDL changes under any condition.
  • Transactional Topology Changes — Our next user-visible change will permit adding or removing any number of nodes simultaneously. Currently, ScyllaDB and Cassandra can only scale one node at a time. This means it can take long hours to double or triple the whole cluster’s capacity. Obviously, this is not the elasticity you’d expect if you have bursty intraday traffic.
  • Tablets — Once range ownership becomes transactional, it will allow many levels of freedom. We plan to improve more aspects of range movements, towards tablets and dynamic range splitting for load balancing.

More about ScyllaDB’s move to Raft?

As of December 2020, the core Raft protocol is implemented in ScyllaDB. The next user-visible improvement is to make topology changes transactional using Raft. We welcome you to follow our progress with Raft and other advancements at Introducing Project Circe: Making the Best NoSQL Database Better.

ScyllaDB University Mascot

ScyllaDB University

Get started on your path to becoming a ScyllaDB expert.