PACELC 是什么
PACELC 补齐了 CAP 的空白：发生分区（P）时，要在可用性 A 与一致性 C 之间取舍；否则（E，Else，即网络正常时），要在延迟 L 与一致性 C 之间取舍。它提醒人们，即使网络完全正常，强一致也要付出跨副本往返的延迟代价。
用它做什么判断
选型时先问系统是否跨地域，再问业务能否接受分区期间不可写。跨地域强一致的代价是一次写入要等多数副本确认，跨区域往返通常在几十毫秒量级，直接限制写入吞吐；而单地域强一致的延迟通常只有毫秒级。把这两个问题问清楚，比背 CAP 定理更有用。
读法
读法
if 分区(P):
在 A 与 C 之间取舍 # 继续服务还是拒绝写入
else(E):
在 L 与 C 之间取舍 # 网络正常时，强一致代价是额外往返延迟
# 示例：Dynamo 风格多主 = PA/EL；多数强一致数据库 = PC/EC 或 PC/EL
# 读法：前缀表示分区时的选择，后缀表示常态下的取舍常见取舍组合
| 系统形态 | 分区时 | 常态下 |
|---|---|---|
| 主从异步复制 | 可继续写主库，故障时可能丢数据 | 读从库延迟低但可能读到旧值 |
| 多数派同步复制 | 少数派分区时不可写 | 每次写入需多数副本确认，延迟较高 |
| 跨地域强一致 | 牺牲可用性保一致 | 跨区域往返延迟成为写入瓶颈 |
| 单地域强一致 | 同左 | 延迟可控，仍在毫秒量级 |
与 BASE 的关系
PACELC 描述的是取舍象限，BASE 描述的是最终一致性这类选择带来的工程后果：基本可用、软状态、最终一致。实际选型时常把两者配合使用——先按 PACELC 判断在分区常态下牺牲一致性还是延迟，再按最终一致的语义设计冲突解决与读己之写策略。只记住某个系统属于哪一类，并不能代替对自身业务一致性要求的分析。
跨地域部署时 EL 侧最容易被忽略：为满足合规把主副本与从副本放在不同区域，即使网络正常，每次强一致读写都要付出跨区域往返时间。