应届生 Java 面试复盘:XXL-JOB 防重复,为什么答成了接口防刷?

最近整理了一场应届生的 Java 后端方向面试。

候选人是一名应届生，曾在北森云计算做 Java 开发实习，参与过智能求职平台后端开发。自我介绍中提到了 Spring Boot、Spring MVC、MyBatis、Spring Cloud Alibaba、Redis、MQ、ES 和 MySQL。

从技术栈来看，候选人接触的内容比较多。

但这场面试真正值得复盘的地方，不是技术名词有多少，而是项目细节能不能讲清楚，以及连续追问之后，回答能不能继续围绕问题展开。

一、项目经历首先要说明来源

面试一开始，候选人介绍了两个项目。

一个是智能求职平台，属于北森云计算实习期间参与的项目。

另一个是银行类项目。面试官继续追问，这个项目是不是候选人从零到一自己完成的。

候选人先表示，这是自己找项目练习。之后又进一步说明，项目来自 GitHub 开源项目，自己主要负责其中一个模块，并不是公司项目。

这里其实暴露了一个常见问题。

「我做过一个银行项目」和「我基于 GitHub 开源项目练习过其中一个模块」，在面试官看来代表完全不同的经验深度。

开源项目本身并不丢人，个人练习也可以体现学习能力。真正需要避免的是项目归属模糊，让面试官误以为这是完整的自研项目。

介绍项目时，最好主动说清楚四件事：

• 项目从哪里来
• 项目服务什么业务
• 自己负责哪一个模块
• 哪些功能是自己真正实现的

项目来源说得准确，反而更容易建立可信度。

二、并行编排降耗约 60%，但口径还不够完整

面试官根据简历，追问了企业列表接口。

这个接口会调用搜索、推荐和企业信息三个服务。候选人提到，因为三个服务之间没有依赖，所以采用并行编排，耗时大约下降了 60%。

这里的 60% 是候选人对智能求职平台列表接口的自述，录音没有交代原始耗时、测试样本、压测环境和具体统计方式。

所以发布时只能写成候选人自述，不能把它写成普遍适用的性能结论。

面试官继续追问，如果企业信息服务突然变慢，如何保证整个列表接口不超时。

候选人提到了降级、熔断、自定义降级类和降级方法，方向上并不完全错误。

问题出现在继续追问之后。

当面试官问到超时时间和自定义线程池，候选人的回答混入了公共线程池、TTL 和最终一致性，几个概念之间没有形成完整链路。

这道题更稳妥的回答顺序应该是：

第一，给每个下游服务设置独立超时时间。

第二，给整个列表接口设置总截止时间。

第三，无依赖的服务可以并行调用，但线程池要控制规模，避免大量请求把资源耗尽。

第四，某个服务超时后，要明确返回空结果、默认值，还是直接降级。

第五，如果数据允许延迟，可以通过缓存或异步补偿降低主链路压力。

面试官想听的不是“并行、熔断、降级”这些词本身，而是故障发生后，接口还能不能稳定返回，以及每一步由谁负责。

三、Redis 挂掉之后，是保证可用还是保证不重复？

候选人提到，Redis 用来记录用户已经看过的职位，从而对推荐结果进行去重。

面试官问，如果 Redis 挂掉，用户会不会看到重复推荐。

候选人的回答是，Redis 异常时可以先关闭去重逻辑，优先保证列表正常展示。等 Redis 恢复之后，再恢复去重功能。

这个思路体现了可用性优先。

但它也带来了明确代价。Redis 故障期间，用户可能看到重复推荐。

这并不能简单判断为对或错，关键要看业务对于重复推荐的容忍度。

如果推荐列表只是体验优化，放行数据可能比接口整体不可用更合理。如果 Redis 记录的是支付、库存或权限状态，就不能直接放行。

面试官又追问，Redis 恢复后数据不一致怎么办。

候选人提到了先更新数据库，再删除缓存，并补充最终一致性兜底。

这里还可以继续讲清楚：

• 故障期间哪些数据允许重复
• 恢复后是否需要重新构建去重集合
• 是否需要补偿任务
• 补偿过程如何避免再次重复
• 业务是否需要保留降级期间的记录

真正有经验的回答，不是只说“缓存失效就降级”，而是能够说明降级期间发生了什么，恢复之后怎样把状态补回来。

四、MQ 消费失败，候选人的回答相对完整

相比前面的回答，MQ 这道题讲得更有层次。

候选人提到了生产端同步发送，等待 Broker 返回 ACK。发送失败时进行重试，也可以通过本地事务日志进行消息补偿。

消费端采用手动提交 offset，只有业务处理成功后才提交消费位置。如果消费失败，就进行重试。多次重试仍然失败，则进入死信队列，后续再人工补偿。

