面试总挂?手写实现提交中逻辑,3招搞定并发与状态

面试被问“如何保证提交中的幂等性”时，你支支吾吾答不上来，心里是不是在滴血？很多开发者平时只会在业务代码里加个 if (status == 1)，一旦面试官追问底层原理，立马卡壳。今天咱们不整虚的，直接上手手写实现“提交中”这个状态的核心逻辑。别小看这个状态机，它是后端高并发场景下的基本功。

1. 为什么“提交中”是个技术深坑？

在电商、支付或表单系统中，“提交中”（Submitting）不仅仅是一个 UI 提示，它是数据一致性的守门员。

场景痛点：

重复点击： 用户手抖，连续点了两次“提交”。第一次请求还在网络里飞，第二次请求已经到了后端。如果后端不拦截，就会产生两笔订单。
网络抖动： 请求发出去了，但响应超时。前端不知道后端到底处理成功没，于是重试。后端如果没做幂等，数据就脏了。
状态污染： 在“提交中”期间，用户修改了表单内容并再次提交，导致最终落库的数据是前后两次混合的“四不像”。

很多初学者以为加个 Loading 动画就行了，其实前端拦截只是第一道防线，真正的硬仗在后端。后端必须能识别出“这是一个正在处理中的请求”，并拒绝或合并后续相同的请求。

2. 核心原理：从“状态”到“令牌”

要实现健壮的“提交中”逻辑，核心在于状态隔离和幂等性校验。

2.1 状态机视角

在数据库层面，我们需要明确定义状态流转：

0: 未提交 (Idle)
1: 提交中 (Submitting)
2: 已提交/成功 (Submitted)
3: 失败 (Failed)

关键原则： 只有状态为 0 的请求才能被受理并更新为 1。状态为 1 的重复请求应直接返回“处理中”提示，而不是再次执行业务逻辑。

2.2 幂等性令牌 (Token)

仅靠状态更新不够，因为数据库的 UPDATE 不是原子的“检查-执行”过程。我们需要引入分布式锁或唯一索引。

方案 A：Redis 分布式锁 在接收请求时，生成一个唯一的 biz_id（如订单号）。尝试对 lock:submit:{biz_id} 加锁。
- 加锁成功：说明是首次提交，执行业务，设置状态为“提交中”。
- 加锁失败：说明已有请求在处理，直接返回“请勿重复提交”。
- 业务结束：无论成功失败，释放锁，并更新最终状态。
方案 B：数据库唯一索引 创建一张 submit_log 表，包含 biz_id 和 status。利用数据库的唯一约束，尝试插入一条 status=1 的记录。
- 插入成功：继续执行业务。
- 插入失败（Duplicate Key）：查询当前状态，若为 1 则提示“处理中”，若为 2 则提示“已提交”。

3. 代码实战：两种主流技术栈对比

下面我们用 Java (Spring Boot) 和 Go (Gin) 两种语言，分别手写实现这套逻辑。你会发现，虽然语言不同，但底层思想是一致的。

3.1 Java 实现：基于 Redis 的分布式锁

在 Java 生态中，Redis 是标配。我们使用 SETNX 命令来确保原子性。

