Redis FUNCTION RESTORE 的 APPEND 与 REPLACE 有什么区别

把 Redis 函数库从一台实例迁移到另一台实例时，FUNCTION RESTORE 的策略决定了目标端遇到同名 library 会怎样处理。APPEND 是默认的保守选项：追加载荷中的库，遇到同名库就中止；REPLACE 则允许用载荷中的同名库替换目标端已有库，但它只处理 library 名称冲突，不会替你解决库内函数名冲突。

官方文档：https://redis.io/docs/latest/commands/function-restore/

如果目标端不应被已有库覆盖，选 APPEND；如果载荷就是目标库的明确更新版本，选 REPLACE。两者都接收 FUNCTION DUMP 生成的序列化载荷，成功时返回 OK。

先看 FUNCTION RESTORE 的覆盖范围

这个命令不是直接接收一段 Lua 源码，而是接收 FUNCTION DUMP 生成的 serialized-value。载荷里可以包含一个或多个函数库，第二个可选参数才是恢复策略：

# 载荷来自 FUNCTION DUMP；策略未写出时默认按 APPEND 处理
redis-cli FUNCTION RESTORE  [FLUSH|APPEND|REPLACE]

# 将备份载荷追加到目标实例，目标端存在同名库时不覆盖
redis-cli FUNCTION RESTORE "$dump" APPEND

# 将载荷中的同名库作为目标端的更新版本
redis-cli FUNCTION RESTORE "$dump" REPLACE

官方命令语法是 FUNCTION RESTORE serialized-value [FLUSH | APPEND | REPLACE]，命令从 Redis Open Source 7.0.0 开始提供，复杂度为载荷中函数数量对应的 O(N)。这里的“恢复”对象是函数库，不是普通键空间数据。

APPEND 适合不覆盖的增量恢复

APPEND 会把载荷中的函数库追加到目标端已有函数库中，这是默认策略。它的关键取舍是“宁可失败，也不覆盖”：只要库名发生冲突，恢复就会中止。因此它适合首次导入、分批补充，或你还没有确认目标端同名库能否被替换的场景。

例如目标端已有 billing_v1，备份载荷也包含 billing_v1，下面的请求不会静默覆盖原库：

# APPEND 是默认策略；同名 library 会触发冲突并中止
redis-cli FUNCTION RESTORE "$dump" APPEND

# 不写策略也等价于 APPEND，适合明确禁止覆盖的导入脚本
redis-cli FUNCTION RESTORE "$dump"

这个行为对发布脚本很有用：脚本可以把“已存在目标库”当成需要人工决策的信号，而不是把一次误传的备份当成线上更新。若你要重试，先确认目标端是否已经部分写入，以及载荷中有哪些 library。

REPLACE 适合更新已有同名库

REPLACE 仍然会保留目标端其他没有出现在载荷里的函数库，但对于载荷中与目标端同名的 library，会使用载荷版本替换目标版本。它适合灰度升级后的函数库同步、从预发布环境推送同名版本，或你已经确定载荷是目标库的权威版本时使用。

# REPLACE 的覆盖粒度是 library；未出现在载荷中的其他库不在本次范围内
redis-cli FUNCTION RESTORE "$dump" REPLACE

# 仅用库名冲突做决策，不要把 REPLACE 理解成“解决所有函数重名”
# 库内函数名的设计与兼容性仍需在生成载荷前处理

尤其要注意，Redis 文档明确说明：REPLACE 不能防止函数名冲突，它只处理 library 名称冲突。换句话说，库名可以被替换，并不代表载荷中的每个函数都能与现有逻辑安全合并。

按迁移场景选择策略

可以先判断目标端是否允许被同名库覆盖，再决定参数。不要只看“能不能恢复”，还要看恢复后目标端的函数库集合是否符合预期：

生产脚本还应把载荷来源、目标环境和选择的策略写入发布记录。FUNCTION RESTORE 成功时返回简单字符串 OK；这只能说明命令接受了恢复请求，不能替代对函数库内容和调用方兼容性的检查。

常见问题

不写 APPEND 或 REPLACE 时默认是什么？

默认是 APPEND。遇到同名 library 时不会按 REPLACE 处理。

REPLACE 会删除目标端所有函数库吗？

不会。REPLACE 只替换载荷涉及的同名 library；如果要先删除所有已有库，应明确选择 FLUSH，并评估影响范围。

APPEND 与 REPLACE 能解决函数名冲突吗？

不能把它们当成函数重名解决器。两种策略的主要差异在 library 名称冲突，库内函数命名和版本兼容仍由迁移方案负责。

记住一个简单判断：不确定是否覆盖时用 APPEND，明确发布同名库的新版本时用 REPLACE，只有确实要清空已有函数库才考虑 FLUSH。