ZooKeeper和CAP理论及一致性原则

朴灿烈づ我的快乐病毒、 2022-05-24 02:16 128阅读 0赞

# ZooKeeper和CAP理论及一致性原则 #

# 一、CAP理论概述 #

CAP理论告诉我们，一个分布式系统不可能同时满足以下三种

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

这三个基本需求，最多只能同时满足其中的两项，**因为P是必须的,因此往往选择就在CP或者AP中**。

\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NS5yD5JX-1584607472252)(http://www.ymq.io/images/2018/ZooKeeper/1.png)\]

## 一致性（C:Consistency） ##

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

## 可用性（A:Available） ##

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

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

## 分区容错性（P:Partition Tolerance） ##

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

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

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

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

# 二、一致性的分类 #

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

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

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

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

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

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

# 三、ZooKeeper提供的一致性服务 #

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

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

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

**单一系统映像**：**一个客户端无论连接到哪一台服务器，它看到的都是同样的系统视图**。这意味着，如果一个客户端在同一个会话中连接到一台新的服务器，它所看到的系统状态不会比 在之前服务器上所看到的更老。当一台服务器出现故障，导致它的一个客户端需要尝试连接集合体中其他的服务器时，所有滞后于故障服务器的服务器都不会接受该 连接请求，除非这些服务器赶上故障服务器。

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

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

# 四、用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不能保证服务可用性。

参考：[https://www.cnblogs.com/xrq730/p/4944768.html][https_www.cnblogs.com_xrq730_p_4944768.html]

参考：[https://blog.csdn.net/xiangxizhishi/article/details/78469027][https_blog.csdn.net_xiangxizhishi_article_details_78469027]

# Contact #

*  作者：鹏磊
 *  出处：[http://www.ymq.io/2018/05/18/zookeeper][http_www.ymq.io_2018_05_18_zookeeper]
 *  版权归作者所有，转载请注明出处
 *  Wechat：关注公众号，搜云库，专注于开发技术的研究与知识分享

\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-4K7uXhVU-1584607472253)(http://www.ymq.io/images/souyunku.png “搜云库”)\]

[https_www.cnblogs.com_xrq730_p_4944768.html]: https://www.cnblogs.com/xrq730/p/4944768.html
[https_blog.csdn.net_xiangxizhishi_article_details_78469027]: https://blog.csdn.net/xiangxizhishi/article/details/78469027
[http_www.ymq.io_2018_05_18_zookeeper]: http://www.ymq.io/2018/05/18/zookeeper