zookeeper原理-一致性

1. 不得不说的CAP原理

要介绍分布式中的一致性，肯定会关联出CAP原理，那什么是CAP呢？

• 一致性（C）：分布式系统更新操作之后，所有的节点数据一致。
• 可用性（A）：每一个非故障的节点必须对每一个请求作出响应。
• 分区容错性（P）：分区容错性。以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择，也就是说无论任何消息丢失，系统都可用。

根据CAP原理可知，任何一个分布式系统，不可能同时满足C、A、P，只能取其二。而且在分布式系统中，网络分区是必然存在的事实，所以要成为一个分布式系统必须保证P，也就是说一个有效的分布式系统只能是CP/AP这两种组合特性。

2.Zookeeper和CAP理论

根据分布式CAP理论分析，可知Zookeeper只能是CP/AP,它到底是哪个呢？答案是CP,即Zookeeper保证了一致性和分区容错性。

相信肯定有人会产生疑问，为什么说Zookeeper不满足A这个特性呢？其实很简单，就是在zookeeper启动或者leader节点宕机等情况下会进行zookeeper的leader选举，这个时候zookeeper进行只读状态，所以客户端的更新请求将全部失败，即可用性在此时是没有办法保证的。

虽然zookeeper是一个CP系统，但是它不是一个强一致性的系统，它是一种顺序一致性的系统。为了说明这种差别，需要介绍一下一致性的分类。

1. 强一致性（strong consistency）。任何时刻，任何用户都能读取到最近一次成功更新的数据。
2. 弱一致性（weak consistency）。用户无法在确定时间内读到最新更新的值。
3. 最终一致性（eventual consistency）。用户只能读到某次更新后的值，但系统保证数据将最终达到完全一致的状态，只是所需时间不能保障。
   上面说了，三种常见的一致性分类，zookeeper是比最终一致性更高的顺序一致性（可以看成保证最终一致性的前提下，顺序响应请求）

3.Zookeeper顺序一致性原理

1. 所有的Follower的写请求都会有leader进行处理，并等待所有的follower处理结果确认。
2. follower收到leader发送来非自身的需要处理的客户端请求，就会和leader同步，即保证follower的处理（主要是持久化和响应客户端）顺序和leader一致。

4.zookeeper一致性的缺陷

在前面介绍的一致性分类中，可知最好的是能实现强一致性，即保证任何时刻所有节点的数据是一致的，但是这种实现的代价是非常大的。在分布式系统中存在多个节点，如果节点数过多为了保证强一致性，需要将所有的节点全部确认一遍才能继续响应。所以zookeeper默认是保证一半节点确认通过即可，但是它会带来其他的问题。

主要是如果客户端连接的是没有参与确认的服务器，会出现客户端读取的"最新"数据其实是旧的数据，所以要保证客户端读取到真正的最新数据，需要先发起sync请求，保证最新数据已经同步完成。