这段回答至少覆盖了三个环节：

• 生产端如何确认消息发送成功
• Broker 如何持久化消息
• 消费端如何重试和提交 offset

不过，如果继续追问，还需要补充消费幂等。

因为消息系统通常不仅要考虑消息丢失，也要考虑重复消费。消费端即使手动提交 offset，在网络超时、消费者重启或重试场景下，也可能再次处理同一条消息。

所以完整回答还应该说明：

• 如何判断消息是否已经处理
• 是否使用业务唯一号
• 数据库是否有唯一约束
• 重复消费时如何安全返回
• 死信消息如何人工补偿并防止二次重复

五、ES 深度分页不能只说“优化查询”

面试官问到 ES 深度分页。

如果用户翻到第 1000 页、2000 页，ES 性能明显下降，应该怎么优化，是否限制最大页码。

候选人先提到了 search_after，之后又提到了 DSL 优化、索引分片、缓存和 Sentinel 慢调用阈值。

这些内容都和性能有关，但没有完整回答深分页为什么会变慢。

更稳妥的回答应该分为三步。

第一，说明传统 from/size 深分页会让查询过程保留前面大量结果，页数越深，内存和 CPU 压力越大。

第二，数据量较大时，可以使用 search_after，并保持查询条件和排序字段稳定。

第三，从产品层限制最大结果范围，或者改成滚动加载，避免用户无限翻页。

如果只说“把分片调一下、把缓存打开”，面试官很难确认候选人是否真正理解深分页问题。

六、整场面试最值得看的追问

面试官最后问 XXL-JOB。

问题很明确：

如果定时任务部署在多台机器上，如何保证同一条数据不会被重复处理？

候选人的回答却转向了：

• JWT 或 API Key 鉴权
• RBAC 权限控制
• HTTPS 加密
• 内网部署
• 防火墙和安全组
• API 网关
• 接口限流
• 异常 IP 封禁

这些内容属于接口安全和访问控制，不能直接解决定时任务重复处理。

题目真正想考察的，至少包括两个层面。

第一层是任务怎么分配

需要明确使用什么路由策略，是否使用 XXL-JOB 分片广播，分片参数如何传递，每台机器处理哪一部分数据。

第二层是业务如何幂等

即使任务被重试、网络超时、执行器故障，也要保证同一条业务数据不会被重复处理。

这时可以结合业务场景选择：

• 数据库唯一约束
• 处理状态字段
• 业务流水号
• 分布式锁
• 幂等表
• 消息去重记录

分片解决的是“谁处理哪部分数据”。

幂等解决的是“同一条数据重复到达怎么办”。

这两个问题有关联，但不能混成一个答案。

这也是整场面试最值得做成短视频的一段。面试官问的是任务重复处理，候选人回答的是接口安全防护，技术词汇不少，但没有回答题目本身。

七、MySQL 和 Spring 事务部分暴露了基础掌握程度

在 MySQL 联合索引问题中，面试官给出一个包含 user_id 和 create_time 的场景，询问谁应该放在前面。

候选人回答 user_id 在前，create_time 在后，理由是 user_id 更像等值匹配，create_time 更像范围查询。

如果实际查询条件确实是 user_id 等值过滤，再按照 create_time 范围查询，这个思路是合理的。

后面问到 Spring 事务为什么可能不生效，候选人提到了几个关键场景：

• private 方法无法被代理增强
• 本类内部调用绕过代理对象
• try-catch 吞掉异常
• 默认回滚规则与异常类型有关

这些点基本抓到了方向，但回答中出现了多次“好像”和停顿，说明概念还没有形成稳定表达。

面试时，知道几个关键词只是基础。更重要的是把问题讲成完整因果链：

为什么没有经过代理，为什么事务没有开启，异常为什么没有继续向外抛，以及什么情况下默认不会回滚。

八、这场面试给 Java 求职者的提醒

第一，讲项目时先说业务目标，再说个人负责的模块。不要只报技术栈。

第二，项目来源要主动说明。公司项目、开源项目、个人练手项目可以都写，但不能混在一起表达。

第三，遇到连续追问时，先判断面试官真正想问什么。题目问幂等，就不要转到鉴权。题目问深分页，就不要只讲缓存。

第四，所有性能数字都要有范围和口径。耗时下降 60% 到底是哪个接口、什么环境、和什么基线对比，需要说明清楚。

这场面试里，候选人并不是完全没有技术基础。

他能说出并行编排、Redis 降级、MQ 重试、死信队列、EXPLAIN、联合索引和事务失效场景。

真正影响回答质量的，是项目细节没有始终讲稳，部分问题在连续追问后开始偏离核心。

如果是你来回答 XXL-JOB 多机执行防重复，你会先讲分片、锁，还是业务幂等？