redis集群原生不支持灰度发布，需通过proxy（如predixy）或客户端sdk实现key前缀路由，注意代理高可用、跨集群事务拦截、连接池隔离及日志打标。
Redis集群本身不支持灰度发布，必须依赖外部组件做流量路由
Redis Cluster 协议层没有版本标识、标签路由或权重分流机制，客户端直连集群时，GET、SET 请求按 slot 哈希硬绑定到固定节点，无法按业务规则动态切流。所谓“Redis 灰度”，本质是绕过集群原生路由，在客户端之上加一层可控的请求分发层。
用 Redis Proxy（如 Predixy、Twemproxy 或自研代理）实现按 key 前缀分流
这是最常用且低侵入的方式：在应用和 Redis 集群之间部署代理，根据 key 的命名特征决定打到哪个后端集群（例如旧集群 vs 新集群）。关键点在于代理需支持自定义路由逻辑，而非仅靠一致性哈希。
- Predixy 支持 Lua 脚本写路由规则，可提取
key中的业务标识（如"user:123:profile"中的"user"），匹配白名单后发往新集群 - 避免用 Twemproxy：它只支持静态分片，不支持运行时判断和双写/分流
- 代理自身要高可用，建议至少双机热备 + VIP 或 DNS 切换，否则它成了单点故障源
- 注意 pipeline 和事务（
MULTI/EXEC）在跨集群场景下会失败，这类请求必须路由到同一集群，代理需识别并拦截非法跨集群操作
客户端 SDK 侧实现灰度：基于连接池 + 动态路由表
当无法部署中间件（如容器环境受限、安全策略禁止代理），就得把路由逻辑下沉到应用层。核心是让 SDK 拥有“双集群连接池”和实时可更新的路由策略。
- 维护两张映射表：
gray_key_patterns（如["order:gray:*", "pay:test:*"]）和gray_cluster_config（新集群地址、密码、超时） - 每次执行
get或set前，先用String.startsWith()或正则匹配 key，命中则走新集群连接池，否则走默认集群 - 路由表必须支持热加载（如监听配置中心变更），不能重启应用；否则灰度开关就失去意义
- 务必关闭新集群的
slave-read-only（若用读写分离），否则SET类命令会因重定向失败而报MOVED或ASK错误
验证灰度效果时，最容易被忽略的是连接复用与 pipeline 污染
很多团队上线后发现“部分请求没走新集群”，排查半天发现不是路由逻辑错，而是连接没切干净。
- 连接池未隔离：旧集群连接池里混着新集群的空闲连接，SDK 误复用导致请求发错地方
- Pipeline 批量命令中混入不同集群的 key（如
["user:1:name", "order:gray:999:status"]），代理或 SDK 无法拆包，整批失败或静默路由到默认集群 - 未禁用客户端自动重试：某次
SET因新集群临时不可达超时，SDK 自动 fallback 到旧集群重试，造成数据不一致 - 监控只看成功率，漏掉“实际打到哪”的 trace 字段——建议在代理或 SDK 日志中强制打标
cluster=old/cluster=new
