Redis 6.0+启用ACL后，哨兵与主从认证失败的根本原因是身份不匹配：哨兵及从节点必须显式配置masteruser和auth-user，使用专用ACL用户（如repluser）并授予+replconf、+psync等权限，而非依赖requirepass和default用户。
根本原因不是密码配错了，而是 Redis 6.0 默认启用 ACL，而哨兵仍按旧逻辑用 requirepass 方式尝试认证，主从之间无法建立复制连接。
ACL 模式下从节点必须显式配置 masteruser
Redis 6.0+ 启用 ACL 后，requirepass 只作用于 default 用户；若主节点已用 ACL SETUSER repluser on >mypass +replconf +psync 创建专用复制用户，从节点光靠 masterauth mypass 不够——它仍以 default 身份发起复制请求，主节点直接拒掉。
- 从节点
redis.conf中必须同时存在：masteruser repluser和masterauth mypass - 主节点执行
ACL GETUSER repluser，输出中必须包含commands=+replconf +psync - 改完配置后必须重启从节点服务，
CONFIG REWRITE不会写入masteruser行，不生效 - 若主节点是集群模式，所有 master 分片都要为该 ACL 用户开放对应权限
哨兵自身也需适配 ACL 认证
哨兵在故障转移时要向主/从节点发 CONFIG SET、SLAVEOF 等命令，如果哨兵连接 Redis 实例时没带 ACL 用户名，会被拒绝执行。
- 哨兵配置里不能只写
sentinel auth-pass <master-name> mypass，还必须加sentinel auth-user <master-name> repluser - 该
repluser必须已在所有被监控的 Redis 实例（主 + 从）上创建并授权，否则哨兵连不上目标节点，日志卡在+failover-state-wait-promotion - 验证方式：用
redis-cli -u redis://repluser:mypass@10.97.0.44:6379手动连主节点，执行INFO replication看是否成功
客户端连接池未刷新导致“切换成功但应用连错”
这不是认证失败，但常被误判为认证问题：哨兵已完成故障转移，新主已就位，但 Spring Boot 应用仍往旧地址发 AUTH 请求，报 NOAUTH Authentication required —— 因为旧主已降级为从，且可能已关闭密码或 ACL 权限。
- Lettuce 默认缓存哨兵返回的主节点地址，且对
+switch-master事件响应迟钝；超时设得太短（如timeout=600）会导致连接卡死在旧连接上 - 必须显式启用动态刷新：
spring.redis.lettuce.cluster.refresh.period=5000（单位毫秒），或升级到 Lettuce 6.2+ 使用DynamicMasterSlaveTopologyProvider - Redisson 配置中
sentinel-password和password是两个字段：前者用于连接哨兵，后者用于连接最终选出的主节点，缺一不可
ACL 是分水岭。Redis 6.0 的认证模型变了，但很多人只改了 requirepass，没补 masteruser 和 sentinel auth-user，结果所有环节都在“等认证通过”，实际是身份不匹配。查日志时看到 NOAUTH，第一反应不该是输错密码，而是确认当前通信双方用的是哪个用户、有没有被 ACL 拦住。
