BASE 是对分布式系统数据语义的一种概括，常作为 ACID 的对照：在分区与延迟不可避免时，以可用性与最终一致性换取可扩展的读写路径。三个字母分别表示：
- Basically Available — 基本可用
- Soft state — 软状态
- Eventually consistent — 最终一致
相对 ACID
| ACID | BASE | |
|---|---|---|
| 典型场景 | 单库事务、强一致账本 | 多副本、跨分区、高可用读写 |
| 一致性 | 提交后在模型承诺范围内立即一致 | 允许副本暂时分歧，之后收敛 |
| 可用性 | 为保一致可拒绝或阻塞 | 尽量响应，即使读到旧值或写到局部 |
| 状态 | 硬状态：事务边界清晰 | 软状态：无访问时也可能因复制而变化 |
BASE 并非否定事务，而是承认：在广域、多副本环境中，强一致、高可用与分区容忍难以同时满足（与 CAP 相关的工程现实）。许多业务可以选择更弱、但更易扩展的一致性模型。
三个词的含义
Basically Available
故障时系统仍尽量提供降级但可用的服务：读可能过期、写可能进入队列、部分功能只读。目标是维持整体可服务性，而非每个请求都返回最新权威结果。
Soft state
数据状态不必仅由用户请求驱动；后台复制、反熵与修复任务可在无访问时改变副本内容。对调用方而言，同一 key 连续两次读取结果不同，不一定来自本地写入。
Eventually consistent
若没有新的更新，在修复机制正常的前提下，经过足够时间后各副本会收敛到同一值。关键在于：收敛时间、冲突解决规则、用户可见的不一致窗口是否可被业务接受。最终一致需要配套明确的冲突处理与产品语义。
工程落点
- 在「最终一致」之上提供更细保证：读己之写（read-your-writes）、因果一致、会话一致等。
- 冲突处理：LWW、向量时钟、CRDT、业务补偿（TCC / Saga）等——选定一种并写入产品约定。
- 幂等与去重：异步与重试场景下，重复投递是常态。
- 语义诚实：界面与文档应说明「可能延迟可见」，避免用强一致话术包装最终一致系统。
实践含义
数据建模时需判断：不一致窗口是否可被用户感知，能否通过补偿收回。若可以，BASE 可用于换取扩展性与可用性；若不可以（如资金硬约束、严格库存），应缩小强一致边界，而不是全局假装「分布式 ACID」。BASE 是取舍声明，不是免责条款。