ZooKeeper和CAP理论及一致性原则

1、CAP理论概述

CAP理论告诉咱们，一个分布式系统不可能同时知足如下三种

• 一致性（C:Consistency）
• 可用性（A:Available）
• 分区容错性（P:Partition Tolerance）

这三个基本需求，最多只能同时知足其中的两项，由于P是必须的,所以每每选择就在CP或者AP中。

一致性（C:Consistency）

在分布式环境中，一致性是指数据在多个副本之间是否可以保持数据一致的特性。在一致性的需求下，当一个系统在数据一致的状态下执行更新操做后，应该保证系统的数据仍然处于一致的状态。例如一个将数据副本分布在不一样分布式节点上的系统来讲，若是对第一个节点的数据进行了更新操做而且更新成功后，其余节点上的数据也应该获得更新，而且全部用户均可以读取到其最新的值，那么这样的系统就被认为具备强一致性（或严格的一致性，最终一致性）。

可用性（A:Available）

可用性是指系统提供的服务必须一直处于可用的状态，对于用户的每个操做请求老是可以在有限的时间内返回结果。“有效的时间内”是指，对于用户的一个操做请求，系统必须可以在指定的时间（即响应时间）内返回对应的处理结果，若是超过了这个时间范围，那么系统就被认为是不可用的。

“返回结果”是可用性的另外一个很是重要的指标，它要求系统在完成对用户请求的处理后，返回一个正常的响应结果。正常的响应结果一般可以明确的反映出对请求的处理结果，即成功或失败，而不是一个让用户感到困惑的返回结果。

分区容错性（P:Partition Tolerance）

分区容错性约束了一个分布式系统须要具备以下特性：分布式系统在遇到任何网络分区故障的时候，仍然须要可以保证对外提供知足一致性和可用性的服务，除非是整个网络环境都发生了故障。

网络分区是指在分布式系统中，不一样的节点分布在不一样的子网络（机房或异地网络等）中，因为一些特殊的缘由致使这些子网络之间出现网络不连通的情况，但各个子网络的内部网络是正常的，从而致使整个系统的网络环境被切分红了若干个孤立的区域。须要注意的是，组成一个分布式系统的每一个节点的加入与退出均可以看做是一个特殊的网络分区。

因为一个分布式系统没法同时知足上面的三个需求，而只能知足其中的两项，所以在进行对CAP定理的应用的时候，须要根据业务的要求抛弃其中的一项，下表所示是抛弃CAP定理中任意一项特性的场景说明。

所以，将精力浪费在思考如何设计能知足三者的完美系统上是愚钝的，应该根据应用场景进行适当取舍。

2、一致性的分类

一致性是指从系统外部读取系统内部的数据时，在必定约束条件下相同，即数据变更在系统内部各节点应该是同步的。根据一致性的强弱程度不一样，能够将一致性的分类为以下几种：

强一致性：（strong consistency）。任什么时候刻，任何用户都能读取到最近一次成功更新的数据。

单调一致性：（monotonic consistency）。任什么时候刻，任何用户一旦读到某个数据在某次更新后的值，那么就不会再读到比这个值更旧的值。也就是说，可获取的数据顺序必是单调递增的。

会话一致性：（session consistency）。任何用户在某次会话中，一旦读到某个数据在某次更新后的值，那么在本次会话中就不会再读到比这值更旧的值，会话一致性是在单调一致性的基础上进一步放松约束，只保证单个用户单个会话内的单调性，在不一样用户或同一用户不一样会话间则没有保障。

最终一致性：（eventual consistency）。用户只能读到某次更新后的值，但系统保证数据将最终达到彻底一致的状态，只是所需时间不能保障。

弱一致性：（weak consistency）。用户没法在肯定时间内读到最新更新的值。

3、ZooKeeper提供的一致性服务

ZooKeeper从如下几点保证了数据的一致性

顺序一致性：来自任意特定客户端的更新都会按其发送顺序被提交保持一致。也就是说，若是一个客户端将Znode z的值更新为a，在以后的操做中，它又将z的值更新为b，则没有客户端可以在看到z的值是b以后再看到值a（若是没有其余对z的更新）。

原子性：每一个更新要么成功，要么失败。这意味着若是一个更新失败，则不会有客户端会看到这个更新的结果。

单一系统映像：一个客户端不管链接到哪一台服务器，它看到的都是一样的系统视图。这意味着，若是一个客户端在同一个会话中链接到一台新的服务器，它所看到的系统状态不会比 在以前服务器上所看到的更老。当一台服务器出现故障，致使它的一个客户端须要尝试链接集合体中其余的服务器时，全部滞后于故障服务器的服务器都不会接受该 链接请求，除非这些服务器遇上故障服务器。

持久性：一个更新一旦成功，其结果就会持久存在而且不会被撤销。这代表更新不会受到服务器故障的影响。

实时性：在特定的一段时间内，客户端看到的系统须要被保证是实时的（在十几秒的时间里）。在此时间段内，任何系统的改变将被客户端看到，或者被客户端侦测到。

4、用CAP理论来分析ZooKeeper

CAP理论告诉咱们，一个分布式系统不可能同时知足如下三种

• 一致性（C:Consistency）
• 可用性（A:Available）
• 分区容错性（P:Partition Tolerance）

这三个基本需求，最多只能同时知足其中的两项，由于P是必须的,所以每每选择就在CP或者AP中。

在此ZooKeeper保证的是CP

分析：可用性（A:Available）

不能保证每次服务请求的可用性。任什么时候刻对ZooKeeper的访问请求能获得一致的数据结果，同时系统对网络分割具有容错性；可是它不能保证每次服务请求的可用性（注：也就是在极端环境下，ZooKeeper可能会丢弃一些请求，消费者程序须要从新请求才能得到结果）。因此说，ZooKeeper不能保证服务可用性。

进行leader选举时集群都是不可用。在使用ZooKeeper获取服务列表时，当master节点由于网络故障与其余节点失去联系时，剩余节点会从新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就致使在选举期间注册服务瘫痪，虽然服务可以最终恢复，可是漫长的选举时间致使的注册长期不可用是不能容忍的。因此说，ZooKeeper不能保证服务可用性。

参考：http://www.javashuo.com/article/p-edywrnfp-da.html

参考：https://blog.csdn.net/xiangxizhishi/article/details/78469027

Contact

• 做者：鹏磊
• 出处：http://www.ymq.io/2018/05/18/zookeeper
• 版权归做者全部，转载请注明出处
• Wechat：关注公众号，搜云库，专一于开发技术的研究与知识分享