Redis ACL SAVE 和 ACL LOAD 怎么迁移用户权限文件

Redis 的用户权限默认先存在运行中的服务里。如果要做容器重建、主机迁移或配置交付，不能只记住几条 ACL SETUSER 命令，而应把用户定义交给外部 ACL 文件：用 ACL SAVE 把当前权限写入文件，目标实例通过 aclfile 在启动时读取；文件修改后，再用 ACL LOAD 重新加载。

官方地址：https://redis.io/

这条流程只讨论 ACL 文件的保存、迁移、加载和重启来源，不展开命令分类授权。最容易混淆的一点是：CONFIG REWRITE 负责重写 Redis 配置，并不会自动触发 ACL SAVE。

先确定权限文件由谁负责

Redis 支持两种放置用户定义的方式：把 user ... 行直接写进 redis.conf，或者在配置中指定外部 ACL 文件。两种方式不能同时用于同一实例。用户较多、需要单独交付权限文件时，外部文件更容易纳入备份和迁移流程。

# 在配置文件中只选择一个外部 ACL 文件入口
aclfile /etc/redis/users.acl

# ACL 文件中的每一行描述一个用户及其规则
user app-reader on ~cache:* +get

文件格式与 redis.conf 中的用户定义格式相同，核心入口是 aclfile。迁移前先确认运行实例实际使用的路径、Redis 进程对文件的读写权限，以及交付系统是否会覆盖该文件。

用 ACL SAVE 保存当前用户权限

如果当前权限已经在运行中的 Redis 中配置完成，优先从运行状态生成 ACL 文件，而不是手工复制零散命令。连接具有相应管理权限的实例后执行：

# 把当前内存中的 ACL 用户配置写入 aclfile 指向的文件
redis-cli -h 127.0.0.1 -p 6379 ACL SAVE

成功时命令返回 OK。文件保存的是 Redis 当前识别到的用户规则，密码不会以明文密码形式出现在常规 ACL 列表里。生成文件后，把它作为迁移产物保存，并在交付前确认它对应的是本次变更后的状态。

如果用户配置是在文件里手工编辑的，保存动作的方向相反：ACL SAVE 会用当前运行配置覆盖文件。因此不要把“手工改文件后执行 ACL SAVE”当成加载操作，否则手工修改可能被当前内存状态覆盖。

把 ACL 文件交付给目标实例

迁移时至少要同时交付两部分：目标实例的 redis.conf 配置入口，以及与之匹配的外部 ACL 文件。只复制 ACL 文件而忘记设置 aclfile，目标实例不会凭文件自动使用这些用户。

# 目标实例的 redis.conf 指向迁移后的权限文件
aclfile /etc/redis/users.acl

# 启动参数保持由目标环境决定，避免把源机器的私有路径写进交付物
redis-server /etc/redis/redis.conf

Redis 启动后，连接目标实例执行 ACL LIST 或 ACL GETUSER 用户名，可以检查当前内存中的用户描述是否来自这份文件。这里的检查是运行流程中的操作确认，不等于把某一台线上页面当作验证对象。

迁移时还要记住两点：

• 外部 ACL 文件与直接写在 redis.conf 中的用户定义是二选一，不能两边都维护。
• 文件中保存的是用户规则和密码哈希等权限数据，应像配置凭据一样控制访问范围，不要把它提交到公开代码仓库。

用 ACL LOAD 热加载修改后的文件

如果目标实例已经运行，且只是要让它读取一份人工修改或配置系统生成的 ACL 文件，可以执行：

# 重新读取 aclfile 指向的完整用户权限文件
redis-cli -h 127.0.0.1 -p 6379 ACL LOAD

关键语义是“整份文件加载”：Redis 会检查文件中的用户定义，只有整体可接受时才替换当前 ACL。若文件中任意用户定义不正确，命令返回错误，旧的 ACL 配置继续有效。这种行为让错误文件不会直接把正在使用的权限状态替换掉。

因此，热加载前要先把文件作为一个完整交付物准备好；热加载后，如果返回错误，应保留错误文件以便修复，同时把“旧 ACL 仍有效”作为当前状态，而不是继续假设新规则已经生效。

不要把 CONFIG REWRITE 当成 ACL SAVE

CONFIG REWRITE 和 ACL SAVE 的持久化对象不同：

如果一次变更同时改了 Redis 配置和 ACL 用户，应该把两个文件分别纳入发布记录，并明确先后顺序。只执行 CONFIG REWRITE 不能证明外部权限文件已同步。

迁移失败时按这个顺序处理

1. 先确认入口。检查目标实例的 aclfile 是否指向预期文件，避免加载了另一份同名文件。
2. 再确认文件完整。不要只复制某一行用户定义；外部 ACL 文件应作为整体交付，逐行用户语法错误都可能让 ACL LOAD 失败。
3. 区分保存和加载。当前运行状态要写到文件用 ACL SAVE，文件内容要进入运行状态用 ACL LOAD。
4. 保留失败版本。加载返回错误时先保留错误文件和错误信息，因为旧 ACL 仍在工作；修复后再对同一个文件执行加载。
5. 最后处理重启。确认目标实例的启动配置仍然指向 ACL 文件，避免重启后回到没有外部文件的配置来源。

# 迁移后的最小操作顺序：先确认文件入口，再按动作选择命令
redis-cli CONFIG GET aclfile
redis-cli ACL SAVE   # 只有需要把当前运行状态写回文件时才执行
redis-cli ACL LOAD   # 只有需要读取文件内容进入当前实例时才执行

上面的三条命令不是固定的无脑脚本：如果源端刚完成用户配置，源端执行保存；如果目标端拿到新的文件，目标端执行加载。把两个方向混用，是迁移中最常见的误操作。

一张表记住 ACL 文件工作流

相关问题

ACL SAVE 会不会把明文密码写进文件？

ACL 文件使用用户规则和密码哈希等形式保存权限信息，不应把它当成普通文本配置公开分发。文件本身仍然需要按敏感配置控制读取和备份权限。

ACL LOAD 失败后需要立刻重启 Redis 吗？

不需要把重启当成默认修复动作。官方语义是错误文件不会替换当前 ACL，先根据返回错误修复完整文件，再重新执行 ACL LOAD 更容易保留现有服务状态。

修改 redis.conf 后执行 CONFIG REWRITE 就够了吗？

如果改动包含外部 ACL 文件中的用户权限，还不够。CONFIG REWRITE 与 ACL SAVE 管理不同文件，迁移清单中应分别记录。