分布式事务-CAP&Raft原理_raft cap

CAP定理

一致性(Consitency)：在分布式系统中的所有数据备份，在同一时刻是否同样的值。

可用性(Availability)：在集群中一部分节点故障后，集群是否还能响应客户的读写请求。

分区容错性(Partition tolerance)：大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区。分区容错的意思是，区间通信可能失败。比如，一台服务器放在中国，另外一台服务器放在美国，这就叫两个区，它们之间可能无法通信。

CAP原则指的是，这三个要素最多只能同时实现两个点，不可能三者兼得。

一般来说，分区容错不可避免，因此，可以认为CAP中的P总是成立。CAP定理告诉我们，剩下的C和A无法同时做到。

Raft算法：Raft

分布式系统中实现一致性的算法 

首先，在Raft中一个节点有三种角色：①追随者(Follower)②候选人(Candidate)③领导者(Leader)

一开始，所有节点都是追随者状态，如果没有领导者给他们发信息，他们可以变成候选人，候选人将会给追随者发起选举，追随者们将会投票给候选人，如果候选人得到了大多数票则它将会成为领导者。这个过程被成为：领导选举。

追随者是如何成为候选人的呢？首先，节点有一个自旋超时时间(150ms-300ms),谁自旋结束的快谁就是候选者，候选人发起选举，如果节点在此轮选举中还没有投票，那么节点将会投票给它，一旦候选人收到大多数投票那么它将成为领导者。成为领导者之后则开始心跳联络，定期向节点发出我还在的消息，节点回复收到，这种状态直到领导者挂掉为止。

所有改变将需要听从领导者，假设客户端发来一条 SET 5 命令，首先，领导者会将这条命令保存到log中，然后会将 SET 5 命令发送给它的追随者，追随者们也是将命令保存至log中，领导者接收到大多数节点的回复--已经将这条命令写入log中了，此时，所有节点日志中的这条命令都是uncommited的。然后，领导会将这条命令commit并通知它的追随者让它们也去提交。这个过程被成为：日志复制。

日志复制过程在分区中的体现：由于网络原因，A、B被划分为1区，C、D、E被划分为2区，1区和2区之间不能通信，A原来是领导者所以在1区它还是领导者，2区经过多轮选举选出了新的领导者，现在有Client1给1区发 SET 10 的命令，A保存命令至日志然后通知B也保存日志，但是通知没有得到大多数节点的回复因此是uncommited的状态，Client2给2区发 SET 100 命令，2区领导者保存命令至日志，同时通知其它节点页保存命令至日志并且收到大多数节点的回复，2区领导者将会commit并会通知其它节点也去commit的。最终，1区和2区的通信回复了，由于2区的领导者是经过多轮选举选出的所以它成为了所以节点的领导者，原来1区的领导者就变成了追随者，1区A、B节点发现跟领导者的日志不一致，马上回滚日志并更新新的日志和提交，至此所有节点的数据是一致的。