This repository has been archived by the owner. It is now read-only.
An implementation of the Raft distributed consensus protocol.
Go
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
.gitignore
.travis.yml
JOINT-CONSENSUS.md
LICENSE
README.md
configuration.go
example_test.go
log.go
log_test.go
peers.go
peers_test.go
rpc.go
server.go
server_internals_test.go
server_test.go
transport.go
transport_test.go

README.md

raft

This is an implementation of the Raft distributed consensus protocol. It's heavily influenced by benbjohnson's implementation. It focuses on providing a clean and usable API, and well-structured internals.

Build Status

Usage

A node in a Raft network is represented by a Server structure. In a typical application, nodes will create a Server, and expose it to other nodes using a Peer interface.

Servers are only useful when they can communicate with other servers. This library includes a HTTP Transport (ingress) and HTTP Peer (egress) which combine to allow communication via REST-ish endpoints. For now, it's the simplest way to embed a Raft server in your application. See this complete example.

Several other transports are coming; see TODO, below.

Adding and removing nodes

The Raft protocol has no affordance for node discovery or "join/leave" semantics. Rather, the protocol assumes an ideal network configuration that's known a priori to nodes in the network, and describes a mechanism (called joint-consensus) to safely replicate that configuration.

My implementation of joint-consensus abides those fundamental assumptions. Nodes may be added or removed dynamically by requesting a SetConfiguration that describes a complete network topology.

TODO

  • Leader election done
  • Log replication done
  • Basic unit tests done
  • HTTP transport done
  • net/rpc transport
  • Other transports?
  • Configuration changes (joint-consensus mode) done
  • Log compaction
  • Robust demo application ☜ in progress
  • Complex unit tests (one per scenario described in the paper)