Redis COPY 复制键时 replace 选项会覆盖什么

Redis COPY 的 REPLACE 不是“把两个 key 合并”，而是决定目标 key 已存在时要不要先删掉它。默认执行 COPY source destination，如果目标键已经存在，命令返回 0，目标原值不变；加上 REPLACE 后，Redis 会移除目标键，再把源键的值复制过去，成功返回 1。源键本身不会被删除，也不会因为复制动作自动建立同步关系。

官方地址：https://redis.io/docs/latest/commands/copy/

先看清两种命令的返回结果

可以把 source 想成待发布快照，把 destination 想成当前线上键。下面的例子只用于说明命令语义，输出是预期示意，不代表本机已经执行。

# 准备一个源键和一个已经存在的目标键
SET profile:ready '{"version":1,"mode":"ready"}'
SET profile:work  '{"version":0,"mode":"draft"}'

# 默认模式不覆盖已有目标，返回 0，目标仍是旧值
COPY profile:ready profile:work
GET profile:work

# 明确允许整键替换，返回 1，目标改为源键内容
COPY profile:ready profile:work REPLACE
GET profile:work

判断重点不是只看命令有没有报错，而是把整数返回值和目标值一起看：返回 0 表示这次没有完成复制，常见原因是目标已存在；返回 1 才表示源键成功复制到了目标。源键不存在时也不能把 REPLACE 当成兜底，它不会凭空创建源数据。

REPLACE 覆盖的是整个 Redis 对象

这里最容易误解的是“覆盖”。如果源键是 Hash，目标键也是 Hash，REPLACE 不会逐字段比较，也不会保留目标中源键没有的字段；它面对的是两个完整 key。目标原来是什么类型，也不影响替换动作最终把源对象放到目标名称下。

因此，想保留目标 Hash 的某几个字段时，不能直接用 COPY ... REPLACE。应根据需求选择 HSET、HDEL 或 Lua/事务方案，把字段级变更写清楚。想做“发布一份完整快照”，才适合使用 REPLACE。它也不是双向同步：复制完成后继续修改 source，destination 不会跟着变化。

把返回值和边界检查放在一起

在脚本或发布流程里，建议先确认源键确实存在，再根据返回值决定是否继续。对集合类型，官方给出的复杂度是最坏 O(N)，其中 N 与集合嵌套成员数量有关；字符串值是 O(1)。大 Hash、List 或 Set 在高峰期复制，仍要考虑单线程命令的阻塞窗口。

# 先确认源键存在，再执行可覆盖复制
EXISTS profile:ready
TYPE profile:ready

# 只在业务确认可以覆盖时使用 REPLACE
COPY profile:ready profile:work REPLACE

# 用 TTL 复核复制后的生命周期，避免把过期策略当成默认合并行为
TTL profile:ready
TTL profile:work

TTL 是独立的生命周期检查项；文章的重点是目标键是否被替换，不应仅凭一次复制就假设目标仍保留原来的过期策略。对有过期要求的缓存发布，复制后应按业务规则显式设置或复核过期时间。

三种场景怎么选命令

如果还需要复制到另一个逻辑数据库，可以使用 DB destination-db；这改变的是目标所在的逻辑数据库，不会把 REPLACE 变成字段合并。Redis COPY 从 Redis Open Source 6.2.0 开始提供，老版本部署要先确认命令可用。

常见问题

不加 REPLACE 时目标键会被部分更新吗？

不会。目标键存在时命令返回 0，不会把源值写入目标，也不会做字段级补丁。

REPLACE 会删除源键吗？

不会。它移除的是目标键，源键仍然保留；如果需求是迁移并删除源键，应另行设计迁移流程。

复制成功后两个 key 会自动保持一致吗？

不会。COPY 只产生一次复制结果，之后两个 key 的读写互不跟随。

记住一个判断句即可：不允许覆盖就接受返回 0 并走冲突分支；允许发布完整对象才使用 REPLACE，并在流程里单独核对 TTL、类型和集群槽位。