CAP

副标题 / 摘要 CAP 不是理论考试题，而是系统设计的现实约束。本文用工程例子解释 CP、AP、CA 的取舍。 目标读者 做系统选型的后端工程师 需要理解一致性与可用性的团队 架构与技术负责人 背景 / 动机 网络分区发生时，系统无法同时满足一致性与可用性。 理解 CAP 可以避免错误的业务承诺。 核心概念 一致性（C）：所有节点读取同样数据 可用性（A）：请求总能得到响应 分区容错（P）：网络分区时仍能工作 实践指南 / 步骤 先确认业务对一致性的硬要求 估算可用性指标（SLA/SLO） 基于分区风险选择 CP 或 AP 明确降级策略与补偿机制 可运行示例 # 简化演示：分区时的读写策略选择 def choose_strategy(needs_strong_consistency: bool): if needs_strong_consistency: return "CP: 拒绝部分请求以保持一致" return "AP: 保持可用，接受短暂不一致" if __name__ == "__main__": print(choose_strategy(True)) print(choose_strategy(False)) 解释与原理 在发生网络分区时，要么拒绝部分请求（保一致），要么接受不一致（保可用）。 因此在分布式系统里，P 几乎是必选项，核心在 C 与 A 的取舍。 常见问题与注意事项 CA 系统是否存在？ 只有在“无分区”假设下才成立，现实中很少。 AP 就一定不一致吗？ 它是“最终一致”，而非永久不一致。 CP 会不会不可用？ 会，CP 在分区时会拒绝请求。 ...

副标题 / 摘要 最终一致性表示“短时间内可能不一致，但最终会收敛”。本文解释它的工程价值与风险。 目标读者 负责分布式系统的后端工程师 设计一致性模型的架构师 需要做数据取舍的产品与技术负责人 背景 / 动机 强一致性通常意味着更高延迟与更低可用性。 最终一致性提供了可用性与扩展性的折中方案。 核心概念 最终一致性：系统在一段时间后收敛一致 收敛时间：达到一致所需的时间窗口 读写冲突：并发更新导致的版本差异 实践指南 / 步骤 识别可容忍不一致的业务 定义收敛时间与告警阈值 引入幂等与重试机制 用版本号/时间戳解决冲突 可运行示例 # 简化的“最终一致”模拟 state = {"A": 0, "B": 0} def update(node, delta): state[node] += delta def reconcile(): total = sum(state.values()) state["A"] = total // 2 state["B"] = total - state["A"] if __name__ == "__main__": update("A", 5) update("B", -1) print(state) # 暂时不一致 reconcile() print(state) # 最终收敛 解释与原理 最终一致性依赖异步复制与冲突解决策略。 它让系统保持高可用与高吞吐，但需要接受短暂的不一致。 常见问题与注意事项 所有业务都适合最终一致吗？ 不适合，金融扣款等场景需要更强一致性。 ...