关于 CAP 定理 与 BASE 理论的学习与整理（待补充）
CAP理论
CAP 理论/定理 起源于 2000 年，由加州大学伯克利分校的 Eric Brewer 教授在分布式计算原理研讨会（PODC）上提出，因此 CAP 定理又被称作 布鲁尔定理（Brewer’s theorem）。两年后，麻省理工学院的 Seth Gilbert 和 Nancy Lynch 发表了布鲁尔猜想的证明，CAP 理论正式成为分布式领域的定理。
CAP定理是指Consistency（一致）、Availability（可用）、 Partition Tolerance（分区容错）三个基本需求，但是这三个需求最多同时满足其中两个（因为是分布式系统，存在网络分区，所以需要以分区容错为前提）
- 一致性，所有节点在同一时间看到的数据相同。每个节点每次读取操作都可以获得最新写入的数据。这个特性要求数据在所有节点上保持一致，如果有多个节点同时进行修改，那么所有节点都必须保持同步。
- 可用性，系统必须随时可用，无论节点失效或网络故障，系统都要继续运行。这个特性要求系统能够在任何时刻都可以提供服务，但是如果出现故障，可能会导致数据不一致。
- 分区容错性，系统必须能够容忍网络分区之间可能发生通信异常（分布式系统前提），即网络中的某些节点失效或无法通信。这个特性要求系统能够在网络分区时继续运行，但是可能会导致数据不一致。
什么是分区？
大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区（Partition）。分区容错的意思是，每个区之间的网络通信可能出现异常。比如，不同城市都有部署服务器，一个城市就是一个区，它们之间可能发生网络问题，导致无法通信。
P-C-A 三种特性不可兼得，如何取舍？
- C&A: 保证一致性和可用性，放弃分区容错。 意味着放弃系统的扩展性，不做分区要求，系统不再是分布式。
- C&P: 保证 分区容错性 和 一致性，放弃可用性（A）。一旦发生网络故障、消息丢失或系统宕机等问题，牺牲用户体验，等系统恢复。（金融系统、电商系统等）
- A&P: 保证 分区容错性 和 可用性，放弃一致性（C）。为保证 一致性 选择其他的策略（强一致性、弱一致性、最终一致性）。（社交网络、新闻网站等）
在取舍上，应具体系统具体分析，不同业务要求可能不太一样，钱的问题就是一分不能多一分不能少，必须保证一致性。如果网络分区长时间处于正常状态（绝大部分时间），可以忽略 P，C 和 A 是能够同时保证的。
PS: 若系统存在网络分区，还要坚持选择CA会发生什么？例如，系统中的某个节点在进行写操作。为了保证 C，必须要禁止其他节点的读写操作，这就和 A 发生冲突了。如果为了保证 A，其他节点的读写操作正常的话，那就和 C 发生冲突了。
BASE理论
BASE 是Basically Available（基本可用）、Soft state（弱状态）、Eventually consistent（最终一致性）三个短语的简写。是由eBay的架构师Dan Pritchett 在其文章 BASE: An Acid Alternative 中第一次明确提出的。BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于 CAP 定理逐步演化而来的，其核心思想是即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。（《从Paxos到Zookeeper》）
- 基本可用：指分布式系统在出现不可预知故障时，允许损失部分可用性，如响应时间上的损失或功能上的损失。
- 软状态：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。
- 最终一致性：数据不可能一直是软状态，在一个时间期限过后，应当保证所有数据副本能达到一致，也就是达到数据的最终一致性。
分布式一致性的 5 种级别
- 强一致性：系统写入了什么，读出来的就是什么。
- 弱一致性：不一定可以读取到最新写入的值，也不保证多少时间之后读取到的数据是最新的，只是会尽量保证某个时刻达到数据一致的状态。
- 最终一致性：弱一致性的升级版，系统会保证在一定时间内达到数据一致的状态。
- 会话一致性：在同一个客户端会话中可以读到一致的值，其他的会话不保证。
- 用户一致性：同一个用户可以读到一致的值，其他用户不能保证。
比较推崇是最终一致性级别，但是某些对数据一致要求十分严格的场景，比如银行转账还是要保证强一致性。
实现最终一致性的具体方式
读写分离
将读操作和写操作分离，写操作直接更新主数据库，而读操作则从副本数据库中读取数据。由于副本数据库的更新有一定的延迟，因此在写入后立即读取数据可能会出现不一致的情况,但可以保证最终一致性。
版本控制
在更新数据时，每次都生成一个新的版本，并将新版本的数据写入分布式系统的不同节点中。在读取数据时，选择最新的版本进行查询。这种方式可以保证数据的最终一致性。
基于时间戳的冲突检测
在更新数据时，每次都添加一个时间戳，并将新数据写入分布式系统的不同节点中。在读取数据时，选择时间戳最大的数据进行查询。这种方式可以避免数据的冲突，并保证数据的最终一致性。
基于分布式事务的方法
在进行跨节点的事务时，使用分布式事务来保证事务的原子性、一致性、隔离性和持久性。这种方式可以保证数据的强一致性，但是性能相对较低，需要考虑系统的复杂度和可扩展性。
最后，还是要根据 业务场景 和 系统架构 选择合适的最终一致性方案。
总结
ACID 是数据库事务完整性的理论，CAP 是分布式系统设计理论，BASE 是 CAP 理论中 AP 方案的延伸。