开场说明
这是一场面向 1-3 年 Java 后端候选人或校招高阶候选人的模拟大厂一面，时长约 30 分钟。面试围绕一个典型的电商活动发奖业务场景展开，串联缓存设计、消息可靠性、事务一致性及分布式协调等核心模块。问题设计兼顾广度与深度，重点考察候选人对技术原理的理解、边界条件的把握以及线上落地能力。追问风格贴近真实大厂节奏，强调“原理 → 边界 → 线上问题 → 取舍落地”的递进逻辑。
本场面试覆盖以下五大模块：
- Redis：热点 Key 处理、缓存一致性、分布式锁
- MQ / 消息队列：幂等消费、消息可靠性、延迟消息
- Spring / Spring Boot：事务传播、AOP 代理、Bean 生命周期
- MySQL：事务隔离、锁机制、binlog 与主从延迟
- 分布式系统：最终一致性、补偿机制、对账设计
我们将从一个“春节红包雨活动”的真实业务场景切入，逐步深入技术细节。
主问题部分
1. 你在项目中负责过哪些高并发活动系统？比如发奖、发券这类？
参考回答：我负责过公司春节期间的“红包雨”活动系统，用户点击页面按钮即可领取随机金额红包，每日限领 3 次。高峰期 QPS 达到 3000+，奖品包括现金券、积分、实物等。系统采用 Spring Boot + Redis + Kafka + MySQL 架构，通过多级缓存、异步发奖、消息幂等保障高可用与一致性。
追问点预判：面试官会关注你如何设计发奖流程、如何防重、如何保证不超发。
2. 红包雨活动中，你是怎么防止用户重复领取的？
参考回答：我采用了“本地缓存 + Redis 分布式锁 + 数据库唯一索引”三重防重机制。首先在 Controller 层用 Caffeine 做本地缓存，缓存用户当日已领取次数（TTL 1 分钟），减少 Redis 压力；然后在 Service 层用 Redisson 的RLock对用户 ID 加锁，防止并发请求穿透；最后在 MySQL 的user_reward_record表上对用户 ID + 活动 ID + 日期建立联合唯一索引，作为最终防重屏障。
追问点预判：面试官会追问锁的粒度、锁超时、本地缓存与 Redis 不一致等问题。
3. 你说用了 Redis 分布式锁，如果锁超时了但业务还没执行完，会发生什么？你怎么解决？
参考回答：这是一个经典问题。如果锁超时释放，而发奖逻辑还在执行，另一个线程可能重复进入，导致重复发奖。我的解决方案是：
- 设置合理的锁超时时间（如 10 秒），并评估业务最大耗时；
- 使用 Redisson 的看门狗机制（WatchDog），自动续期锁（默认每 10 秒续一次）；
- 在业务逻辑中增加状态检查，比如先查数据库是否已发奖，避免重复执行。
追问点预判：面试官可能追问看门狗原理、续期失败场景、是否用 Lua 脚本保证原子性。
4. 发奖逻辑是同步还是异步？为什么？
参考回答：采用异步发奖。用户点击后立即返回“领取成功”，实际发奖通过 Kafka 消息异步处理。原因有三：
- 发奖涉及积分、券包、短信通知等多个子系统，同步调用链太长，影响用户体验；
- 异步可削峰填谷，应对突发流量；
- 便于后续扩展，比如增加风控审核、人工干预等流程。
追问点预判：面试官会追问消息丢失、重复消费、顺序性等问题。
5. Kafka 消息如何保证不丢失、不重复？
参考回答：
- 不丢失：生产者开启
acks=all，确保消息写入所有 ISR 副本；Broker 配置min.insync.replicas=2；消费者手动提交 offset，处理完再提交。 - 不重复：消费者端实现幂等。我采用“消息 ID + 业务唯一键”存入 MySQL，消费前先查是否已处理。消息 ID 由 Snowflake 生成，保证全局唯一。
追问点预判：面试官会追问 Snowflake 时钟回拨、幂等表设计、高并发下幂等性能。
6. 幂等表在高并发下会不会成为性能瓶颈？你怎么优化？
参考回答：确实可能。我的优化策略包括：
- 幂等表按用户 ID 分表（16 张），分散写入压力；
- 使用 Redis 做一级幂等缓存，缓存已处理的消息 ID（TTL 7 天），命中则直接返回；
- 幂等表只存必要字段（msg_id, user_id, status, create_time），并建联合索引；
- 定期归档历史数据，避免单表过大。
追问点预判：面试官可能追问 Redis 缓存与 DB 不一致、分表策略、归档机制。
7. 如果发奖过程中某个子系统（比如积分系统）挂了，你怎么保证最终一致性？
参考回答：我设计了一套“本地事务表 + 定时任务补偿”机制。发奖服务在本地事务中同时写入“发奖记录”和“待发送消息”两张表，保证原子性。然后由定时任务扫描“待发送消息”表，重试发送 Kafka 消息。如果积分系统恢复，消息可重新消费；如果长时间失败，则触发告警，人工介入。
此外，我们还做了对账系统，每天凌晨比对发奖记录与积分变动，发现不一致则自动补偿或告警。
追问点预判：面试官会追问本地事务表如何防重、定时任务频率、对账粒度。
8. 对账系统是怎么设计的？比对哪些数据？
参考回答：对账系统基于 MySQL binlog + Kafka 构建。我们使用 Canal 监听发奖记录表的变更，发送到 Kafka，由对账服务消费。对账服务每天凌晨执行以下比对：
- 发奖记录中“已发放”状态的记录数 vs 积分系统当日积分增加记录数；
- 按用户维度比对积分变动总额是否一致；
- 发现差异则生成对账异常单，支持手动重试或自动补偿。
追问点预判：面试官可能追问 Canal 原理、对账延迟、补偿策略。
追问部分
追问 1：你说用 Canal 监听 binlog，如果 Canal 挂了或者延迟很高，对账会不准，你怎么监控和应对？
考察点：分布式系统可观测性、故障恢复能力
参考回答：我们做了三层监控：
- Canal 实例存活监控（Prometheus + Grafana），挂了自动告警；
- Kafka 消息堆积监控，如果 lag 超过 10 万条，触发告警；
- 对账服务自身记录“最后处理时间”，如果超过 24 小时未更新，说明卡住了。
应对措施：
- Canal 挂了自动重启（K8s 托管）；
- 延迟高时，临时增加对账任务并行度；
- 极端情况下，支持手动触发全量对账（按天回溯）。
追问 2：Redis 缓存用户领取次数，如果 Redis 挂了，本地缓存也失效，会不会导致超发？
考察点：缓存高可用、降级策略
参考回答：这是个关键风险点。我们的降级策略是：
- Redis 挂了，本地缓存失效，但数据库唯一索引仍有效，最多导致少量重复请求打到 DB；
- 由于有唯一索引，重复插入会失败，不会超发；
- 同时，我们配置了 Redis 集群（哨兵模式），单点故障自动切换；
- 极端情况下，可临时关闭活动入口，避免雪崩。
补充：我们还在 Nginx 层做了限流，单用户每秒最多 5 次请求，进一步降低风险。
追问 3：你说用 Redisson 看门狗续期，如果 GC 停顿导致续期失败，锁被释放，会怎样？
考察点：JVM 与分布式系统交互、GC 影响
参考回答：Redisson 看门狗通过一个后台线程每 10 秒续一次锁（默认 leaseTime=30s）。如果发生 Full GC，线程暂停，续期失败，锁被释放。此时另一个线程可能获取锁并执行发奖。
我们的应对：
- 在业务逻辑中增加“状态检查”：执行前先查数据库是否已发奖；
- 发奖记录表有唯一索引，重复插入会抛异常，被捕获后忽略；
- 监控 GC 时间，避免长时间停顿（我们用的是 G1，MaxGCPauseMillis=200ms）。
面试点评
本场面试主要考察候选人在高并发活动场景下的系统设计能力，重点包括：
- 防重设计：从本地缓存到分布式锁再到数据库唯一索引的多层防御；
- 消息可靠性：Kafka 生产消费配置、幂等实现、补偿机制；
- 最终一致性：本地事务表、定时补偿、对账系统；
- 边界与容错：锁超时、缓存失效、GC 影响、主从延迟等极端场景应对。
候选人容易卡壳的点：
- 看门狗续期原理不清楚；
- 幂等表设计未考虑分表与性能；
- 对账系统只提概念，无具体实现细节；
- 忽略 GC 对分布式锁的影响。
整体强度适中，适合 1-3 年候选人，既能展示广度，也有深度追问空间。
技术补丁包
Redis 分布式锁（Redisson）原理：基于 Lua 脚本实现原子加锁，看门狗线程自动续期（默认每 10 秒续一次，leaseTime=30s）。 设计动机：解决锁超时导致并发安全问题。 边界条件：GC 停顿可能导致续期失败；锁粒度应尽量细（如 userId）。 落地建议：结合业务状态检查，避免依赖锁作为唯一防重手段。
消息幂等消费原理：通过唯一消息 ID + 业务键判断是否已处理。 设计动机：防止网络重试或消费者重启导致重复消费。 边界条件：幂等表可能成为热点；Redis 缓存与 DB 不一致。 落地建议：采用“Redis 缓存 + DB 唯一索引”二级幂等，分表分散压力。
本地事务表 + 异步消息原理：在本地事务中同时写入业务数据和待发送消息，保证消息不丢失。 设计动机：解决分布式事务难题，实现最终一致性。 边界条件：定时任务可能延迟；消息重复发送。 落地建议：消息表需有状态字段（pending/sent/failed），支持重试与告警。
对账系统设计原理：基于 binlog 监听 + Kafka + 定时比对，发现数据不一致。 设计动机：保障跨系统数据最终一致。 边界条件：binlog 延迟；对账任务性能瓶颈。 落地建议：按天分片对账，支持手动触发；异常单需有处理流程。
Canal 监听 binlog原理：伪装成 MySQL 从库，接收 binlog 事件并转发至 Kafka。 设计动机：解耦数据变更与业务逻辑，实现数据同步。 边界条件：Canal 实例单点故障；网络延迟导致 lag。 落地建议：部署多个 Canal 实例，监控 lag 与存活状态。
缓存降级策略原理：当 Redis 不可用时，依赖数据库唯一索引兜底。 设计动机：保障系统基本可用性。 边界条件：数据库压力增大；短暂不一致。 落地建议：结合限流（如 Nginx 层）控制请求量。
Kafka 消息可靠性原理：生产者
acks=all，Broker 多副本，消费者手动提交 offset。 设计动机：防止消息丢失。 边界条件：ISR 副本不足时写入失败；消费者处理慢导致 lag。 落地建议：监控 ISR 数量与 lag，合理设置副本数。GC 对分布式系统影响原理：Full GC 导致线程暂停，影响看门狗续期。 设计动机：理解 JVM 与分布式组件的交互风险。 边界条件：长时间 GC 停顿（>30s）。 落地建议：使用 G1 垃圾回收器，控制 MaxGCPauseMillis；业务层增加状态检查。
数据库唯一索引防重原理：利用唯一约束阻止重复插入。 设计动机：作为最终防重屏障。 边界条件：高并发下唯一索引可能成为热点。 落地建议：合理设计索引字段（如 user_id + activity_id + date），避免全表扫描。
多级缓存一致性原理：本地缓存（Caffeine） + 分布式缓存（Redis） + DB。 设计动机：提升读取性能，降低 DB 压力。 边界条件：缓存与 DB 不一致；缓存雪崩。 落地建议：本地缓存设置短 TTL（如 1 分钟），Redis 做主缓存，DB 为数据源。
定时任务补偿机制原理：扫描未处理消息，重试发送。 设计动机：应对子系统临时故障。 边界条件：任务执行频率与性能；重复处理。 落地建议：任务分片执行，记录最后处理 ID，避免全表扫描。
Snowflake 消息 ID 生成原理：基于时间戳 + 机器 ID + 序列号生成全局唯一 ID。 设计动机：保证消息唯一性。 边界条件：时钟回拨导致 ID 重复。 落地建议：使用开源实现（如 Hutool），或引入 Zookeeper 协调机器 ID。
Redis 集群高可用原理：哨兵模式或 Cluster 模式自动故障转移。 设计动机：避免单点故障。 边界条件：主从切换期间短暂不可用。 落地建议：监控主从状态，配置合理超时时间。
Nginx 限流原理：基于 IP 或用户 ID 限制请求频率。 设计动机：防止恶意刷奖。 边界条件：误杀正常用户。 落地建议：结合业务场景设置合理阈值（如 5 req/s）。
对账异常处理流程原理：发现不一致后生成异常单，支持自动补偿或人工处理。 设计动机：保障资金安全。 边界条件：自动补偿可能失败。 落地建议：异常单需有状态流转（待处理/已补偿/已关闭），并通知相关人员。
G1 垃圾回收器调优原理：分代收集，可预测停顿时间。 设计动机：减少 Full GC 对业务影响。 边界条件：Region 大小配置不当。 落地建议：设置
-XX:MaxGCPauseMillis=200，监控 GC 日志。消息表状态机设计原理：定义消息状态（pending/sent/failed/retrying）。 设计动机：支持重试与监控。 边界条件：状态流转逻辑复杂。 落地建议：使用状态模式，避免 if-else 泛滥。
分表策略原理：按用户 ID 哈希分表。 设计动机：分散写入压力。 边界条件：跨分片查询困难。 落地建议：分表数取 2 的幂（如 16），便于扩展。
缓存穿透防护原理：对不存在的数据也缓存空值。 设计动机：防止恶意查询不存在 key。 边界条件：空值缓存可能占用内存。 落地建议：设置较短 TTL（如 5 分钟）。
最终一致性 vs 强一致性原理：允许短暂不一致，通过补偿达到一致。 设计动机：提升系统可用性。 边界条件：对账周期内数据不一致。 落地建议：根据业务容忍度选择，金融类业务慎用。
