1. 一个具体问题
团队选择了一个在网络分区时保证强一致性的数据库，就以为架构取舍已经结束。上线后两个地区的用户都抱怨写入慢，而此时并没有故障。跨地区副本的同步等待，说明日常运行也需要在一致性和延迟之间做选择。
2. 一句话解释
PACELC 用两个问题分析复制系统：分区时如何权衡可用性与一致性，正常时又如何权衡延迟与一致性。
3. 出处与原意
Daniel Abadi 在 2010 年的文章中提出 PACELC 表述，并在后续研究中展开。P 表示分区，A 与 C 表示可用性和一致性；E 表示否则，L 与 C 表示延迟和一致性。它是补充 CAP 讨论范围的设计框架，不应被误读为另一个所有系统只有四个固定类别的完整定理。
4. 原理与机制
复制要让多个地点看到相同更新，往往需要通信。同步等待远端确认会进入用户请求的关键路径；异步复制则可以先返回，但远端读取可能落后。网络没有断开并不表示通信免费。实际权衡依赖操作种类、读写比例、副本位置和所要求的一致性级别，因此同一数据库不同配置可能呈现不同选择。缓存读、主节点写和会话内读己之写，也可能具有不同承诺，不能用一个标签覆盖全部行为。
延迟讨论应区分平均值与尾部，也应分开读和写。例如写入等待多数副本可能提高写延迟，却让某些读取更容易获得所需保证；就近读取可能快，但用户刚写完立即读时需要额外协调。对同一用户连续操作的承诺，有时比“全系统每次读取绝对一致”的笼统要求更贴近需求。明确这些细节后，才能判断具体协议是否承担了必要代价。
5. 一个完整案例
假设案例：一个跨城市协作工具允许用户修改昵称，也处理不能重复使用的邀请码。昵称更新先在本地确认，再异步传播，短时间看到旧昵称可以接受；邀请码兑换则等待统一确认，避免两个用户获得同一资格。正常情况下，团队测量两类请求的延迟分布；网络分区时，昵称仍可暂存修改，兑换则暂停部分请求。恢复后对昵称按明确规则合并，而不是简单丢弃更新。这个案例展示的是按业务语义选择代价，并非所有数据必须保持相同级别。
6. 适用条件与反例
适合比较多地域数据库、复制方案和缓存策略，但它没有替代完整的故障模型。持久性、成本、冲突可合并性和读写隔离仍需单独评估。也不能声称强一致性一定很慢；部署距离和协议优化可能让额外成本很小，关键是测量而不是口号。
7. 今天可以尝试的行动
为一项业务分别填两行：正常网络下需要什么读取承诺、能接受多少延迟；网络分区时哪些操作允许继续、结果如何修复。然后使用实际部署距离做一次测试，把正常路径和故障路径的代价同时放进方案。