Redis COPY 怎么安全复制键：REPLACE、DB 与集群哈希槽边界

线上缓存热修复时，最怕的不是复制失败，而是目标键原本有值却被误判成“已经复制成功”。Redis 的 COPY 返回的是 1 或 0：目标键不存在时复制成功，目标键已存在且没有加 REPLACE 时返回 0。把这个返回值、TTL 和集群哈希槽一起验收，才不会把旧缓存当成新缓存。

先用一个返回值判断复制是否真的发生

先准备一对不会影响业务的测试键。字符串最容易观察，但同样的命令也适用于 List、Set、Hash、Sorted Set 和 Stream 等 Redis 数据类型。

SET cache:user:42 '{"tier":"pro","quota":80}' EX 300
DEL cache:user:42:backup
COPY cache:user:42 cache:user:42:backup
GET cache:user:42:backup
PTTL cache:user:42:backup

这里的整数回复是 1，说明目标键确实创建了。复制操作会带上源键的剩余生存时间，所以最后的 PTTL 应该接近 300 秒，而不是永久键。实际值会因命令执行间隔略有下降。

把目标键先写入一个旧值再试一次：

SET cache:user:42:backup old-value EX 120
COPY cache:user:42 cache:user:42:backup
GET cache:user:42:backup

此时返回 0，目标键仍然是 old-value。这个行为很适合作为“只补缺失缓存”的保护门，但不能把 0 当作网络异常或源键不存在。源键不存在时也会返回 0，排查时要补一条 EXISTS。

REPLACE 不是普通覆盖开关

需要把目标键刷新成源键内容时，才显式加上 REPLACE：

SET cache:user:42:backup old-value EX 120
COPY cache:user:42 cache:user:42:backup REPLACE
GET cache:user:42:backup
PTTL cache:user:42:backup

目标键会先被删除，再创建为源键的副本。它的意义不只是“写入新值”：目标键原有的数据类型、旧内容和旧 TTL 都会被替换。脚本如果允许用户传入目标键，最好先做命名空间校验，避免一次复制覆盖了不该动的业务键。

还要注意数据量。复制字符串的工作量接近 O(1)，但复制一个有大量成员的 Hash 或 Set，成本会随成员数量增长。可以在低峰期用 MEMORY USAGE 估算目标体积，并把复制动作放入可回滚的维护窗口。

DB 参数与 Redis Cluster 的边界

单机或主从实例启用了多个逻辑库时，可以把目标键放到另一个 DB：

SELECT 0
SET feature:checkout on EX 600
COPY feature:checkout feature:checkout:staging DB 1
SELECT 1
GET feature:checkout:staging

DB 1 改的是目标键所在的逻辑库，不是物理 Redis 节点，也不会把命令变成跨实例迁移。Redis Cluster 只使用 DB 0，不能用这个参数绕过分片规则。

集群环境下，源键和目标键必须位于同一个哈希槽。要让相关键稳定落在同一槽，可以使用同一个 hash tag：

SET user:{42}:profile pro EX 300
DEL user:{42}:profile:backup
COPY user:{42}:profile user:{42}:profile:backup

{42} 是两把键共享的槽标签。若源键是 user:42:profile、目标键是 backup:user:42:profile，即便它们看起来属于同一业务，也不能据此推断一定同槽。跨槽复制应改用具备明确迁移语义的方案，并单独评估网络、权限和回滚。

把复制动作写成可验收的小流程

维护脚本不要只记录 COPY 的整数回复，至少留下以下四项：源键是否存在、源键类型、COPY 返回值、目标键复制后的 TTL。这样能区分“源键不存在”“目标键已存在”“跨槽失败”和“复制成功但 TTL 不符合预期”。

如果复制的是业务配置而不是缓存，建议在源值中带上版本号，复制后读取目标值并比对版本。对于大集合，则再记录成员数或内存估算，不要在高峰期批量复制未知大小的键。

常见问题

Redis COPY 返回 0 是失败吗？

不一定。目标键已存在且未使用 REPLACE，或者源键不存在，都可能得到 0；要结合 EXISTS 和 TYPE 判断。

COPY 会复制源键的过期时间吗？

会复制源键当前的剩余 TTL，验收时用 PTTL 读取目标键，不能只比较字符串内容。

Redis Cluster 能用 COPY 的 DB 参数跨库吗？

不能。Cluster 只使用 DB 0，DB 参数也不能绕过源键和目标键必须同槽的限制。

目标键一定要加 REPLACE 吗？

不需要。只想补齐缺失缓存时不要加；只有确认旧值可以被源值替换时才加。

结语：先确认覆盖意图，再确认槽位和 TTL

COPY 的最小用法很简单，真正容易出错的是把返回值、覆盖语义和部署形态混在一起。单机多 DB 关注目标库，集群关注 hash tag 和同槽，所有环境都要核对目标键的 TTL。把这三层检查写进脚本，复制键才会是一项可回放、可解释的维护动作。