Question 1

如何设计一个幂等的支付回调接口？

Accepted Answer

我的方案是幂等键 + 数据库唯一约束兜底：用支付网关的业务单号做幂等键，回调先按单号查支付流水状态机——已终态直接返回成功，处理中返回重试。关键是「先查后写」有并发窗口：两个重复回调同时查到「未处理」就会双写，所以流水表对单号建唯一索引，插入冲突即视为重复请求安全返回。我在真实项目里就靠这个唯一索引拦下过网关抖动引发的三连回调，账务零重复。分布式锁我只作为减少无效冲突的优化，不作为正确性依据——正确性永远压在数据库约束上。

Question 2

缓存与数据库的一致性怎么保证？

Accepted Answer

先说结论：绝大多数业务用 Cache-Aside——读走缓存、写库后删缓存、再配 TTL 兜底就足够，剩下的极小概率脏窗口由过期时间收敛。如果业务对脏读更敏感，我会加延迟双删或订阅 binlog 异步失效，但要承认代价：链路更长、组件更多、排障更难。我做商品详情缓存时评估过：容忍秒级不一致，最终只用删缓存 + 60 秒 TTL，上线后缓存不一致工单为零。所以我的答题框架是先给业务容忍度，再选一致性等级——一致性是权衡出来的，不是堆方案堆出来的。

Question 3

单表数据量过亿了，你会怎么处理？

Accepted Answer

我不会直接答分库分表，先问两件事：读写比例和查询模式，以及数据的冷热分布。演进顺序是归档 → 分区 → 分库分表：很多「过亿」表 80% 是冷数据，先把历史数据归档到冷存储，主表可能直接降回千万级；还不够就按时间分区，改造成本低；真到分片，shard key 要跟着主查询路径选（比如订单按用户 ID），并提前接受两个代价——跨片查询要走聚合层、扩容要做数据迁移。我上一家公司订单表就是先归档砍掉 70% 数据、半年后才真正分片，避免了过早引入分布式复杂度。

Question 4

消息队列你用来解决什么问题？消息丢失怎么办？

Accepted Answer

我用消息队列主要解决三类问题：大促削峰（把瞬时十万级写请求缓冲成平稳消费）、系统解耦（订单完成后积分/通知/风控各自订阅，不互相拖累）、最终一致（跨服务状态同步）。消息丢失我分三段兜：生产端开确认机制加本地消息表，发送失败落表重投；Broker 端多副本持久化；消费端做幂等消费，重试超限进死信队列人工介入。我实际排查过一次「丢消息」：最后定位是消费者异常被吞导致 offset 提交越过了失败消息——所以我现在坚持消费失败必须显式抛出，让重试和死信机制接得住。

Question 5

线上一条 SQL 突然变慢，你的排查步骤？

Accepted Answer

我的排查顺序是先定范围再看单条：监控确认是这一条慢还是整库慢、有没有锁等待和连接堆积——如果整体慢，多半是资源或锁的问题，不该盯着 SQL 本身。确认是单条后，EXPLAIN 看执行计划：有没有走索引、扫描行数、是否临时表排序。我印象最深的一次是订单查询突然全表扫描：SQL 没变，是调用方把单号从字符串改传了数字，隐式类型转换让索引直接失效，EXPLAIN 的 type 从 ref 变 ALL 一眼可见。修复传参并加了慢查询告警。所以我的方法论是：监控定位 → 执行计划取证 → 找变更源，不猜。

Question 6

设计一个短链服务，QPS 十万级怎么扛？

Accepted Answer

我先估算再设计：假设日增千万短链、读写比 100:1，读 QPS 十万级、存储每年百 GB 量级——结论是典型读多写少系统，架构重心在读路径。写路径用分段发号器（每台服务预取一段 ID 区间）生成 62 进制短码，避免单点；读路径三层：本地缓存扛热点、Redis 集群做主缓存、DB 兜底，突发热点 key 用本地缓存 + 随机过期打散。跳转层前置 CDN/边缘节点可以再挡一大截。最后我会主动补两个边界：发号与落库的一致性（预取段崩溃只浪费区间、不产生冲突），以及防刷——对生成接口做限流和恶意域名黑名单。

Question 7

分布式事务有哪些方案？你实际用过哪种？

Accepted Answer

按一致性从强到弱：2PC 强一致但同步阻塞，互联网业务少用；TCC 靠业务实现 Try/Confirm/Cancel，灵活但侵入大；SAGA 长事务正向执行 + 逆向补偿；本地消息表最朴素——业务与消息同库同事务，异步投递保证最终一致。我实际用得最多的是本地消息表：积分发放场景里订单库内同事务写订单和消息记录，定时任务扫表投递、消费端幂等。踩过的坑是补偿类方案的空回滚与悬挂——Cancel 先于 Try 到达时要落「已取消」标记拦截迟到的 Try。我的结论：能用最终一致就不上 TCC，方案复杂度必须和业务的一致性要求匹配。

Question 8

讲一个你主导的高并发场景改造

Accepted Answer

我主导过一次秒杀链路改造。改造前大促峰值 8000 QPS 时下单接口 P99 超 3 秒、错误率 2%。我没有直接上方案，先压测定位瓶颈：火焰图显示 60% 耗时在库存行锁竞争，其次是同步扣减积分的 RPC。改造三步：库存预热到 Redis 用 Lua 原子扣减、订单落库走消息队列异步化、积分改为最终一致的异步发放。结果大促实测扛住 3 万 QPS，P99 降到 180ms、错误率 0.01%。反思是我当时给 Redis 扣减设计了过重的对账补偿，实际一年只触发两次——如果重来我会先用更简单的定时对账，把工程时间投到限流预案上。

后端工程师高频面试题：8 道必考题与作答要点