开场说明这是一场面向校招高阶及 1-3 年 Java 后端候选人的模拟大厂一面时长约 30 分钟。面试以“会员积分系统”为业务主线串联起缓存设计、消息可靠性、事务一致性及对账补偿等核心模块。问题覆盖 Redis、MySQL、MQ、Spring 事务与 JVM 基础强调从原理到边界再到线上落地的完整链路。追问风格贴近真实大厂节奏先问用法再挖原理接着压边界场景最后落到项目取舍。候选人画像具备 Spring Boot MySQL Redis 基础开发经验参与过简单业务模块开发但对高并发、一致性保障和故障兜底机制理解较浅。主问题部分1. 你在项目中如何实现用户积分的增加请描述核心流程。参考回答 用户完成下单或签到等行为后后端接收事件先查用户当前积分然后加锁更新积分字段最后返回新积分值。使用 MySQL 的UPDATE user_points SET points points ? WHERE user_id ?保证原子性。面试官追问点是否考虑并发场景如何避免超发2. 如果积分更新频繁MySQL 压力大你会怎么优化参考回答 引入 Redis 缓存用户积分行为触发后先写 Redis再异步同步到 MySQL。Redis 使用INCRBY命令保证原子性同时设置过期时间防止冷数据长期占用内存。面试官追问点Redis 宕机了怎么办数据丢了怎么恢复3. 你说异步同步具体怎么实现用线程池还是消息队列参考回答 用消息队列更可靠。积分变更后发一条消息到 Kafka消费者监听并落库 MySQL。相比线程池MQ 提供持久化、重试和削峰能力。面试官追问点消息丢了或重复消费怎么办4. 消息重复消费怎么处理你做过幂等设计吗参考回答 在消费者端做幂等。每条消息带唯一业务 ID如user_id action_type timestamp消费前先查 MySQL 是否已处理过该 ID若已存在则跳过。面试官追问点唯一 ID 冲突概率高吗如何生成更可靠的唯一键5. 如果 Redis 和 MySQL 数据不一致你怎么发现和修复参考回答 通过定时对账任务扫描差异。每天凌晨跑批对比 Redis 中积分总和与 MySQL 实际值发现不一致则触发告警并尝试修复。修复策略可以是“以 MySQL 为准”或“以最新行为日志为准”。面试官追问点对账频率怎么定实时性要求高的话怎么办6. 你说用 Kafka那消息顺序性怎么保证比如用户连续签到两次必须按顺序处理。参考回答 Kafka 通过分区保证同一 key 的消息有序。将user_id作为消息 key确保同一用户的积分变更消息进入同一个 partition消费者单线程消费即可保序。面试官追问点分区数变了怎么办扩容后顺序性还成立吗7. Spring 事务在积分更新中怎么用的Transactional 能保证 Redis 和 MySQL 同时成功吗参考回答 不能。Transactional 只管理数据库事务Redis 操作不在事务范围内。如果先写 MySQL 成功再写 Redis 失败就会不一致。我们通常先写 MySQL再写 Redis并配合重试或补偿机制。面试官追问点那有没有办法做到“近似事务”比如两阶段提交8. 你们系统出现过积分超发吗怎么排查的参考回答 出现过一次。原因是并发签到未加锁多个请求同时读出旧值并叠加。后来加了分布式锁Redisson并在 MySQL 层用SELECT FOR UPDATE做二次校验。面试官追问点Redisson 锁过期了但业务还在执行会怎么样追问部分追问 1Redis 做积分缓存如果缓存击穿怎么办候选人可能回答加互斥锁只让一个请求回源查 DB。面试官继续压互斥锁用本地锁还是分布式锁为什么如果回源查询很慢比如用户历史积分复杂计算锁持有时间过长其他请求全阻塞怎么办有没有不阻塞的方案比如缓存空值或异步预热正确答案方向 必须用分布式锁如 Redisson因为多实例部署下本地锁无效。对于慢查询可设置锁超时 异步刷新缓存或采用“缓存空对象 延迟双删”策略。高并发场景建议预热点用户积分。追问 2Kafka 消费者宕机重启后如何保证不丢消息候选人可能回答开启自动提交 offset消费者处理完再手动提交。面试官继续压手动提交的时机怎么选处理中提交还是处理完提交如果消费者处理消息时崩溃offset 已提交但业务未落库怎么办你们有没有做消费进度监控如何快速定位积压正确答案方向 必须“处理完再提交 offset”否则会丢消息。建议结合业务日志记录处理状态或使用事务型消息如 RocketMQ。监控方面可用 Kafka Manager 或自研 dashboard 跟踪 lag。追问 3Spring Transactional 在嵌套调用时传播行为怎么选候选人可能回答一般用 REQUIRED支持嵌套事务。面试官继续压如果外层事务回滚内层事务一定回滚吗如果内层方法抛出异常但被 catch 了外层事务还会回滚吗在积分系统中发消息要不要放在事务内为什么正确答案方向 REQUIRED 下内外层共享事务任一回滚则整体回滚。但异常必须抛出才能触发回滚catch 后需手动 setRollbackOnly。发消息应放在事务提交后如 TransactionalEventListener避免事务未提交就发消息导致状态不一致。追问 4对账任务发现 Redis 积分比 MySQL 高可能是什么原因候选人可能回答Redis 未及时同步或 MySQL 写入失败但 Redis 成功了。面试官继续压如何区分是“同步延迟”还是“永久丢失”如果差异持续扩大说明系统有漏洞你如何设计自动修复策略修复时会不会引发新的不一致比如修复过程中又有新行为正确答案方向 可通过行为日志时间戳判断是否为延迟。自动修复应基于“最终一致性”原则采用“增量修复 版本号控制”修复期间新行为仍正常处理修复完成后再次校验。追问 5如果让你设计一个积分流水表你会怎么建索引候选人可能回答按 user_id 和 create_time 建联合索引。面试官继续压查询某用户最近 10 条流水SQL 怎么写索引是否生效如果还要按 action_type 筛选索引怎么调整数据量上亿后分页查询LIMIT 1000000, 10很慢怎么优化正确答案方向 索引应为(user_id, create_time DESC)查询用WHERE user_id ? ORDER BY create_time DESC LIMIT 10。加 action_type 可建(user_id, action_type, create_time)。大分页建议用游标分页基于 last_id 或 last_time。面试点评本场面试聚焦“会员积分系统”这一典型业务场景覆盖了缓存一致性、消息可靠性、事务边界、对账补偿四大核心能力域。重点考察候选人是否具备从“功能实现”到“稳定性保障”的思维跃迁。候选人易卡点混淆本地锁与分布式锁适用场景忽视消息消费的幂等与顺序保障对 Spring 事务传播理解停留在注解层面缺乏异常处理与监听器配合意识对账设计缺乏自动化与版本控制思维。高分候选人应能清晰区分“理想模型”与“工程落地”的差距并给出可落地的兜底方案。技术补丁包Redis 缓存击穿防护原理当热点 key 失效时大量请求同时击穿到 DB需通过互斥锁限制回源并发。 设计动机避免 DB 瞬时压力导致雪崩。 边界条件锁超时设置需大于业务最大处理时间否则可能重复回源。 落地建议使用 Redisson 的RLock配合缓存空值 延迟双删策略。Kafka 消息顺序性保障原理同一 key 的消息路由到同一 partition单线程消费保证顺序。 设计动机解决用户行为时序依赖问题如签到、兑换。 边界条件partition 数量变更会导致 key 重新哈希历史顺序可能被打乱。 落地建议partition 数提前规划或通过业务层 version 字段做最终一致性校验。Spring 事务传播行为REQUIRED原理若当前存在事务则加入否则新建事务。 设计动机简化嵌套服务调用的事务管理。 边界条件异常必须抛出才能触发回滚catch 后需手动标记回滚。 落地建议结合TransactionalEventListener在事务提交后发消息避免状态不一致。消息幂等消费设计原理通过唯一业务 ID 判断消息是否已处理。 设计动机应对网络重试、消费者重启等导致的重复投递。 边界条件唯一 ID 需全局唯一且稳定避免时间戳精度不足。 落地建议使用user_id action_type biz_id组合配合数据库唯一索引或 Redis set 去重。MySQL 联合索引最左前缀原则原理查询条件必须包含索引最左列才能生效。 设计动机提升多条件查询性能。 边界条件范围查询右边的列无法使用索引。 落地建议高频查询字段放左侧排序字段放右侧避免SELECT *。分布式锁 Redisson 实现原理原理基于 Redis 的SET resource_name random_value NX PX timeout命令实现。 设计动机提供跨 JVM 的互斥访问控制。 边界条件锁自动过期可能导致业务未完成就被释放引发并发问题。 落地建议使用看门狗机制自动续期或业务层加 version 控制。缓存与数据库双写一致性原理无法强一致只能追求最终一致。 设计动机提升读性能同时保障数据可靠性。 边界条件先写 DB 还是先写缓存删除缓存失败怎么办 落地建议采用“先写 DB再删缓存” 延迟双删 对账补偿组合策略。Kafka 消费者 offset 管理原理消费者记录已消费位置重启后从上次的 offset 继续。 设计动机避免重复消费或丢失消息。 边界条件自动提交可能导致消息未处理完就标记为已消费。 落地建议手动提交 offset配合业务处理状态日志。对账任务设计要点原理定期比对源系统与目标系统数据差异。 设计动机发现并修复异步系统的不一致问题。 边界条件对账期间新数据持续写入可能导致误判。 落地建议基于时间窗口对账配合 version 或 timestamp 做增量修复。Spring AOP 代理机制原理基于 JDK 动态代理或 CGLIB 生成代理对象。 设计动机实现声明式事务、日志等横切关注点。 边界条件同类内部方法调用不走代理Transactional 失效。 落地建议避免同类内自调用事务方法或通过AopContext.currentProxy()获取代理。Redis INCRBY 原子性原理Redis 单线程执行命令INCRBY 是原子操作。 设计动机替代数据库自增提升性能。 边界条件仅适用于整数值浮点需自行处理精度。 落地建议配合 Lua 脚本实现复杂原子逻辑。MySQL MVCC 与读提交隔离级别原理通过 undo log 构建数据快照实现非阻塞读。 设计动机提升并发读性能。 边界条件不可重复读问题依然存在。 落地建议积分系统通常用 READ_COMMITTED避免幻读影响对账。线程池拒绝策略原理当队列满且线程数达上限时触发拒绝。 设计动机防止资源耗尽。 边界条件CallerRunsPolicy 可能导致调用方阻塞。 落地建议积分系统建议使用 DiscardPolicy 或自定义降级策略避免影响主流程。JVM OOM 排查流程原理通过堆转储分析对象占用。 设计动机定位内存泄漏或大对象问题。 边界条件Full GC 频繁但堆不大可能是元空间溢出。 落地建议结合 Arthas 在线诊断关注静态集合、线程池未关闭等常见泄漏点。最终一致性补偿机制原理通过定时任务或消息重试达成数据一致。 设计动机弥补异步系统无法强一致的缺陷。 边界条件补偿频率与业务容忍度需平衡。 落地建议设计可重试、可幂等的补偿接口配合告警监控。