搜索结果： "最终一致" (12)
数据对账：Redis 与 DB 的最终一致
Redis 扣的、MQ 传的、DB 记的——三个存储三条路径，每个失败分支都是差异来源。总库存恒等式、实时抽样加离线全量、自动修复与人工兜底的分界线，对账是最终一致的最后一块拼图。
分布式事务的微服务落位：Seata 与最终一致
拆掉的不只是代码，还有事务——下单扣库存跨了服务，@Transactional 失效了。第一问永远是能不能不用分布式事务；真要用，AT、TCC、消息最终一致各有各的账单，决策树帮你选。
实战场景集：订单超时、秒杀、数据同步、最终一致
理论装进业务才算数。四个高频场景的完整方案：延迟消息三保险、秒杀的预扣库存、binlog 订阅式数据同步、支付回调的最终一致——每道菜都标了用了系列里哪几味药。
RocketMQ 架构：NameServer、主从与 Dledger
四个角色撑起十万级吞吐：无状态的 NameServer 用最终一致换简单，CommitLog 大文件混写保住顺序写红利，Dledger 用 Raft 把手动切换变成自动选主。一篇看懂 RocketMQ 的骨架。
对账系统：最终一致的最后防线
防御做得再全，季度审计照样翻出差异。对账是分布式事务的最后一道防线：不信任任何一方自报，用独立数据源做全量比对——长款、短款、状态不符逐笔揪出，自动平账、人工差错池、挂账三路分流。
本地消息表：最朴素的最终一致
先发消息后提交事务，回滚收不回消息；先提交再发消息，进程挂了消息蒸发。本地消息表用最笨的办法破局：业务数据和消息记录同库同事务，后台任务扫描投递——不依赖任何框架，两张表加一个定时任务就是全部。
TCC：把事务搬进业务代码
XA 的性能债还不起，就用业务改造来换：Try 预留、Confirm 确认、Cancel 释放。把数据库的锁换成业务字段里的冻结标记，吞吐回来了，代价是每个参与者多写两个接口、多背一套幂等纪律。
理论基石：从 ACID 到 CAP 再到 BASE
ACID 的护城河出了单机就塌了；CAP 不是三选二，P 没得选，真正的取舍在 C 和 A 之间；BASE 把中间态合法化，最终一致成为互联网架构的宿命。理论不解决问题，但决定你选方案时问什么问题。
订单创建了，库存没扣：分布式事务从哪来的
单体拆成微服务，@Transactional 鞭长莫及：订单库提交了，库存服务却超时回滚，账对不上。网络不可靠、失败只是一部分、超时三态——分布式事务的所有方案，都是在给这三个现实打补丁。