Raft protocol implementation as part of "Distributed databases" course in UCU
Raft decomposes the consensus problem into three relatively independent subproblems:
Leader election: a new leader must be chosen when an existing leader fails.
Log replication: the leader must accept log entries
Safety: the key safety property for Raft is the State Machine Safety Property. If any server has applied a particular
log entry to its state machine, then no other server may apply a different command for the same log index. The solution involves an
additional restriction on the election mechanism.
Raft guarantees that each of these properties is true at all times.
Election Safety: at most one leader can be elected in a given term.
Leader Append-Only: a leader never overwrites or deletes entries in its log; it only appends new entries.
Log Matching: if two logs contain an entry with the same index and term, then the logs are identical in all entries
up through the given index.
Leader Completeness: if a log entry is committed in a given term, then that entry will be present in the logs
of the leaders for all higher-numbered terms.
State Machine Safety: if a server has applied a log entry at a given index to its state machine, no other server
will ever apply a different log entry for the same index.
Info about implementation
Each server launches rpc server
Communication with client is done via raft http client or you can do it directly via evans
Creating new entry is done via leader node, other nodes will respond with no success and leader id.
Each node could reveil log via GetLog rpc call. (this is done according to task requirements)
How to launch:
Install dependencies with dep ensure
Change number of nodes and set an unique ID to each in env/env.go