Redis MSETNX 怎么保证多个键要么全部创建要么不创建

批量初始化 Redis 配置时，最容易误判的一种现象是：命令返回 0，于是代码以为“前面几个键已经写进去了，只有某个键失败”。MSETNX 的语义恰好相反：只要给出的键中有一个已经存在，Redis 就不会设置任何一个键。

结论：MSETNX 只有两种结果。所有键都不存在时，所有键一次性创建并返回 1；至少一个键已存在时，一个键也不会创建并返回 0。它适合做一组关联键的首次初始化，而不是覆盖更新。

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

问题现场：返回 0 不等于部分成功

假设应用第一次上线，需要同时写入订单的状态、版本和创建时间。代码把这三个键放进一次 MSETNX：

# 这些键都不存在时，三组键值会一起创建
MSETNX order:1001:status pending order:1001:version 1 order:1001:created_at 2026-10-13T06:00:00+08:00

如果三个键都是新键，返回整数 1。如果另一个进程已经创建了 order:1001:version，这次请求返回 0，而 order:1001:status 和 order:1001:created_at 也不会被写入。这个“全有或全无”正是它和逐个 SETNX 的区别。

时间线：一个已存在的键如何让整批写入停止

1. 初始化请求携带多个键值对，Redis 收到的是一条 MSETNX 命令。
2. Redis 判断这些键是否全部不存在。
3. 全部不存在时，命令原子地写入所有键，返回 1。
4. 只要发现一个已有键，命令不执行任何写入，返回 0。

因此排查日志时，应把返回 0 记录成“初始化条件未满足”，而不是“部分键写入失败”。如果后续业务需要知道是哪个键已经存在，可以额外用 EXISTS 或 MGET 做诊断；这些检查不改变 MSETNX 本身的全有或全无语义。

最小命令：用返回值确认是否全部创建

MSETNX 的语法是 MSETNX key value [key value ...]，参数必须成对出现。下面的示例展示成功和失败两种情况：

# 第一次写入：两个键都不存在，因此返回 1
MSETNX profile:42:name Ada profile:42:level 3

# 第二次写入：profile:42:name 已存在，因此返回 0，两个键都不会改变
MSETNX profile:42:name Grace profile:42:level 4

# 读取结果：第二次请求不会把 level 改成 4
MGET profile:42:name profile:42:level

预期逻辑是：第一次返回 1；第二次返回 0；最后读取到的仍是第一次写入的两项值。这里不要把 0 当成网络错误，真正的传输或命令错误应当由客户端的 error 分支单独处理。

Go 客户端：把全有或全无映射成清晰分支

使用 Go 客户端时，MSETNX 通常返回一个布尔结果。关键是先判断错误，再判断布尔值，不能把 false 和 err != nil 合并成同一种失败。

package main

import (
    "context"
    "fmt"

    "github.com/redis/go-redis/v9"
)

func initOrder(ctx context.Context, rdb *redis.Client, orderID string) error {
    // 同一批字段必须成组创建；MSetNX 返回 false 时不会留下半组数据。
    created, err := rdb.MSetNX(ctx, map[string]interface{}{
        "order:" + orderID + ":status":     "pending",
        "order:" + orderID + ":version":    1,
        "order:" + orderID + ":created_at": "2026-10-13T06:00:00+08:00",
    }).Result()
    if err != nil {
        // 网络或命令错误不能当作“已有键”，交给上层决定是否重试。
        return fmt.Errorf("初始化订单键失败: %w", err)
    }
    if !created {
        // false 表示至少一个键已存在，本次没有任何键被设置。
        return fmt.Errorf("订单 %s 已初始化或存在冲突", orderID)
    }

    // true 只表示这一批键全部创建成功。
    return nil
}

如果业务允许多个请求同时竞争首次初始化，只有拿到 true 的请求应继续执行“首次创建后的动作”。拿到 false 的请求可以重新读取当前值，决定是复用已有状态、返回幂等成功，还是提示数据冲突。

根因：把 MSETNX 当成多个 SETNX 连续执行

很多“怎么只写进去一半”的排查，根因并不是 MSETNX 发生了部分写入，而是业务代码先后发送了多条 SETNX，或者把 MSETNX 返回 0 后又读取到了更早存在的键，于是将两件事混在了一起。

MSETNX 的职责很窄：判断所有键都不存在时一次性创建。它不会覆盖已有键，也不会返回“成功创建了几个键”。如果需求是覆盖写，应该明确使用 MSET；如果需求是不同条件下执行更复杂的逻辑，则需要另行设计，但不应把这些需求偷偷塞进 MSETNX 的返回值解释中。

防复发：让初始化流程可重试、可判断

可以把初始化动作收敛成三个判断：

1. 命令错误：保留错误上下文，按连接和重试策略处理，不把它转成业务冲突。
2. 返回 0：说明至少一个键已经存在，不继续执行依赖“首次创建”的副作用动作。
3. 返回 1：说明这一批键都由本次请求创建，可以继续后续流程。

还要注意，MSETNX 的时间复杂度是 O(N)，N 是键的数量；一次塞入过大的键集合会让单条命令变重。Redis 官方文档还提示，集群环境中的多键命令行为需要结合多键操作规则判断。本文只讨论命令本身的全有或全无语义，不把跨槽路由当成普通单实例命令来处理。

相关问题

MSETNX 返回 0 时会不会已经写入部分键？

不会。按 MSETNX 的语义，只要至少一个键已经存在，本次不会设置任何键。

MSETNX 能不能覆盖已有键？

不能。它只负责“全部不存在时创建”；需要覆盖写时应选择具有覆盖语义的命令。

怎么知道具体是哪个键已经存在？

先把返回 0 视为整批未创建，再用 EXISTS 或 MGET 做诊断读取，不要从返回值 0 推导出具体键名。