import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.stereotype.Service;
import javax.annotation.Resource;
import java.time.Duration;@Service
public class SubmitService {@Resourceprivate StringRedisTemplate redisTemplate;@Resourceprivate OrderRepository orderRepository; // 假设的仓储层/*** 处理提交逻辑* @param bizId 业务唯一标识* @param data 业务数据*/public Result<String> submit(String bizId, String data) {String lockKey = "lock:submit:" + bizId;// 1. 尝试获取锁，过期时间设置为30秒，防止死锁Boolean locked = redisTemplate.opsForValue().setIfAbsent(lockKey, "1", Duration.ofSeconds(30));if (Boolean.FALSE.equals(locked)) {// 2. 获取锁失败，说明有并发请求正在处理// 这里可以查询一下具体状态，给出更友好的提示String status = redisTemplate.opsForValue().get("status:" + bizId);if ("1".equals(status)) {return Result.fail("请求处理中，请勿重复提交");} else if ("2".equals(status)) {return Result.fail("该业务已提交成功");}return Result.fail("系统繁忙，请稍后重试");}try {// 3. 获取锁成功，标记状态为“提交中”redisTemplate.opsForValue().set("status:" + bizId, "1", Duration.ofSeconds(30));// 4. 执行核心业务逻辑 (模拟耗时操作)doBusinessLogic(bizId, data);// 5. 业务成功，标记状态为“已提交”redisTemplate.opsForValue().set("status:" + bizId, "2", Duration.ofDays(1));return Result.success("提交成功");} catch (Exception e) {// 6. 业务失败，标记状态为“失败”，允许用户重试redisTemplate.opsForValue().set("status:" + bizId, "3", Duration.ofHours(1));return Result.fail("提交失败：" + e.getMessage());} finally {// 7. 无论成功失败，释放锁，允许后续可能的重试或新请求// 注意：这里释放锁后，如果用户立刻再次点击，且业务已失败，状态是3，可以重新进入// 如果业务已成功，状态是2，会被上面的 status 检查拦截redisTemplate.delete(lockKey);}}private void doBusinessLogic(String bizId, String data) throws Exception {// 模拟数据库写入Thread.sleep(1000);orderRepository.save(new Order(bizId, data));}
}

代码解析：

setIfAbsent：这是 Redis 原子操作的核心，确保只有一个线程能拿到锁。
状态分离：我们将“锁”和“业务状态”分开存储。锁用于防并发，状态用于防重复和查进度。
finally 块：务必在 finally 中释放锁，防止异常导致锁永远不释放。

3.2 Go 实现：基于本地 Map + Mutex 的轻量级方案

在 Go 中，如果服务是单实例或不需要跨实例共享状态，可以使用内存结构。如果是微服务多实例，建议还是用 Redis 或 Etcd。这里为了演示简洁，我们用 sync.Map 和 RWMutex 模拟。

package serviceimport ("fmt""sync""time"
)// SubmitState 定义提交状态
type SubmitState intconst (StateIdle SubmitState = iotaStateSubmittingStateSubmittedStateFailed
)type SubmitManager struct {mu      sync.RWMutexstates  map[string]SubmitState
}var Manager = &SubmitManager{states: make(map[string]SubmitState),
}// Submit 处理提交逻辑
func (m *SubmitManager) Submit(bizID string, data string) (string, error) {m.mu.Lock()defer m.mu.Unlock()// 1. 检查当前状态state, exists := m.states[bizID]if exists {switch state {case StateSubmitting:return "", fmt.Errorf("请求处理中，请勿重复提交")case StateSubmitted:return "", fmt.Errorf("该业务已提交成功")case StateFailed:// 失败状态允许重试，重置为 Idlem.states[bizID] = StateIdle}}// 2. 标记为提交中m.states[bizID] = StateSubmitting// 3. 异步执行业务逻辑，避免阻塞主 goroutine (简化版同步执行)go func() {defer func() {m.mu.Lock()defer m.mu.Unlock()// 模拟业务耗时time.Sleep(1 * time.Second)// 模拟业务成功m.states[bizID] = StateSubmitted// 这里可以触发通知等后续操作}()// 实际业务代码_ = data}()return "accepted", nil
}

代码解析：

sync.RWMutex：Go 的并发控制基石。由于涉及读状态和写状态，我们使用读写锁。
状态机转移：在加锁期间，严格检查并转移状态。
异步处理：Go 的 goroutine 非常适合处理这种“接收请求-立即响应-后台执行”的模式。

4. 核心差异对比

为了让你更清晰地选择适合你项目的方案，下表对比了 Java Redis 方案与 Go 内存方案：

