本文详解 go 中使用 redigo 批量加载海量键（如 2 亿）时频繁连接重置、eof 和拒绝连接的根本原因，指出内存瓶颈是主因，并提供哈希优化、分片策略、连接池调优及原子写入加固等生产级解决方案。

向 Redis 写入 2 亿级键值对是一项高压力操作，而你在约 3100 万键处反复失败（报错如 connection reset by peer、connection refused、EOF），根本原因极大概率不是 Go 客户端逻辑缺陷，而是 Redis 实例因内存耗尽被系统 OOM Killer 终止或主动崩溃——这直接导致后续连接失败或命令执行中断。

Redis 官方明确指出：单实例可支持 ≥2.5 亿 keys，但前提是系统内存充足。每个简单字符串键（如 SET key value）在 Redis 中实际占用远不止键值本身：需额外开销存储元数据、dictEntry 结构、SDS 字符串头、内存碎片等。实测中，2 亿个中等长度 key-value（如 32B key + 8B value）极易突破 20–40 GB 内存阈值。一旦超出，Linux 内核会强制 kill redis-server 进程，造成“连接被拒绝”或“连接重置”——此时你的 Go 程序仍在尝试复用已失效连接，自然触发 EOF 或 io.ErrUnexpectedEOF。

✅ 正确应对策略

1. 优先优化存储结构：用 HASH 替代扁平 KEY

避免为每个业务 ID 创建独立 key（如 user:1001, user:1002…），改用哈希结构聚合存储：

// ❌ 低效：2 亿个独立 key
conn.Send("SET", "user:1001", "100")
conn.Send("EXPIRE", "user:1001", 3600)

// ✅ 高效：按前缀分桶，每 Hash 存 1000 个字段（节省 50%+ 内存）
bucket := fmt.Sprintf("users:%d", int64(keyID)/1000)
conn.Send("HSET", bucket, fmt.Sprintf("id_%d", keyID), "100")
conn.Send("EXPIRE", bucket, 3600) // 整个 bucket 统一过期

配合 HGETALL / HSCAN 可高效批量读取，且 Redis 对 Hash 的内存编码（ziplist → hashtable）自动优化小集合。

2. 实施水平分片（Sharding）

单机扛不住？将数据分散至多个 Redis 实例：

func getShardAddr(key string) string {
    hash := fnv.New32a()
    hash.Write([]byte(key))
    shardID := int(hash.Sum32() % uint32(len(shardAddrs)))
    return shardAddrs[shardID]
}

// 写入时路由到对应实例
shardAddr := getShardAddr(key)
conn := poolMap[shardAddr].Get()
defer conn.Close()
conn.Send("SET", key, maxCount)
conn.Send("EXPIRE", key, numSecondsExpire)
conn.Do("EXEC")

推荐初始分片数 4–8，后续按需扩容。注意：跨分片事务不可用，但对计数类场景（如你案例中的 maxCount）通常无影响。

3. 修复客户端关键缺陷

你当前代码存在严重资源泄漏与并发风险：

• ❌ defer conn.Close() 在循环内无效（defer 在函数退出时才执行，此处循环未退出）；
• ❌ MULTI/EXEC 批处理未限制大小（200 万 keys 一次性发 MULTI 会导致 Redis 单命令缓冲区溢出、OOM）；
• ❌ 连接池 MaxIdle=3 过小，高并发下连接争抢加剧超时。

✅ 修正后的安全批量写入（含分块 + 错误重试 + 连接及时释放）：

func RedisServerBatchLoadKeys(rtbExchange string, keys []string) error {
    const batchSize = 1000 // 每批最多 1000 个 key，防 Redis 单次负载过大
    for i := 0; i < len(keys); i += batchSize {
        batch := keys[i:min(i+batchSize, len(keys))]
        if err := loadSingleBatch(rtbExchange, batch); err != nil {
            return fmt.Errorf("batch [%d-%d] failed: %w", i, i+len(batch)-1, err)
        }
    }
    return nil
}

func loadSingleBatch(rtbExchange string, keys []string) error {
    conn := GetConnOrPanic(rtbExchange)
    defer conn.Close() // ✅ 此处 defer 有效：函数退出即关闭

    conn.Send("MULTI")
    for _, key := range keys {
        conn.Send("SET", key, maxCount)
        conn.Send("EXPIRE", key, numSecondsExpire)
    }
    reply, err := conn.Do("EXEC")
    if err != nil {
        // 区分网络错误与 Redis 命令错误
        if netErr, ok := err.(net.Error); ok && netErr.Timeout() {
            return fmt.Errorf("redis timeout: %w", err)
        }
        if errors.Is(err, io.EOF) || strings.Contains(err.Error(), "connection reset") {
            return fmt.Errorf("redis server unreachable (OOM?): %w", err)
        }
        return fmt.Errorf("redis exec error: %w", err)
    }

    // EXEC 返回 []interface{}，需检查是否全成功
    if replies, ok := reply.([]interface{}); ok {
        for j, r := range replies {
            if r == nil { // nil 表示该命令在 EXEC 中失败（如语法错）
                return fmt.Errorf("command %d in batch failed: nil reply", j/2)
            }
        }
    }
    return nil
}

4. 连接池与服务端协同调优

• 客户端：MaxActive 提至 50–100（根据 CPU 核心数），IdleTimeout 保持 240s，增加 Wait: true 避免获取连接阻塞；
• 服务端：在 redis.conf 中设置：

  maxmemory 32gb
  maxmemory-policy allkeys-lru   # 或 volatile-lru，避免 OOM
  tcp-keepalive 300              # 保活探测，早发现断连

总结

2 亿键写入失败，90% 概率是内存不足引发的 Redis 进程崩溃。不要试图靠重试或加大连接池解决根本问题。务必：

1. 用 INFO memory 实时监控 used_memory_peak_human；
2. 优先采用 Hash 分组 + TTL 统一管理；
3. 必须分片时，设计一致性哈希或范围分片；
4. 客户端严格控制批大小、及时释放连接、精准分类错误；
5. 生产环境开启 Redis 持久化（RDB/AOF）与监控告警（如内存 >85% 触发预警）。

唯有从数据模型、架构分片、资源监控三层面协同优化，才能稳定承载亿级 Redis 数据规模。