三丰的大厂 Java 面试从 Spring Boot 秒杀接口到 Redis、Kafka 与支付一致性三丰把简历上的“熟悉高并发架构”加粗了三遍走进一家互联网电商公司的面试间。面试官翻到项目经历“你做过限量商品秒杀。我们就用这个业务聊一款商品库存 100 件活动开始时大量用户同时下单订单需要在规定时间内完成支付。”三丰点头“这个我熟主要是让用户抢得快让服务器倒得慢。”面试官合上简历“服务器不能倒。今天三轮每轮四个问题。你可以先讲简单方案我会继续追问。”本文示例基于 Java 17、Spring Boot 3 与关系型数据库。Spring Boot 3 的基线是 Java 17相关 Servlet、JPA 等 API 使用jakarta.*包名。示例用于讲清机制生产实现还需要结合流量、数据库、部署方式和测试结果调整。第一轮先把一个订单创建正确问题 1Spring Boot 秒杀接口怎样接收请求用户身份和参数分别在哪里校验面试官“用户点击抢购发送POST /api/seckill/orders。请求里有商品 ID 和购买数量你准备怎么写”三丰“用RestControllerPostMapping接请求RequestBody接 JSON数量至少为 1。登录用户从 Spring Security 的认证上下文取不能让客户端传个userId就代表谁。”面试官“不错身份来源这一点很重要。参数合法就一定能下单吗”三丰“还得查活动时间、商品状态、限购规则。参数校验检查格式业务校验检查能不能买。”面试官“回答得清楚。那你把 Controller 写薄一点我们继续看业务层。”问题 2用 MyBatis 和事务创建订单怎样防止数据库库存变成负数面试官“库存只剩一件两个人同时读到库存为 1。先查询、再更新安全吗”三丰“不安全。可以直接执行带条件的更新库存够才扣影响行数是 1 才算成功。订单写入和库存扣减放一个事务。”面试官“很好比先查再扣可靠。事务失败呢”三丰“让它回滚。不能扣完库存订单还没写进去我就先发朋友圈庆祝。”面试官“那你知道Transactional在什么情况下可能不生效吗”三丰“这个……可能是注解心情不好。我一般重启一下。”面试官在纸上写下“事务代理边界需要补课。”问题 3用户连点两次或者超时后重试怎样避免重复订单面试官“按钮置灰够不够”三丰“不够别人可以直接请求接口。后端要有幂等键数据库加唯一约束。一个活动只允许买一次的话可以约束活动 ID 和用户 ID。”面试官“方向正确。第一次成功了但响应丢了第二次请求应该得到什么”三丰“返回之前那张订单的结果不要再扣一次库存。”面试官“很好。如果订单允许多次购买呢”三丰“那就不能拿用户 ID 一刀切得按一次业务操作设计幂等键。”面试官点了点头三丰把背挺直了两厘米。问题 4给这个接口写测试你会用 JUnit 5、Mockito 测什么三丰“JUnit 5 测成功下单、库存不足、未登录、重复请求。Mockito 模拟库存扣减失败检查没有继续创建订单。用 AssertJ 写断言。”面试官“不错。两个请求同时抢最后一件Mockito 能证明数据库不会超卖吗”三丰“我可以把 Mock 设置成只成功一次。”面试官“那只能证明你设置的 Mock 会成功一次。”三丰“懂了要用真实数据库做并发集成测试。Mock 是排练数据库才是上台。”第二轮流量上来以后别把数据库挤爆问题 5活动页大量访问用 Redis 缓存商品信息如何处理穿透、击穿和雪崩面试官“刚才订单能创建了。现在活动开始前商品详情被大量访问。”三丰“商品信息放 Redis。查询不存在的商品是穿透可以缓存短时间空值或者用布隆过滤器热点键过期是击穿可以预热并控制回源大量缓存同时过期是雪崩TTL 加随机值。”面试官“回答不错。如果 Redis 整体不可用呢”三丰“那就回源数据库。”面试官“全部请求一起回源”三丰“……数据库可能会加入 Redis 的休假群。还得限流、降级给回源设置上限。”问题 6能不能在 Redis 中预扣库存Lua 脚本解决了什么又没解决什么三丰“Lua 可以把检查库存和扣库存一起执行避免两个请求都看见最后一件。还可以一起检查用户是否已经抢过。”面试官“很好。Redis 扣成功了应用立刻宕机还没有保存订单怎么办”三丰“把库存加回去。”面试官“谁知道需要加如果消息其实已经发出只是你没收到确认呢”三丰“让定时任务……认真地看看。”面试官“需要可追踪的预占记录、幂等状态转换和对账。Lua 保证脚本内的执行原子性不会替你完成跨系统事务。”三丰小声说“原来原子也有管辖范围。”问题 7引入 Kafka 异步创建订单怎样处理发送丢失、重复消费和消费积压面试官“抢购通过后发送消息消费者再创建订单。接口可以直接返回‘下单成功’吗”三丰“应该先返回‘已受理’有请求 ID用户查询结果。还没落库不能当订单已经成功。”面试官“这点很好。消息和数据库怎么保持一致”三丰“开启 Kafka 的 exactly-once然后数据库应该也跟着 exactly-once。”面试官“Kafka 的事务语义有边界。外部数据库不会自动加入。消费成功但提交位点前宕机消息还会重来。”三丰“那数据库也要幂等。至于一致性……我简历上主要负责这一块的字体。”问题 8换成 Spring WebFlux吞吐量就一定更高吗MyBatis 能直接放进去吗三丰“WebFlux 非阻塞感觉很适合秒杀。线程少一点老板听着也舒服。”面试官“MyBatis 通过 JDBC 访问数据库通常是阻塞调用。放到事件循环线程上会怎么样”三丰“一个人堵门后面的人全排队。”面试官“对。你怎么选”三丰“现有业务都是 JDBC就先用 Spring MVC。真要做响应式链路再评估 R2DBC 和非阻塞客户端。迁移不能只换 Controller。”面试官“这次判断比较务实。隔离阻塞调用可以做过渡但不能让数据库容量凭空增长。”第三轮钱到账了系统还得说得明白问题 9支付回调重复到达且同时发生超时关单你怎么处理面试官“用户付款后支付平台回调两次。与此同时延迟任务准备关闭订单。”三丰“先验签核对商户、订单号、金额和支付状态。重复回调不能重复发货用支付流水唯一约束再按订单状态做条件更新。”面试官“基础不错。关单已经成功本地又收到支付成功呢”三丰“那就……把订单改回来”面试官“库存可能已经被别人买走。要明确支付关闭协议、查询支付结果和退款补偿不能无条件复活订单。”三丰“钱和库存同时谈恋爱果然容易有三角关系。”问题 10优惠券、库存、订单分属微服务OpenFeign 超时后要不要直接重试三丰“可以用 Resilience4j 做超时、熔断和重试。”面试官“超时意味着对方没有执行吗”三丰“不一定可能执行了但响应丢了。写请求得带操作 ID保证幂等。”面试官“很好。扣券成功、库存预占失败怎么补偿”三丰“再调用接口把券还回去。还失败就再还直到感动它。”面试官“补偿本身也要幂等、有持久化进度和重试上限还要考虑人工处理。不是一个try/catch就能覆盖全部故障。”问题 11上线后用户说下单慢Prometheus、Micrometer 和 Jaeger 怎么帮你定位三丰“Micrometer 采指标Prometheus 存和查Grafana 看图。Jaeger 看链路日志用 SLF4J 配 Logback带 trace ID。”面试官“回答得不错。你会重点看什么”三丰“接口延迟分位数、错误率、Kafka 积压、HikariCP 连接池等待、数据库慢查询。”面试官“能不能把订单号放到 Prometheus 标签里方便检索”三丰“能吧每个订单都独一无二。”面试官“正因为独一无二会产生大量时间序列。订单号更适合进入日志或受控的追踪属性指标标签要控制基数。”三丰把“独一无二”从架构优点里划掉了。问题 12用 Docker、Kubernetes 和 CI/CD 发布怎样避免升级时丢请求、丢消息三丰“流水线先跑测试再构建镜像。Kubernetes 配 readiness 和 liveness滚动发布。应用收到终止信号时优雅关闭。”面试官“不错。数据库字段改名旧 Pod 还在读旧字段怎么办Kafka 消费者处理中就被杀了怎么办”三丰“字段先别急着删用 Flyway 分阶段变更。消息要处理成功再提交位点宕机重放靠幂等兜住。”面试官“继续。终止宽限期比处理时间短呢”三丰“那就……祈祷 Kubernetes 今天比较温柔。”面试官合上笔记“基础概念有一些掌握复杂故障链路还需要深入。今天先到这里你回家等通知后续由 HR 联系。”三丰走出会议室给朋友发消息“面试官让我回家了说明他认可我的远程办公潜力。”文末答案解析把三丰含糊的地方讲清楚第 1 题答案接口分层、认证与校验一次请求通常经过过滤器、安全过滤链、Controller、Service、Mapper再访问数据库。Spring Security 在请求进入业务前完成认证与权限检查Controller 负责协议和参数转换Service 负责业务规则与事务Mapper 负责 SQL。DTO 可以写成public record SeckillRequest( jakarta.validation.constraints.NotNull Long skuId, jakarta.validation.constraints.Min(1) int quantity ) {}Controller 中使用Valid RequestBody SeckillRequest request才会触发相应的 Bean Validation项目还需要提供校验实现例如引入spring-boot-starter-validation。身份从经过验证的认证对象中读取并转换为系统内部用户 ID。客户端传来的用户 ID、商品价格、优惠金额都不能直接作为可信业务事实。JWT 必须验证签名、允许的算法、有效期以及系统要求的 issuer、audience 等声明简单 Base64 解码不等于认证。业务层还要检查活动是否开始、商品是否参与活动、购买数量是否符合限购要求。关键检查必须在实际写入或预占时仍然有效不能依赖活动页几秒前展示的数据。库存不足、重复购买属于可预期业务结果应返回明确错误码而不是全部包装成服务器异常。第 2 题答案条件更新与本地事务“先读库存再按读到的数值写回”容易产生并发竞争。可以把库存条件放进更新语句UPDATE sku_stock SET available available - #{quantity} WHERE sku_id #{skuId} AND available #{quantity};这里是 MyBatis 参数写法#{}使用参数绑定。业务层检查影响行数等于 1 才允许继续创建订单。数据库通过自己的并发控制保证这次条件更新的执行语义仍需处理锁等待、死锁和事务超时。Transactional(rollbackFor Exception.class) public OrderResult createOrder(CreateOrderCommand command) { int changed stockMapper.decrease( command.skuId(), command.quantity()); if (changed ! 1) { throw new SoldOutException(); } orderMapper.insert(command); return loadResult(command.requestId()); }该示意要求库存和订单使用同一个本地事务管理器管理的数据库资源。多个服务、多个独立数据库或 Redis 不会因为这个注解自动形成原子事务。常见事务问题包括默认代理模式下同类内部直接调用带注解的方法绕过代理对象不是 Spring 管理的 Bean捕获异常后正常返回导致事务提交选错事务管理器异步线程没有继承调用线程的事务上下文。默认回滚规则通常针对RuntimeException和Error检查型异常需要按需求配置。代理方式、方法可见性等细节也会影响拦截稳妥做法是将事务入口放在经代理调用的公开业务方法上。同一热点库存行仍可能成为数据库瓶颈。条件更新解决正确性问题高并发容量还需要入口限流、排队以及实际压测。第 3 题答案幂等键、业务唯一约束与结果复用幂等意味着同一次业务操作重复执行最终业务效果与执行一次相同。它不要求每次 HTTP 响应字节完全一致但重复请求应能查到明确、稳定的业务结果。常见约束包括同一次下单使用相同request_id并在数据库建立唯一索引。如果规则是每人每场活动只能买一次再建立(activity_id, user_id)唯一约束。保存请求关键参数的摘要防止同一个幂等键被用于不同商品或数量。不能只做“先查询是否存在再插入”因为两个请求可能同时查不到。唯一约束是并发竞争下的最终保护。竞争失败的事务应回滚再在合适的新事务或独立查询中读取已有订单避免在已失败的事务里继续工作。如果流程包含异步处理可以保存PROCESSING、SUCCEEDED、FAILED等请求状态。客户端重试时复用同一个键如果每次重试都生成新键服务端无法识别它们是同一次操作。RedisSET NX可以用于入口拦截但键会过期Redis 也有故障和恢复过程不能独自承担订单唯一性的最终保障。第 4 题答案测试必须覆盖真实故障边界单元测试验证业务分支Mockito 可以控制依赖返回值例如库存扣减返回 0 时不插入订单。JUnit 5 提供测试生命周期、参数化测试等能力AssertJ 提供可读的断言。数据库并发行为需要集成测试。可用 Testcontainers 启动与生产同类型的数据库再通过并发线程和同步屏障让多个请求争抢库存。测试结束后验证库存始终非负。成功订单对应的购买数量与库存扣减量一致。同一业务幂等键只产生一张订单。订单插入失败时库存修改确实回滚。还应测试“提交已成功但客户端没有收到响应”的重试以及消费者在数据库提交后、Kafka 位点提交前崩溃的重复处理。H2 等内存数据库适合部分测试但 SQL 方言、锁和事务隔离行为可能与生产数据库不同。并发正确性测试应优先使用实际数据库类型。Mockito 无法证明数据库锁机制、SQL 唯一约束和真实事务配置正确。第 5 题答案缓存保护的是读流量库存决策仍需权威路径穿透是请求的数据不存在缓存未命中后反复查询数据库。短 TTL 空值缓存可以缓解布隆过滤器可以快速排除明确不存在的 ID但存在假阳性新商品加入时也要更新过滤器。击穿是一个热门键失效导致大量并发回源。可以在活动前预热使用单次加载协调机制并让等待请求有超时和降级策略。逻辑过期适合允许短暂旧数据的展示内容需要后台刷新和刷新失败处理。雪崩既可能来自大量键同时到期也可能来自缓存服务整体不可用。TTL 加随机值主要缓解前者后者需要入口限流、回源配额、熔断以及允许时使用本地 Caffeine 缓存或降级页面。不能把全部流量无条件压到数据库。商品标题、图片、活动说明通常允许一定延迟真实可售库存和下单资格需要明确权威来源与一致性约束。页面显示“还有库存”只是展示实际购买仍需原子扣减或预占。更新数据库后删除缓存是常用策略但删除失败、并发回填旧值等问题仍然存在。可按业务要求引入重试、版本号、变更事件和定期校验。支付与库存等关键决策不能直接依赖可能过期的展示缓存。第 6 题答案Redis Lua 的边界与库存预占协议Lua 可以在一次脚本执行中完成“检查重复请求、判断剩余数量、扣减、写预占记录”。脚本执行期间不会被其他客户端命令穿插但运行时错误并不意味着已执行写入会自动回滚所以要先检查输入、键类型等条件再进行写操作。Redis Cluster 中多键脚本涉及的键必须落在同一个哈希槽可以使用相同 hash tag例如stock:{activity42}与reservation:{activity42}。这也意味着热点活动可能集中到一个分片需要评估容量。预占记录至少包含操作 ID、用户、商品、数量、过期时间和状态。状态可设计为RESERVED → CONFIRMED或RESERVED → RELEASED。确认与释放都必须是条件状态转换只有处于可转换状态才执行重复释放不能反复增加库存。真正复杂的地方是 Redis、Kafka 和数据库之间的故障窗口。需要明确选择一种可验证的方案例如数据库仍是库存和订单的最终权威Redis 仅做流量筛选实际成功以数据库条件更新为准。Redis 承担预占时在同一原子操作中写入可供后台转发的记录例如同槽 Stream消费者幂等落库并建立预占记录与订单的对账和修复流程。第二种方案仍需评估 Redis 持久化、复制、故障切换以及消息保留策略不能将“写入 Redis 成功”理解成绝对不会丢失。发生消息确认超时时先按操作 ID 查询和核对状态不能立即盲目回补因为消息可能已经进入下游。数据库和 Redis 都各自做一次未经协调的库存扣减会产生两套互相冲突的账。设计时必须说明哪个数值代表可售量、哪个代表预占量以及如何确认和释放。第 7 题答案Kafka、Outbox 与消费幂等异步接口返回“已受理”并提供查询 ID。最终结果至少区分处理中、订单成功和业务失败。用户体验需要超时提示与结果查询避免用户因长时间无反馈不断提交。对于数据库状态变更需要可靠发布事件的场景常用事务消息表即 Transactional Outbox在同一个数据库事务中写业务状态和待发送事件。后台任务或 CDC 读取事件并发送到 Kafka。发送确认后记录处理进度确认丢失时允许再次发送。消费者在一个数据库事务中写去重记录并完成业务修改提交后再提交消费位点。Outbox 解决的是同一个数据库事务中的业务记录与待发事件的一致性。它不会自动解决“Redis 已预占但尚未写入数据库”的窗口该窗口需要上一题中的可靠记录或补偿协议。消费者可以对event_id建唯一约束订单再对业务请求 ID 建唯一约束。若事务回滚去重记录也必须回滚否则会出现消息被标为处理过、业务却没完成的情况。Kafka 幂等生产者可以减少特定发送重试导致的重复。Kafka 事务支持特定 Kafka 读、处理、写链路的事务语义不能自动覆盖外部 MySQL 的副作用因此仍需要数据库幂等。积压要同时观察消息数量、最老消息等待时间、消费速率和失败重试。可增加分区与消费者但一个消费组内对某主题的活跃消费者并行度受分区数限制。还应限制入口、批量处理并隔离异常消息。要求同一订单事件有序时可使用订单 ID 作为分区键消息进入同一分区并不等于整个业务系统获得全局顺序。第 8 题答案MVC 与 WebFlux 要按完整调用链选择Spring MVC 适合大量现有 Servlet、JDBC 和 MyBatis 应用。常规请求处理会占用工作线程阻塞调用需要合理配置线程池、连接池和超时。WebFlux 支持响应式处理常用运行方式依赖少量事件循环线程处理大量连接。它适合等待 I/O 较多且下游具备非阻塞能力的场景例如使用 WebClient 访问远端服务、通过 R2DBC 访问支持的关系型数据库。如果直接在事件循环线程执行 MyBatis、阻塞文件读取或长时间 CPU 计算会阻塞同一线程负责的其他请求。将遗留阻塞任务放到受控调度器例如boundedElastic可以隔离影响但仍需限制并发与队列数据库连接数也不会增加。R2DBC 与 JPA、MyBatis 的编程模型不同事务上下文和错误处理也需要重新理解。响应式不是在方法返回类型外面包一层Mono就完成迁移。技术选择最终用压测判断在相同业务、资源和正确性要求下比较吞吐、P95/P99 延迟、错误率、CPU、内存和连接使用情况。同步写入密集型秒杀服务采用 MVC 完全可以合理。第 9 题答案支付幂等、订单状态机与关单竞争支付回调必须按支付平台协议验签。如果协议基于原始请求字节验签就不能先修改或重新序列化请求再验证。还要核对商户身份、订单号、金额、币种、支付状态和交易流水。金额通常用最小货币单位的整数或规范使用BigDecimal避免用浮点数参与金额计算。回调处理可在本地事务中写入带唯一约束的支付流水、按条件更新订单状态、写入后续履约事件的 Outbox。重复回调返回平台约定的成功响应履约消费者也要幂等防止重复发货。UPDATE orders SET status PAID, paid_at CURRENT_TIMESTAMP WHERE order_id #{orderId} AND status PENDING_PAYMENT;影响行数为 0 时要查询现有状态已支付可能是重复通知已关闭可能需要走异常支付处理不能一律当成功。超时任务发现本地未支付后不宜直接释放库存。支付平台可能已经扣款而回调延迟。需要调用平台查询或关闭交易并根据其协议确认交易是否已支付、能否关闭及是否仍可能支付。平台调用不宜放进长时间持锁的数据库事务里。可以采用PENDING_PAYMENT → CLOSING → CLOSED的中间状态与可重试任务再用条件更新协调支付确认和关单。具体状态转换必须符合支付平台语义。如果最终出现订单已关闭但支付成功应进入可追踪的退款或人工处理流程库存释放、退款和履约事件都需要幂等。第 10 题答案超时、重试与跨服务补偿超时表示调用方在期限内没有得到结果不能据此判断下游是否执行。库存预占、扣券、扣款等写操作必须提供稳定操作 ID下游保存执行结果并允许按 ID 查询。OpenFeign 是声明式 HTTP 客户端。Resilience4j 可以提供熔断、重试、隔离和限流等能力但具体超时由所用客户端与调用配置共同决定需要检查实际配置不能仅凭引入依赖认定保护已经生效。重试应限定异常类型、次数和总时间并使用退避与随机抖动。业务库存不足不应反复重试。网关、订单服务和下游同时重试会放大请求量因此要约定哪一层负责重试并给整个调用链设置时间预算。多个服务的业务流程可以使用 Saga每一步记录进度并配置补偿。例如先预占优惠券再预占库存最后确认订单库存预占失败后取消优惠券预占。补偿不是数据库回滚它是一个新的业务操作也可能失败因此需要持久化任务、幂等执行、状态查询和告警。库存和券可以用 TCC 思路设计Try 预留、Confirm 确认、Cancel 释放。实现时要处理重复确认、重复取消、取消先于 Try 到达以及 Try 在取消之后迟到等问题。支付这种外部副作用通常需要按平台能力使用关闭或退款流程不能假设所有服务都支持统一事务。第 11 题答案指标定位范围追踪定位路径日志还原细节Micrometer 为 Java 应用提供指标门面Prometheus 拉取或通过适当组件接收指标并查询Grafana 展示监控面板。Jaeger、Zipkin 可用于分布式追踪现代链路通常通过 OpenTelemetry 等组件采集与传播上下文。日志使用 SLF4J 作为门面绑定 Logback 或 Log4j2 等具体实现并注意依赖中不要同时引入冲突的实现。排查“下单慢”时先区分请求本身慢还是“已受理到订单创建”的异步等待时间长。建议关注HTTP 请求速率、错误率、P95/P99 延迟。秒杀受理率、订单成功率、售罄拒绝率等业务指标。Kafka lag、最老事件等待时间、消费者处理耗时与重试量。HikariCP 活跃连接、待获取连接数、连接获取耗时。数据库慢 SQL、锁等待Redis 延迟JVM GC、CPU、堆内存。业务拒绝和系统错误应分别统计否则正常售罄可能触发大量误报。Kafka lag 还需要与流量和等待时长结合单看数量不足以判断用户体验。Prometheus 的每组标签值会形成时间序列。订单号、用户 ID、原始请求 URL 可能产生巨大基数HTTP 路径宜使用/orders/{id}这样的模板。订单 ID 放入结构化日志或受控追踪属性同时避免记录支付凭证、令牌和敏感个人信息。同步 HTTP、异步 Kafka 和线程切换都需要正确传播 trace context。只在当前线程设置 MDC并不能自动保证后续异步任务继续带有 trace ID。第 12 题答案滚动发布、优雅退出与兼容迁移流水线可以依次完成 Maven 或 Gradle 构建、单元与关键集成测试、依赖检查、Docker 镜像构建以及部署验证。镜像应使用可追踪版本或摘要避免用可变的latest作为正式环境唯一依据。Kubernetes 三类探针作用不同startup 判断启动是否完成readiness 判断能否接收业务流量liveness 判断是否需要重启。数据库短暂故障不一定表示应用需要重启若将所有下游可用性都放进 liveness可能造成集体重启。优雅退出需要协调流量摘除、停止接收新任务、处理在途请求和消费者退出。readiness 变化与终止信号不是绝对即时的全局切换网关、连接复用和负载均衡传播也要纳入测试。Spring Boot 可配置优雅关闭Kubernetes 的terminationGracePeriodSeconds应覆盖所需退出时间。Kafka 消费者完成数据库提交后再提交位点被强制终止时未提交位点的消息会重新投递业务依靠幂等恢复。处理中的事件不能只保存在内存。滚动发布还会引发消费组重平衡应测试处理耗时与消费组相关超时配置。数据库升级采用“扩展—迁移—收缩”先添加新字段让新旧版本都能工作再迁移数据和切换读取最后确认旧版本退出后移除旧字段。Flyway、Liquibase 帮助管理迁移版本但 DDL 是否事务化、是否锁表取决于数据库工具不能消除这些风险。消息协议也要兼容。JSON 新增字段需要消费者允许并合理处理Protobuf 删除字段应保留编号不能复用Avro 需要按照实际读写模式配置兼容规则。回滚应用版本前同样要确认数据库与消息格式仍支持旧程序。三丰这次没能把复杂问题说清楚但每个追问都指向同一件事设计一个电商系统需要逐项说明成功条件、失败窗口、持久化记录、重复执行的处理方式以及发生偏差后如何恢复。把这些讲清楚“熟悉高并发架构”才有具体内容。