Redis Go客户端在IPv6环境下的连接问题解析

问题背景

Redis的Go语言客户端(go-redis)在IPv6网络环境中运行时，用户报告了一个特定的连接问题。当应用程序尝试创建消费者组(XGroupCreateMkStream命令)时，会收到"dial tcp: address fd01:abcd::7d03:6379: too many colons in address"的错误提示。

有趣的是，在相同的环境下，基本的Ping命令能够成功执行，但后续的XGroupCreateMkStream操作却会失败。这个问题在go-redis 9.5.1版本中持续出现，而在较早的9.3.0版本中则表现为偶尔失败后能够恢复。

技术分析

IPv6地址格式问题

核心问题在于Redis集群模式下对IPv6地址的处理。当客户端接收到MOVED重定向响应时，Redis服务器返回的IPv6地址格式不符合Go语言net包的标准要求。典型的IPv6地址应该用方括号包裹，如[fd01:abcd::7d03]:6379，但实际接收到的却是未包裹的格式fd01:abcd::7d03:6379。

命令路由机制

在Redis集群模式下，客户端需要根据键的哈希槽(slot)计算来确定应该连接哪个节点。对于XGroupCreateMkStream命令，内部的路由计算存在缺陷：

1. cmdFirstKeyPos函数错误地将XGroupCreateMkStream命令的第一个键位置返回为1，而实际上应该是2
2. 这导致Slot函数接收到了错误的参数("create"字符串而非实际的stream名称)
3. 最终计算出错误的槽位，触发MOVED重定向

连接建立过程

Ping命令能够成功而XGroupCreateMkStream失败的原因在于：

1. 初始连接建立时使用的是服务名称(xxx-crdb.test.svc.cluster.local)，DNS解析正常
2. 集群模式下，客户端会通过CLUSTER SLOTS命令获取所有节点信息
3. 当命令路由错误导致MOVED响应时，IPv6地址格式问题才显现出来

解决方案

针对这一问题，开发者提出了多方面的改进：

1. 增强IPv6地址解析的兼容性，使其能够处理带方括号和不带方括号的IPv6地址格式
2. 修正XGroupCreateMkStream命令的键位置计算逻辑
3. 完善MOVED/ASK重定向处理机制中的地址解析部分

技术启示

这一案例揭示了分布式系统开发中的几个重要考量点：

1. 网络协议兼容性：IPv6与IPv4的差异需要在网络库中妥善处理
2. 集群客户端实现：需要精确理解Redis集群协议的各种响应格式
3. 命令路由机制：不同Redis命令的键位置规则需要准确实现
4. 版本兼容性：网络协议和客户端实现的变更需要考虑向后兼容

通过这一问题的分析和解决，go-redis客户端在IPv6环境下的稳定性和兼容性得到了显著提升，为在现代化网络环境中部署Redis集群提供了更好的支持。