From bfd6faa26d08caecb6dfd15db58b77699a0a63bd Mon Sep 17 00:00:00 2001 From: VinterHe Date: Thu, 15 Jul 2021 17:17:07 +0800 Subject: [PATCH 1/6] =?UTF-8?q?=E5=A2=9E=E5=8A=A0zookeeper=E9=80=89?= =?UTF-8?q?=E4=B8=BE=E7=9A=84=E8=BF=87=E5=8D=8A=E6=9C=BA=E5=88=B6=E9=98=B2?= =?UTF-8?q?=E6=AD=A2=E8=84=91=E8=A3=82=E7=9A=84=E6=8F=8F=E8=BF=B0?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../distributed-system/zookeeper/zookeeper-intro.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/docs/system-design/distributed-system/zookeeper/zookeeper-intro.md b/docs/system-design/distributed-system/zookeeper/zookeeper-intro.md index 4978fb1a979..8c6d9645408 100644 --- a/docs/system-design/distributed-system/zookeeper/zookeeper-intro.md +++ b/docs/system-design/distributed-system/zookeeper/zookeeper-intro.md @@ -265,6 +265,11 @@ ZooKeeper 集群在宕掉几个 ZooKeeper 服务器之后，如果剩下的 ZooK 综上，何必增加那一个不必要的 ZooKeeper 呢？ +### 4.4. ZooKeeper 选举的过半机制防止脑裂 +另外过半机制也可以防止脑裂情况的发生。 + +脑裂：对于一个集群，想要提高这个集群的可用性，通常会采用多机房部署，比如现在有一个由6台服务器所组成的一个集群，部署在了两个机房，每个机房三台。正常情况下只有一个leader，但是当两个机房中间网络断开的时候，每个机房的三台服务器都会认为另一个机房的三台服务器下线，而选出自己的leader并对外提供服务。若没有过半机制，当网络恢复的时候会发现有两个leader。仿佛是一个大脑（leader）分散成了两个大脑，这就发生了脑裂现象。因为脑裂期间两个大脑都对外提供了服务，这将会带来数据一致性等问题。 + ## 5. ZAB 协议和Paxos 算法 Paxos 算法应该可以说是 ZooKeeper 的灵魂了。但是，ZooKeeper 并没有完全采用 Paxos算法 ，而是使用 ZAB 协议作为其保证数据一致性的核心算法。另外，在ZooKeeper的官方文档中也指出，ZAB协议并不像 Paxos 算法那样，是一种通用的分布式一致性算法，它是一种特别为Zookeeper设计的崩溃可恢复的原子消息广播算法。 @@ -296,4 +301,4 @@ ZAB 协议包括两种基本的模式，分别是 ## 7. 参考 -1. 《从 Paxos 到 ZooKeeper 分布式一致性原理与实践》 \ No newline at end of file +1. 《从 Paxos 到 ZooKeeper 分布式一致性原理与实践》 From cf5193ca5e5e74d0cfe30f5931556d4c780371c9 Mon Sep 17 00:00:00 2001 From: fengxiao <1063371248@qq.com> Date: Sun, 18 Jul 2021 13:38:44 +0800 Subject: [PATCH 2/6] =?UTF-8?q?=E9=94=99=E5=88=AB=E5=AD=97=E4=BF=AE?= =?UTF-8?q?=E6=94=B9?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...\256\241\347\256\227\346\234\272\347\275\221\347\273\234.md" | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git "a/docs/network/\350\256\241\347\256\227\346\234\272\347\275\221\347\273\234.md" "b/docs/network/\350\256\241\347\256\227\346\234\272\347\275\221\347\273\234.md" index 07028ccfa44..5b593a72cfc 100644 --- "a/docs/network/\350\256\241\347\256\227\346\234\272\347\275\221\347\273\234.md" +++ "b/docs/network/\350\256\241\347\256\227\346\234\272\347\275\221\347\273\234.md" @@ -113,7 +113,7 @@ ## 三 TCP,UDP 协议的区别 ![TCP、UDP协议的区别](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/tcp-vs-udp.jpg) -UDP 在传送数据之前不需要先建立连接，远地主机在收到 UDP 报文后，不需要给出任何确认。虽然 UDP 不提供可靠交付，但在某些情况下 UDP 确是一种最有效的工作方式（一般用于即时通信），比如： QQ 语音、 QQ 视频 、直播等等 +UDP 在传送数据之前不需要先建立连接，远地主机在收到 UDP 报文后，不需要给出任何确认。虽然 UDP 不提供可靠交付，但在某些情况下 UDP 却是一种最有效的工作方式（一般用于即时通信），比如： QQ 语音、 QQ 视频 、直播等等 TCP 提供面向连接的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接。 TCP 不提供广播或多播服务。由于 TCP 要提供可靠的，面向连接的传输服务（TCP的可靠体现在TCP在传递数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制，在数据传完后，还会断开连接用来节约系统资源），这一难以避免增加了许多开销，如确认，流量控制，计时器以及连接管理等。这不仅使协议数据单元的首部增大很多，还要占用许多处理机资源。TCP 一般用于文件传输、发送和接收邮件、远程登录等场景。 From edecf8fdd41505752b39585d23fad5412ff97c2b Mon Sep 17 00:00:00 2001 From: VinterHe Date: Sun, 18 Jul 2021 14:53:55 +0800 Subject: [PATCH 3/6] =?UTF-8?q?=E4=BF=AE=E6=94=B9ZooKeeper=20=E9=80=89?= =?UTF-8?q?=E4=B8=BE=E7=9A=84=E8=BF=87=E5=8D=8A=E6=9C=BA=E5=88=B6=E9=98=B2?= =?UTF-8?q?=E6=AD=A2=E8=84=91=E8=A3=82?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../distributed-system/zookeeper/zookeeper-intro.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/docs/system-design/distributed-system/zookeeper/zookeeper-intro.md b/docs/system-design/distributed-system/zookeeper/zookeeper-intro.md index 8c6d9645408..9f52ec182cc 100644 --- a/docs/system-design/distributed-system/zookeeper/zookeeper-intro.md +++ b/docs/system-design/distributed-system/zookeeper/zookeeper-intro.md @@ -266,9 +266,12 @@ ZooKeeper 集群在宕掉几个 ZooKeeper 服务器之后，如果剩下的 ZooK 综上，何必增加那一个不必要的 ZooKeeper 呢？ ### 4.4. ZooKeeper 选举的过半机制防止脑裂 -另外过半机制也可以防止脑裂情况的发生。 -脑裂：对于一个集群，想要提高这个集群的可用性，通常会采用多机房部署，比如现在有一个由6台服务器所组成的一个集群，部署在了两个机房，每个机房三台。正常情况下只有一个leader，但是当两个机房中间网络断开的时候，每个机房的三台服务器都会认为另一个机房的三台服务器下线，而选出自己的leader并对外提供服务。若没有过半机制，当网络恢复的时候会发现有两个leader。仿佛是一个大脑（leader）分散成了两个大脑，这就发生了脑裂现象。因为脑裂期间两个大脑都对外提供了服务，这将会带来数据一致性等问题。 +集群脑裂：对于一个集群，通常多台机器会部署在不同机房，来提高这个集群的可用性。保证可用性的同时，会发生一种机房间网络线路故障，导致机房间网络不通，而集群被割裂成几个小集群。这时候子集群各自选主导致“脑裂”的情况。 + +举例说明：比如现在有一个由6台服务器所组成的一个集群，部署在了两个机房，每个机房三台。正常情况下只有一个leader，但是当两个机房中间网络断开的时候，每个机房的三台服务器都会认为另一个机房的三台服务器下线，而选出自己的leader并对外提供服务。若没有过半机制，当网络恢复的时候会发现有两个leader。仿佛是一个大脑（leader）分散成了两个大脑，这就发生了脑裂现象。因为脑裂期间两个大脑都可能对外提供了服务，这将会带来数据一致性等问题。 + +过半机制防止脑裂：ZooKeeper的过半机制导致不可能产生两个leader，因为少于等于一半是不可能产生leader的，这就使得不论机房的机器如何分配都不可能发生脑裂。 ## 5. ZAB 协议和Paxos 算法 From 473d7200a1ae6607296697ffedf833162eac8fc8 Mon Sep 17 00:00:00 2001 From: wulnm Date: Mon, 19 Jul 2021 13:25:02 +0800 Subject: [PATCH 4/6] =?UTF-8?q?=E5=A2=9E=E5=8A=A0HashSet=E6=96=B0=E5=A2=9E?= =?UTF-8?q?=E5=85=83=E7=B4=A0=E6=96=B9=E6=B3=95=E7=9A=84=E6=8F=8F=E8=BF=B0?= =?UTF-8?q?&typo?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...01\351\235\242\350\257\225\351\242\230.md" | 23 ++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git "a/docs/java/collection/Java\351\233\206\345\220\210\346\241\206\346\236\266\345\270\270\350\247\201\351\235\242\350\257\225\351\242\230.md" "b/docs/java/collection/Java\351\233\206\345\220\210\346\241\206\346\236\266\345\270\270\350\247\201\351\235\242\350\257\225\351\242\230.md" index 2db5c4b13c9..5c0c5b389d7 100644 --- "a/docs/java/collection/Java\351\233\206\345\220\210\346\241\206\346\236\266\345\270\270\350\247\201\351\235\242\350\257\225\351\242\230.md" +++ "b/docs/java/collection/Java\351\233\206\345\220\210\346\241\206\346\236\266\345\270\270\350\247\201\351\235\242\350\257\225\351\242\230.md" @@ -432,10 +432,31 @@ TreeMap treeMap = new TreeMap<>((person1, person2) -> { ### 1.4.4. HashSet 如何检查重复 -以下内容摘自我的 Java 启蒙书《Head fist java》第二版： +以下内容摘自我的 Java 启蒙书《Head first java》第二版： 当你把对象加入`HashSet`时，`HashSet` 会先计算对象的`hashcode`值来判断对象加入的位置，同时也会与其他加入的对象的 `hashcode` 值作比较，如果没有相符的 `hashcode`，`HashSet` 会假设对象没有重复出现。但是如果发现有相同 `hashcode` 值的对象，这时会调用`equals()`方法来检查 `hashcode` 相等的对象是否真的相同。如果两者相同，`HashSet` 就不会让加入操作成功。 +在openjdk8中，`HashSet`的`add()`方法只是简单的调用了`HashMap`的`put()`方法，并且判断了一下返回值以确保是否有重复元素。直接看一下`HashSet`中的源码： +```java +// Returns: true if this set did not already contain the specified element +// 返回值：当set中没有包含add的元素时返回真 +public boolean add(E e) { + return map.put(e, PRESENT)==null; +} +``` + +而在`HashMap`的`putVal()`方法中也能看到如下说明： +```java +// Returns : previous value, or null if none +// 返回值：如果插入位置没有元素返回null，否则返回上一个元素 +final V putVal(int hash, K key, V value, boolean onlyIfAbsent, + boolean evict) { +... +} +``` + +也就是说，在openjdk8中，实际上无论`HashSet`中是否已经存在了某元素，`HashSet`都会直接插入，只是会在`add()`方法的返回值处告诉我们插入前是否存在相同元素。 + **`hashCode()`与 `equals()` 的相关规定：** 1. 如果两个对象相等，则 `hashcode` 一定也是相同的 From 66dd9aa1c2e7478067801ec5a336cdbd68477f58 Mon Sep 17 00:00:00 2001 From: guide Date: Wed, 21 Jul 2021 09:34:39 +0800 Subject: [PATCH 5/6] =?UTF-8?q?zookeeper=20=E8=84=91=E8=A3=82=E7=8E=B0?= =?UTF-8?q?=E8=B1=A1=E6=8F=8F=E8=BF=B0=E5=AE=8C=E5=96=84?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../zookeeper/zookeeper-intro.md | 37 ++++++++++--------- 1 file changed, 20 insertions(+), 17 deletions(-) diff --git a/docs/system-design/distributed-system/zookeeper/zookeeper-intro.md b/docs/system-design/distributed-system/zookeeper/zookeeper-intro.md index 715a870ed3e..8178d303a48 100644 --- a/docs/system-design/distributed-system/zookeeper/zookeeper-intro.md +++ b/docs/system-design/distributed-system/zookeeper/zookeeper-intro.md @@ -1,4 +1,3 @@ - @@ -13,7 +12,7 @@ - [3. ZooKeeper 重要概念解读](#3-zookeeper-重要概念解读) - [3.1. Data model（数据模型）](#31-data-model数据模型) - [3.2. znode（数据节点）](#32-znode数据节点) - - [3.2.1. znode 4种类型](#321-znode-4种类型) + - [3.2.1. znode 4 种类型](#321-znode-4种类型) - [3.2.2. znode 数据结构](#322-znode-数据结构) - [3.3. 版本（version）](#33-版本version) - [3.4. ACL（权限控制）](#34-acl权限控制) @@ -23,7 +22,7 @@ - [4.1. ZooKeeper 集群角色](#41-zookeeper-集群角色) - [4.2. ZooKeeper 集群中的服务器状态](#42-zookeeper-集群中的服务器状态) - [4.3. ZooKeeper 集群为啥最好奇数台？](#43-zookeeper-集群为啥最好奇数台) -- [5. ZAB 协议和Paxos 算法](#5-zab-协议和paxos-算法) +- [5. ZAB 协议和 Paxos 算法](#5-zab-协议和paxos-算法) - [5.1. ZAB 协议介绍](#51-zab-协议介绍) - [5.2. ZAB 协议两种基本的模式：崩溃恢复和消息广播](#52-zab-协议两种基本的模式崩溃恢复和消息广播) - [6. 总结](#6-总结) @@ -31,7 +30,6 @@ - ## 1. 前言 相信大家对 ZooKeeper 应该不算陌生。但是你真的了解 ZooKeeper 到底有啥用不？如果别人/面试官让你给他讲讲对于 ZooKeeper 的认识，你能回答到什么地步呢？ @@ -50,7 +48,7 @@ 另外，本文不光会涉及到 ZooKeeper 的一些概念，后面的文章会介绍到 ZooKeeper 常见命令的使用以及使用 Apache Curator 作为 ZooKeeper 的客户端。 -*如果文章有任何需要改善和完善的地方，欢迎在评论区指出，共同进步！* +_如果文章有任何需要改善和完善的地方，欢迎在评论区指出，共同进步！_ ## 2. ZooKeeper 介绍 @@ -117,7 +115,7 @@ ZooKeeper 数据模型采用层次化的多叉树形结构，每个节点上都 介绍了 ZooKeeper 树形数据模型之后，我们知道每个数据节点在 ZooKeeper 中被称为 **znode**，它是 ZooKeeper 中数据的最小单元。你要存放的数据就放在上面，是你使用 ZooKeeper 过程中经常需要接触到的一个概念。 -#### 3.2.1. znode 4种类型 +#### 3.2.1. znode 4 种类型 我们通常是将 znode 分为 4 大类： @@ -260,6 +258,7 @@ ZooKeeper 集群中的所有机器通过一个 **Leader 选举过程** 来选定 ### 4.3. ZooKeeper 集群为啥最好奇数台？ ZooKeeper 集群在宕掉几个 ZooKeeper 服务器之后，如果剩下的 ZooKeeper 服务器个数大于宕掉的个数的话整个 ZooKeeper 才依然可用。假如我们的集群中有 n 台 ZooKeeper 服务器，那么也就是剩下的服务数必须大于 n/2。先说一下结论，2n 和 2n-1 的容忍度是一样的，都是 n-1，大家可以先自己仔细想一想，这应该是一个很简单的数学问题了。 + 比如假如我们有 3 台，那么最大允许宕掉 1 台 ZooKeeper 服务器，如果我们有 4 台的的时候也同样只允许宕掉 1 台。 假如我们有 5 台，那么最大允许宕掉 2 台 ZooKeeper 服务器，如果我们有 6 台的的时候也同样只允许宕掉 2 台。 @@ -267,15 +266,19 @@ ZooKeeper 集群在宕掉几个 ZooKeeper 服务器之后，如果剩下的 ZooK ### 4.4. ZooKeeper 选举的过半机制防止脑裂 -集群脑裂：对于一个集群，通常多台机器会部署在不同机房，来提高这个集群的可用性。保证可用性的同时，会发生一种机房间网络线路故障，导致机房间网络不通，而集群被割裂成几个小集群。这时候子集群各自选主导致“脑裂”的情况。 +**何为集群脑裂？** + +对于一个集群，通常多台机器会部署在不同机房，来提高这个集群的可用性。保证可用性的同时，会发生一种机房间网络线路故障，导致机房间网络不通，而集群被割裂成几个小集群。这时候子集群各自选主导致“脑裂”的情况。 + +举例说明：比如现在有一个由 6 台服务器所组成的一个集群，部署在了 2 个机房，每个机房 3 台。正常情况下只有 1 个 leader，但是当两个机房中间网络断开的时候，每个机房的 3 台服务器都会认为另一个机房的 3 台服务器下线，而选出自己的 leader 并对外提供服务。若没有过半机制，当网络恢复的时候会发现有 2 个 leader。仿佛是 1 个大脑（leader）分散成了 2 个大脑，这就发生了脑裂现象。脑裂期间 2 个大脑都可能对外提供了服务，这将会带来数据一致性等问题。 -举例说明：比如现在有一个由6台服务器所组成的一个集群，部署在了两个机房，每个机房三台。正常情况下只有一个leader，但是当两个机房中间网络断开的时候，每个机房的三台服务器都会认为另一个机房的三台服务器下线，而选出自己的leader并对外提供服务。若没有过半机制，当网络恢复的时候会发现有两个leader。仿佛是一个大脑（leader）分散成了两个大脑，这就发生了脑裂现象。因为脑裂期间两个大脑都可能对外提供了服务，这将会带来数据一致性等问题。 +**过半机制是如何防止脑裂现象产生的？** -过半机制防止脑裂：ZooKeeper的过半机制导致不可能产生两个leader，因为少于等于一半是不可能产生leader的，这就使得不论机房的机器如何分配都不可能发生脑裂。 +ZooKeeper 的过半机制导致不可能产生 2 个 leader，因为少于等于一半是不可能产生 leader 的，这就使得不论机房的机器如何分配都不可能发生脑裂。 -## 5. ZAB 协议和Paxos 算法 +## 5. ZAB 协议和 Paxos 算法 -Paxos 算法应该可以说是 ZooKeeper 的灵魂了。但是，ZooKeeper 并没有完全采用 Paxos算法 ，而是使用 ZAB 协议作为其保证数据一致性的核心算法。另外，在ZooKeeper的官方文档中也指出，ZAB协议并不像 Paxos 算法那样，是一种通用的分布式一致性算法，它是一种特别为Zookeeper设计的崩溃可恢复的原子消息广播算法。 +Paxos 算法应该可以说是 ZooKeeper 的灵魂了。但是，ZooKeeper 并没有完全采用 Paxos 算法 ，而是使用 ZAB 协议作为其保证数据一致性的核心算法。另外，在 ZooKeeper 的官方文档中也指出，ZAB 协议并不像 Paxos 算法那样，是一种通用的分布式一致性算法，它是一种特别为 Zookeeper 设计的崩溃可恢复的原子消息广播算法。 ### 5.1. ZAB 协议介绍 @@ -283,15 +286,15 @@ ZAB（ZooKeeper Atomic Broadcast 原子广播） 协议是为分布式协调服 ### 5.2. ZAB 协议两种基本的模式：崩溃恢复和消息广播 -ZAB 协议包括两种基本的模式，分别是 +ZAB 协议包括两种基本的模式，分别是 -- **崩溃恢复** ：当整个服务框架在启动过程中，或是当 Leader 服务器出现网络中断、崩溃退出与重启等异常情况时，ZAB 协议就会进入恢复模式并选举产生新的Leader服务器。当选举产生了新的 Leader 服务器，同时集群中已经有过半的机器与该Leader服务器完成了状态同步之后，ZAB协议就会退出恢复模式。其中，**所谓的状态同步是指数据同步，用来保证集群中存在过半的机器能够和Leader服务器的数据状态保持一致**。 -- **消息广播** ：**当集群中已经有过半的Follower服务器完成了和Leader服务器的状态同步，那么整个服务框架就可以进入消息广播模式了。** 当一台同样遵守ZAB协议的服务器启动后加入到集群中时，如果此时集群中已经存在一个Leader服务器在负责进行消息广播，那么新加入的服务器就会自觉地进入数据恢复模式：找到Leader所在的服务器，并与其进行数据同步，然后一起参与到消息广播流程中去。 +- **崩溃恢复** ：当整个服务框架在启动过程中，或是当 Leader 服务器出现网络中断、崩溃退出与重启等异常情况时，ZAB 协议就会进入恢复模式并选举产生新的 Leader 服务器。当选举产生了新的 Leader 服务器，同时集群中已经有过半的机器与该 Leader 服务器完成了状态同步之后，ZAB 协议就会退出恢复模式。其中，**所谓的状态同步是指数据同步，用来保证集群中存在过半的机器能够和 Leader 服务器的数据状态保持一致**。 +- **消息广播** ：**当集群中已经有过半的 Follower 服务器完成了和 Leader 服务器的状态同步，那么整个服务框架就可以进入消息广播模式了。** 当一台同样遵守 ZAB 协议的服务器启动后加入到集群中时，如果此时集群中已经存在一个 Leader 服务器在负责进行消息广播，那么新加入的服务器就会自觉地进入数据恢复模式：找到 Leader 所在的服务器，并与其进行数据同步，然后一起参与到消息广播流程中去。 -关于 **ZAB 协议&Paxos算法** 需要讲和理解的东西太多了，具体可以看下面这两篇文章： +关于 **ZAB 协议&Paxos 算法** 需要讲和理解的东西太多了，具体可以看下面这两篇文章： -- [图解 Paxos 一致性协议](http://codemacro.com/2014/10/15/explain-poxos/) -- [Zookeeper ZAB 协议分析](https://dbaplus.cn/news-141-1875-1.html) +- [图解 Paxos 一致性协议](http://codemacro.com/2014/10/15/explain-poxos/) +- [Zookeeper ZAB 协议分析](https://dbaplus.cn/news-141-1875-1.html) ## 6. 总结 From 4c8d1a38e8dece567ee80702ef34b7633907d3ae Mon Sep 17 00:00:00 2001 From: callmePicacho <38685653+callmePicacho@users.noreply.github.com> Date: Thu, 22 Jul 2021 14:51:23 +0800 Subject: [PATCH 6/6] =?UTF-8?q?Update=20CAP=E7=90=86=E8=AE=BA.md?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit fix typo --- .../distributed-system/CAP\347\220\206\350\256\272.md" | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git "a/docs/system-design/distributed-system/CAP\347\220\206\350\256\272.md" "b/docs/system-design/distributed-system/CAP\347\220\206\350\256\272.md" index d12ffaa17f9..1a0383577a6 100644 --- "a/docs/system-design/distributed-system/CAP\347\220\206\350\256\272.md" +++ "b/docs/system-design/distributed-system/CAP\347\220\206\350\256\272.md" @@ -26,7 +26,7 @@ CAP 理论的提出者布鲁尔在提出 CAP 猜想的时候，并没有详细 因此，对于 CAP 的民间解读有很多，一般比较被大家推荐的是下面 👇 这种版本的解。 -在理论计算机科学中，CAP 定理（CAP theorem）指出对于一个分布式系统来说，当设计读写操作时，只能能同时满足以下三点中的两个： +在理论计算机科学中，CAP 定理（CAP theorem）指出对于一个分布式系统来说，当设计读写操作时，只能同时满足以下三点中的两个： - **一致性（Consistence）** : 所有节点访问同一份最新的数据副本 - **可用性（Availability）**: 非故障的节点在合理的时间内返回合理的响应（不是错误或者超时的响应）。 @@ -84,4 +84,4 @@ CAP 理论的提出者布鲁尔在提出 CAP 猜想的时候，并没有详细 1. [CAP 定理简化](https://medium.com/@ravindraprasad/cap-theorem-simplified-28499a67eab4) （英文，有趣的案例） 2. [神一样的 CAP 理论被应用在何方](https://juejin.im/post/6844903936718012430) （中文，列举了很多实际的例子） -3. [请停止呼叫数据库 CP 或 AP ](https://martin.kleppmann.com/2015/05/11/please-stop-calling-databases-cp-or-ap.html) （英文，带给你不一样的思考） \ No newline at end of file +3. [请停止呼叫数据库 CP 或 AP ](https://martin.kleppmann.com/2015/05/11/please-stop-calling-databases-cp-or-ap.html) （英文，带给你不一样的思考）