第2章：事务一致性、延迟优化、容灾设计与公司侧重点对比
本章聚焦交易系统最核心的三大技术战役：数据一致性保障、毫秒级延迟优化与跨机房容灾设计。面试官通过这三类问题快速评估候选人对交易链路全貌的理解深度与实战韧性。
面试问答卡 ①｜高并发下的事务一致性方案
| 面试问题 | 在秒杀场景下，如何保证库存扣减与订单创建的强一致性？ |
| 考察点 | 一致性模型理解、分布式事务架构能力、方案取舍逻辑 |
| 回答框架 | 1. 业务量级评估 → 2. 核心链路识别 → 3. 方案选型（TCC vs 本地消息表）→ 4. 异常处理与补偿机制 |
| 示例回答 | “秒杀场景优先保证最终一致。我用本地消息表：扣库存成功 → 写消息表 → 异步消费创建订单。如果消息失败，定时补偿扫描未处理记录，结合Redis预扣库存兜底。强一致场景（如金额扣减）才用TCC。” 约85字 |
| 可能追问 | “本地消息表与RocketMQ事务消息区别？”“TCC空回滚、幂等如何设计？” |
| 避坑提醒 | 不要一刀切推荐强一致方案。面试官期待你根据延迟SLA和一致性等级做权衡。 |
面试问答卡 ②｜全链路延迟优化
| 面试问题 | 交易链路上，从下单到返回用户一共150ms，如何优化到50ms以内？ |
| 考察点 | 链路感知能力、工具方法、优化优先级排序 |
| 回答框架 | 1. 链路分解与打点 → 2. 定位瓶颈（网络/DB/序列化/锁）→ 3. 分层优化 → 4. 灰度验证 |
| 示例回答 | “先全链路打点，发现p99瓶颈在DB写和RPC。优化：1)写操作异步化（消息队列削峰）；2)热点key本地缓存；3)RPC合并请求、减少序列化耗时；4)预加载支付渠道信息。最终p99降至45ms。” 约92字 |
| 可能追问 | “如何做全链路Trace？”“异步化后一致性问题怎么解？” |
| 避坑提醒 | 只谈缓存削峰不说一致性风险，会被认为思考片面。优化后必须给出数据（p99/p999对比）。 |
面试问答卡 ③｜跨机房容灾设计
| 面试问题 | 设计异地多活交易系统，若上海机房整体不可用，如何保证用户可正常下单？ |
| 考察点 | 容灾架构能力、数据同步方案、流量调度与一致性取舍 |
| 回答框架 | 1. 容灾目标（RTO/RPO）→ 2. 单元化 vs 主备 → 3. 数据同步（DRC/CQRS）→ 4. 流量切换策略 → 5. 回切与验证 |
| 示例回答 | “采用单元化架构，每个单元包含完整交易链路。上海、杭州互为主备。数据通过DRC实时同步，RPO<20s；前端通过DNS+GSLB探测可用性，故障时自动切流。库存独立分片，跨单元用最终一致消息同步。每季度做一次混沌工程演练。” 约96字 |
| 可能追问 | “分库分表后全局ID怎么生成？”“单元化下订单全表扫描场景怎么优化？” |
| 避坑提醒 | 容灾方案不讲RTO/RPO指标，会被认为没有实战经验。一定要强调演练和可观测性。 |
💡 面试加分点：主动输出“公司侧重点对比”——面试官极度看重候选人是否了解不同公司对一致性与延迟的权衡差异。
公司侧重点对比 (知识结构表)
| 公司类型 | 一致性要求 | 延迟要求 | 典型方案 |
|---|---|---|---|
| 大流量电商 (淘宝/京东/拼多多) | 库存最终一致，资金强一致 | p99 < 50ms | TCC + 本地消息表 + Redis预扣 |
| 金融支付 (支付宝/微信支付) | 强一致（分布式事务+2PC） | p99 < 100ms (含风控) | 自研分布式事务框架 + 幂等表 |
| 证券交易 (券商核心) | 强一致 + 事务持久化 | p99 < 5ms（撮合） | 内存撮合 + 分级故障隔离 |
| 出行/外卖 (滴滴/美团) | 状态最终一致，计费强一致 | p99 < 200ms | SAGA + 异步补单 |
| 新兴平台 (快手/抖音电商) | 最终一致为主，高可用优先 | p99 < 80ms | 消息队列 + 预占 + 延迟补偿 |
可迁移话术：“我们参考了XX公司的做法，但根据业务特性做了取舍——例如我们在资金环节使用TCC，而库存环节使用消息队列+定期对账，这样在满足业务一致性的同时，将p99延迟从120ms优化到了65ms。”
⚠️ 常见失分点：回答容灾时只说“多机房部署”缺乏细节；谈一致性时不提补偿和幂等；谈优化时不提数据验证。面试官用追问“如果方案失败了怎么办”来区分是否真做过。