大家好，我是小❤，一个漂泊江湖多年的 985 非科班程序员，曾混迹于国企、互联网大厂和创业公司的后台开发攻城狮。
在计算机科学领域，分布式系统是一门极具挑战性的研究方向，也是互联网应用中必不可少的优化实践，而 CAP 理论和 BASE 理论则是分布式系统中的两个关键的概念。
今天，小❤将带大家深入浅出地探讨这些概念，帮助大家更好地理解分布式系统的奥秘。
首先，让我们来谈谈分布式系统。你可以将分布式系统想象成一个庞大的计算机网络，由多个计算机或服务器节点组成，它们可能分布在不同的地理位置上。
图片
如图所示，应用层的三个节点都发布在不同的城市。这些节点之间可以相互通信和协作，共同完成复杂的任务。
想象一下，你是一名团队领导，有一项任务需要完成。如果你独自一人完成，可能需要花费很长时间。
但如果你将任务分解成几个子任务，分派给你的团队成员，他们可以并行工作，更快地完成任务。这就是分布式系统的核心思想。
接下来，让我们谈谈 CAP 理论，它是分布式系统设计中非常重要的一个原则。
CAP 是指在分布式系统中，Consistency（一致性）、Availability（可用性）和 Partition tolerance（分区容错性）这三个基本原则。
一致性意味着无论你从分布式系统的哪个节点读取数据，你都会获得相同的数据副本，它确保了数据的准确性。
在分布式系统中，广泛的一致性分为三种，分别是强一致性、弱一致性和最终一致性。
强一致性要求用户在分布式系统中访问数据时，不管是哪个节点的响应，数据都应该完全一致。
比如在订单系统中球鞋库存还剩 10 双，张三刚买了一双球鞋，数据更新完成后，接下来李四看到的球鞋数量就只有 9 双，否则就可能会出现超卖的情况。
但这需要更多的时间和精力来协调，就像李四在买鞋的时候，必须排队先等张三的购买动作结束后才可以继续，效率较低。
弱一致性是指，在分布式系统中的数据被更新后，也允许让后续的访问拿到更新之前的老数据。
就像参加聚会一样，每个人都有自己的钟表。各自的钟表时间可能会有点不一样，但是这不影响大家聚在一起玩耍。
弱一致性提高了业务的效率，但有时会导致一些混乱，想象一下如果聚会人员的时间差太多，就会陷入长久的等待。
最终一致性是弱一致性的特殊形式，要求系统的数据更新完成，在一段时间以后，后续的所有访问都能拿到最新的数据。
这就像朋友圈的消息传播。当你发了一条消息，它不会立刻被所有朋友看到，但最终，每个人都会看到相同的消息。
一般的业务系统基于性价比的考量，绝大多数都是采用最终一致性作为分布式系统的设计思想。
而 CAP 理论里的一致性，则要求是强一致性。正如官方文档中描述的那样：All nodes see the same data at the same time，所有节点在同一时间内数据完全一致。
可用性意味着分布式系统的每个请求都应该得到响应，而且应该在有限的时间内完成。
可用性确保了系统的稳定性和可靠性，它描述的是系统能够很好地为用户服务，不会出现用户操作失败或者访问超时的情况，影响用户体验。
即官方所说Reads and writes always succeed，服务在正常响应时间内一直可用。
分区容错性是指系统能够在网络分区或通信故障的情况下继续运行，也就是节点之间的网络通信出现故障了，或者系统中的某一个节点出问题了，我们仍然需要保证业务系统可用。
即 The system continues to operate despite arbitrary message loss or failure of part of the system，分布式系统在遇到某个节点或者网络分区故障时，仍然能够对外提供满足一致性或可用性的服务。
这时，有分布式基础的同学可能就会问了，CAP 理论确实很重要，但是这三个特性似乎不能同时满足，是吧？
没错，这就是 CAP 理论的核心观点。
CAP 理论告诉我们，在一个分布式系统中，我们最多只能同时满足其中 2 个特性，而无法同时满足 3 个。
图片
为什么 C，A，P 三者不可兼得？首先，我们得知道，在分布式系统中，由于网络不可靠，为了保证服务可以时刻对外提供服务，所以分区容错性是一定要保证的。
试想如果只有一个分区，谈分布式就没有意义了。而多个分区，一定会有分区的故障问题，分布式系统中保证分区容错就变成最基本的诉求了。
所以现在我们只需考虑在分区容错的基础上，能否同时满足一致性和可用性，我们可以用反证法来证明。
假设现在有两个分区 P1 和 P2，分区上都有同一份数据 D1 和 D2， 现在它们是完全相同的。
图片
接下来，有一个请求 1 访问了 P1，更改了 D1 上的数据。然后又有一个请求 2 访问了 P2，去访问 D2 的同一份数据。
这时，我们需要权衡。
如果先保证满足一致性和分区容错，即 CP。
这个过程很容易出现：D1 已经更新数据，但是查询 D2 时，数据返回的还是老数据。
为了保证 D2 和 D1 数据完全一致，必须在更新 D1 数据时给 P2 上的 D2 数据上锁，等待 D1 更新完成后再同步更新 D2。
这个过程中，锁住的 D2 就没法给请求 2 实时响应，也就是违背了 P2 上的可用性。
所以在满足一致性的前提下，CAP 无法同时满足。
如果先保证满足可用性和分区容错，即 AP。
可用性要求 P1 和 P2 都可以实时响应，因此在 D2 刚更新完还未同步给 D1 时，两个 DB 的数据是不一致的，也就违背了 P1 和 P2 上的数据一致性。
所以在满足可用性的前提下，CAP 亦无法同时满足。
CAP 三者不可兼得，该怎么选择呢？一般根据我们的业务可以有以下选择。
保证分区的强一致性（C），不要求可用（A）。
相当于请求到达某个系统之前，需要等待数据完全同步以后，才会得到系统的数据响应，一般在数据需严格保持一致的金融系统中会使用这种模式。
保证分区的可用性（A），不要求强一致性（C）。
当请求访问某个分区的数据时，可能拿到未同步的老数据，这种模式一般只要求数据满足最终一致性，进而保证系统响应速度和高可用。
AP 在业界使用范围较广，比如著名的 BASE 理论（下文会细讲）。
上文已经说过，分布式系统中无法同时保证系统的强一致性（C）和可用性（A）。
这是因为分布式系统中的分区是客观存在无法避免的，而单体系统中的数据库可以通过事务保证数据的一致性和可用性，比如 MySQL 中事务的四大特性（原子性、一致性、隔离性和持久性，简称 ACID）。
BASE 理论是当今互联网分布式系统的实践总结，它的核心思想在于，既然在分布式系统中实现强一致性的代价太大，那不如退而求其次。
只需要各应用分区在提供高可用服务的基础上，尽最大能力保证数据一致性，也就是保证数据的最终一致性。
BASE 理论是 CAP 中保证分区容错（P）的前提下，对可用性（A）和一致性（C）的权衡，它由 Basically Available（基本可用），Soft State（软状态），Eventually-Consistent（最终一致性）三方面构成，简称 BASE 理论。
分布式系统中，CAP 理论提供了一个理论框架，而 BASE 理论则提供了一种实际操作的指导原则。
BASE 理论认为，分布式系统在面临故障或异常情况时，可以选择降低性能或一致性要求，以保持基本的可用性。
这意味着系统可能会出现一些短暂的不一致性，但最终会达到一致状态。
正如一个银行系统的系统设计，一般有功能需求和非功能需求，我们首先需要保证核心功能需求的基本可用性。
在银行系统里，用户提款、转账等交易模块就是核心功能，是用户的基本需求，不能出问题。
而非核心功能可以出现异常，但需要保证在一段时间内修复。
非功能需求是指用户业务不依赖的其它需求，比如性能相关的：要求用户转账在 0.5 秒内完成，但是由于网络延迟等原因，可以延迟响应至1~2 秒。
由于系统出现此类异常，从而影响了系统的高可用性，但核心流程依然可用，即基本可用性。
软状态是指系统服务可能处于中间状态，数据在保证一致性的过程中可能延迟同步，但不会影响系统的可用性。
比如我们在购买火车票付款结束之后，就可能处在一个既没有完全成功，也没有失败的中间等待状态。用户需要等待系统的数据完全同步以后，才会得到是否购票成功的最终状态。
BASE 理论认识到，在分布式系统中，状态可能会随时间变化而软化，而不是立即达到一致状态。
这意味着我们需要容忍一些状态的不确定性，比如我们在火车票候补排队时是不确定是否可以候补成功的。
最终一致性是 BASE 理论的核心思想。它指出，分布式系统可以在一段时间内保持不一致状态，但最终会收敛到一致状态。
它不像强一致性那样，需要分区数据保证实时一致，导致系统数据的同步代价过高。也不像弱一致性那样，数据更新后不保证数据一致，导致后续的请求只能访问到老数据。
当前业界的分布式系统，甚至关系数据库系统的数据，大都是用最终一致性实现的。比如 MySQL 的主从备份，就是在一段时间内通过 binlog 日志和监听线程让从库和主库的数据保持最终一致。
总的来说，BASE 理论其实就是牺牲了各节点数据的强一致性，允许不同节点的数据在一段时间内不一致，来获得更高的性能和高可用性。
在单体系统中，数据库还能通过 ACID 来实现事务的强一致性，但分布式事务需要考虑节点通信的延迟和网络故障。
所以，BASE 理论是我们在实际的分布式系统中经常使用的方案。
本文链接：http://www.28at.com/showinfo-26-10898-0.html深入浅出：分布式、CAP 和 BASE 理论
声明：本网页内容旨在传播知识，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。邮件：2376512515@qq.com
上一篇： 这种方法可以解决开发中的重复“造轮子”
Copyright © 2016-2023 天津谷骐科技有限公司 版权所有 sitemap.xml
违法及侵权请联系：2376512515@qq.com 津ICP备18001702号
津公网安备 12010102000574号
