Redis 3.2 支持原生集群（Cluster）模式，自3.0版本起已引入；但Windows平台的Redis-x64-3.2.100移植版不支持集群，仅适用于开发测试，且已停止更新。
redis:3.2 镜像跑 --cluster-enabled yes，会直接报错或静默失败——因为该参数从 Redis 3.0 引入，但 3.2 版本对集群的兼容性和稳定性远不如 5.0+，且官方文档明确建议生产环境使用 6.0+。
下面分三个真实高频场景给出可落地的操作路径：
用 docker run 快速起一主二从（无哨兵）
适合开发/测试环境快速验证主从同步逻辑，不涉及自动故障转移。
- 启动主节点：
docker run -d --name redis-master -p 6379:6379 redis:3.2 redis-server --appendonly yes - 启动从节点1：
docker run -d --name redis-slave1 -p 6380:6379 redis:3.2 redis-server --slaveof redis-master 6379 --appendonly yes - 启动从节点2：
docker run -d --name redis-slave2 -p 6381:6379 redis:3.2 redis-server --slaveof redis-master 6379 --appendonly yes
⚠️ 注意：Docker 默认 bridge 网络下，容器名 redis-master 可被其他容器解析；但若用 --network host，则必须用宿主机 IP（如 127.0.0.1）代替容器名，否则 slaveof 会连接失败。
用 docker-compose 搭建带哨兵的三节点高可用组
这是 Redis 3.2 能做到的最接近“生产可用”的方案，需显式启动 3 个哨兵进程监控同一主从组。
- 哨兵配置文件
sentinel.conf内容必须包含：sentinel monitor mymaster redis-master 6379 2（quorum=2 表示至少 2 个哨兵同意才触发切换） -
docker-compose.yml中需定义 1 个 master、2 个 slave、3 个 sentinel 服务，并确保它们在同一个自定义网络（如redis-net）中 - 哨兵容器启动命令必须加
--sentinel参数：redis-server /etc/redis/sentinel.conf --sentinel
? 关键点：哨兵无法跨 Docker 网络发现 Redis 实例。如果 Redis 容器用了 host 网络，哨兵也必须用 host，否则 sentinel monitor 中写的 redis-master 会解析失败。
用 Codis 3.2 实现分片+高可用（替代原生 Cluster）
当业务需要水平扩展（比如 key 分片、自动迁移），又卡在 Redis 3.2 不升级时，Codis 是唯一成熟选择。它把分片逻辑放在 proxy 层，后端 Redis 仍用 3.2 主从组。
- Codis 的
codis-dashboard必须先启动，且依赖 ZooKeeper（不能用 etcd 或本地文件） - 每个
codis-proxy启动前，必须通过 Dashboard 手动初始化 slot range 并关联到某组 Redis（如 group-1 对应 master+slave） - 客户端连接的是 proxy 的 19000 端口，不是 Redis 的 6379；proxy 会自动将请求路由到对应 group 的 master 或 slave
⚠️ 容易漏掉的一步：Codis 初始化后，必须执行 codis-config server add ... 和 codis-config slot init，否则 proxy 启动会报 no available backend 错误。
--cluster-enabled 配置硬套到 3.2 上，结果容器反复重启却查不到日志里的有效错误——因为 3.2 根本不识别这个参数。真要上 Cluster，镜像至少换 redis:6.2 或更高。 
