Mock 面试复盘：从重复扣款到高峰扩容，项目深挖该怎么准备？

今天帮人做了一场 Mock Interview，围绕一个积分支付项目，聊了幂等、数据库与缓存一致性、高峰扩容，以及项目经历怎么讲。

整理几个值得准备的追问。以下是模拟面试讨论，不是某家公司的真实面经，案例做了泛化处理。

1. 第三方扣款成功，但本地还没记录结果，服务就挂了，怎么办？

场景是：服务调用第三方扣除积分，对方已经成功，但本地进程在写数据库之前崩溃。用户随后重试。

这道题如果只回答“加锁”“加幂等”或者“失败重试”，还不够。需要把故障之后的流程讲完整。

首先，本地不知道结果，不代表扣款失败。这笔交易应该保持“处理中”或“结果未知”，不能直接重新发起一笔新的扣款。

其次，需要区分两层保护：

* 本地通过条件写入、状态机等方式，协调同一笔交易的并发处理。
* 第三方通过幂等协议，保证同一笔业务请求重试不会重复扣款。

重试时复用同一个幂等 key 和原请求参数，前提是第三方支持相应语义，且仍在其幂等有效期内。如果结果依然无法确认，就需要查询和对账。

还可以继续追问：如果用户不再重试，谁负责把这笔交易处理完？这时就需要后台恢复机制，不能只依赖用户再次点击。

关键点：本地锁解决不了跨系统的重复扣款问题，超时也不能直接解释为业务失败。

2. 数据库写成功了，缓存更新失败，应该返回什么？

先明确数据库和缓存各自承担什么职责。

如果数据库是事实来源，业务交易已经成功提交，通常不应仅因缓存更新失败，就把整笔业务返回成失败，否则可能诱发不必要的重试。

但“缓存失败没关系，下次查数据库”也有漏洞：缓存里可能还留着旧值，下次请求仍然命中旧值，根本不会回源。

因此，需要继续解释：

* 使用什么缓存更新或失效策略？
* 最多允许旧数据存在多久？
* 更新失败之后，如何恢复？
* 哪些关键操作不能依赖缓存数据作决定？

TTL 可以限制旧值存活时间，但不等于强一致。涉及支付批准、余额校验等操作，需要明确权威判断由谁完成。

3. Peak hours 很多用户同时访问，如何 scale？

常见回答是加实例、加 load balancer、加 cache。可以作为开头，但还需要沿着请求链路找瓶颈。
.google  и
应用层：服务是否无状态，能否横向扩展？已知高峰是否需要提前扩容？

数据库层：连接数、吞吐、分区分布是否会先到上限？

下游层：第三方接口有没有配额？如果下游只能处理固定吞吐，增加本地实例并不能提升端到端容量。

流量隔离：查询请求会不会占满资源，影响真正的支付请求？

失败处理：有没有超时、限流和重试预算？指数退避加 jitter 可以缓解同步重试，但仍需限制重试次数和总量。

我觉得这一部分最重要的是讲清楚：扩的是哪一层、解决哪个瓶颈，以及扩完之后瓶颈会转移到哪里。

4. 总流量大和 hot key，要分开讨论

大量用户访问不同数据，与大量请求集中访问同一个 key，处理方式不一样。

热点读可以考虑缓存、合并并发请求等方式。

热点写则需要结合数据模型讨论：能否拆分？是否要求顺序？是否存在必须串行更新的共享状态？

尤其是余额这类数据，不能为了分散流量就随意拆分写入。需要解释拆分之后如何保持业务正确性。

5. 项目介绍中的 ownership 和指标，也会被深挖

介绍项目时，最好明确区分：

* 哪些架构在你加入前已经存在？
* 哪些方案是你提出并推动的？
* 哪些部分由团队共同实现？
* 哪些数字是设计目标，哪些是压测结果，哪些是生产观测？

例如，“设计支持某个 TPS”和“生产高峰实际达到某个 TPS”，代表的证据不同。讲清楚测试条件、延迟和错误率，比单独报一个吞吐数字更有说服力。

这次复盘的感受是，准备项目深挖时，可以沿着请求链路，把每一步都问一遍：

如果这一步成功了，但下一步失败了，系统现在是什么状态？谁来恢复？重试是否安全？用户会看到什么？

能把这条链路讲清楚，整个设计会扎实很多。

也欢迎大家讨论：面试里遇到这种“第三方成功、本地结果未知”的场景，你们通常会继续追问哪些边界条件？

匿名用户 发表于 2026-11-08 18:44:21
我其实面试没怎么被深挖过personal project，奇怪了

不同公司的面试内容不一样

我其实面试没怎么被深挖过personal project，奇怪了

謝謝分享