非Serializable事务下如何避免tableA的重复插入问题？

针对你遇到的并发重复插入问题，结合不能使用Serializable事务的限制，这里有几个高效的可行方案：

1. 给tableA新增业务唯一约束（优先推荐） #

既然tableA目前只有自动生成的ID，没有业务层面的唯一键，先梳理清楚业务上哪些字段组合能唯一标识一条记录（比如触发API的业务标识、关联tableB/C的关键ID组合等），直接在tableA上给这些字段添加唯一复合约束。

处理逻辑：

• 并发请求执行插入时，数据库会自动校验唯一约束，仅第一个请求能插入成功
• 后续请求会抛出唯一约束冲突异常，API捕获该异常后，直接返回"操作成功"即可（因为目标记录已存在）

优点：

• 完全利用数据库原生能力，性能高，无需额外维护锁表或分布式锁
• 避免无效事务执行，冲突检查在数据库层面快速完成

注意点：

• 如果唯一键包含允许null的字段，需注意数据库规则（比如MySQL中多个null值不会触发唯一约束冲突，这种情况可用默认值替代null）
• 新增约束前要清理tableA中已存在的重复记录

2. 优化现有lock表方案，将锁操作前置 #

你之前的lock表方案问题在于锁操作晚于验证查询，导致并发请求已执行大量插入逻辑才失败。调整事务流程，把lock表的插入放在事务最开始：

事务执行步骤：

1. 尝试向lock表插入唯一复合键记录（这一步会触发数据库行锁，并发请求会在此等待）
2. 成功插入后，再执行tableB/C的验证查询
3. 验证通过后向tableA插入数据
4. 提交事务，lock表的记录可选择保留或定期清理（若不需要历史锁记录）

调整后，只有拿到锁的请求会执行后续验证和插入操作，其他请求要么在第一步等待（直到前一个事务提交），要么在插入lock表时因唯一键冲突直接失败，不会走到后面的无效操作。

优点：

• 保留原方案不阻塞tableA/B/C其他操作的优势
• 避免无效事务执行，减少数据库资源浪费

注意点：

• lock表的唯一键要和业务场景强绑定，确保同一业务逻辑的请求会竞争同一个锁键
• 可给lock表添加过期时间字段，定期清理无用锁记录，避免表数据膨胀

3. 应用层分布式锁 #

如果不想修改数据库结构，可用Redis等实现分布式锁：

• 在API处理请求的最开始，根据业务唯一标识（比如验证条件的哈希值、关联业务ID）生成锁键
• 尝试获取分布式锁（设置合理过期时间，避免死锁）
• 拿到锁的请求执行验证和插入操作，完成后释放锁
• 没拿到锁的请求可选择直接返回"操作已在处理"，或等待一段时间重试

优点：

• 完全在应用层处理，不占用数据库资源，适合tableB/C批量插入压力大的场景
• 锁粒度可灵活控制

注意点：

• 要确保分布式锁的可靠性，比如用Redisson的可重入锁+看门狗机制自动续期，避免锁提前过期导致并发问题
• 处理锁释放的异常情况，比如事务执行失败时要主动释放锁

4. 乐观锁+重试机制（适合并发较低场景） #

如果并发量不是特别高，可结合查询和重试：

• 验证完tableB/C的结果后，先查询tableA是否存在符合业务唯一条件的记录
• 若不存在，执行插入操作
• 若插入时抛出唯一约束异常，再次查询tableA，确认记录已存在后返回成功，否则重试几次

优点：实现简单，无需额外锁机制
缺点：并发高时重试次数会增加，可能带来一定性能开销

内容的提问来源于stack exchange，提问作者Aravindh Vasu