BASE 理论
BASE 理论
BASE 理论起源于 2008 年， 由eBay的架构师Dan Pritchett在ACM上发表。
介绍
BASE 是 Basically Available（基本可用）、Soft-state（软状态）和 Eventually Consistent（最终一致性）三个短语的缩写。BASE 理论是对 CAP 中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于 CAP 定理逐步演化而来的，它大大降低了我们对系统的要求。
BASE 理论的核心思想
即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。
也就是牺牲数据的一致性来满足系统的高可用性，系统中一部分数据不可用或者不一致时，仍然要保持系统整体“主要可用”。
BASE 理论本质上是对 CAP 的延申和补充，更具体地说，是对 CAP 中 AP 方案的一个补充。为什么这么说呢？CAP 理论中我们说过：如果系统没有发生“网络分区”的话，节点间的网络连接通信时正常，也就不存在分区容错性。这个时候，我们就需要同时保证一致性和可用性。如果系统发生了“网络分区”，我们就需要考虑选择 CP 还是 AP。因此，AP 方案只是系统在发生“网络分区”的时候放弃一致性，而不是永远放弃一致性。在分区故障恢复之后，系统应该在一点时间内达到最终一致性。这一点其实就是 BASE 理论延伸的地方。
BASE 理论三要素
基本可用
基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性（不等价于系统不可用）。
什么叫允许损失部分可用性呢？
- 响应时间上的损失：正常情况下，处理用户请求只需要 0.5s 返回结果，但是由于系统出现故障，处理用户请求的时间变为 3s.
- 系统功能上的损失：正常情况下，用户可以使用系统的全部功能，但是由于系统访问量突然剧增，系统部分非核心功能无法使用。
软状态
软状态指允许系统中的数据存在中间状态（CAP 理论中的数据不一致），并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
最终一致性
最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
分布式一致性的 3 中级别
- 强一致性：系统写入了什么，读出来的就是什么。
- 弱一致性：系统不保证能在第一时间读取到最新数据，也不保证多长时间之后可以读取到的数据是最新的，只是会尽量保证某个时刻达到系统能达到数据一致的状态。
- 最总一致性：弱一致性的升级版，系统会保证在一定时间内达到数据一致的状态。
那实现最终一致性的具体方式是什么呢？
提示
- 读时修复：在读取数据时，检测数据的不一致，进行修复。比如 Cassandra 的 Read Repair 实现，具体来说，在向 Cassandra 系统查询数据的时候，如果检测到不同节点的数据副本不一致，系统就自动修复数据。
- 写时修复：在写入数据时，检测数据的不一致时，进行修复。比如 Cassandra 的 Hinted Handoff 实现。具体来说，Cassandra 集群的节点之间远程写入数据的时候，如果写失败，就将数据缓存下来，然后定时重传，修复数据的不一致性。
- 异步修复：这是最常用的方法，通过定时对账检测副本数据的一致性，并修复。
比较推荐的是 写时修复，这种方式对性能消耗比较低。
总结
ACID 时数据库事务完整性的理论，CAP 时分布式系统设计理论，BASE 是 CAP 理论中 AP 方案的延伸。
摘自 JavaGuide 点击此处查看原文