BASE理论是对CAP中AP方案的延伸补充

BASE指基本可用（Basically Available）、软状态（Soft State）、最终一致性（Eventual Consistency），核心思想是：即使做不到CAP意义上的强一致性，应用也可以通过适合的方式最终达到一致状态。基本可用指分布式系统出现故障时，允许损失部分可用性，只保证核心功能可用——这里的关键词是”部分”和”核心”，判断哪些业务可以损失、哪些必须保住本身就是一项有挑战的工作：比如用户管理系统里，”登录”是核心（已注册用户登不进去，意味着充了钱的游戏玩不了、云存储用不了，损失和影响范围都很大），”注册”相对是非核心（新用户注册不了顶多是流失一小部分潜在用户，且新注册用户体量远小于已登录用户体量）。软状态指允许系统存在不会影响整体可用性的中间状态，这个”中间状态”本质上就是CAP理论里说的数据不一致状态。最终一致性指系统内所有数据副本经过一定时间后，最终会收敛到一致状态——关键词是”一定时间”和”最终”，”一定时间”和具体数据的特性强相关，不同数据能容忍的不一致窗口完全不同：比如微博系统里，用户账号数据最好能在1分钟内达成一致（用户在A节点登录后，短时间内不太可能立刻切到另一个节点，但十分钟后就有可能），而用户发布的最新微博可以容忍30分钟内达成一致（看不到明星最新发的微博，用户感知不到差异，只会以为明星还没发）；”最终”意味着不管这个窗口多长，系统最后一定会达到一致状态，不是永远不一致。BASE理论本质上是对CAP理论的延伸和补充，更准确地说，是专门针对CAP里AP方案的补充：一方面，CAP理论忽略延迟这个假设意味着完美的CP场景根本不存在，即使只有几毫秒的数据复制延迟，这几毫秒内系统也不符合严格CP的要求，因此CAP里所谓的CP方案其实也是在实现最终一致性，只是它的”一定时间”短到只有几毫秒而已；另一方面，AP方案里牺牲一致性只发生在分区期间，而不是永久放弃一致性，这一点正是BASE理论真正延伸的地方——分区期间牺牲一致性，但分区故障恢复后系统应该达到最终一致性。综合来看，ACID是数据库事务完整性理论，CAP是分布式系统设计理论，BASE则是CAP理论中AP方案的进一步延伸。

结构图：

flowchart TB
  A["BASE理论"]
  A --> B["基本可用<br/>故障时允许损失部分可用性，保核心功能<br/>如登录是核心，注册是非核心"]
  A --> C["软状态<br/>允许存在不影响整体可用性的中间状态<br/>=CAP理论中的数据不一致状态"]
  A --> D["最终一致性<br/>所有副本经过一定时间后最终收敛一致<br/>不同数据容忍窗口不同(账号1分钟/微博内容30分钟)"]
  D --> E["BASE的本质：CAP中AP方案的延伸补充"]
  E --> F["CP其实也是最终一致性<br/>只是'一定时间'短到几毫秒"]
  E --> G["AP牺牲一致性仅限分区期间<br/>分区恢复后应达到最终一致"]