使用go-redis调用ZRange出现解析错误，求助排查原因

问题场景 #

使用go-redis的ZRange方法调用AWS MemoryDB集群时出现解析错误，相关代码如下：

clusterOption := &redis.ClusterOptions{
    DialTimeout:  ev.Redis.DialTimeout,
    ReadTimeout:  ev.Redis.ReadTimeout,
    WriteTimeout: ev.Redis.WriteTimeout,
    PoolSize:     ev.Redis.PoolSize,
    PoolTimeout:  ev.Redis.PoolTimeout,
    MinIdleConns: ev.Redis.MinIdleConnections,
    MaxRedirects: ev.Redis.MaxRedirects,
    Addrs:        []string{ev.Redis.Address},
    TLSConfig: &tls.Config{
        MinVersion: tls.VersionTLS12,
    },
}

redisClient := redis.NewClusterClient(clusterOption)
if err := redisClient.Ping(ctx).Err(); err != nil {
    return nil, fmt.Errorf("pinging failed, %s", err.Error())
}
ids, err := redisClient.ZRange(context.Background(), "x:123", 0, -1)

报错信息 #

触发的两个错误与有序集合元素数量强相关：

• 元素数量为21028时，报错：redis: can't parse array/set/push reply: "$24"
• 元素数量为475490时，报错：redis: invalid reply: "\r\n"

环境信息 #

• AWS MemoryDB集群：9节点、3分片，Redis版本7.0
• Golang版本：1.21.1
• go-redis版本：v9.3.0

可能的原因分析 #

1. 网络传输与超时限制 #

大体积的ZRange结果（尤其是47万+元素）在跨分片传输时，容易出现数据包截断、延迟。如果当前配置的ReadTimeout不足以支撑大结果的完整传输，会直接导致读取中断，残留\r\n这类不完整的空回复，触发解析错误。

2. go-redis集群模式的分片合并逻辑bug #

go-redis在集群模式下处理ZRange请求时，需要向多个分片发起请求再合并结果。v9.3.0版本可能存在分片结果合并时的解析漏洞：正常ZRange应返回数组格式回复，但合并过程中若处理不当，会把单个分片的非数组格式回复当成整体结果，导致"$24"这类解析报错。

3. MemoryDB与原生Redis的兼容性差异 #

AWS MemoryDB作为Redis兼容服务，部分默认配置（如分片同步策略、回复压缩机制）可能与原生Redis有差异，大结果返回的格式不符合go-redis的解析预期，引发错误。

4. 连接池复用的脏数据残留 #

连接池中的连接若未正确重置，复用了之前请求残留的不完整数据，当下一次大请求时，这些残留数据会被当成新回复的一部分，干扰解析逻辑，触发错误。

临时排查建议 #

• 调高ReadTimeout配置，测试是否能解决大元素数量下的报错
• 改为分批获取结果（比如分多次调用ZRange，每次取10000条），避免一次性请求过大体积的数据
• 升级go-redis到最新稳定版本，确认是否是已知bug已被修复
• 检查MemoryDB节点日志，确认是否存在大请求处理时的异常或回复截断情况

内容的提问来源于stack exchange，提问作者Kartal