幂等消费防重表设计详解

本文深入剖析了Python微服务中幂等消费防重表的核心设计原则与实战陷阱，强调防重表绝非简单记流水，而是必须以业务唯一ID（如order_no、message_id）为唯一键、与业务操作共处同一数据库事务、通过INSERT IGNORE或ON CONFLICT原子写入、并配合定期清理过期数据的严谨机制；文章直击“SELECT+INSERT并发冲突”“自增ID误用”“跨事务导致漏处理”“防重表膨胀失控”四大高频翻车点，用可落地的建表语句、SQLAlchemy示例和运维建议，帮开发者避开看似简单实则致命的设计误区，真正实现可靠、高效、可持续的幂等消费。

防重表字段设计必须用业务唯一ID，不能只靠自增主键

防重表不是用来“记流水”的，而是用来“判重复”的。如果只用数据库自增 id 当主键，那根本拦不住重复消息——每条消息插入都会成功，完全失去去重意义。

正确做法是把业务天然唯一的标识作为主键或唯一索引，比如订单号 order_no、支付流水号 trade_no、或生产端生成的 message_id。这个字段必须由上游确定、全局唯一、不可篡改。

• 推荐建表语句：CREATE TABLE t_dedup (msg_id VARCHAR(64) PRIMARY KEY, created_at DATETIME DEFAULT NOW())
• 避免用 INT AUTO_INCREMENT 做去重依据——它不携带业务语义，也无法跨服务对齐
• 如果业务没现成唯一ID，必须由生产者生成 UUID 或 Snowflake ID 并透传，不能由消费者临时拼接

INSERT IGNORE 和 ON CONFLICT 是最稳的写入方式

用 SELECT + INSERT 两步走，在并发场景下大概率出问题：两个线程同时查不到记录，然后都插入成功。这不是理论风险，是压测必现的 bug。

真正可靠的写法，是靠数据库原子性完成“存在即失败”判断。MySQL 用 INSERT IGNORE，PostgreSQL 用 ON CONFLICT DO NOTHING，它们都在单条 SQL 内完成校验与写入，不会被并发打断。

• Python 示例（SQLAlchemy）：session.execute(text("INSERT IGNORE INTO t_dedup (msg_id) VALUES (:msg_id)"), {"msg_id": msg_id})
• 执行后检查 rowcount：等于 0 表示已存在，直接跳过后续业务逻辑；大于 0 才继续处理
• 别用 try...except IntegrityError 捕获唯一键冲突——它属于异常流，性能差且掩盖真实意图

防重表必须和业务操作在同一个事务里

很多人把“插防重表”和“更新订单状态”分成两个事务，以为只要先插成功就能防重。错。一旦中间发生崩溃或网络断开，就会留下防重记录但业务没执行，下次消息来反而被跳过，导致漏处理。

必须确保：防重记录写入和业务变更要么全成功，要么全回滚。否则幂等就变成了“半截幂等”，比不做还危险。

• 使用同一 DB 连接、同一 session，所有操作包裹在 session.begin() 和 session.commit() 中
• 不要在防重表用 Redis 替代数据库——Redis 没有事务一致性，无法保证和 MySQL 业务表强一致
• 如果业务本身跨库（如订单库 + 库存库），防重表必须和核心业务表同库，否则无法加分布式事务

别忘了清理老数据，否则防重表会越涨越大

防重表不是日志表，不需要永久保留。消息处理完一段时间后（比如 7 天），对应记录就没用了。不清理，轻则磁盘爆满，重则 INSERT IGNORE 变慢——索引膨胀会影响所有写入性能。

• 加定时任务（如 Celery beat 或系统 cron），每天凌晨执行：DELETE FROM t_dedup WHERE created_at
• 清理 SQL 必须带 WHERE 条件，并确保 created_at 字段有索引，否则会锁表
• 上线前先估算数据量：按每秒 1000 条消息算，7 天就是 6 亿行，没清理机制根本扛不住

防重表看着简单，但字段选错、写法用错、事务分错、数据不清理——四个点里踩中任意一个，幂等就形同虚设。实际线上最容易翻车的是“SELECT+INSERT”和“跨事务写入”，这两个坑几乎每个团队都至少掉进去过一次。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《幂等消费防重表设计详解》文章吧，也可关注golang学习网公众号了解相关技术文章。