Repository files navigation

This is an akka based implementation of theRaft consensus algorithm.It is generic enough that you can build your own replicated state machines on top of it (with raft keeping track of the consensus part of it).

This implementation isakka-cluster aware, so it can be easily deployed on multiple machines.Implementation wise, all parts of the raft whitepaper are covered:

• Leader election
• Dynamic membership changes (with transitioning periods implemented as Joint Consensus)
• Deployment across multiple nodes
• Log compaction, via snapshotting

💥 💥

This project is a side-project of mine and is still work in progress (treat it as EARLY PREVIEW) and has a number of known protocol bugs (seeIssues). It is NOT recommended to be used in production, however it's a great project to play around with implementing and discussing the Raft protocol.

💥 💥

In other words: Use at own risk, best not on any production-like environments (for now).

Raft is a distributed consensus algorithm, much like Paxos (but simpler).This implementation is fully akka (and akka-cluster) based, and can be used to deploy a replicated state machine on top of akka clusters.

THIS API IS STILL SUBJECT TO CHANGE

classWordConcatRaftActorextendsRaftActor {typeCommand=Cmndvarwords=Vector[String]()/**   * Called when a command is determined by Raft to be safe to apply;   * Application results are sent back to the client issuing the command.*/defapply= {caseAppendWord(word)=>      words+: word      log.info("Applied command [{}], full words is: {}", command, words)      word// will be sent back to original actor, who sent the AppendWord commandcaseGetWords=>valres= words.toList      log.info("Replying with {}", res)      res  }}// ...valmembers= (1 to3) map { i=> system.actorOf(Props[WordConcatRaftActor], name=s"raft-member-$i") }valclusterConfiguration=ClusterConfiguration(raftConfiguration.members+ additionalActor)// 0, 1members foreach { _!ChangeConfiguration(clusterConfiguration)// todo implement re-routing if you send to a non-leader// then send messages to it; the state machine will only be applied when consensus has been reached about a valueleader!ClientRequest(AppendWord("I"))leader!ClientRequest(AppendWord("like"))leader!ClientRequest(AppendWord("capybaras"))// ... after some timeleader!GetWordsexpectMsg(List("I","like","capybaras"))

And if you want to enable snapshotting support it's as simple as implementing one method and matching forInstallSnapshotin your Actor:

classSnapshottingWordConcatRaftActorextendsRaftActor {typeCommand=Cmndvarwords=Vector[String]()defapply= {caseAppendWord(word)=>      words+: word      wordcaseGetWords=>valres= words.toList      log.info("Replying with {}", res)      rescaseInstallSnapshot(snapshot)=>      words= snapshot.data.asInstanceOf[Vector[String]]  }overridedefprepareSnapshot(meta:RaftSnapshotMetadata)=Future.successful(Some(RaftSnapshot(meta, words)))}

In the above examples, theclient implementation is very naive, and assumes you have some wayof finding out who the current Leader is (as this is a requirement to interact with any Raft cluster).Thankfully, you can use the providedRaftClientActor, which works like a proxy that forwards all your messagesto the currentLeader, or stashes them if the cluster has noLeader at the moment (is undergoing an election) andsends the messages once the Leader becomes available.

Simply:Apache 2.0

Issues, Pull Requests as well as Tweets and Emails are more than welcome!

• An excellent analysis usingfuzz testing of akka-raft, discovering a number of protocol bugs by @colin-scott, blog postFuzzing Raft for Fun and Publication and linked inside it the whitepaper draft.

• Raft - In Search of an Understandable Consensus Algorithm whitepaper

• See other implementations (many lanugages) onraftconsensus.github.io

• Docs onakka-cluster in2.3.0-RC2.

We have discussed this paper both in Kraków and London, on theseawesome reading clubs (drop by if you're into CS papers!):

• Software Craftsmanship Kraków - SCKRK.com
• Paper Cup - the reading club - London