Redis 6.0集群不自动同步ACL，必须逐节点手动配置并执行ACL SAVE持久化；否则客户端重定向后因认证失败或权限缺失报NOAUTH/NOPERM。
Redis 6.0 集群本身不支持 ACL 用户同步，必须为每个节点单独配置 ACL —— 这是集群模式下最常被忽略的前提。
为什么集群里 ACL 不自动同步
Redis Cluster 的节点间只同步数据分片（slot）和拓扑信息，ACL 是服务端本地状态，ACL SETUSER 命令不会广播到其他节点。你在一个节点上创建了 order_svc 用户，其他节点仍只有默认的 default 用户，客户端连过去若路由到未配置的节点，就会因认证失败或权限越界报错。
- 现象：客户端用
AUTH order_svc ord123!连接集群任意节点，有时成功、有时返回NOAUTH Authentication required或NOPERM this user has no permissions to run the 'GET' command - 根本原因：集群客户端（如 Lettuce、Jedis Cluster）通常只对第一个节点做 AUTH，后续 MOVED/ASK 重定向后的新连接默认走
default用户 - 兼容性影响：哪怕用了
--user参数启动redis-cli -c，它也无法保证每次重定向都重新认证
必须逐节点执行 ACL SETUSER 并 SAVE
没有捷径，必须登录每个主节点（含从节点，以防故障切换）手动配置并持久化。推荐用脚本批量操作：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 先确认所有节点运行 Redis 6.0+：
redis-cli -h node1 -p 6379 INFO server | grep redis_version - 对每个节点执行相同 ACL 命令，例如订单服务用户：
ACL SETUSER order_svc on >ord123! ~order:* +@read +@write -FLUSHDB -FLUSHALL - 立即保存到磁盘（避免重启丢失）：
ACL SAVE（注意：需在redis.conf中已配置aclfile路径） - 验证是否生效：
ACL GETUSER order_svc，检查keys和commands字段是否符合预期
客户端连接时必须显式指定用户名，且不能依赖集群自动透传
旧版 AUTH <password> 在集群中会隐式走 default 用户；新方式必须每条连接都带用户名。
- Jedis Cluster 不原生支持多用户，需改用
JedisPool管理单节点连接，或升级到 Jedis 4.x 并手动构造带user参数的JedisClientConfig - Lettuce 推荐使用
RedisURI.Builder显式设置：RedisURI.Builder.redis(host, port).withUsername("order_svc").withPassword("ord123!".toCharArray()) - redis-cli 测试务必加
-c+--user：redis-cli -c --user order_svc --pass ord123! -h node1 -p 6379，否则连不上非首节点 - 云厂商托管集群（如阿里云 DCS、腾讯云 CRS）可能封装了 ACL 同步逻辑，但自建集群绝无此能力
键模式（~pattern）在集群中仍受限于单节点视角
~order:* 只限制当前节点能访问哪些 key，但无法阻止客户端发一个 GET order:123 到错误节点——因为集群靠 hash tag（如 {order:123}）决定 slot 分配，ACL 不参与路由决策。
- 风险点：若业务 key 没加 hash tag，
order:123可能落在任意节点，而只有该节点配置了order_svc用户才允许访问 - 正确做法：强制 key 命名带一致 hash tag，例如统一用
{order}:123，确保同前缀 key 落在同一 slot 和同一节点 - ACL 无法替代应用层路由控制，它只是“进门后能不能碰东西”，不是“该进哪扇门”
真正麻烦的从来不是命令怎么写，而是集群里每个节点的 ACL 状态是否完全一致、客户端是否真正在每次 TCP 连接时都传了正确的 username。漏掉一个节点的 ACL SAVE，或客户端某次重连没带用户参数，权限体系就形同虚设。
