Redis 里要执行多条命令有哪些方式？秒杀场景里选哪种？

大厂面试经常问的经典问题：“Redis 里要执行多条命令，有哪些方式？秒杀场景里选哪种？” 时，如果你只说了 “用 Pipeline 批量发”，结果面试官要追问：“秒杀扣库存要原子性，Pipeline 能保证吗？用事务还是 Lua 脚本？” 瞬间亚麻呆住了 —— 只知道有这个方案，却不懂每种方案的业务适配性，直接不好意思你被判定 “没在业务里用过 Redis 多命令执行”。

其实 Redis 多命令执行是大厂面试的 “高频业务题”，面试官要的不是 “报方案名”，而是你能结合场景说清 “为什么选这个方案”—— 毕竟多命令执行的核心是平衡 “效率（减少网络往返）” 和 “原子性（避免中间出错）”，比如秒杀要原子性，数据同步要效率，选对方案才能避免线上事故。

今天用 4 个真实业务场景，拆透 Redis 多命令执行的 4 种方案，补上你可能不懂的 “细节盲区”，最后给面试标准答案模板，下次再被问，直接让面试官点头。

先搞懂：为什么大厂总问 “Redis 多命令执行”？

很多人以为这是 “Redis 语法题”，其实是 “业务架构题”。面试官想通过这个问题判断两点：

1. 你懂不懂 “效率 vs 原子性” 的平衡？比如批量同步数据要效率，秒杀扣库存要原子性，方案选择不同；
2. 你有没有业务实战经验？比如转账、秒杀、缓存更新这些场景，怎么用多命令执行解决实际问题，而不是背命令。

所以答题的核心，不是罗列 “有批量命令、Pipeline、事务、Lua 脚本”，而是 “业务场景→核心需求（效率 / 原子性）→选什么方案→为什么”。

先明确：多命令执行的 2 个核心需求（业务里绕不开）

不管是电商、金融还是社交，用 Redis 执行多条命令，本质都是为了解决两个问题，这也是选方案的关键：

• 需求 1：提效率：单条命令发 10 次要 10 次网络往返，批量发只需要 1 次，尤其客户端和 Redis 不在同一机房时，延迟能降 90%（比如数据同步场景）；
• 需求 2：保原子性：多条命令要么全成，要么全败，不能出现 “一半成功一半失败”（比如秒杀扣库存：先查库存→再扣减，中间被其他请求插进来，就会超卖）。

所有方案都是围绕这两个需求设计的，下面用 4 个真实业务场景，拆透每种方案的用法，补上容易懂的细节。

4 种方案 + 业务场景：从 “怎么用” 到 “为什么选”（面试重点）

每种方案都对应不同的业务需求，先讲 “业务痛点”，再讲 “方案实现”，最后说 “为什么选它”，关键细节会补充说明，避免只背命令不落地。

方案 1：批量命令（MSET/MGET）—— 同类型命令提效，适合缓存批量操作

业务场景：电商商品详情页，要缓存 10 个商品的基础信息（ID、名称、价格），每个商品用字符串键（如goods:1001、goods:1002）存储。痛点：如果循环调用 10 次GET命令，要 10 次网络往返，延迟高，页面加载慢（尤其用户在异地，网络延迟 100ms 的话，10 次就是 1 秒，远超用户忍耐阈值）。

怎么实现？用 MGET 批量获取

# 批量设置 10 个商品缓存（MSET：同类型字符串命令，1 次请求完成）
127.0.0.1:6379> MSET goods:1001 "iPhone15,5999" goods:1002 "华为 Mate60,6999" ... goods:1010 "小米 14,4999"
OK
# 批量获取 10 个商品缓存（MGET：1 次请求拿回所有结果，延迟从 1 秒压到 100ms）
127.0.0.1:6379> MGET goods:1001 goods:1002 ... goods:1010
1) "iPhone15,5999"
2) "华为 Mate60,6999"
...
10) "小米 14,4999"

为什么选它？

• 优点：Redis 原生支持，不用额外写代码；1 次网络往返，效率最高；单条命令天然原子（Redis 单线程，执行 MSET 时不会被其他命令打断，不会出现 “只设置了 5 个商品” 的情况）；
• 缺点：只能处理同类型命令（比如 MSET 只能操作字符串，不能混合 HSET 哈希命令；想批量操作哈希，得用 HMSET，不能和 MSET 混在一起）；
• 适用场景：批量操作同一种数据结构（如缓存批量设置 / 获取、批量删除同类型键）。

