raft--选举和朝代替换

前段时间和师傅一起搞了个双机备份的定制，打打杂，但是听他们讨论感觉还挺好玩的，就上网找了点东西玩下，纯属个人多动按奈不住找点东西装个酷，让自己爱上自己，当然也作为我们这群大波屌丝的饭后消遣活动。

查下网上的资料都不难发现，每篇文章在讨论亲爱的raft时，都会附带让你先了解下分布式的老情人，曾是分布式的“权威代表”（当然，现在我也不太清楚还是不是了，毕竟我只是打酱油的）--Paxos算法。他的伯乐是一向财大气粗，好玩高科技的google。google的chubby锁服务使用这个算法作为一致性算法，让他开始流传开来，并获图灵奖（当然这个算法本身是真的很牛逼哄哄的）。那么，为啥我要看raft而不是看Paxos呢？道理很简单了，学习Paxos，臣妾办不到哇，那玩意太难了！听说，raft相对于来说会比较简单点，更容易理解（我想可能吧）。

一般希望数据能够有较高的可用性，就会写多份数据来进行实现，但是在实现数据写多份的操作，就希望我们每份数据能具有一致性，当然数据的一致性还是会引发一些性能的问题。对于分布式存储，相对来说数据的一致性是更为重要的，不然我们分布存储下来干啥使。

相对于两台PC，只要实现两台直接相互沟通，对于提交过来的信息，备机只能选择无条件的服从，不同意，那就一起回滚咯，根本没有别的太多的限制。就像两个人吃饭，一个说吃面一个人说吃饭，谁强大听谁的，只要有一方愿意服从就可以了。

但是对于多个人的情况就不同了，大家如果意见不一致，就得希望这当中能有那么一个人出来做大哥，听他的调遣，他说吃啥就吃啥。但是大哥不是那么好当的，就像国家主席似的，不是你说当就能当的，还是得投票的，而且法律面前人人平等，你不能剥夺任何一个人的参与权。分布式存储时，服务器就是遵循的这种原则。因此，每台服务器都有三种角色：leader（领导）、candidate（候选人）、follower（平民）。选举的举措还是很好理解的，当然是一部分从平民中变成了候选人，然后平民选举产生leader。在开始时，每台服务器都处于follower状态（没有谁出生就是leader的），但是在这里成为候选人并不像我们现实中那么困难，需要做大量的工作，这里采用的方式很简单，每个follower都会在一个随机的时间内发出请求（即心跳机制），让大家推选他为下任leader。发出请求的follower为candidate，没有发出请求的follower依旧为follower，而获得票数最多的则为leader。当然candidate同时也可以为自己投票（也是挺自恋的），且每个服务器只能投一票，已经投过票的则不能投票。如图1为某一服务器在这三个角色中的转换图。

当然看图就知道，角色转换之间肯定有不少的激情，再说来点激情这leader当的肯定不爽，就像一个皇帝，你不经历下磨难怎么能抗打当个体恤爱民的好皇帝，怎么能有那种慢慢的虚荣感，是吧？就如抢别人的东西总是好吃点的！所以，leader选举的过程也总是会出现那么几个想争夺的人。

1. 如果follower在成为Candidate的时候，已经有一个Leader了，怎么办
   那么作为获选人的服务器当然要看下这个leader是否是现在这个朝代（一个term在我的理解相当于一个朝代）的领导人。如果 是，那么只有服从，如果不是，那么对不起，我要推翻旧朝代，等待被推崇为新的统治者。
2. 两个follower同时发送请求
   如果两个follower同时发送请求，那么这两个follower则同时为candidate。然后看获得的票数，谁的票数最多，谁就是leader。那么问题来了， 作为一台服务器，不能写一大串的算法来判断该让谁来当吧？一两个的还好，一大堆的怎么办？这里采用的是先到先得的态度，谁先找到我，我就投谁的！ 如果票数一样呢？那就更简单了，说明选举失败了，只能进行下一轮选举。
3. 如果有两个Leader呢
   假设老皇帝死了，新皇帝上位了，开始整顿朝纲，后来老皇帝复活了（当然这不是诈尸，可能老皇帝是假死的），那么抱歉了，你是以前的皇帝（即向上面说的，你是上个朝代的人），现在没人听从你的命令了，那么即使你是上一朝代的皇帝，你现在也得听我的安排。

选举的时间由图2表示，假设有S1、S2、S3、S4、S5台服务器，则服务器的可能状态有这几种。

是不是挺好玩的？感觉你就是上帝操做着所有！这也是raft算法选举Leader的思想，然后Leader发送心跳包到所有的服务器，建立自己的政权，防止有人造反（产生新的选举）。