本文解析 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 仅能防止单实例内重复插入，无法解决分布式多实例、服务重启后状态丢失等问题。长期应考虑：
- 使用 INSERT ... ON CONFLICT DO NOTHING（PostgreSQL 9.5+）替代应用层判断；
- 或引入 Redis Bloom Filter 做跨进程粗筛。
- 日志必须包含上下文：记录 bodyHash、bodyString 及错误类型，便于快速定位是真冲突还是重试扰动。
- 监控连接健康度：通过 pg_stat_activity 或 Prometheus + postgres_exporter 监控 bad_conn 类错误频率，及时发现网络或配置隐患。
通过将“重试决策权”从不可控的驱动层上收至业务代码，配合事务边界与精准错误分类，即可彻底消除此类伪唯一冲突错误，构建真正健壮的数据库写入管道。
