zookeeper基础（关于恢复模式及CAP定理）

恢复模式的三个原则

当集群正在启动过程中，或Leader崩溃后，集群就进入了恢复模式。对于要恢复的数据状态需要遵循三个原则。

Leader 的主动出让原则

若集群中Leader 收到的Follower心跳数量没有过半，此时Leader会自认为自己与集群的连接出现了问题，其会主动修改自己的状态为Looking，去查找新的Leader。
而其他Server 由于有过半的主机认为已经丢失了Leader，所以它们会发起新的Leader选举，选举一个新的Leader。

已被处理的消息不能丢

正常情况下，当Leader 收到超过半数 Follower 的Acks后，就向各个Follower 广播commit 消息，批准各个Server执行该写操作事务。当各个Server 在接收到Leader 的commit 消息后就会在本地执行该写操作，然后会向客户端响应写操作成功。
但是如果在非全部Follower 收到 Commit 消息之前Leader 就挂了，这将导致一种后果：部分Server已经执行了该事务。当新的Leader被选举出，集群经过恢复模式后需要保证所有Server 上都执行了哪些已经被部分Server执行过的事务

被丢弃的消息不能再现

当在Leader 新事务已经通过，其已经将该事务更新到了本地，但所有的Follower 还都没有收到Commit之前，Leader宕机了。此时，所有Follower根本就就不知道该Proposal的存在。当新的Leader被选举出来，整个集群进入正常服务之后，之前挂了的Leader主机重新启动并注册成为了Follower。若那个别人根本不知道的Proposal 还保留在那个主机，那么其数据就会比其他主机多出了内容，导致整个系统的状态不一致。所以，该Proposal会被丢弃。类似这样应该被丢弃的事务，是不能再次出现在集群中的，应该被清除。

CAP定理

简介

CAP定理又称为CAP原则，指的是在一个分布式的系统中，Consistency（一致性）、Availability（可用性）、Partition tolerance（分区容错性），三者不可兼得。

• 一致性（C）：分布式系统中多个主机之间是否能够保持数据的一致。即，当系统数据发生更新操作后，各个主机中的数据仍然处于一致的状态，也就是说所有节点拥有数据的最新版本。
• 可用性（A）：系统提供的服务是否一致处于可用的状态，即对于用户的每一个请求，系统是否总是可以在有限的时间内对用户作出响应。
• 分区容错性（P）：分布式系统在遇到任何网络分区故障时，依然能够保证对外提供满足一致性和可用性的服务。分区是网络分区。

对于分布式系统，网络环境相对是不可控的，出现网络分区是不可避免的，因此系统必须具备分区容错性。但其并不能保证一致性和可用性。CAP原则对于一个分布式系统来说，只可能满足两项，即要么CP、要么AP、要么CA。
上图直观点：