“什么叫你打了 4 次 lumi 都没打过？！”
第一次看到这句话，我也愣了一下。后来才发现，这里的“打”不是游戏里的“打 Boss”，而是后端联调中常说的“打接口”；lumi 也不是某个角色名，而是业务系统里的一个内部任务代号。更准确地说，它通常指一个批量触发、数据同步或外部服务回写任务。连续调用 4 次都没有真正生效，说明问题大概率不是因为运气差，而是接口设计、幂等控制、事务边界或日志排查上出了系统性漏洞。
这篇文章就围绕这个场景展开。我会先解释这种“连续多次调用仍失败”的问题究竟属于哪类技术问题，再给出一个最小可复现的后端示例工程，用代码来演示如何设计任务接口、如何记录执行状态、如何判断一次任务到底有没有真正成功。你不需要知道 lumi 具体是某套业务系统里的什么服务，你只需要把它理解成：一个你正在排障的内部服务代号。搞懂排查思路之后，可以把 lumi 替换成你自己的 Batch 任务、RPC 接口或消息队列消费者。
1. 为什么会出现“连续打了 4 次都没打过”的问题
1.1 lumi 只是一个占位服务，问题本质是“看起来成功，实际没成功”
在真实的后端系统里，任务执行失败并不是只有“接口直接报错”一种表现。更常见的情况是：调用方收到 HTTP 200，接口日志里也打印了任务执行成功，但最后查询业务结果时，发现数据没有变化。于是调用方只能再提交一次，第二次又看到“成功”，再查业务数据，还是没变化。这样反复几次，同事就会忍不住问：什么叫你打了 4 次 lumi 都没打过？
之所以会出现这种局面，通常是因为调用方把“请求送达服务端”和“业务处理成功”这两件事混为一谈。请求成功提交到服务端，只代表 HTTP 请求被 Controller 接收了，不代表业务状态从 INIT 变成 SUCCESS，也不代表数据库里那条记录被正常更新。真正的成功标准，应该是核心业务数据发生了预期变化，并且这个变化可被查询、可被审计、可被重复验证。
1.2 这类问题通常涉及哪些核心矛盾
连续多次调用仍失败，问题往往不是单点原因，而是多层因素叠加。从调用方看，可能是重试策略不合理、请求参数每次都不一样、没有判断返回值；从服务提供方看，可能是任务执行没有做状态持久化、没有做幂等、异常被 try-catch 吞掉后返回成功；从基础设施看，可能是分布式锁没锁住、事务边界开得过大、缓存和数据库数据不一致、消息队列重复消费。
换句话说，这不是一个简单的“多打几次就能成功”的问题。如果每次请求都没有留下可追踪的执行记录，那么第 4 次和第 1 次本质上没有区别，都是在重复踩同一个坑。正确做法是先把第 1 次失败的真实原因找出来，再决定是否允许自动重试、如何防止重复执行、如何让下一次执行能真正成功。
2. 示例场景与排错环境准备
2.1 一个可复现的四次失败场景
假设业务系统里有一个内部任务代号叫 lumi，它的作用是：根据调用方传入的 requestId，执行一次资产数据同步。调用方每次提交任务时都会生成一个新的 requestId，期望最终能把某个业务表的状态更新为 SUCCESS。
第一次调用，任务接口返回 200，但数据库中没有任何记录被创建。原因是 lumi 的核心业务处理抛出了异常，但异常在 Controller 层被一个比较宽泛的 catch 语句捕获后，返回了一个固定的 success 标记。第二次调用，调用方换了新的 requestId，接口还是返回 200，但状态表只插入了一条 RUNNING 记录，没有更新成 SUCCESS。原因是任务里开启了数据库事务，执行异常后整个事务回滚，RUNNING 记录也随之消失。第三次调用，更换了锁的过期时间，但发现任务被并发触发，两个请求同时进入，数据库唯一索引拦截了其中一个请求，而拦截后的异常没有被转换为可理解的错误提示。第四次调用，调用方终于看到了明确的失败信息，但还不知道怎么自动恢复。
这个场景看起来很复杂，但拆解之后，技术点非常集中：任务状态机设计、幂等控制、事务边界、异常处理和可观测性。下面我们围绕这些点展开。
2.2 技术栈说明与版本原则
本文示例以 Java 17 和 Spring Boot 3.x 为基础，数据库使用 MySQL 8.x，缓存和分布式锁相关的讨论会结合 Redis 展开。不过本文的核心并不绑定某个具体版本，如果你使用的是 Spring Boot 2.7.x 或 JDK 11，大部分代码思路同样适用。版本差异主要存在于部分依赖的命名和自动配置类上，遇到问题时优先以你当前项目的依赖版本为准。
项目的关键依赖包括：spring-boot-starter-web 提供 HTTP 接口能力，spring-boot-starter-jdbc 负责数据库访问，mysql-connector-j 驱动连接 MySQL。下面的示例中我还会用到 Redis 做锁演示，但即使你没有 Redis，也可以先用数据库唯一索引完成幂等控制。
2.3 项目结构说明
为了便于阅读，我们约定项目结构如下：
src/main/java/com/example/lumi/ ├── LumiApplication.java ├── controller/ │ └── LumiTaskController.java ├── service/ │ └── LumiTaskService.java └── model/ └── LumiRunRequest.java如果你已经熟练使用 Spring Boot，也可以把类名改成你自己项目里的命名风格。重点是理解 Service 层中状态处理的思想，而不是照搬包名。
3. 一次调用失败后，优先排查哪四层原因
3.1 请求真的到达服务端了吗
先把最简单的可能排除掉。当调用方说“我打了 4 次 lumi 都没打过”时，第一步不是查业务代码，而是确认这 4 次请求是否真的到达了 lumi 服务端。可以使用操作系统的网络排查命令查看端口连通性，也可以在 lumi 服务端打印一条请求入口日志，记录请求路径、请求参数和请求时间。由于文章主题不是网络排查，这里不展开抓包细节，但这个步骤不能跳过。
很多长时间排查无果的问题，最后发现是网关路由规则写错了，请求根本没有转发到 lumi 服务上。调用方看到的 200 响应来自网关的默认响应，而不是 lumi 业务代码的返回结果。这也是“打了 4 次都没打过”的常见原因之一：你打的对象可能从一开始就错了。
3.2 服务端真的执行成功了吗
确认请求到达服务端后，继续查服务端日志。这里要看三个关键点：第一，Controller 方法是否入参正确；第二，Service 方法是否抛出了异常；第三，异常是否被某个全局异常处理器或 try-catch 代码块吞掉。
较常见的错误写法是：
try { lumiTaskService.run(request); return Result.success(); } catch (Exception e) { log.error("lumi 任务执行失败", e); return Result.success(); }这段代码的问题很明显：异常已经被日志记录下来，但接口仍然返回成功。如果调用方只看 HTTP 状态码和返回体里的 success 字段，会误以为任务已经执行成功。这种“吞异常返回成功”的做法，在联调和排障阶段会带来极大的误导。正确的做法是遇到异常时返回明确的失败状态，至少要让调用方知道这次调用没有成功。
3.3 结果真的反馈给调用方了吗
即便服务端已经成功处理完业务，也可能因为返回结构设计不合理，导致调用方无法判断成功。比如任务接口设计成异步模式，提交后立即返回“已受理”，但真正执行是在后台线程中完成。这时候如果调用方不理解异步语义，就会以为“受理成功”等于“业务成功”。
所以建议在接口返回结构中明确区分两种状态：
taskStatus: ACCEPTED这种状态表示任务已经被接收，但仍需要后续主动查询任务结果。对于同步任务，则可以直接返回 SUCCESS 或 FAILED。如果你正在排障“连续多次调用不生效”，先检查接口返回的状态语义是否被调用方正确理解，再看 Service 内部的最终业务表状态。
3.4 为什么重复执行后依然失败
如果多次请求每次都生成了不同的 requestId，每次都返回成功，但数据库里仍然没有正确结果，那就要考虑是否是同一个底层原因在反复触发。举例来说，如果 lumi 任务执行前需要查询一个配置表，而这个配置表里缺少必要数据，那么换多少 requestId，执行多少次，都会在同一个位置失败。此时不停重试没有意义，应该先补全前置数据，或者把失败原因在日志和返回结果里完整暴露出来。
从工程经验看，一个任务连续失败多次，最值得警惕的是：每次失败都发生在同一个状态。这时要找出失败位置的共同点，而不是继续发起第 5 次调用。
4. 手把手写一个最小可运行的 lumi 任务接口
4.1 需求定义
下面我们实现一个简化版 lumi 任务接口。接口接收两个参数：requestId 和 operator。requestId 是本次任务的幂等键，operator 记录操作人。接口每次被调用时，需要先检查 requestId 是否已经成功执行；如果已经成功，直接返回成功；如果没有执行过，则插入一条 RUNNING 记录，然后执行业务逻辑；业务执行成功后将状态更新为 SUCCESS；业务执行失败则把状态更新为 FAILED，并记录错误信息，方便下一次重试。
为了避免代码过长导致理解困难，这里不引入 Redis 锁，只使用数据库唯一索引做幂等控制。真实项目中，如果你需要防止多个线程同时处理同一个 requestId，可以在此基础上增加 Redis 分布式锁。先掌握数据库幂等，再扩展锁，会更轻松。
4.2 数据库表设计与 SQL
先创建 lumi 任务的执行记录表。这张表是判断“到底有没有打过”的核心依据：
CREATE TABLE lumi_exec_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '主键', request_id VARCHAR(64) NOT NULL COMMENT '请求幂等ID', operator VARCHAR(64) NOT NULL COMMENT '操作人', status VARCHAR(16) NOT NULL COMMENT '状态：RUNNING/SUCCESS/FAILED', error_msg VARCHAR(500) DEFAULT NULL COMMENT '失败原因', create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间', UNIQUE KEY uk_request_id (request_id) ) ENGINE = InnoDB DEFAULT CHARSET = utf8mb4 COMMENT = 'lumi任务执行记录表';表结构的关键点是 request_id 上的唯一索引。这个唯一索引可以防止同一个 requestId 被并发重复执行。status 字段用来记录任务从开始到结束的完整生命周期。
4.3 Spring Boot 配置文件
在 src/main/resources/application.yml 中配置数据源：
server: port: 8080 spring: application: name: lumi-demo datasource: url: jdbc:mysql://localhost:3306/lumi_demo?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: your-password driver-class-name: com.mysql.cj.jdbc.Driver这里需要替换成你自己的数据库地址、账号和密码。如果你的 MySQL 不是 8.x，driver-class-name 可能需要改成旧版驱动。第 4.2 节创建的表在当前数据库中已经存在后，才能继续运行接口。
4.4 Lumi 任务 Service 核心代码
在 src/main/java/com/example/lumi/service/LumiTaskService.java 中，加入如下核心代码：
package com.example.lumi.service; import org.slf4j.Logger; import org.slf4j.LoggerFactory; import org.springframework.dao.DuplicateKeyException; import org.springframework.dao.EmptyResultDataAccessException; import org.springframework.jdbc.core.JdbcTemplate; import org.springframework.stereotype.Service; import java.util.Objects; @Service public class LumiTaskService { private static final Logger log = LoggerFactory.getLogger(LumiTaskService.class); private static final long RUNNING_TIMEOUT_SECONDS = 120L; private final JdbcTemplate jdbcTemplate; public LumiTaskService(JdbcTemplate jdbcTemplate) { this.jdbcTemplate = jdbcTemplate; } public void run(String requestId, String operator) { String status = queryStatus(requestId); if ("SUCCESS".equals(status)) { log.info("幂等命中，requestId={} 已成功，直接返回", requestId); return; } if ("RUNNING".equals(status)) { if (isRunningTimeout(requestId)) { log.warn("requestId={} 执行超时，标记为失败", requestId); markFailed(requestId, "running timeout, please retry with new requestId"); } else { throw new IllegalStateException("requestId=" + requestId + " 正在执行中，请勿重复提交"); } } try { insertRunningRecord(requestId, operator); } catch (DuplicateKeyException e) { String currentStatus = queryStatus(requestId); if ("SUCCESS".equals(currentStatus)) { log.info("重复请求，但 requestId={} 已成功，直接返回", requestId); return; } throw new IllegalStateException("requestId=" + requestId + " 已存在，状态为 " + currentStatus, e); } log.info("lumi 任务开始执行，requestId={}", requestId); try { executeLumiCoreTask(requestId); } catch (Exception e) { log.error("lumi 任务执行失败，requestId={}", requestId, e); markFailed(requestId, e.getMessage()); throw e; } markSuccess(requestId); log.info("lumi 任务执行成功，requestId={}", requestId); } private void executeLumiCoreTask(String requestId) { // 这里替换成真实业务逻辑，比如同步数据、生成报表、调用远程服务。 // 为了示例方便，这里只做一件事：如果是 mock-fail 开头的 requestId，就触发失败。 if (requestId != null && requestId.startsWith("mock-fail")) { throw new RuntimeException("mock business exception"); } } private String queryStatus(String requestId) { try { return jdbcTemplate.queryForObject( "SELECT status FROM lumi_exec_record WHERE request_id = ?", String.class, requestId); } catch (EmptyResultDataAccessException e) { return null; } } private boolean isRunningTimeout(String requestId) { try { Long seconds = jdbcTemplate.queryForObject( "SELECT TIMESTAMPDIFF(SECOND, create_time, NOW()) FROM lumi_exec_record WHERE request_id = ?", Long.class, requestId); return seconds != null && seconds > RUNNING_TIMEOUT_SECONDS; } catch (EmptyResultDataAccessException e) { return false; } } private void insertRunningRecord(String requestId, String operator) { jdbcTemplate.update( "INSERT INTO lumi_exec_record(request_id, operator, status, error_msg) VALUES (?, ?, 'RUNNING', NULL)", requestId, operator); } private void markSuccess(String requestId) { jdbcTemplate.update( "UPDATE lumi_exec_record SET status = 'SUCCESS', error_msg = NULL WHERE request_id = ?", requestId); } private void markFailed(String requestId, String errorMsg) { String msg = Objects.toString(errorMsg, "unknown error"); if (msg.length() > 500) { msg = msg.substring(0, 500); } jdbcTemplate.update( "UPDATE lumi_exec_record SET status = 'FAILED', error_msg = ? WHERE request_id = ?", msg, requestId); } }这段代码就是我们解决“打了多次都没打过”的核心。它做了三件非常重要的事情：第一，每次真正执行任务前，先查询 requestId 是否已经成功过；第二，执行前插入 RUNNING 记录，借助数据库唯一索引防止并发重复处理；第三，业务执行失败时，记录 FAILED 和错误原因，而不是让异常被静默吞掉。
这里没有给 run 方法加 @Transactional，这是有意为之。因为如果任务执行失败，我们不希望 RUNNING 记录随着事务回滚一起消失。我们需要的是把 RUNNING 改为 FAILED，方便下次重试时判断。如果你一定要在方法上加事务，要特别注意异常和状态更新的顺序，否则会得到“看起来回滚了，其实状态记录还没落库”的尴尬结果。
4.5 Controller 和请求模型代码
在 src/main/java/com/example/lumi/controller/LumiTaskController.java 中，加入如下代码：
package com.example.lumi.controller; import com.example.lumi.model.LumiRunRequest; import com.example.lumi.service.LumiTaskService; import org.slf4j.Logger; import org.slf4j.LoggerFactory; import org.springframework.web.bind.annotation.PostMapping; import org.springframework.web.bind.annotation.RequestBody; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RestController; import java.util.Map; @RestController @RequestMapping("/internal/lumi") public class LumiTaskController { private static final Logger log = LoggerFactory.getLogger(LumiTaskController.class); private final LumiTaskService lumiTaskService; public LumiTaskController(LumiTaskService lumiTaskService) { this.lumiTaskService = lumiTaskService; } @PostMapping("/run") public Map<String, Object> run(@RequestBody LumiRunRequest request) { try { lumiTaskService.run(request.requestId(), request.operator()); return Map.of( "success", true, "requestId", request.requestId(), "message", "task finished"); } catch (Exception e) { log.error("requestId={} 执行异常", request.requestId(), e); return Map.of( "success", false, "requestId", request.requestId(), "message", e.getMessage()); } } }请求模型 LumiRunRequest 使用 Java Record 定义：
package com.example.lumi.model; public record LumiRunRequest(String requestId, String operator) { }Controller 的职责是接收请求和返回结果。这里虽然也在 catch 中捕获了异常，但注意两点：第一，日志中打印了完整异常栈，方便后续定位；第二，返回体中的 success 字段是 false，调用方不会误判为成功。
4.6 运行与验证
启动 Spring Boot 应用后，先模拟一次成功调用：
curl -X POST http://localhost:8080/internal/lumi/run \ -H "Content-Type: application/json" \ -d '{"requestId":"d1a2b3c4-0001","operator":"csdn-demo"}'预期返回：
{"success":true,"requestId":"d1a2b3c4-0001","message":"task finished"}查询数据库：
SELECT request_id, status, error_msg, create_time, update_time FROM lumi_exec_record WHERE request_id = 'd1a2b3c4-0001';可以看到一条状态为 SUCCESS 的记录。此时再次调用同一个 requestId，不会重复执行业务逻辑，而是直接幂等命中返回成功。
再模拟一次失败调用，使用 mock-fail 开头的 requestId：
curl -X POST http://localhost:8080/internal/lumi/run \ -H "Content-Type: application/json" \ -d '{"requestId":"mock-fail-0002","operator":"csdn-demo"}'预期返回：
{"success":false,"requestId":"mock-fail-0002","message":"mock business exception"}数据库中的记录状态为 FAILED，error_msg 中记录了具体失败原因。这就比“接口返回 200，但数据库什么都没变”要友好得多。
5. 连续四次失败的根因排查清单
如果你手头的 lumi 任务也出现了“连打 4 次都没打过”的情况，不要盲目发起第 5 次请求。建议按下面这个清单逐项排查：
| 问题现象 | 常见原因 | 解决思路 |
|---|---|---|
| 接口返回 200，但数据库没有新记录 | 请求未到达服务端，或异常被吞掉后返回固定成功 | 查看服务端入口日志，检查是否经过网关路由 |
| 数据库有 RUNNING 记录，但任务最终没成功 | 执行过程中抛异常，且状态未更新为 FAILED | 在异常处理中主动调用 markFailed，并抛出异常给调用方 |
| 同一个 requestId 被重复发送时并发执行 | 只做业务判断，没有数据库唯一索引或分布式锁 | 增加唯一索引，配合状态查询实现幂等 |
| 重复点击任务提交按钮后出现大量异常提示 | 前一个请求仍在执行中，状态为 RUNNING | 将 RUNNING 理解为“处理中”，提示用户稍后查询任务结果 |
| 第 4 次调用仍然失败，且失败位置完全相同 | 前置数据缺失或配置不完整，重试无效 | 分析错误日志中的共同点，修复前置条件后再重试 |
| 调用方不知道任务成功还是失败 | 返回结果中没有区分 ACCEPTED、SUCCESS、FAILED | 统一接口返回值，明确任务终态 |
这个清单并不是万能的，但可以覆盖大多数任务接口联调场景。遇到复杂问题时，应当先定位到具体的失败堆栈，再结合数据库状态和日志链路一起判断。
6. 生产环境中的工程建议
6.1 幂等设计是任务接口的底线
只要任务接口可能被调用方重试，就必须考虑幂等。常见的幂等方案有三种：数据库唯一索引、Redis 分布式锁、状态机前置判断。本文示例使用的是数据库唯一索引 + 状态判断，这种方式对大多数任务型接口都足够。唯一需要注意的是，requestId 的生成规则要保证全局唯一。一般建议使用 UUID、雪花 ID 或“业务类型 + 业务主键 + 时间戳”的组合，避免不同业务之间出现相同 requestId。
如果你需要更强的并发控制，可以在插入 RUNNING 记录前，使用 Redis 的 SETNX 命令加锁：
Boolean locked = stringRedisTemplate.opsForValue() .setIfAbsent(lockKey, requestId, Duration.ofSeconds(10)); if (!Boolean.TRUE.equals(locked)) { throw new IllegalStateException("任务执行中，请勿重复提交"); } try { lumiTaskService.run(requestId, operator); } finally { String currentValue = stringRedisTemplate.opsForValue().get(lockKey); if (requestId.equals(currentValue)) { stringRedisTemplate.delete(lockKey); } }这里删除锁之前要先比较 value 是否是当前线程写入的 requestId，防止误删其他线程的锁。锁的过期时间要根据任务最大执行时间设置，不能设置得过短，否则任务还没执行完，锁就自动过期了。不过 Redis 分布式锁只是补充手段，数据库唯一索引仍然是最可靠的兜底。
6.2 不要把所有逻辑都包进一个大事务
很多开发者习惯在 Service 方法上直接加 @Transactional，然后在这个方法里调用远程接口、执行耗时的数据分析、或者同步数据。这种做法很容易导致数据库连接长时间占用，并且当远程调用失败时，整个事务回滚，导致已经写入的状态记录也一起消失。
对于任务类接口，更推荐把状态流转拆成独立的数据操作：先写 RUNNING，再执行业务，最后写 SUCCESS 或 FAILED。每一步之间不强行使用同一个事务，而是通过状态字段和错误日志保证数据可追踪、可恢复。当然，如果业务本身要求多个数据库表必须原子更新，那么事务仍然必不可少，但远程调用和长耗时操作应该放在事务之外。
6.3 失败重试要设计退避策略，而不是无脑重试
如果 lumi 第 1 次失败后，你着急地打了第 2 次、第 3 次、第 4 次，大概率会得到相同的结果。真正合理的重试策略是：先等待一小段时间，再重试一次；如果仍然失败，则等待更长时间，或者直接把任务放入失败队列，由后台任务统一处理。指数退避是常见的实现方式。
以调用方为例，可以在捕获失败后使用简单的指数退避：
第 1 次失败后等待 1 秒 第 2 次失败后等待 2 秒 第 3 次失败后等待 4 秒 第 4 次失败后等待 8 秒重试次数建议限制在 3 到 5 次以内。超过重试上限后，应当告警人工介入，而不是无限重试。如果任务是幂等的，重试不会造成重复数据；如果任务不是幂等的，必须先把幂等做完善，再允许重试。
6.4 日志和监控要做到可串联
排障“打了 4 次 lumi 都没打过”时，最怕的是 4 次请求的日志散落在不同服务中，无法串联。建议在接口入口生成或者透传 traceId，并在日志中打印 requestId。调用方提交请求时，也可以把 requestId 放到请求参数中，这样整个链路的日志都能通过 requestId 搜索出来。
除了日志，还要对任务状态进行监控。比如每分钟扫描一次 lumi_exec_record 表中超过 5 分钟仍然是 RUNNING 的记录，将它们判断为超时任务并发告警。这样的监控可以发现那些“接口已经返回成功，但状态没有走到终态”的隐蔽问题。
6.5 生产环境变更要谨慎
如果你是在生产环境中排查问题，涉及数据库表结构调整、批量修改历史数据或重新触发失败任务之前，一定要先评估影响范围。建议在测试环境完整复现问题后，再对生产环境操作。修改数据前要备份，触发批量任务前要确认任务接口具备幂等能力，避免重复执行造成不可逆的数据变更。涉及人工执行 SQL 更新时，尽量使用事务包裹，并且在更新前先 SELECT 确认影响行数与预期一致。
7. 写在最后
回顾整篇文章，核心想表达的东西并不复杂：判断一次任务是否成功，不能只看 HTTP 返回码，也不能只看
