【分布式事务连载 02】CAP、PACELC 与 BASE老板要实时一致架构师为何说不系列第 2 篇承接单边账说明「本地 ACID 不够」本篇回答那我们到底能承诺多强的一致目标用分区演练 订单状态机吃透 CAP / PACELC / BASE并把「最终一致」落到可执行闭环。1. 问题引入产品经理小美的一句话事故复盘会上小美拍桌子「能不能保证用户点完支付立刻、永远、两边绝对一致做不到就别上微服务。」老张喝了口凉水「能。把所有服务塞回一个库关掉跨机房别拆。你要跨服务、跨机房、高可用还要『立刻永远绝对』——物理定律先不同意。」本篇不站队吵架只把定律讲清楚再讲工程怎么「认怂认得漂亮」。2. CAP三个字母真正难的是分区发生时2.1 定义用人话再说一遍CAP由 Eric Brewer 在 2000 年提出指的是分布式系统的三个核心特性字母含义用户体感C Consistency一致性所有节点同一时刻读到同一份最新数据强一致 / 线性一致视角「我在哪读都一样」A Availability可用性非故障节点必须在有限时间给出成功/失败响应不能无限卡住「系统还活着能点」P Partition tolerance分区容错性节点之间网络断了系统仍按设计继续运行「机房光纤被挖断也有预案」保C弃A保A弃C必须容忍分区 P分区发生时拒绝写入/读取 - 系统繁忙继续本地服务 - 短暂不一致核心结论在网络分区P必然发生的前提下只能在 C 和 A 之间二选一。CP 系统牺牲可用性保证一致性。分区时拒绝服务等恢复后再响应。例如ZooKeeper、HBase、etcd。AP 系统牺牲一致性保证可用性。分区时各节点继续响应但可能返回旧数据。例如Cassandra、DynamoDB、Eureka。注意CAP 里的 C 是线性一致性强一致不是数据库 ACID 里的 C。ACID 的 C 是“别把数据搞坏、别违反业务规则”CAP 的 C 是“所有节点看到的数据要一样”。2.2 分区演练极简购两个机房假设订单服务主写在机房 1只读副本在机房 2光纤被挖断ReplicaDC2PrimaryDC1UserDC2UserDC1ReplicaDC2PrimaryDC1UserDC2UserDC1network partitionalt[choose CP][choose AP]pay success orderPAIDquery ordererror busy keep correctstill UNPAID available but staleCP 阵营例子不少强一致元数据、传统 XA/2PC 协调思路——宁可失败不给错数据。AP 阵营例子DNS、很多缓存、最终一致订单查询——先让你查稍后对齐。2.3 和分布式事务的关系事务思路更偏代价2PC / XACP阻塞、延迟、吞吐差消息最终一致 / TCC 补偿AP 事后收敛中间态、要幂等对账Seata AT更偏最终一致一阶段已提交存在可见中间态宣称「我们系统同时满足 CAP」——面试口径直接判错生产里通常是CP 或 AP 为主再局部补强。3. PACELC没分区时你也在做选择CAP 只描述「分区时」。生产还有半句更扎心的PACELCPACELC由 Daniel Abadi 在 2012 年提出是对 CAP 的补充和细化。它指出CAP 只讨论了分区发生时的取舍但没有分区正常运行时也有取舍——那就是延迟Latency和一致性Consistency之间的权衡。若有Partition在A与C间选Else没分区在Latency 与Consistency 间选。P 发生 → 选 A 或 C P 不发生 → 选 L低延迟或 C强一致极简购例子场景更偏为什么收银台同步扣库存再返回C延迟高用户要「买到」的确定感支付成功后异步加积分L短暂不一致积分晚 3 秒可接受跨城同步 2PC 转账C延迟更高金融不变量日志/埋点收集L丢一点也能活小美要的「立刻」有时是L 与 C 的冲突甚至还没到分区。把所有写都做成同步强一致双十一 QPS 会先把你打穿。4. BASE不是放弃一致是把一致推迟到可接受窗口4.1 三个词怎么落到订单BASE含义极简购落地BABasically Available故障时降级仍提供核心能力积分服务挂了下单支付仍可完成SSoft state允许中间态订单WAIT_PAY→PAYING→PAID/CLOSEDEEventually consistent无新更新后最终收敛支付回调 超时关单 日终对账重要BASE不否定ACID。单库内照样 ACID跨服务用 BASE 谈「全局怎么收敛」。4.2 订单状态机create orderstart paypay callback okpay failed retrytimeoutpay timeout closeWAIT_PAYPAYINGPAIDCLOSEDPAYING 是软状态窗口库存预扣中、余额可能冻结必须有超时与补偿。对应动作没有这些就不是 BASE是「烂尾」状态/事件必须做什么进入PAYING库存 Try 预扣 / 超时时钟启动PAIDConfirm 扣减发「支付成功」可靠事件CLOSEDCancel 释放预扣若已扣款则退款补偿日终订单 vs 支付单 vs 库存流水对账4.3 最终一定一致怎么证明发现差异对齐业务写入可靠投递 Outbox幂等消费失败可补偿定时对账兜底收敛完成窗口多长算合格业务定义不是技术口号。业务可接受窗口兜底支付结果展示秒级主动查单 回调积分到账秒分钟重试 对账补发跨行清算小时日终清算文件对账发票开具小时级人工 批次任务5. 实战案例支付中状态 超时关单5.1 表字段CREATETABLEtrade_order(idBIGINTPRIMARYKEY,statusVARCHAR(16)NOTNULL,-- WAIT_PAY / PAYING / PAID / CLOSEDpay_deadlineDATETIMENOTNULL,-- 超时关单时间versionINTNOTNULL,-- 乐观锁...);5.2 发起支付进入软状态TransactionalpublicvoidstartPay(LongorderId){TradeOrderorderorderMapper.selectForUpdate(orderId);if(order.getStatus()!WAIT_PAY){thrownewBizException(状态不允许支付);}orderMapper.updateStatus(orderId,WAIT_PAY,PAYING);// 同时库存 Try、启动超时任务或依赖 pay_deadline 扫描stockClient.tryFreeze(order.getSkuId(),order.getCount(),orderId);}5.3 超时关单任务防止预扣永久占用Scheduled(fixedDelay5000)publicvoidcloseExpiredPayingOrders(){ListTradeOrderlistorderMapper.selectExpired(PAYING,LocalDateTime.now());for(TradeOrdero:list){// 幂等关单intnorderMapper.casUpdateStatus(o.getId(),PAYING,CLOSED,o.getVersion());if(n1){stockClient.cancelFreeze(o.getId());// Cancel 必须幂等// 若支付渠道已成功走对账纠偏而不是盲关}}}5.4 对账兜底每日 02:00 支付中心成功流水 LEFT JOIN 订单 - 有支付无 PAID 订单 → 补成 PAID Confirm 库存 - 有 PAID 无支付 → 告警人工或自动退款流程 - 库存冻结超时未释放 → 强制 Cancel 告警没有这步你的「最终一致」只是希望有了这步才是工程。6. 把三个理论嵌回极简购选型语言是否可对账是否是资损风险且窗口必须接近0?偏 CP: XA/强同步偏 APBASE多方资源预留?TCC / SAGAOutbox / 事务消息低侵入多库写?Seata AT下篇起我们进入具体协议与方案你心里要有这把尺子先问不变量与窗口再问用什么中间件。7. 踩坑总结别用「最终一致」偷换 CAP 的 C。最终一致是 BASE 语境不是「我们也有 C」。中间态不设超时 资源泄漏库存预扣成永久冻结。只异步、不幂等、不对账 永久不一致。无分区时也有 L vs C同步链路堆太多双十一先死在延迟上。对用户要诚实积分「预计 5 分钟内到账」比「已到账」却查不到体验更好客服更少。自测题分区时保 C 弃 A用户会看到什么保 A 弃 C 呢PACELC 比 CAP 多解释了什么生产现象画出你司一个订单状态机标出每个中间态的超时与补偿动作。下期预告《032PC / 3PC最像正经事务的方案为何在微服务里经常变成堵车》我们会用「工行→建行」转账动画式时序图把 Prepare/Commit、协调者宕机、3PC 超时误判一个个拆开。