阿里巴巴 Java / 后端怎么准备
阿里后端公开讨论里，「稳定」经常比「新组件」更重要。交易域的幂等、库存和超时是最容易被追问的三条线。
本页不写中间件清单，只练你怎么把正确性说圆。请用自己的订单或库存项目替换例子。
阿里怎么面Java后端
- 基础（线程、事务隔离）之后进入交易链路设计。
- 面试官常追问部分失败：扣了库存但订单没建起来怎么办。
- 容量题要有数字直觉：QPS、库存分片、降级开关。
面试阶段与知识点
第一批不把每个阶段拆成独立 URL，避免程序化重复页。阶段对应下面的题，练完再用模拟面试串起来。
- 事务与隔离：能解释你选的隔离级别在超卖场景的后果。
- 交易链路：下单、支付、库存、取消的状态机。
- 容量：大促预案和降级，要有你参与过的事实。
- 值班：半夜告警你怎么决策。
值得开口练的题
每题给考察点、思路、结构化参考答案和追问。参考答案用来组织语言，面试时必须换成你自己的项目事实。
用户点了两次提交，如何保证只生成一笔订单？
考察点
- 客户端重试
- 幂等令牌
- 唯一约束
回答思路
从幂等令牌讲到数据库唯一键，客户端和服务端两层都要有，不要只靠前端防抖按钮。
结构化参考答案
- 下单页先申请幂等号，提交请求必须携带；服务端按幂等号去重，重复提交返回同一结果。
- 订单表建立业务唯一键（用户加活动加令牌），冲突视为同一单，避免并发插入两笔。
- 网络超时返回「处理中」而不是让用户重试生成新单，查询接口也用同一令牌定位。
- 支付链路沿用订单号做幂等，避免一单两付或支付回调重复入账。
面试官可能追问
- 令牌存在 Redis 丢失了怎么办？
- 两个设备同时提交？
- 为什么不把防抖当充分条件？
库存 1 件，两个请求同时来，怎么避免超卖？
考察点
- 条件更新
- 预扣
- 回补
回答思路
核心是库存原子扣减，而不是先查后改；高并发下还要考虑分段库存和回补幂等。
结构化参考答案
- 用 UPDATE stock SET n=n-1 WHERE n>=1 这类条件更新，看影响行数判断是否扣减成功。
- 高并发可分段库存降低热点，但每段仍要原子扣减，售罄状态要在各段聚合后统一暴露。
- 预扣库存要有超时回补机制，回补操作本身也要幂等，防止重复回补导致库存漂移。
- 超卖一旦发生，用订单状态、赔偿策略和用户沟通收口，而不是静默改历史库存数字。
面试官可能追问
- 缓存里的库存能当准绳吗？
- 分仓库存怎么汇总售罄？
- 回补消息晚到会不会超卖后再多补？
扣库存成功但创建订单失败，你怎么回滚？
考察点
- 分布式事务替代
- 反向补偿
- 可见性
回答思路
优先讲本地消息表或事务消息等可补偿方案，少一上来堆 TCC 名词，把失败路径说清楚。
结构化参考答案
- 能放在同一数据库的尽量同事务提交；跨库存服务则先写「扣减意图」再异步建单。
- 建单失败发补偿消息回补库存，补偿逻辑可重试且幂等，避免重复回补或漏回补。
- 用户侧展示「处理中」状态，避免以为没下成又去重试造成双扣或重复订单。
- 对账任务定期扫意图表，长时间未完成的自动触发补偿或人工介入。
面试官可能追问
- 补偿失败谁来值守？
- TCC 和消息表你怎么选？
- 用户已经看到「已下单」怎么办？
大促前你怎么做容量评估？
考察点
- 链路拆解
- 瓶颈
- 降级
回答思路
用一次你参与过的压测或预案来讲，没有就明确说是方法论，并给出可量化的链路拆解。
结构化参考答案
- 把下单链路拆成入口、库存、优惠、支付回调等节点，分别估算峰值 QPS 和资源消耗。
- 找出数据库行锁、缓存热点、下游限额等瓶颈，标出最先打满的一环。
- 准备降级开关：关闭非核心功能、启用排队、降低计价精度等，并写清触发条件。
- 演练回滚和开关生效路径，确认能在分钟级内止血，而不是纸上预案。
面试官可能追问
- 压测模型和真实用户差在哪？
- 哪个接口你坚决不降级？
- 如何避免压测打到真实库存？
凌晨告警支付成功率下跌，产品希望先重启，你怎么做？
考察点
- 先观察再生手
- 最小动作
- 沟通
回答思路
值班题看你是否会在信息不足时乱动；先观测再最小化操作，同步产品和客服。
结构化参考答案
- 先看错误码分布、依赖服务健康和最近发布记录，而不是立即重启所有支付节点。
- 若是单机或单可用区异常再摘流隔离；全站问题优先走开关、限流或版本回滚。
- 同步产品和客服当前影响范围与预计恢复时间，避免私下重启造成更大抖动。
- 事后补齐故障时间线、根因分析和预防项，把临时动作沉淀进值班手册。
面试官可能追问
- 重启确实能暂时恢复，你还追根因吗？
- 和产品意见不一致谁拍板？
- 你如何避免背锅文化？
和岗位、模拟面试一起用
资料管理里保存目标岗位 JD，模拟面试会按简历出题。点题目下的按钮会把本题带进模拟开场，仍需先绑定简历与岗位。