面试总挂?手写实现提交中逻辑,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 ResultString 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 (fmtsynctime
)// 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招搞定并发与状态
面试被问“如何保证提交中的幂等性”时，你支支吾吾答不上来，心里是不是在滴血？很多开发者平时只会在业务代码里加个 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 ResultString 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 (fmtsynctime
)// 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 校验，没有处理复杂的并发状态流转。手写实现一遍，你才能真正理解其中的坑。
你在项目里踩过这个坑吗？比如锁过期导致的数据不一致，或者前端重试导致的脏数据？评论区聊聊，看看谁踩的坑更离谱。