分布式系统的共同知识: 正确理解CAP定理

前言

我已经阅读了很多有关CAP的书籍，并阅读了许多同事的博客文章. 基本上每个人对它的理解都不同，但是布鲁尔教授必须过于简单地定义它，而没有特定的描述和场景. 分析. 因此，我根据一些资料整理出一篇文章，并与您分享.

标题正确书写. 也许有些观点不是100％正确或模棱两可的，但我希望与您分享讨论以达成最终正确性.

简介

CAP定理，也称为布鲁尔定理，是埃里克·布鲁尔教授在2000年提出的一个猜想，指出对于分布式系统，不可能满足以下三点:

Consistency（一致性）: 所有节点在同一时间看到相同的数据. （所有节点同时具有相同的数据）

可用性（availability）: 它保证每个请求都收到有关成功还是失败的响应. （保证无论成功与否，每个请求都会响应）

分区容限: 即使系统的任何一部分丢失或出现故障分布式系统理解，系统也可以继续运行. （系统中任何信息的丢失或故障都不会影响系统的继续运行）

许多书籍和文章都引用了Robert Greiner在2014年8月写的博客文章. 与研究Brewer教授的残酷定义相比，Robert Greiner的定义更容易理解.

定义

原始: 在分布式系统（共享数据的互连节点的集合）中，在写/读对中，您只能获得以下三个保证中的两个: 一致性，可用性和分区容差-其中之一必须牺牲.

转换: 在分布式系统（相互连接并共享数据的节点的集合）中，当涉及到读写操作时，它只能保证一致性，可用性和分区容差容差）三种中的两种，另一个必须牺牲.

关键字: 互连节点（连接节点），共享数据（共享数据），写/读对（读/写）

从上一段来看，有几个，也就是说，当我们谈论CAP定理时，在进行数据读写，数据共享和节点互连的前提下，选择以上两个，建议不要花时间和精力来满足这三个方面.

例如，Web群集和Memcached群集不是讨论的主题

Web群集仅用于在不同节点上进行资源复制和分发，但是节点之间没有互连或数据共享（会话ID，内存缓存）.

Memcached群集数据存储通过客户端实现哈希一致性，但是群集节点没有互连，也没有数据共享.

通常，CAP定理不会讨论分布式系统的所有功能.

一致性（一致性）

原始的: 保证读取会返回给定客户端的最新写入.

翻译: 对于特定的客户端，保证读取操作返回最新的写入操作结果

关键字: 给定的客户.

此处的一致性与我们通常对ACID的了解有所不同. ACID的一致性与的数据完整性有关.

以上定义并不表示所有节点必须同时具有相同的数据，并且重点放在客户端上. 如果出现这种情况，您需要在自动柜员机（客户）的银行卡中存入500元，然后立即在自动柜员机上启动. 查看余额时，会显示添加后的500元余额，然后我们也可以取出500元. 查询余额读取操作可以是写入后立即读取的主库，也可以是写入后一定时间（中途不写入）后读取从库.

可用性（Availability）

原始: 非故障节点将在合理的时间内（无错误或超时）返回合理的响应.

转换: 非故障节点将在合理的时间内返回合理的响应（不是错误或超时）.

关键字: 非故障节点，非故障节点，合理的响应

此处的可用性与我们通常认为的高可用性略有不同. 高可用性是指系统执行其功能而不中断的能力.

失败的节点不再可用，因为请求结果是错误或超时. 合理的答复并不表示它是成功还是失败，但是答复应准确说明其是否成功. 例如，如果我们读取sql服务器群集的从，则同步将花费一些时间. 读取的数据可能不是最新数据，但这是合理的响应.

分区容限（分区容限）

原始: 发生网络分区时，系统将继续运行.

翻译: 发生网络分区时，系统将继续正常运行

关键字: 继续运行（继续正常运行）

如果您创建一个redis单主从机集群，则有一个从机节点由于一天的网络故障而变得不可用，但是另一个单主从机集群仍然可以正常工作，那么我们认为这是分区宽容的.

CA-牺牲分区容错

作为分布式系统，总是会进行分区（每2年50分钟，或者每年3分钟，共10分钟？），因此CAP的讨论主要基于P的建立. 假设我们牺牲了P这是因为发生了网络故障，并且该分区变得不可用. 此时，请求以错误和超时响应，这与可用性的定义相冲突.

但是，如果分区在大多数时间都不存在，则对单个节点进行读/写操作，则无需在C和A之间做出选择. 但是上面说分区总是会发生. 这不是彼此矛盾吗？如果一年内99.99％的时间是正常的，并且不可用时间是0.01％（52.56分钟）不可用，则该时间在业务接受范围之内，或仅影响某个地区（华南，华北，中部）中国？），那么CA也是可选的.

牺牲PC可用性

最典型的情况是RDBMS集群和Redis集群，它们都使用主从复制来实现读写分离. 如果两者均建立主从集群，则在主节点上写入数据分布式系统理解，以确保后续的读取操作获得最新数据（一致性），此读取操作仍将请求主节点（读取和写入的复杂性）分离是在不同步的从属中导致业务异常的. 为了确保业务的正常性，写入后的读操作将请求主库），一个从属节点被挂起，但是只要主节点和其他从属节点仍然存在正常运行，可以满足分区容错要求. 但是有一天，由于网络故障，主节点的写操作错误或超时，则该系统不可用（牺牲了可用性）.

这时，可以引入其他功能和机制，例如Redis哨兵模式和故障转移功能.

PA牺牲的一致性

最典型的情况是Cassanda群集和Riak群集. 这种类型的分布式可以由任何节点写入，也可以由任何节点读取. 当它显示为群集时，无论写入哪个节点，该节点都将成为数据同步到其他节点. 由于采用了这种同步方法，因此在读取数据时访问一个节点就足够了（就像任意访问不会阻止您），但是由于其他节点的数据同步，数据可能不是最新的（牺牲一致性）. 如果当前节点由于网络异常而变得不可用（无论读\写），您都可以传输访问节点（可用性）.

此外，此处牺牲一致性并不意味着放弃一致性，并且PA选择最终的一致性（经过一段时间的同步，系统中的所有数据副本最终将达到一致状态）

摘要

上面提到的“牺牲”一词并不意味着选择其中一个. 可以根据设计在子系统和模块（例如PA和PC，CA和PC）之间混合使用.

本文对CAP定理进行了简单的组合描述. 我指的是一些书籍和文章以及我的理解. 希望与您分享. 如果您有不同的建议和看法，包括文章中的描述错误，请在下面评论，指出我会及时进行更改.

作者: 陈恭

来源:

关于作者: 项目开发侧重于Microsoft平台. 如有任何疑问或建议，请赐教！

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/jisuanjixue/article-211731-1.html