From 966facaf8412b14f7d3e072e1e8a0d1af8801975 Mon Sep 17 00:00:00 2001 From: guide Date: Fri, 28 May 2021 08:22:32 +0800 Subject: [PATCH 1/2] =?UTF-8?q?=E5=AE=8C=E5=96=84=20CAP=20=E7=90=86?= =?UTF-8?q?=E8=AE=BA?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../distributed-system/CAP\347\220\206\350\256\272.md" | 8 ++++---- 1 file changed, 4 insertions(+), 4 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 045581b916a..d12ffaa17f9 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" @@ -46,13 +46,13 @@ CAP 理论的提出者布鲁尔在提出 CAP 猜想的时候，并没有详细 > > 简而言之就是：CAP 理论中分区容错性 P 是一定要满足的，在此基础上，只能满足可用性 A 或者一致性 C。 -因此，**分布式系统理论上不可能选择 CA 架构，只能选择 CP 或者 AP 架构。** +因此，**分布式系统理论上不可能选择 CA 架构，只能选择 CP 或者 AP 架构。** 比如 ZooKeeper、HBase 就是 CP 架构，Cassandra、Eureka 就是 AP 架构，Nacos 不仅支持 CP 架构也支持 AP 架构。 -**为啥无同时保证 CA 呢？** +**为啥不可能选择 CA 架构呢？** 举个例子：若系统出现“分区”，系统中的某个节点在进行写操作。为了保证 C， 必须要禁止其他节点的读写操作，这就和 A 发生冲突了。如果为了保证 A，其他节点的读写操作正常的话，那就和 C 发生冲突了。 -举个例子：若系统出现“分区”，系统中的某个节点在进行写操作。为了保证 C， 必须要禁止其他节点的读写操作，这就和 A 发生冲突了。如果为了保证 A，其他节点的读写操作正常的话，那就和 C 发生冲突了。 +**选择 CP 还是 AP 的关键在于当前的业务场景，没有定论，比如对于需要确保强一致性的场景如银行一般会选择保证 CP 。** -**选择的关键在于当前的业务场景，没有定论，比如对于需要确保强一致性的场景如银行一般会选择保证 CP 。** +另外，需要补充说明的一点是： **如果网络分区正常的话（系统在绝大部分时候所处的状态），也就说不需要保证 P 的时候，C 和 A 能够同时保证。** ### CAP 实际应用案例 From ae8a771476d3e35b9dffb83218ecfe65d9cd417a Mon Sep 17 00:00:00 2001 From: guide Date: Fri, 28 May 2021 08:53:47 +0800 Subject: [PATCH 2/2] =?UTF-8?q?BASE=E7=90=86=E8=AE=BA=EF=BC=9A=E5=AE=9E?= =?UTF-8?q?=E7=8E=B0=E6=9C=80=E7=BB=88=E4=B8=80=E8=87=B4=E6=80=A7=E7=9A=84?= =?UTF-8?q?=E5=85=B7=E4=BD=93=E6=96=B9=E5=BC=8F=E6=98=AF=E4=BB=80=E4=B9=88?= =?UTF-8?q?=E5=91=A2=3F?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../distributed-system/BASE\347\220\206\350\256\272.md" | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git "a/docs/system-design/distributed-system/BASE\347\220\206\350\256\272.md" "b/docs/system-design/distributed-system/BASE\347\220\206\350\256\272.md" index 0a0bd06f58b..17c5789ce28 100644 --- "a/docs/system-design/distributed-system/BASE\347\220\206\350\256\272.md" +++ "b/docs/system-design/distributed-system/BASE\347\220\206\350\256\272.md" @@ -53,6 +53,14 @@ CAP 理论这节我们也说过了： > > **业界比较推崇是最终一致性级别，但是某些对数据一致要求十分严格的场景比如银行转账还是要保证强一致性。** +那实现最终一致性的具体方式是什么呢? [《分布式协议与算法实战》](http://gk.link/a/10rZM) 中是这样介绍： + +> - **读时修复** : 在读取数据时，检测数据的不一致，进行修复。比如 Cassandra 的 Read Repair 实现，具体来说，在向 Cassandra 系统查询数据的时候，如果检测到不同节点 的副本数据不一致，系统就自动修复数据。 +> - **写时修复** : 在写入数据，检测数据的不一致时，进行修复。比如 Cassandra 的 Hinted Handoff 实现。具体来说，Cassandra 集群的节点之间远程写数据的时候，如果写失败 就将数据缓存下来，然后定时重传，修复数据的不一致性。 +> - **异步修复** : 这个是最常用的方式，通过定时对账检测副本数据的一致性，并修复。 + +比较推荐 **写时修复**，这种方式对性能消耗比较低。 + ### 总结 **ACID 是数据库事务完整性的理论，CAP 是分布式系统设计理论，BASE 是 CAP 理论中 AP 方案的延伸。**