本文解析 go 应用中因连接重试机制导致的“duplicate key violates unique constraint”误报问题，揭示 database/sql 自动重试与驱动行为的隐式风险，并提供基于事务、幂等设计与错误分类处理的生产级解决方案。
本文解析 go 应用中因连接重试机制导致的“duplicate key violates unique constraint”误报问题，揭示 database/sql 自动重试与驱动行为的隐式风险，并提供基于事务、幂等设计与错误分类处理的生产级解决方案。
在 Go 程序中对 postgresql 执行高并发插入时，即使应用层已通过内存哈希（如 MD5）预判去重，仍偶发出现 pq: duplicate key value violates unique constraint “bd_hash_index” 错误——这看似违背逻辑，实则暴露了 Go 数据库抽象层一个关键但易被忽视的设计细节：连接级自动重试机制。
? 问题根源：database/sql 的静默重试陷阱
Go 标准库 database/sql 在执行 Exec() 时，若底层驱动返回 driver.ErrBadConn（例如网络闪断、ssl 握手失败、连接池中连接失效），会自动在新连接上重试该 SQL 语句最多 10 次（由 maxBadConnRetries 控制）。而 lib/pq 驱动在部分 SSL 异常（如 renegotiation failure、证书验证中断）场景下，可能错误地返回 ErrBadConn，尽管前一次 INSERT 实际已在数据库中成功提交。
这意味着：
✅ 第一次执行：INSERT INTO bodies (…) VALUES (‘abc123’, …) → 成功写入 DB，但因 SSL 错误未收到确认；
⚠️ 驱动误判为连接异常 → database/sql 启动重试；
❌ 第二次执行：同一语句再次提交 → 触发唯一索引冲突，抛出 duplicate key 错误。
? 注意：该问题与应用层 map[String]bool 去重完全无关——它发生在单次 Exec() 调用内部，是基础设施层的行为，开发者无法通过加锁或检查 map 规避。
✅ 正确解法：用事务 + 显式错误处理替代裸 Exec
最直接可靠的修复是禁用自动重试，将控制权交还给业务逻辑。核心策略是：
- 强制使用显式事务（避免语句被重复执行）；
- 精准识别并分类处理错误（区分真冲突、连接错误、其他异常）；
- 在事务外实现幂等重试逻辑（而非依赖 sql.DB 的黑盒重试）。
以下是重构后的安全插入逻辑：
func (pr *Process) insertBodyTx(hash, typ, source, bodyStr string, ts int64) error { tx, err := pr.DB.Begin() if err != nil { return fmt.Errorf("begin tx: %w", err) } defer tx.Rollback() // 确保失败时回滚 stmt, err := tx.Prepare("INSERT INTO bodies (hash, type, source, body, created_timestamp) VALUES ($1, $2, $3, $4, $5)") if err != nil { return fmt.Errorf("prepare: %w", err) } defer stmt.Close() _, err = stmt.Exec(hash, typ, source, bodyStr, ts) if err != nil { var pgErr *pq.Error if errors.As(err, &pgErr) && pgErr.Code == "23505" { // unique_violation return nil // 忽略重复，视为成功（幂等） } if isConnectionError(err) { return fmt.Errorf("connection error, retry needed: %w", err) } return fmt.Errorf("insert failed: %w", err) } return tx.Commit() } // isConnectionError 判断是否为可重试的连接类错误（非业务逻辑错误） func isConnectionError(err error) bool { if err == nil { return false } // 检查常见网络/SSL错误关键词 msg := strings.ToLower(err.Error()) return strings.Contains(msg, "connection refused") || strings.Contains(msg, "i/o timeout") || strings.Contains(msg, "ssl") || strings.Contains(msg, "broken pipe") || strings.Contains(msg, "use of closed network connection") }在主循环中调用并实现指数退避重试：
for p := range pr.Channel { // ... 计算 hash（同原逻辑）... if _, ok := pr.BodiesHash[bodyHash]; !ok { pr.BodiesHash[bodyHash] = true // 事务插入，带重试 var finalErr error for i := 0; i < 3; i++ { finalErr = pr.insertBodyTx(bodyHash, p.GetType(), p.GetSource(), p.GetBodyString(), nowUnix) if finalErr == nil { break // 成功退出 } if !isConnectionError(finalErr) { break // 非连接错误（如唯一冲突已忽略，其他错误不重试） } time.Sleep(time.Second * time.Duration(1<<uint(i))) // 1s, 2s, 4s } if finalErr != nil { pr.Logger.Printf("Failed to insert after retries: %v | hash: %s", finalErr, bodyHash) } } }⚠️ 关键注意事项与增强建议
- SSL 配置优化：若内网环境可控，建议连接字符串中显式设置 sslmode=disable（如答案所述），规避 TLS 层不稳定引发的误判；生产外网环境则应启用 sslmode=require 并确保证书链完整。
- 内存去重 ≠ 数据库去重：map[string]bool 仅能防止单实例内重复插入，无法解决分布式多实例、服务重启后状态丢失等问题。长期应考虑：
- 日志必须包含上下文：记录 bodyHash、bodyString 及错误类型，便于快速定位是真冲突还是重试扰动。
- 监控连接健康度：通过 pg_stat_activity 或 prometheus + postgres_exporter 监控 bad_conn 类错误频率，及时发现网络或配置隐患。
通过将“重试决策权”从不可控的驱动层上收至业务代码，配合事务边界与精准错误分类，即可彻底消除此类伪唯一冲突错误，构建真正健壮的数据库写入管道。