上来先看了2b的要求文档。主要就是要handle log了。
里面强烈推荐了3篇文章，我认真做了阅读。发现了我之前实现的一些问题。
其中一个是来自中文的翻译
比如：如果在超过选取领导人时间之前没有收到来自当前领导人的AppendEntries RPC或者没有收到候选人的投票请求，则自己转换状态为候选人
原文：If election timeout elapses without receiving AppendEntries RPC from current leader or granting vote to candidate: convert to candidate.
区别就是一个是授予了投票再唤醒，另一个是只要收到rpc就唤醒。
文章链接来自hint：
- Give yourself time to rewrite your implementation in light of lessons learned about structuring concurrent code. In later labs you'll thank yourself for having Raft code that's as clear and clean as possible. For ideas, you can re-visit our structure,locking and guide, pages.
实现的时候，发现除了是授予了投票，要唤醒。还有当选了LEADER也要唤醒。
重跑了下测试，没啥问题
第一步 阅读论文5.3- 6之前
https://www.infoq.cn/article/raft-paper
第二步 FROM HINT
You will need to implement the election restriction (section 5.4.1 in the paper).
Raft 使用投票的方式来阻止没有包含全部日志条目的服务器赢得选举。一个候选人为了赢得选举必须要和集群中的大多数进行通信，这就意味着每一条已经提交的日志条目最少在其中一台服务器上出现。如果候选人的日志至少和大多数服务器上的日志一样新（up-to-date，这个概念会在下边有详细介绍），那么它一定包含有全部的已经提交的日志条目。RequestVote RPC 实现了这个限制：这个 RPC（远程过程调用）包括候选人的日志信息，如果它自己的日志比候选人的日志要新，那么它会拒绝候选人的投票请求。
Raft 通过比较日志中最后一个条目的索引和任期号来决定两个日志哪一个更新。如果两个日志的任期号不同，任期号大的更新；如果任期号相同，更长的日志更新。
这一步 应该上一章已经实现了。
剩下一些HINT，在上一章基本都COVER住了，不用太多改动
比如
One way to fail the early Lab 2B tests is to hold un-needed elections, that is, an election even though the current leader is alive and can talk to all peers. This can prevent agreement in situations where the tester believes agreement is possible. Bugs in election timer management, or not sending out heartbeats immediately after winning an election, can cause un-needed elections.
第三步 实现START
根据方法描述，实现如下
第四步 实现startAppendLog
搜索到//now only for heartbeat
然后开始把这个方法从只是发送HEART BEAT 到真的开始发日志。
论文重点
当这个条目被安全的复制之后（下面的部分会详细阐述），领导人会将这个条目应用到它的状态机中并且会向客户端返回执行结果。如果追随者崩溃了或者运行缓慢或者是网络丢包了，领导人会无限的重试 AppendEntries RPC（甚至在它向客户端响应之后）直到所有的追随者最终存储了所有的日志条目。
领导人跟踪记录它所知道的被提交条目的最大索引值，并且这个索引值会包含在之后的 AppendEntries RPC 中（包括心跳 heartbeat 中），为的是让其他服务器都知道这条条目已经提交。一旦一个追随者知道了一个日志条目已经被提交，它会将该条目应用至本地的状态机（按照日志顺序）
- 如果在不同日志中的两个条目有着相同的索引和任期号，则它们所存储的命令是相同的。
- 如果在不同日志中的两个条目有着相同的索引和任期号，则它们之间的所有条目都是完全一样的。
第一条特性源于领导人在一个任期里在给定的一个日志索引位置最多创建一条日志条目，同时该条目在日志中的位置也从来不会改变。第二条特性源于 AppendEntries 的一个简单的一致性检查。当发送一个 AppendEntries RPC 时，领导人会把新日志条目紧接着之前的条目的索引位置和任期号都包含在里面。如果追随者没有在它的日志中找到相同索引和任期号的日志，它就会拒绝新的日志条目。这个一致性检查就像一个归纳步骤：一开始空的日志的状态一定是满足日志匹配原则的，一致性检查保证了当日志添加时的日志匹配原则。因此，只要 AppendEntries 返回成功的时候，领导人就知道追随者们的日志和它的是一致的了。
下面是最关键的一段话
为了使得追随者的日志同自己的一致，领导人需要找到追随者同它的日志一致的地方，然后删除追随者在该位置之后的条目，然后将自己在该位置之后的条目发送给追随者。这些操作都在 AppendEntries RPC 进行一致性检查时完成。领导人给每一个追随者维护了一个nextIndex，它表示领导人将要发送给该追随者的下一条日志条目的索引。当一个领导人开始掌权时，它会将nextIndex初始化为它的最新的日志条目索引数 +1（图 -7 中的 11）。如果一个追随者的日志和领导者的不一致，AppendEntries 一致性检查会在下一次 AppendEntries RPC 时返回失败。在失败之后，领导人会将nextIndex递减然后重试 AppendEntries RPC。最终nextIndex会达到一个领导人和追随者日志一致的地方。这时，AppendEntries 会返回成功，追随者中冲突的日志条目都被移除了，并且添加所缺少的上了领导人的日志条目。一旦 AppendEntries 返回成功，追随者和领导人的日志就一致了，这样的状态会保持到该任期结束。
需要知道GO 切片知识
https://stackoverflow.com/questions/27055626/concisely-deep-copy-a-slice?rq=1
因为 //在失败之后，领导人会将nextIndex递减然后重试 AppendEntries RPC
所以要包在一个FOR循环里，失败就重试，成功就RETURN,因为变成了循环 注意DEFER unlock就不能用在循环体里了，不然就死锁了。
下图我们发现第一条我们实现了，后面都没有完整实现。第二条的前半段在之前Start()里实现的。后半段把条目应用到状态机后响应客户端还没实现。
领导人规则的第五条，因为是要看MATCH INDEX，而MATCH INDEX只在发送成功的时候会更新。所以为了减少不必要的CHECK，我们可以放在
reply.Success里来做注意 这里中文是病句
因为原文为
If there exists an N such that N > commitIndex, a majority of matchIndex[i] ≥ N, and log[N].term == currentTerm: set commitIndex = N (§5.3, §5.4).
我们一点一点来，先处理reply.Success
第五步 实现updateCommitIndex
就是根据上面的英文来实现，超过半数的话，就排序然后找中间偏大的那个，来比即可。
注意在找超过半数的时候，很容易忘记LEADER自己的INDEX没有更新，造成临界点刚好没到半数。
到此为止，我们基本实现了startAppendLog，第一个//now only for heartbeat变为了真的会APPEND LOG的方法
下面开始写HANDLER
第六步 实现AppendEntries
这里论文也有写怎么做，介于中文翻译的质量确实不理想。这里贴个英文图
因为这边开始会RETURN了。所以我们要把收到APPEND ENTRIES 这个RPC的CHANNEL 唤醒的操作放到DEFER里去
在UTIL.GO 里定义MIN INT 方法
不知道你有没有注意到我们一直在更新commitIndex，但是我们没有更新lastApplied
这里还有一条所有服务器的规则
如果commitIndex > lastApplied，lastApplied自增，将log[lastApplied]应用到状态机（5.3 节）
第七步 思考何时updateLastApplied
为了减少调用次数，我们只要思考何时会更新COMMITINDEX
发现2处
第八步 实现updateLastApplied
调试
BUG 1
按照老师的建议，我们先测2B最简单的，发现出问题了，INDEX越界
排查了下。
这边应该是=，我之前写成+=
BUG2
数组越界的错没了。下面的错非常棘手。
他报了这个 config.go:465: one(100) failed to reach agreement
在仔细阅读了https://thesquareplanet.com/blog/students-guide-to-raft/
我依然没有任何收获。
决定在关键位置打LOG。大概率是因为APPEND ENTRIES 这个RPC 有逻辑没做对。
所以我在发送RPC前后，加了LOG
得到信息如下
感觉没太大问题，不过可以知道REPLY 是SUCCESS的。说明HANDLER里面逻辑是正确的。
因为最终服务器需要在APPLY CHANNEL，读信息
所以我们在CHANNEL出去的时候做一个打印，看下有没有出去。
随后因为走的分支是REPLY.SUCCESS
在这个里面把对应的参数也打印一下。
打印结果，发现消息完全没有出去的迹象。
分析LOG可以得知
matchIndex 一开始是-1，后来变成了0
而我们初始化的时候就对matchIndex 初始化为了0.
再增加了一个元素后，依然是0，而updateCommitIndex的关键就是N > commitIndex, a majority of matchIndex[i] ≥ N。
那么问题就是即使所有NODE 都收到了那个元素，然而matchIndex最大也是到0， 0是不会超过commitIndex 初始化的0
再回过去看commitIndex 和 matchIndex的定义
按照这个定义的理解，只有被提交的最高索引。那么初始化怎么说也应该是-1呀。
我开始按照我的思路改成-1，APPLYMSG出去了。可是测试需要的INDEX是我返回的INDEX还要+1.我又不好改测试。
一阵无语的时候我发现
这么重要的信息中文翻译里竟然没有
改动如下0改称1，加上注释
PASS 2B
Test Race
TEST.SH
因为有些并发的问题，可能不是每次重现，所以要尽可能多测来确定有没有问题。
我把这个标准定为1000次， 可是1000次要跑很久。所以我通过SHELL来处理这个问题。
SHELL 脚本如下，每处理完10次TEST打一个进度
#!/bin/bash
export PATH="$PATH:/usr/lib/go-1.9/bin"
rm res -rf
mkdir res
test_list=(
2A
2B)
for i in `seq 1000`
do
if [ $(($i % 10)) -eq 0 ]
then
echo $i
fi
for j in ${test_list[@]}
do
go test -run $j &> ./res/$j
if [ $? -ne 0 ]
then
echo "run failed."
exit 1
fi
done
done
