本文详解 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 进程崩溃。不要试图靠重试或加大连接池解决根本问题。务必：
- 用 INFO memory 实时监控 used_memory_peak_human；
- 优先采用 Hash 分组 + TTL 统一管理；
- 必须分片时，设计一致性哈希或范围分片；
- 客户端严格控制批大小、及时释放连接、精准分类错误；
- 生产环境开启 Redis 持久化（RDB/AOF）与监控告警（如内存 >85% 触发预警）。
唯有从数据模型、架构分片、资源监控三层面协同优化，才能稳定承载亿级 Redis 数据规模。