方案 2：Pipeline（管道）—— 混合命令提效，适合非原子性场景

业务场景：电商每日凌晨 3 点，要把 MySQL 里的 1000 个用户等级同步到 Redis（用户等级存在哈希键user:level:1001，同时要记录同步时间sync:time为字符串键）。痛点：要执行 1000 次HSET（用户等级）+1 次SET（同步时间），共 1001 条命令，循环单条发延迟太高（1001 次网络往返，延迟可能超 10 秒）；且命令类型不同（哈希 + 字符串），批量命令用不了。

怎么实现？用 Pipeline 批量发混合命令（以 Java RedisTemplate 为例）

// 1. 创建 Pipeline（注意：RedisTemplate 的 Pipeline 需通过连接获取，确保批量执行）
RedisPipeline pipeline = redisTemplate.getConnectionFactory().getConnection().openPipeline();
try {
    // 2. 批量添加混合命令（哈希 HSET + 字符串 SET）
    for (Long userId : userIds) { // 1000 个用户
        String userLevelKey = "user:level:" + userId;
        // 从 MySQL 查用户等级 level（省略查询逻辑）
        Integer level = getUserLevelFromMySQL(userId);
        pipeline.hSet(userLevelKey, "level", level); // 哈希命令
    }
    // 记录同步时间（字符串命令，和哈希命令混在一起发）
    pipeline.set("sync:time", LocalDateTime.now().toString());
    // 3. 一次性执行所有命令，获取结果（1 次网络往返，延迟压到 100ms 内）
    List<Object> results = pipeline.syncAndReturnAll();
} finally {
    // 关闭 Pipeline，释放连接
    pipeline.close();
}

关键补充：为什么 Pipeline 不保证原子性？

很多人误以为 Pipeline 是 “批量原子执行”，其实不是 ——Redis 执行 Pipeline 中的命令时，是逐条执行的。比如上面的同步场景，Pipeline 里有 1000 个 HSET 和 1 个 SET，执行到第 500 个 HSET 时，若其他客户端发了一条SET sync:time "2024-01-01"，这条命令会插入到第 500 个 HSET 和第 501 个 HSET 之间，导致 “同步时间被篡改”，出现数据暂时不一致（虽然最终同步完成后会覆盖，但中间状态有风险）。这就是 Pipeline 的核心局限：它只解决 “效率问题”，不解决 “原子性问题”。

为什么选它？

• 优点：支持混合命令（哈希、字符串、集合都能一起发）；1 次网络往返，效率比单条发高 100 倍；
• 缺点：不保证原子性（中间可能插入其他命令）；命令太多时可能导致客户端缓冲区溢出（建议单次不超过 1000 条）；
• 适用场景：非原子性要求的批量操作（如数据同步、批量初始化缓存、日志批量写入 —— 这些场景即使中间被插入命令，最终结果能对齐，不影响业务）。

方案 3：事务（MULTI/EXEC）—— 简单原子操作，适合无逻辑判断场景

业务场景：金融转账场景，用户 A 给用户 B 转 100 元，Redis 里用字符串键存余额（balance:A=500，balance:B=500），需要执行两步：①DECRBY balance:A 100（扣 A 的钱）；②INCRBY balance:B 100（加 B 的钱）。这两步必须同时成功或失败，不能出现 “扣了 A 的钱（A 剩 400），没加 B 的钱（B 还是 500）”—— 否则用户会投诉 “钱没了”。

怎么实现？用事务包裹两条命令

# 1. 标记事务开始（所有后续命令进入队列，不执行，避免中间被干扰）
127.0.0.1:6379> MULTI
OK
# 2. 添加事务命令（扣 A 的钱、加 B 的钱，命令入队，返回 QUEUED 表示暂存）
127.0.0.1:6379> DECRBY balance:A 100
QUEUED
127.0.0.1:6379> INCRBY balance:B 100
QUEUED
# 3. 执行事务（所有命令一次性执行，期间 Redis 不处理其他客户端命令，保证原子性）
127.0.0.1:6379> EXEC
1) (integer) 400  # A 的余额：500-100=400（执行成功）
2) (integer) 600  # B 的余额：500+100=600（执行成功）

