Redis 7.0集群中ACL权限不自动同步，必须在每个节点统一配置aclfile并禁用redis.conf中的user行，否则导致AUTH失败或权限不生效；所有节点需共享同一aclfile路径、逐节点执行ACL SETUSER与ACL SAVE，并确保目标key所在slot的节点均配置对应用户及匹配pattern。
Redis 7.0集群中ACL权限不会自动同步到所有节点，必须在每个节点上单独配置或统一使用aclfile，否则会出现“用户存在但权限不生效”或“AUTH失败”的问题。
ACL配置必须用aclfile，不能只靠CONFIG REWRITE
在集群环境下，CONFIG REWRITE只会把用户写入当前节点的redis.conf，其他节点无感知。哪怕你用ACL SETUSER成功设置了用户，重启后只有执行过命令的那个节点保留配置——其余节点仍只有default用户。
- 必须在所有节点的
redis.conf中统一配置：aclfile /path/to/users.acl - 注释掉所有
user行（包括user default ...），避免与aclfile冲突 -
aclfile路径需所有节点一致，且Redis进程有读取权限 - 首次启用时，先用
ACL SAVE生成初始文件，再分发到各节点
ACL SETUSER命令在集群里要逐节点执行
临时调试或灰度开通权限时，不能只连一个节点运行ACL SETUSER就认为全集群生效。Redis集群不广播ACL变更，每个节点维护独立的用户表。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 连接每个节点分别执行：
./redis-cli -p 7001 ACL SETUSER alice on >pwd ~orders:* +@read +GET - 执行完立即
ACL SAVE，确保写入aclfile（如果已配置） - 若未配
aclfile，重启后权限丢失；若已配但忘记ACL SAVE，下次加载仍是旧快照 - 验证是否生效：
./redis-cli -p 7001 AUTH alice pwd→ 成功后再试GET orders:123
Key pattern限制在集群下必须匹配slot分布
ACL的~pattern只控制键名匹配，不干预slot路由。如果给用户授权~user:*，但实际user:1001落在节点A，user:2002落在节点B，而你只在节点A配置了该用户，那么访问user:2002会直接报错NOAUTH或NOPERM。
- 务必保证所有含目标key的slot所在节点，都配置了对应用户及
~pattern - 用
CLUSTER KEYSLOT user:1001查key归属slot，再用CLUSTER NODES查slot分配情况 - 对跨slot的通配符如
~*或~logs:*，只要pattern覆盖多个slot，就必须全节点部署用户
角色继承和@category在集群中完全可用，但别依赖default用户
@read、@write这些类别在7.0集群中行为一致，无需额外适配。真正容易踩坑的是默认用户：集群启动后default用户始终存在，但它的权限由各节点aclfile或redis.conf决定——如果某节点没配default，它就变成off状态，导致未指定用户名的连接直接拒绝。
- 显式声明
default用户权限（哪怕只是on nopass ~* +@connection）比依赖隐式行为更可靠 - 生产环境禁用
default：ACL SETUSER default off，强制所有客户端带用户名认证 -
ACL DRYRUN alice GET user:1001可在任意节点验证权限逻辑，不触发真实操作
最常被忽略的一点：ACL规则顺序影响最终权限。比如+@read ~orders:* -GET和-GET ~orders:* +@read效果不同——前者允许读其他key但禁止读orders，后者允许读orders但禁止所有GET。集群里每个节点的规则顺序必须一致，否则同个用户在不同节点行为不一致。
