Redis ACL LOAD 失败时怎样确认旧权限仍在生效

Redis 使用外部 ACL 文件时，ACL LOAD 不是“读到哪一行就应用到哪一行”的增量更新。官方文档说明：只有当文件中的用户都能正确指定时，加载才会成功；否则 Redis 返回错误，旧配置继续有效。因此，排查重点不是立刻覆盖运行态，而是用 ACL LIST 或 ACL GETUSER 读取当前实例里的规则，确认失败前的权限仍然存在。

官方文档：https://redis.io/docs/latest/operate/oss_and_stack/management/security/acl/

• ACL LOAD 报错：先把它当作一次未生效的文件变更。
• ACL LIST：适合快速看到所有用户的规则表达式。
• ACL GETUSER：适合针对一个用户分别查看状态、密码摘要、命令、键和频道。
• 文件已经改过不等于运行态已经改过，必须以 Redis 返回的运行态为准。

先理解 ACL LOAD 失败后的状态

外部 ACL 文件通常通过 aclfile 指令接入 Redis。文件的每一行描述一个用户及其规则，例如启用状态、密码、可执行命令和键模式。执行 ACL LOAD 时，Redis 会尝试把这个文件作为一组完整的用户配置加载；某个用户的规则写错、字段不完整或语法无法解析，都会让这次加载失败。

这里最容易误判的是“文件改动”和“内存中的 ACL”是两个对象。加载失败之后，磁盘文件可能已经是新版本，但实例仍保留此前能够正常工作的旧权限。不要根据编辑器里看到的内容判断某个账号现在能否登录，也不要因为文件中已经删除了某条规则，就立刻认定该规则在运行态消失。

加载前先建立运行态基线

如果变更流程允许，先保存一份当前运行态的关键信息。全量规则可以用 ACL LIST 查看，单个用户则用 ACL GETUSER 拆开查看。密码字段只会以摘要形式出现，也不要把命令输出原样写进公开日志。

# 只在受控终端执行；--askpass 避免把管理密码直接放进命令参数
redis-cli --askpass ACL LIST

# 针对目标用户读取运行态；用户名要按实际大小写填写
redis-cli --askpass ACL GETUSER app_reader

基线至少记录四类非敏感信息：用户是否为 on、允许的命令或命令类别、键模式以及频道模式。密码摘要和完整输出不应进入工单、聊天或普通监控标签。对于发布前后都要比较的账号，可以只保留脱敏后的规则摘要，例如“app_reader 为 on，仅允许 +get，键模式为 ~cache:*”。

ACL LOAD 报错时怎样确认旧权限仍在

先执行加载并保留 Redis 返回的错误文本。随后不要再次执行一串可能修改权限的命令，而是回到刚才的观察点：用 ACL LIST 检查目标用户是否仍然存在，用 ACL GETUSER 检查原来的状态、命令和键模式是否仍在。

# 重新加载外部 ACL 文件；返回错误时先停止后续权限变更
redis-cli --askpass ACL LOAD

# 读取全量运行态，确认失败没有把用户列表替换成半套结果
redis-cli --askpass ACL LIST

# 对关键账号做定点检查；这里只记录状态和授权范围，不记录密码内容
redis-cli --askpass ACL GETUSER app_reader

判断逻辑可以压缩成一句话：如果 ACL LOAD 返回错误，而关键用户的运行态仍与加载前基线相同，就说明这次文件变更没有生效，旧权限仍在内存中。这里的“相同”应比较授权语义，而不是比较输出行的顺序；用户列表的排序或密码摘要格式不应成为误报警依据。

修复文件后如何确认新规则已替换

修复时只改造成加载失败的具体问题，保留一个可追踪的文件版本。完成语法和用户规则核对后，再执行一次 ACL LOAD。成功返回后，不要只看“命令成功”，还要针对本次变更涉及的用户做定点读取。

# 先确认 redis.conf 指向的 aclfile 是本次修复的文件
redis-cli --askpass CONFIG GET aclfile

# 仅在修复后的 ACL 文件已就位时重新加载
redis-cli --askpass ACL LOAD

# 读取变更用户，确认启用状态、命令和键模式已经变成预期值
redis-cli --askpass ACL GETUSER app_reader

如果新规则把账号从 on 改为 off，或者收窄了键模式，已有连接与新连接的观察方式也要分开设计。ACL 规则变化对连接的实际影响取决于客户端当前认证状态和命令请求，不要拿一条旧连接的成功请求证明所有新连接都已经满足目标权限。

另外，ACL SAVE 与 CONFIG REWRITE 处理的对象不同。使用外部 ACL 文件时，配置文件和 ACL 文件是分开的；不要把修改了 redis.conf 或执行了 CONFIG REWRITE，误当成已经把当前 ACL 规则保存回外部文件。

把失败回滚纳入权限发布清单

生产操作中，最稳妥的顺序是“记录基线—加载—遇错停止—读取运行态—修复—再次加载—定点确认”。不要用反复执行 ACL SETUSER 来掩盖文件加载问题，否则文件和内存规则会逐渐分叉，下一次重启或 ACL LOAD 可能再次改变结果。

常见问题

ACL LOAD 失败会不会只应用前面几行？

按 Redis 官方文档描述，应把失败理解为本次文件没有整体替换成功，旧配置继续有效。最终仍以返回错误和随后读取到的运行态为准。

为什么 ACL LIST 和文件内容不一样？

最常见原因是文件已经编辑但还没有成功加载，或实例实际使用的 aclfile 路径不是你修改的那一份。先用 CONFIG GET aclfile 核对路径，再看加载结果。

只检查 ACL LIST 就够了吗？

全量检查适合发现用户是否存在，但关键账号还应使用 ACL GETUSER 查看命令、键和频道权限。只看到用户名存在，不能证明它的授权范围正确。

ACL LOAD 成功后还要检查旧权限吗？

要。成功加载只说明文件被接受；针对变更账号做定点检查，才能确认状态和授权范围确实变成预期值。

参考：Redis ACL 官方文档。本文配图为原创静态说明图，用于解释状态关系，不代表本机或线上 Redis 的执行截图。