关键补充：事务的错误处理 —— 运行时错误不回滚（举个具体例子）

Redis 事务的错误分两种，处理逻辑不同，面试时提一句能加分：

• 语法错误（比如命令写错）：比如事务里加了DEC balance:A 100（少了 RBY），EXEC时 Redis 会直接返回错误，所有命令都不执行（A 的钱不会扣，B 的也不会加）；
• 运行时错误（命令语法对，但操作对象错）：比如事务里有SET k1 v1（字符串命令）和HSET k1 f1 v1（对字符串 k1 用哈希命令），EXEC后：

  127.0.0.1:6379> MULTI
  OK
  127.0.0.1:6379> SET k1 v1
  QUEUED
  127.0.0.1:6379> HSET k1 f1 v1
  QUEUED127.0.0.1:6379> EXEC
  1) OK  # SET 成功
  2) (error) WRONGTYPE Operation against a key holding the wrong kind of value  # HSET 失败

这时SET k1 v1会成功，HSET会失败，但 Redis不会回滚 SET 的结果（k1 还是 v1）—— 这是 Redis 事务的核心特点，和 MySQL 事务不同，面试时要说明 “因为 Redis 追求高性能，回滚会增加开销，所以需要业务层自己处理运行时错误”。

为什么选它？

• 优点：保证原子性（执行 EXEC 时，Redis 单线程处理，不会被其他命令插入，避免 “一半成功一半失败”）；支持混合命令；
• 缺点：不支持逻辑判断（比如想先查 A 的余额够不够 100，再决定扣不扣，事务做不到 —— 因为事务里的命令是入队时不执行，无法基于查询结果做判断）；运行时错误不回滚，需业务层处理；
• 适用场景：简单原子操作（无逻辑判断，如转账、增减关联键值 —— 这些场景命令语法简单，不容易出运行时错误，且不需要基于前置结果做判断）。

方案 4：Lua 脚本 —— 复杂原子操作，秒杀 / 分布式锁必用

业务场景：电商秒杀场景，商品库存存在 Redis 字符串键stock:1001（初始库存 100），用户下单时要执行 3 步：① 查库存是否 > 0；② 扣减库存（DECRBY 1）；③ 记录下单用户（SADDseckill:users:1001userId）。这三步必须原子执行，且要先判断 “库存够不够”“用户有没有重复下单”—— 事务做不到（无逻辑判断），Pipeline 不保证原子性（会超卖），只能用 Lua 脚本。

怎么实现？用 Lua 脚本写原子逻辑

-- Lua 脚本功能：秒杀扣库存+记录用户，库存足够、用户未下单才执行
-- 参数说明：KEYS[1]=库存键，KEYS[2]=下单用户集合键；ARGV[2]=用户 ID（ARGV[1]可留空，方便扩展）
local stockKey = KEYS[1]
local userSetKey = KEYS[2]
local userId = ARGV[2]
-- 1. 先判断用户是否已下单（避免重复下单，比如用户点了两次按钮）
local isMember = redis.call('SISMEMBER', userSetKey, userId)
if isMember == 1 then
    return -1  -- 已下单，返回失败标识
end
-- 2. 再判断库存是否足够（避免超卖，库存<=0 时拒绝）
local currentStock = tonumber(redis.call('GET', stockKey) or "0")
if currentStock <= 0 then
    return 0  -- 库存不足，返回失败标识
end
-- 3. 最后扣库存+记录用户（两步原子执行，期间不会被其他命令打断）
redis.call('DECRBY', stockKey, 1)
redis.call('SADD', userSetKey, userId)
return 1  -- 成功，返回成功标识

Java 中调用 Lua 脚本（RedisTemplate，实战代码）

