ACID 与 BASE 是什么
ACID 强调原子、一致、隔离与持久，事务提交后状态立即生效且所有人看到同样结果；BASE 强调基本可用、软状态与最终一致，允许中间状态存在，替换以业务补偿换取可用性与伸缩性。两者不是先进与落后的关系，而是对应不同业务容忍度：账务与交易倾向 ACID，社交动态、统计与推荐常选 BASE。同一个系统内也可以按业务分区分别选择。
对比
| 维度 | ACID | BASE |
|---|---|---|
| 一致性 | 强一致，事务提交即对所有读可见 | 最终一致，允许中间状态 |
| 可用性 | 冲突时倾向阻塞或失败 | 倾向继续服务，牺牲部分一致性 |
| 复杂度 | 数据库承担多数并发控制 | 应用承担补偿、对账与冲突解决 |
| 典型场景 | 交易、账务、库存扣减 | 社交动态、推荐、日志、统计 |
基本信息
| ACID 四要素 | 原子性、一致性、隔离性、持久性 |
|---|---|
| BASE 三要素 | 基本可用、软状态、最终一致 |
| 选择依据 | 业务能否接受短暂不一致，以及能接受多久 |
| 补偿手段 | 对账任务、补偿事务、人工介入队列 |
| 混用原则 | 同系统内按业务分区选择，明确哪些链路必须强一致 |
典型使用场景
- 支付与扣款：必须强一致，失败就明确失败而不是稍后对齐
- 库存扣减：核心链路强一致，周边统计可最终一致
- 积分与等级：允许延迟生效，用事件异步更新
- 消息通知：异步发送失败可重试，不影响主交易结果
- 跨系统对账：先用 BASE 保证可用，再靠 T+1 对账校正
- 大促场景：非核心链路降级为最终一致，保住主交易链路
选择依据是业务能否接受短暂不一致及其时长，而不是技术先进与否；能说清“允许不一致多久、不一致时谁负责修”才算选明白。
核心账务使用最终一致，却不做对账与补偿设计，数据不一致会长期累积且无法定位。