014、分布式系统核心：一致性、可用性与分区容错

014、分布式系统核心：一致性、可用性与分区容错

深夜报警：订单状态丢了

上周三凌晨两点，手机突然狂震。监控告警显示，订单服务的双活机房出现数据不一致——同一订单在A机房显示“已支付”，在B机房却是“待付款”。业务部门紧急来电，用户已经投诉付款后订单没反应。

团队连夜拉会查日志，发现根因是跨机房同步延迟导致的状态覆盖。这已经不是第一次了，每次扩容或网络抖动都会暴露类似问题。我盯着监控面板上跳动的延迟曲线，突然想起CAP定理那张老图——原来教科书里的理论，真能在生产环境给你一记重拳。

CAP不是选择题，是场景题

很多工程师把CAP定理简单理解为“三选二”，其实误解很深。CAP的真正含义是：当网络分区（Partition）发生时，你必须在一致性（Consistency）和可用性（Availability）之间做权衡。

注意前提：分区发生时。如果网络永远可靠，你可以同时做到CA。但现实是，机房光纤可能被挖断、交换机可能故障、云服务商可能抽风……分区终会发生，你必须提前设计好策略。

看看这几个典型场景：

场景一：支付流水库
我们用了主从同步+半同步机制。主库在北京，从库在上海。正常情况下，写主读从，延迟控制在10ms内。但去年运营商光缆中断那次，上海从库同步延迟飙升到30秒。这时候怎么办？

如果选择C（一致性），上海所有支付查询必须走北京主库，但跨机房延迟导致响应超时，上海业务基本不可用。