一致性分析
Raft算法解决的不仅仅是分布式集群环境下的一致性问题，还有一定限度内的容错性（半数节点工作正常则服务可用，异常节点恢复正常后可以继续加入到集群中工作）
raft系统中强一致性不仅仅是写操作，所有的读的请求也要转发到leader，leader确认了自己的leader地位后才能反馈给客户端的，重点注意。（例如consul集群中的consistent模式，而不是default模式和stale模式）
Raft的强一致性，对客户端来看，一旦确认过的command，只要集群可用，每次访问返回的结果都一样。
但是实际上在Raft集群节点之中，是最终一致性+半数以上一致性的模式，Leader会不停的给不一致的Node发送RPC，并且会维护一个matchIndex[]，直到所有的Node的数据一致。Raft的强一致性并不能保证读取到最最最新的数据。
因为系统中没有锁的概念，所以并不能实现类似Mysql SERIALIZABLE这种级别的安全，Raft的读取是leader confirm了自己的地位之后，读取leader状态机中的值的过程。但是这个过程中，可能有新的命令正在执行，也就是写的时候没有加锁，正在写又没有完成apply的数据，是读不到的。
所以在consul的集群中，支持三种模式：stale、default、consistent模式
- stale 模式：所有Node都可以直接返回自己状态机里的结果
- default模式：所有Query都转给Leader，leader来返回自己状态机里的结果
- consistent模式：所有Query都转给Leader，leader需要发送一个心跳，确认自己的leader地位之后，leader来返回结果
这三种模式都可以确保一点：读取的都是状态机中的数据。所以数据可能不是最新的，但是都是半数节点确认过的数据。
除了PK一致性，实际运用中还要考虑读的性能：stale模式的读取性能 >default模式 >consistent模式。
既然Raft标准模式也无法确保读取到最新的数据，那么可以根据业务场景选择适合自己的模型。
参考
Raft算法中文版（论文翻译）
https://www.cnblogs.com/linbingdong/p/6442673.html
