Raft paper summarization

Part 2A: leader election

Implement Raft leader election and heartbeats (AppendEntries RPCs with no log entries). The goal for Part 2A is for a single leader to be elected, for the leader to remain the leader if there are no failures, and for a new leader to take over if the old leader fails or if packets to/from the old leader are lost. Run go test -run 2A to test your 2A code.

**Goal**

Sending and receiving RequestVote RPCs

Steps:

Add the state for leader election to the `Raft` struct in `raft.go`

	// 2A
	currTerm   int32
	votedFor   int
	logEntries []logEntry

define a struct to hold information about each log entry

type logEntry struct {
	command string
	term    int32
}

Fill in the `RequestVoteArgs` and `RequestVoteReply` structs

// example RequestVote RPC arguments structure.
// field names must start with capital letters!
type RequestVoteArgs struct {
	// Your data here (2A, 2B).
	term         int32
	candidateId  int
	lastLogIndex int32
	lastLogTerm  int32
}

// example RequestVote RPC reply structure.
// field names must start with capital letters!
type RequestVoteReply struct {
	// Your data here (2A).
	term        int32
	voteGranted bool
}

Modify `Make()` to create a background goroutine that will kick off leader election periodically by sending out `RequestVote` RPCs when it hasn't heard from another peer for a while.

Implement the `RequestVote()` RPC handler so that servers will vote for one another

To implement heartbeats, define an `AppendEntries` RPC struct, and have the leader send them out periodically.

Write an `AppendEntries` RPC handler method that resets the election timeout so that other servers don't step forward as leaders when one has already been elected.

The tester requires that the leader send heartbeat RPCs no more than ten times per second.

Part 2B: log

从当前的Leader处收到AppendEntries RPCs或向Candidate投票的时候reset ElectionTimeout()

All you need to know about index

1. Leader开始，接受Client的命令，将Command append到log尾部，让Server更新状态机 2. Server更新状态机中的log并返回true的reply。注意，此时Leader和Server的commitIndex都没有发生变化，变化的只是Leader中的nextIndex和matchIndex。这里在Term相同的情况下返回false的reply，会让Leader中的nextIndex自减。 3. 每当一个AppendEntries返回true以后，触发信号，让Leader检查commitIndex是否能够更新，能更新就增大commitIndex，在下次heartbeat的时候就会更新Server中的commitIndex。

Part 2C: persistence

Part 2D: log compaction

实现Snapshot，index意味着所有index之前的log都将被丢弃

Follower应该使用快照来赶上整体的进度

忽略CondInstallSnapshot

可以先将index设为0,慢慢增大来尝试通过2D的第一个test

如果leader没有能让follower up-to-date的条目，则发送快照

不要实现论文中figure 13的offset

需要让GC可以access被丢弃的条目，即不存在可访问被丢弃条目的指针

保存最新快照的lastIncludedTerm和lastIncludedIndex