拼多多 Java / 后端怎么准备
拼多多后端公开讨论里，拼团和峰值交易出现得很多。状态多、超时多、重试多，正确性比堆缓存更关键。
五题覆盖成团、关单、支付、削峰和效率协作。用你的交易项目经历来答，不要编造平台数据。
拼多多怎么面Java后端
- 状态机题会追问所有超时分支。
- 峰值题要能讲排队和降级，而不只是加机器。
- 准备好「便宜效率」和「体验」冲突时的说法。
面试阶段与知识点
第一批不把每个阶段拆成独立 URL，避免程序化重复页。阶段对应下面的题，练完再用模拟面试串起来。
- 拼团状态机：成团和失败。
- 支付与关单：竞争条件。
- 削峰：入口保护。
- 效率：成本和体验。
值得开口练的题
每题给考察点、思路、结构化参考答案和追问。参考答案用来组织语言，面试时必须换成你自己的项目事实。
拼团差一人时超时，已支付用户怎么走？
考察点
- 状态
- 退款
- 通知
回答思路
先画状态机：待成团、已成团、已失败；超时任务只能从待成团迁出，不能误伤已成团。
结构化参考答案
- 超时关团任务用条件更新把团状态改为失败，已成团或已失败的团不受该任务影响。
- 已支付但未成团的用户走退款流水，退款必须幂等，避免重复退或漏退引发客诉。
- 通知文案要带失败原因和后续动作，减少用户反复咨询客服和投诉。
- 拼团预扣的库存要同步回补，回补操作也要幂等，防止库存长期被占用。
面试官可能追问
- 最后一秒有人加入如何与超时竞争？
- 退款渠道失败怎么办？
- 机器人成团是否允许？
关单和支付回调同时到达，如何避免关了还能算支付成功？
考察点
- 条件更新
- 支付后重开
- 用户展示
回答思路
关单和支付回调是竞争事件，要用订单行锁或版本号串行处理，避免状态互相覆盖。
结构化参考答案
- 支付回调只在订单仍为待支付时更新为已支付，已关闭则进入「支付成功但订单关闭」补偿分支。
- 补偿路径要么自动退款，要么在业务规则允许下复活订单，全程用支付单号保证幂等。
- 用户展示以最终一致为准，处理中状态不给「已关闭」和「已支付」并存的矛盾文案。
- 对账任务专门扫描这类补偿单，防止漏退或重复退长期积累成资金差异。
面试官可能追问
- 复活订单是否要重新占库存？
- 如何对账这类补偿？
- 客户端轮询看到关闭后又成功怎么解释？
活动入口 QPS 远超下单能力，你怎么削峰？
考察点
- 分层限流
- 排队
- 公平
回答思路
入口、服务、库存三层都要削峰，且对用户可理解；未扣库存前不要让用户以为已抢到。
结构化参考答案
- 边缘网关限流挡住异常客户端和刷子流量，保护后端核心下单链路。
- 业务层排队返回等待状态和预估时间，而不是把线程池拒绝直接抛给用户。
- 库存未扣减成功前，前端不展示「已抢到」类成功态，避免虚假承诺引发纠纷。
- 排队资格分配要公平，可用随机或令牌机制，避免只让网络近的机房用户成功。
面试官可能追问
- 排队放弃如何回收资格？
- 内部压测如何模拟真实排队？
- 如何防止黄牛插队？
为了省成本把很多同步改成异步，用户开始投诉「状态慢」，你怎么看？
考察点
- 关键路径
- 成本
- 体验
回答思路
不是所有链路都能异步；先找出用户必须同步感知的关键路径，再谈成本和体验权衡。
结构化参考答案
- 列出用户必须同步感知的步骤，如支付结果、成团结果，这些路径保持同步或近实时。
- 积分、推荐、统计等非关键链路可保持异步，节省资源但不影响主流程感知。
- 给关键路径设定 SLA 和超时告警，异步化不能成为延迟失控的借口。
- 用投诉率、转化率和 infra 成本数据说明异步化的收益与代价，便于和产品对齐。
面试官可能追问
- 哪条链路你绝不异步？
- 如何向成本负责人解释？
- 异步失败用户如何自助重试？
促销库存已经卖超，你先改数字还是先停活动？
考察点
- 止血
- 诚实
- 修数纪律
回答思路
先停入口止血，再修数和对外沟通；禁止先改展示数字掩盖超卖，修数要有纪律和复核。
结构化参考答案
- 立即停售或改为售罄状态，停止新订单进入，避免在已知超卖情况下继续扩大差异。
- 已下单用户按规则履约或协商处理，不偷偷改历史订单状态和库存记录。
- 对内冻结相关活动配置和手工改库存权限，防止运营再次绕过系统约束。
- 事后补强条件扣减、库存告警和对账，把这次事故沉淀成可执行的预防项。
面试官可能追问
- 对外怎么说？
- 是否赔偿？谁定？
- 如何避免运营再手工改库存？
和岗位、模拟面试一起用
资料管理里保存目标岗位 JD，模拟面试会按简历出题。点题目下的按钮会把本题带进模拟开场，仍需先绑定简历与岗位。