分布式一致性——raft一致性
参考：http://www.jdon.com/artichect/raft.html
分布式系统需要解决的问题：CAP理论
C：consistency，一致性，所有数据变动都是一致的。
A：available，好的响应性能。
P：partition tolerance 分区容忍。
定理：任何分布式系统只可以同时满足两个，不可三者得兼。
raft中角色有三种：
Leader：处理所有客户端请求，日志复制等，一般只有一个。
Follower：被动处理Leader发来的请求。
Candidate：可以被选为一个新的Leader。
raft分为两个阶段：选举、
选举出来的Leader带领进行正常操作。每个节点都可以成为Candidate，像其他节点发送vote请求，最先得到N/2+1选票的就当选为Leader。Leader当选后向选民发出指令，比如日志复制等，以后通过心跳进行日志复制的通知。如果Leader宕机了，则Follow重新选举为Leader。如果某一时间选举Leader时有多个Leader得到票数一样，则在timeout比如300ms后重新选举，先得到N/2+1的成为Leader，这时候同票的概率大大降低。每个Candidate通常timeout时间不同，那么最短timeout时间的那个就会最先得到大多数投票。
日志复制：
假设Leader已经选出，现在客户端发出一个增加日志的要求，Leader要求Follower遵从他的指令，都将这个新的日志内容追加到他们各自日志中，当超过半数以上的Follow都向Leader发出确认后，Follower服务器将日志写入磁盘文件后，确认追加成功，发出Commited Ok，Leader返回添加成功给client。在下一个心跳heartbeat中，Leader会通知所有Follwer更新commited 项目。
分区容忍：
如果这时候发生了网络分区，则原先的Leader只能正常访问本分区内的Follower，失去Leader的分区会重新选举一个Leader出来。如果这之后网络故障消失了，因为新的Leader的term比老的Leader的term大，那么原先的Leader会成为Follow，在失联阶段这个老Leader的任何更新都不能算commit，都回滚，接受新的Leader的新的更新。
http://www.cnblogs.com/bangerlee/p/5991417.html
为达到更容易理解和实行的目的，Raft将问题分解和具体化：Leader统一处理变更操作请求，一致性协议的作用具化为保证节点间操作日志副本(log replication)一致，以term作为逻辑时钟(logical clock)保证时序，节点运行相同状态机(state machine)[4]得到一致结果。Raft协议具体过程如下：
- Client发起请求，每一条请求包含操作指令
- 请求交由Leader处理，Leader将操作指令(entry)追加(append)至操作日志，紧接着对Follower发起AppendEntries请求、尝试让操作日志副本在Follower落地
- 如果Follower多数派(quorum)同意AppendEntries请求，Leader进行commit操作、把指令交由状态机处理
- 状态机处理完成后将结果返回给Client
指令通过log index(指令id)和term number保证时序，正常情况下Leader、Follower状态机按相同顺序执行指令，得出相同结果、状态一致。