Raft in NPL

Design

After a short research on the design and implementation of rqlite and actordb, TableDB with Raft replication will be started with the NPL Raft implemetation, which is (probably) the fundamental of this project. If we have finish this, we could consider to add more functional features like actordb.

TableDB with Raft implemetation will be much like rqlite, the only difference is TableDB's replication is on the table(collection) level, while rqlite is on the whole sqlite datebase(which may have multiple tables) level，the replication level can be in a higher layer.

A much coarse roadmap：

• Implement Raft consensus with NPL, according to the Raft paper and jraft
  • Leader election
  • Log replication
  • Cluster membership changes
  • Log compaction
  • Client interaction
• Add more abstract interface to TableDB to adapt to the Raft consensus, with reference to rqlite
• Test. Test correctness and performance of the implementation, and fix.

NPL Raft

In order to get a quick(in one month), full feature and correct NPL Raft implementation, it will be helpful to refer to an existing (full feature and correct) implementation. After several days' digging into NPL and various Raft implementations on the raft consensus website, I choose jraft, a Java implemetation. There are several reasons for this:

• NPL is recommended to an OO style coding
• jraft is full feature, correct and still under maintenance
• jraft is straight forward, and have a good understandability, much thanks to the good Java OO style

Puzzles

Consistency has many corner cases to handle, especially network problem.

1. Say we have 3 servers, A,B,C. A is supposed to be the leader. What if (A->B and C->B)'s network is broken, but (B->A and B->C) works, what happens to the implementation?

   • B will turn to candidate, B's term will increase 1.
   • B send requestVote request to A and C.
   • A/C will update their term to B's term, empty voteFor(make -1), become Follower and compare their logs with B's log.
   • if B's log is not up-to-date, A/C will become Candidate.

   Think in another way: Say B's log is delayed and A/C contains most recent commited logs. A/C should decline the vote to maintain correctness.

2. What happens when the network is recovered.