ACID，BASE 与 CAP 理论

1. ACID：单机时代的“律法”

ACID 是传统关系型数据库（如 MySQL、Oracle）的命根子。它的核心目的只有一个：保证数据的绝对可靠和完整。

• A (Atomicity) 原子性： 就像一个承诺，要么全做，要么全不做。转账时，A 扣钱和 B 钱到账必须同时成功。
• C (Consistency) 一致性： 数据库从一个合法状态变成另一个合法状态。比如：账户余额不能为负数。
• I (Isolation) 隔离性： 多个并发事务像排队一样，互不干扰。
• D (Durability) 持久性： 只要事务提交了，就算服务器断电，数据也要刻在硬盘里。

它的本质： 强一致性。宁可慢，宁可死锁，数据也绝不能错。

2. BASE：分布式时代的“权衡”

在互联网爆发后，单机撑不住了，数据必须分散在成千上万台机器上。这时，ACID 的强一致性成了性能杀手。于是诞生了 BASE。

• BA (Basically Available) 基本可用： 系统坏了没关系，核心功能得能用。比如：双 11 期间，搜索可能变慢，但下单必须成功。
• S (Soft State) 软状态： 允许数据在一段时间内不一致（中间态）。比如：你发了朋友圈，服务器还没同步到你朋友的手机上。
• E (Eventually Consistent) 最终一致性： 不追求瞬间一致，但保证经过一段时间后，大家看到的数据都是一样的。

它的本质： 牺牲强一致性，换取极致的高可用和扩展性。

3. CAP：那个“无法打破”的魔咒

CAP 是一条定理，它揭示了分布式系统的残酷现实：在一个存在网络分区（P）的系统中，一致性（C）和可用性（A）不可兼得。

• C (Consistency) 强一致性： 所有节点在同一时刻看到相同的数据。
• A (Availability) 可用性： 每一个请求都能收到响应（不论对错）。
• P (Partition Tolerance) 分区容错性： 即使网络断了（节点间无法通信），系统也要能跑。

它们之间的三角关系

在分布式系统中，P（分区容错）是必选项（因为网络总会坏）。那么你就必须在 C 和 A 之间二选一：

1. 选择 CP (ACID 倾向)： 为了保证数据一致，在网络故障时拒绝服务。比如：Zookeeper、Redis 强一致性配置。
2. 选择 AP (BASE 倾向)： 为了保证高可用，允许读到旧数据。比如：Redis 默认异步复制、Cassandra。

总结：它们到底在干啥？