// 1. 定义 Lua 脚本（建议放配置文件，避免硬编码）
String luaScript = "local stockKey = KEYS[1]...return 1 end";  // 替换为上面的完整脚本
// 2. 执行脚本（参数说明：脚本内容、返回值类型、KEYS 列表、ARGV 列表）
Long result = (Long) redisTemplate.execute(
    new DefaultRedisScript<>(luaScript, Long.class),  // 指定脚本和返回值类型
    Arrays.asList("stock:1001", "seckill:users:1001"),  // KEYS：库存键、用户集合键
    "", "user:123"  // ARGV：第 1 个留空（扩展用），第 2 个是用户 ID
);
// 3. 处理结果（根据脚本返回的标识，返回不同业务提示）
if (result == 1) {
    System.out.println("秒杀成功，跳转支付页");
} else if (result == 0) {
    System.out.println("手慢了，库存已空");
} else if (result == -1) {
    System.out.println("您已下单，请勿重复操作");
}

为什么选它？

• 优点：原子性最强（整个脚本视为一个 “超级命令”，Redis 单线程执行，期间不处理其他命令，避免超卖 / 重复下单）；支持逻辑判断（查库存、判重复，事务做不到的它都能做）；减少网络往返（1 次脚本调用完成 3 步，不用发 3 条命令）；
• 缺点：脚本不宜过长（建议不超过 100 行，否则会阻塞 Redis 单线程，影响其他业务 —— 比如脚本里循环 1000 次，会导致 Redis 卡住 1 秒，其他请求超时）；调试相对复杂（需用 Redis-cli 的EVAL命令测试，不能单步调试）；
• 适用场景：复杂原子操作（有逻辑判断，如秒杀、分布式锁、有条件的多命令逻辑 —— 这些场景一旦原子性被破坏，会出现超卖、死锁等线上事故，必须用 Lua 脚本）。

面试官常追问：4 种方案怎么选？（一张表理清，面试直接说）

很多人答完方案就没了，其实面试官最后会问 “怎么选方案”，这才是区分 “背命令” 和 “懂业务” 的关键。用一张表总结核心区别，面试时直接按这个逻辑说：

一句话选型逻辑：先看 “要不要原子性”→不要选 Pipeline / 批量命令（同类型优先批量）；要的话看 “要不要逻辑判断”→要选 Lua 脚本，不要选事务。

面试标准答案模板（直接套用，不出错）

下次再被问 “Redis 怎么执行多条命令？不同场景怎么选？”，直接按这个结构答，结合业务场景，面试官会觉得你有实战经验：

“Redis 执行多条命令主要有 4 种方案，核心是根据业务的‘原子性需求’和‘逻辑判断需求’选择，结合具体场景如下：

1. 批量命令（如 MSET/MGET）：适合同类型命令的批量提效场景，比如电商商品详情页缓存 10 个商品信息，用 MGET 一次获取，1 次网络往返效率最高，且单条命令天然原子，缺点是不支持混合命令。
2. Pipeline（管道）：适合混合命令但无需原子性的场景，比如每日凌晨同步 1000 个用户等级到 Redis，用 Pipeline 批量发 HSET 和 SET 命令，减少网络延迟，缺点是不保证原子性 ——Redis 执行时会逐条处理，中间可能插入其他命令，适合数据同步这类最终结果能对齐的场景。
3. 事务（MULTI/EXEC）：适合简单原子操作（无逻辑判断），比如用户 A 给 B 转账，用事务包裹 DECRBY 和 INCRBY，保证两步同时成功或失败，缺点是不支持逻辑判断（不能查余额够不够再扣），且运行时错误不回滚，需业务层处理。
4. Lua 脚本：适合复杂原子操作（有逻辑判断），比如秒杀场景，用 Lua 脚本一次完成‘查库存→扣库存→记用户’，整个脚本原子执行，避免超卖，缺点是脚本不宜过长，防止阻塞 Redis。

选型时先判断原子性需求：不需要选 Pipeline / 批量命令（同类型优先批量）；需要的话看逻辑判断需求：需要选 Lua 脚本，不需要选事务。”

最后说句实话

Redis 多命令执行不是 “选哪个更高级”，而是 “选哪个更适合业务”—— 比如秒杀选 Lua 脚本不是因为它难，而是因为它能解决 “超卖” 这个致命问题；数据同步选 Pipeline 不是因为它简单，而是因为它能提效且不影响结果。大厂面试考的就是这种 “业务适配能力”，而不是命令记忆。

以上关于Redis 里要执行多条命令有哪些方式？秒杀场景里选哪种？的文章就介绍到这了，更多相关内容请搜索码云笔记以前的文章或继续浏览下面的相关文章，希望大家以后多多支持码云笔记。