⚖️BASE 与 ACID / CAP 的关系
ACID 追求强一致（银行转账），BASE 接受弱一致（社交动态）。CAP 说分区时只能选 C 或 A——BASE 就是"选 A 后如何把一致性补回来"的方法论。
| 理论 | 立场 | 典型场景 |
|---|---|---|
| ACID | 强一致、事务严格 | 银行核心、账目 |
| CAP | 分区下 C 与 A 二选一（P 必选） | 理论框架 |
| BASE | 舍强一致换可用，最终一致 | 电商、社交、缓存 |
记忆：BASE 不是"不要一致性"，而是"不要求实时一致，但保证最终会一致"。它是分布式的"务实主义"。
🧩BASE 三要素
① BA — Basically Available（基本可用）
系统出现故障时，允许降级而非全挂。例如：响应变慢（限流）、返回兜底数据（缓存页）、部分功能不可用（只展示核心链路）。可用性优先于完美。
② S — Soft State（软状态）
允许系统中间状态存在且不立即一致。比如"订单处理中""余额同步中"——这些数据暂时不一致是被允许的，只要最终对齐。
③ E — Eventually Consistent（最终一致）
经过一小段时间（秒级/分钟级）后，所有副本数据会达到一致。这是 BASE 的落脚点，也是"柔性"能成立的底气。
一句话：基本可用（不崩）+ 软状态（允许中间不一致）+ 最终一致（迟早对齐）。三者合起来，就是"柔性事务"的骨架。
🔄最终一致性（五档强度）
"最终一致"不是一刀切，按"用户何时看到一致"分强弱。
| 类型 | 说明 | 例子 |
|---|---|---|
| 因果一致 | 有因果关系的操作顺序被保留 | 评论→回复，回复不会早于评论显示 |
| 读己之写 | 自己改完立刻能读到自己的新值 | 改完昵称刷新能看到 |
| 会话一致 | 同一会话内读己之写 | 一次登录会话里保持一致 |
| 单调读 | 不会读到比之前更旧的数据 | 翻页不会看到"倒退"的旧内容 |
| 单调写 | 同一客户端的写按序执行 | 写操作不乱序 |
选型：不是所有业务都要"读己之写"。像"朋友圈点赞数"用最弱的最终一致即可；"账户余额"则要有更强保证（甚至走强一致/对账）。
💡柔性事务：BASE 的工程实现
分布式事务很难做 2PC（阻塞、单点），工业界多用"柔性事务"替代强一致事务。
常用模式：
TCC（Try-Confirm-Cancel）：预留资源→确认/补偿，业务侵入大但可控。
消息队列最终一致：本地事务写业务+发消息，下游消费补偿，最常用。
Saga：长事务拆成一系列本地事务，失败则反向补偿。
最大努力通知：尽最大努力把结果通知对方，允许重试直到成功。
与事务章节呼应：严格的 2PC/3PC 见 transaction/ 目录；BASE 下的柔性事务是"放弃强一致、换可用与性能"的务实选择。
🛒实战示例：电商下单
这就是 BASE：用户下单基本可用（立即返回成功）；系统处于软状态（库存/积分短暂未更新）；通过 MQ 异步处理实现最终一致（几秒内全部对齐）。
🎯面试要点速记
定位：BASE 是 CAP 中"选可用(A)"后的设计理论，放弃强一致、追求最终一致。
三要素：BA 基本可用 + S 软状态 + E 最终一致。
最终一致分级：因果/读己之写/会话/单调读/单调写，按需选强度。
柔性事务：TCC / 消息最终一致 / Saga / 最大努力通知。
对比 ACID：ACID 强一致难扩展，BASE 弱一致易扩展，按需取舍。
适用：电商、社交、缓存等"不怕短暂不一致"的场景。
必考题："BASE 和 ACID 怎么选？"——核心链路（钱、账）用 ACID/强一致；非核心/高并发（点赞、动态、积分）用 BASE/最终一致。几乎所有大厂都是"混合架构"。