lab2A

这部分的内容是用来实现leader election过程，按照解释，每个节点创建之初都为follower 都会有一个超时时间，超时之后我们进入leader election状态。过程需要currentTIme++ votedFor=rf.me等等操作，paper上有详细介绍。 在我么能实现过程中遇到的第一个大概了事ticker的实现。其中要实现超时逻辑。一个简单的判断为

 for {  
   if 超时{  
     Election  
   }  
   time.Sleep(Duration)  
 }

当然在go中我们还可以通过timer和chan来实现阻塞唤醒 在上述代码中的第一个问题？Duration事多少？即多久我们检测一次是否超时，在我最早的设计中。100ms才进行一次检测（超时周期200-350），如果剩余还能运行的时间小于了100ms，则是这duraton为这个小的时间段。这样考虑的原因是为了性能，过高检测频率我担心会导致系统性能差。 但是，在实际中经常会发生错误，最常见的就是多个节点经常会一块进入candidate状态。导致谁也无法成为leader。问题出在，当一个candidate发送requestVote时，接受请求节点会重置超时时间，而我们的检测间隔太长无法及时的响应。 所以第一个问题的解决方法就是增加轮询频率，Duration的值设置为了10ms，经过测试并不会导致性能严重下降，现代处理器完全能够应对这样情况。

另外关于RequestVote结果的处理。 最初版本汇总

//简略版  
for i:=0;i<len(rf.peer);i++{  
  args  
  replgy  
  count=1  
  go func(id int){  
    ok:=rf.sendRequestVote(&args,&reply,id)  
    if ok{  
      if reply.success{  
        count++  
      }  
      if count>len(rf.peer)/2  
        rf.convertToLeader()  
        go boardcastHeartBeats()  
    }  
  }(i)     
}  
​

只要超过len(rf.peer)/2立马改变状态，响应非常迅速，这里又个非常明显的缺点，boardcastHeartBeats()会被执行多次，在2A中就算这样也能通过测试