一致性的来龙去脉
先回答一个问题：为什么分布式系统中一致性问题那么难？
首先我们知道在单机系统中不存在数据的一致性问题，在分布式系统中，由于采用多机器进行分布式部署，必然带来数据的复制，那为什么引入数据的复制呢？主要试图解决的两个问题：
- 可用性：避免单点故障
- 性能：多机器提供相同服务
既然数据的复制不可避免，那么就勇敢的直面它，不过在此之前，让我们先认清下一致性的到底试图解决什么？
一致性问题最早出现在Reaching Agreement in the Presence of Faults中，简单来说一致性就是系统中各个独立的部分就某件事达成一致，但就是让大家都达成统一意见就是这么难，出现了Paxos, Zab , Raft等算法。本文重点介绍raft算法，因此下面会就raft具体展开。
raft中为了保证一致性，都有哪些方法呢？
- Leader Election
- Log Replication
先讲第一个，Leader Election，顾名思义就是领袖选举，先来搞清楚为什么会有领袖选举？因为在分布式环境下，多个机器之间要进行数据的复制，如果没有一个leader，所有的机器都能够提供读/写服务，那就需要保证(NXN)个数据复制都要一直成功，但是如果有了一个leader后，所有的读写都由leader来协调，那只要保证N个数据的复制成功，一下子就减轻了复杂度。
下面我们就开始正式的学习Leader Election了。
Leader Election
在raft中每个节点都属于3种角色中的一个
- Leader（领袖）
- Follower（群众）
- Candidate（候选人）
这3种角色的转换关系如下：
图中有个新的概念叫：term（任期），每个领导人都有自己的任期，任期到了就需要开始新的一轮选举，在每个任期内，可以没有leader，但是不能出现大于两个的leader。
raft将整个时间轴按照任期来划分，每个任期都起始于选举，即出现有Candidate开始竞选leader的时候。
我们对照着状态图来说下正常的选举过程。
- 系统刚启动的时候，每个节点都是follower状态，如果节点在follower状态期间，在一个election timeout时间内没有收到来自Leader的消息，则可以假设没有leader，于是启动选举过程，新增自己本地的任期
- 此时节点转换到了Candidate状态，首先当然是投票给自己，并且发送RequestVote RPCs给其他follower，让他们支持自己当leader，此时在收到投票结果后，可能会出现3种结果
2.1 获得了大多数的认可，赢得了投票，成为leader
2.2 发现了别人已经成为leader了或者自己的任期落后于别人的任期，自动转换为follower
2.3 一个选举周期过去了，也没有赢得竞选，开始新一轮竞选
画个图说明下：
问题：
- 怎么知道大多数人？Candidate要知道人有多少，人在哪，才能去邀请他们投票
当选举出了leader后，我们就可以正式开始对外服务了，提供读写请求，也正是我们要介绍个第二个保证一致性的方法：Log Replication
Log Replication
日志复制，自然而然的问题是：为什么通过日子复制的方式来解决数据一致性问题？使用日志的方式相比较其他有什么好处？
采用日志的方式，究其原因还是为了提高可靠性，像2PC一样，我们先将要做出的改变写到本地日志，然后再将其复制到其他follower，当一切就续后，最后再执行真正的写操作，将失败的可能性降到了最低，因此一步操作总比多步出错的可能性低。
针对上面的每一个步骤leader都可能故障的讨论，可以参考Raft 为什么是更易理解的分布式一致性算法
关于代码的实现，会在后续的文章中给出，敬请期待