维度	Java + Redis	Go + Memory (Map)
适用架构	微服务、多实例部署	单体应用、单实例部署
并发安全	依赖 Redis 原子操作，跨进程安全	依赖 Mutex，仅单进程内安全
性能	存在网络 IO 开销，毫秒级	内存操作，纳秒/微秒级
持久性	数据在 Redis，重启不丢（需配置持久化）	数据在内存，服务重启后状态丢失
复杂度	中等，需管理 Redis 连接和 Key 过期	低，代码简洁
故障恢复	Redis 挂了，需降级策略（如本地限流）	服务重启，状态清零，可能导致重复提交
扩展性	强，支持集群，天然分布式	弱，水平扩容时需引入外部存储

选型建议：

如果你的系统是单体架构，且QPS不高，Go 的内存方案足够快且简单。
如果你使用的是 Spring Boot 微服务，或者系统有多个实例，必须使用 Redis 或数据库唯一索引。内存方案在多实例下会失效，因为实例 A 的锁对实例 B 不可见。

5. 进阶避坑：那些让你加班的“提交中”问题

5.1 锁过期时间怎么设？

很多新手设成 1秒 或 10秒，结果业务逻辑稍微慢一点，锁就过期了，第二个请求进来，数据就崩了。 最佳实践：

看业务耗时： 如果业务耗时在 500ms 以内，锁设 5-10 秒足够。
看数据库慢查询： 检查你 SELECT 和 INSERT 的 P99 耗时，锁时间应为 P99 的 3-5 倍。
看网络延迟： 如果客户端和服务端跨地域，考虑网络抖动。

5.2 业务成功但释放锁失败怎么办？

如果业务成功了，状态写成了 2，但 redis.delete(lockKey) 失败了（比如网络抖动），锁还在那儿挂着。 后果： 用户在 30 秒内（锁过期时间）无法再次提交，即使他修改了数据想重新提交。 解决方案：

Lua 脚本删除： 确保删除锁时，Value 必须是当前持有者（防止误删别人的锁）。
缩短锁时间： 结合业务状态判断。如果锁存在，但状态已是 2，前端可以直接提示“已提交”，而不是傻等。

5.3 前端配合

后端做得再好，前端不配合也是白搭。

禁用按钮： 点击后立刻 disabled，并显示 Loading。
防抖 (Debounce)： 对提交按钮做 500ms 的防抖处理。
Token 刷新： 每次页面加载或表单重置时，生成新的 request_id，避免跨会话冲突。

6. 真实案例：某电商大促的教训

之前在一个 CSDN 分享的高并发案例中，某电商在大促期间出现了“超卖”和“重复订单”。排查发现，他们的“提交中”逻辑只在前端做了禁用，后端直接查库 SELECT count(*) 然后 INSERT。在高并发下，两个线程同时查库，count 都是 0，于是都执行了 INSERT。 修复方案：

后端引入 Redis 分布式锁。
数据库层面，对 order_no 加唯一索引。
捕获 DuplicateKeyException，返回友好提示。 结果： 修复后，重复订单率为 0，响应时间增加 5ms（可接受）。

7. 总结与互动

“提交中”的状态管理，看似简单，实则是高并发系统的基石。

前端负责用户体验和第一道拦截。
后端负责数据一致性和最终裁决。
Redis/DB 提供原子性和持久化保障。

不要迷信框架自带的“防重复提交”注解，很多时候它们只是简单的 Token 校验，没有处理复杂的并发状态流转。手写实现一遍，你才能真正理解其中的坑。

你在项目里踩过这个坑吗？比如锁过期导致的数据不一致，或者前端重试导致的脏数据？评论区聊聊，看看谁踩的坑更离谱。

面试总挂?手写实现提交中逻辑,3招搞定并发与状态

面试总挂?手写实现提交中逻辑,3招搞定并发与状态

1. 为什么“提交中”是个技术深坑？