## 01、痛点

上周三凌晨，订单服务突然开始超卖：一款库存 100 的爆款商品，最终卖出 130 件。我是老李，被拉进排查群时，第一反应是看库存扣减代码。开发小哥写的逻辑很“朴素”：先 GET 库存，判断是否大于 0，再 DECR 扣减，最后 SET 一条订单标记。他坚持认为 Redis 每条命令都是原子的，所以这个流程不会出问题。

问题恰恰出在这里。单条 Redis 命令确实具备原子性：GET 要么读到旧值，要么读到新值；DECR 的递减本身也不会被打断。可是，“先读库存、再判断、再扣减、再写标记”是一个由多条命令组成的业务动作。两个请求同时执行时，可能都读到库存 1，都通过判断，然后各自 DECR，最终库存变成 -1，订单却写成功两个，超卖发生。

这类错误在并发场景里很常见，本质是把“单命令原子性”误当成了“业务动作原子性”。在多命令之间，其他客户端的命令可以插进来，网络往返、服务端调度都会影响最终结果。单机 Redis 的单线程执行模型能使每条命令串行执行，但没法自动把多条命令拼接成一个不可分割的整体。

痛点是：库存扣减这类典型读改写操作，不能只靠单命令原子性；否则要么超卖，要么要靠复杂的分布式锁和补偿逻辑来兜底，成本高、易错、客户端代码复杂。

## 02、是什么

要解决多条命令的组合问题，需要先分清三件完全不同的事：Pipeline、Transaction 和 Lua Script。它们常被混为一谈，但目标和边界并不相同。

Pipeline 解决的是网络往返时间（RTT）问题。客户端在普通模式下，每次发送一条命令都要等待响应，N 条命令就有 N 次网络来回。Pipeline 允许客户端把多条命令打包后一次性发送给服务端，服务端按顺序执行并一次性返回结果，从而把 N 次 RTT 降为 1 次。注意，它不提供原子性，服务端仍然是逐条执行，命令之间可以插入其他客户端的命令；前面命令失败也不影响后续命令继续执行。

Transaction 提供命令批量执行语义。客户端用 MULTI 开启事务，后续命令进入队列，直到 EXEC 时才由服务端按入队顺序连续执行。在 EXEC 执行期间，Redis 单线程会集中处理队列中的命令，不会被其他客户端命令打断。但事务有个关键限制：EXEC 之前拿不到中间执行结果，因此不能在事务中根据前一条命令的返回值决定后续命令。它适合“命令集合已经确定”的批量写入，不适合“读改写且需要判断”的场景。事务还支持 WATCH 做乐观锁，但那属于配合机制，不是事务本身的能力。

Lua Script 用于服务端原子业务逻辑。通过 EVAL 或 EVALSHA 把一段 Lua 脚本传给 Redis，脚本在服务端执行。脚本执行期间，Redis 不会处理其他命令，因此脚本内部的读取、判断、写入天然是原子的。Lua 可以读取数据、做条件分支、循环、写入，这正好补上了事务不会做判断的短板。

Spring Data Redis 对这三者都有原生支持：executePipelined() 对应 Pipeline；SessionCallback 常用于在同一个连接中执行事务；RedisScript 则用于加载和执行 Lua 脚本。三件事都跟“多条命令”有关，但解决的问题完全不同。

## 03、为什么

为什么现在必须把这三件事讲清楚？因为 Redis 在业务侧的用法已经从“简单缓存”进入“轻量一致性与高性能读改写”的阶段，尤其是库存、限流、秒杀、计数器等场景。Spring Boot 项目接入 Redis 非常方便，反而让很多人忽略底层语义：有的用 executePipelined 批量发命令，就以为有了原子性；有的用 MULTI/EXEC 包裹库存判断，却发现条件分支根本没法写；还有的把 Lua 当成纯性能优化，不理解它其实是业务原子逻辑的载体。

以库存扣减为例，如果不理解这三者的边界，开发者很可能写出文章开头的错误代码；或者知道要用原子操作，却选错工具：用 Pipeline 减少 RTT，结果还是超卖；用事务想判断库存，结果发现 EXEC 前无法做分支。更麻烦的是，这类并发问题往往要在流量上来之后才暴露，排查困难，线上影响大。

从架构角度看，Spring Boot 服务通常通过 Lettuce 或 Jedis 连接 Redis。不同的连接模式和 API 封装会进一步影响开发者对原子性的感知。executePipelined() 内部可能复用连接、异步发送；SessionCallback 则在模板管理的连接上执行回调；RedisScript 直接调用 EVAL/EVALSHA。只有理解了“服务端到底发生了什么”，才能选对 API，避免把客户端行为和服务端语义混为一谈。

现在很多团队在微服务里做库存扣减时，会引入分布式锁、消息队列、数据库事务等重型方案，其实如果 Redis 承载库存数据，一段 Lua 脚本往往就能解决核心的原子读改写问题。前提是要清楚 Lua 能做什么、Pipeline 和事务不能做什么。

## 04、架构

从调用链路看，三种模式在客户端和服务端之间的数据流不同。

普通模式下，客户端每次发送一条命令，等待一条响应。比如库存判断要发 GET，扣减要发 DECR，写标记要发 SET，总共有 3 次网络往返。如果业务高峰有大量请求，网络 RTT 会成为瓶颈。

Pipeline 模式下，客户端把 GET、DECR、SET 打包成一个批次，通过一次写入发送给服务端，服务端逐条执行并返回一个数组响应。服务器执行顺序不变，但执行期间仍可能插入其他客户端命令，因为 Redis 是单线程事件循环，命令与命令之间会回到事件循环处理其他请求。Pipeline 主要优化客户端到服务端的往返次数，对原子性没有帮助。

Transaction 模式下，客户端先发送 MULTI，随后发送的命令进入事务队列，此时服务端只返回“QUEUED”，不会真正执行。客户端发送 EXEC 后，服务端开始执行队列中的命令。执行这个队列期间，Redis 事件循环不会处理其他客户端的命令，因此命令间不会被其他请求插入。但要注意：因为命令是在 EXEC 之前就确定好的，服务端不可能在事务中根据前面命令的返回值决定后续命令。

Lua 模式下，客户端把脚本内容或 SHA1 摘要通过 EVAL/EVALSHA 发送到服务端。Redis 会加载脚本并执行，脚本的整个生命周期内，服务端不会处理其他命令。脚本中的 redis.call 或 redis.pcall 可以读取和写入，相当于把多个 Redis 命令和一个小的判断逻辑放进了服务端。对于库存扣减，脚本可以先 GET 库存，判断是否足够，再 DECRBY 扣减，最后 SET 订单标记，整个过程不会被其他请求穿插。

在 Spring Boot 架构中，RedisTemplate 是高层的模板。executePipelined() 会借助连接批量发送；SessionCallback 能拿到同一个连接，适合把 MULTI/EXEC 放在一起；RedisScript 通常定义为 Bean，执行时内部调用 scriptExecutor 使用 EVALSHA，脚本第一次执行会先加载缓存，后续用 SHA1 调用，减少网络传输。

理解这些数据流，比记住 API 名称更重要，因为出现线上问题时，最终要回答的是“在 Redis 服务端，这几个命令之间发生了什么”。

## 05、实战

下面用库存扣减作为实战场景，展示一段 Lua 原子逻辑。需求是：判断库存是否充足，充足则扣减，并写一条订单标记；不充足则返回失败。整个过程必须原子，不能超卖，也不能重复扣减。

先定义一个 Lua 脚本，文件可以放在 resources/lua/stock_deduct.lua：

```lua
-- KEYS[1]: 库存 key
-- KEYS[2]: 订单标记 key
-- ARGV[1]: 扣减数量
-- ARGV[2]: 订单标记 value
local stock = tonumber(redis.call('GET', KEYS[1]))
if not stock then
    return -1
end
if stock < tonumber(ARGV[1]) then
    return 0
end
redis.call('DECRBY', KEYS[1], ARGV[1])
redis.call('SET', KEYS[2], ARGV[2], 'NX', 'EX', 3600)
return 1
```

脚本逻辑非常直白：读取库存，判断是否足够，足够才扣减并写订单标记。因为脚本在 Redis 服务端执行，整个“读—判断—写”过程不会被其他客户端命令打断，解决了超卖问题。

在 Spring Boot 中，把这个脚本注册为 Bean：

```java
@Configuration
public class RedisScriptConfig {

    @Bean
    public RedisScript<Long> stockDeductScript() {
        DefaultRedisScript<Long> script = new DefaultRedisScript<>();
        script.setLocation(new ClassPathResource("lua/stock_deduct.lua"));
        script.setResultType(Long.class);
        return script;
    }
}
```

然后在 Service 中调用：

```java
@Service
public class StockService {

    private final RedisTemplate<String, String> redisTemplate;
    private final RedisScript<Long> stockDeductScript;

    public StockService(RedisTemplate<String, String> redisTemplate,
                        RedisScript<Long> stockDeductScript) {
        this.redisTemplate = redisTemplate;
        this.stockDeductScript = stockDeductScript;
    }

    public Long deduct(String stockKey, String orderFlagKey, int amount, String orderId) {
        return redisTemplate.execute(
                stockDeductScript,
                List.of(stockKey, orderFlagKey),
                String.valueOf(amount),
                orderId
        );
    }
}
```

调用 deduct 方法时，RedisTemplate 会执行 EVALSHA，如果服务端还没有脚本缓存，则会回退到 EVAL。返回值 1 表示成功，0 表示库存不足，-1 表示库存 key 不存在。

为了对比，再看一下 Pipeline 和事务的用法边界。如果仅用 Pipeline 发三条命令：

```java
List<Object> results = redisTemplate.executePipelined((RedisCallback<Object>) connection -> {
    byte[] stockKey = rawKey("stock:1001");
    byte[] flagKey = rawKey("order:flag:1001");
    connection.get(stockKey);
    connection.decrBy(stockKey, 1);
    connection.set(flagKey, rawString("order:xx"));
    return null;
});
```

这段代码能减少网络往返，但 GET 和 DECR 之间仍然可能被其他请求插入，超卖风险没有消除。Pipeline 不适合需要判断的读改写。

再看事务。用 SessionCallback 包裹 MULTI/EXEC：

```java
List<Object> results = redisTemplate.execute(new SessionCallback<List<Object>>() {
    @Override
    public List<Object> execute(RedisOperations operations) {
        operations.multi();
        operations.opsForValue().get("stock:1001");
        operations.opsForValue().decrement("stock:1001");
        operations.opsForValue().set("order:flag:1001", "order:xx");
        return operations.exec();
    }
});
```

这个事务确实会在 EXEC 期间按顺序执行三条命令，但在事务中 GET 的返回值是不可见的，无法判断库存是否足够；要么把判断放在事务外，那又失去了原子性；要么配合 WATCH 做乐观锁，但代码复杂且要处理重试。这就是为什么事务不能完全代替 Lua。

## 06、洞见

测验里有两个问题，答案可以更进一步说明三个工具的边界。

Pipeline 为什么不能代替事务？因为 Pipeline 只是改变了客户端发送命令的方式，把多次网络往返合并成一次。服务端仍然是“接收一条、执行一条、再接收下一条”，命令之间保持独立。其他客户端的命令可以穿插进来，前一条命令失败也不影响后续。它不提供“这几个命令是一组，执行期间别人别插进来”的语义，所以不能代替事务。

事务为什么又不能完全代替 Lua？事务能保证队列中的命令在 EXEC 执行期间不被打断，但命令集合在 EXEC 前已经确定，并且 EXEC 前无法获取中间结果。业务上最常见的“库存是否足够”需要先读、再判断、再决定是否扣减，这个判断没法放在事务内部。用 WATCH 可以实现类似 CAS 的效果，但需要客户端循环重试，并且 WATCH 的粒度、失败窗口都增加复杂度。Lua 则把判断逻辑放进 Redis 服务端，脚本执行期间不处理其他命令，既解决原子性，又解决条件分支，因此更适合库存扣减这类场景。

更深一层看，选择原则可以归纳为：只需要减少网络往返，不要求原子性，用 Pipeline；需要批量执行且不依赖中间结果，用事务；需要读改写、条件判断、循环等原子业务逻辑，用 Lua。三个工具并不是互斥的，Lua 脚本内部也可以使用 redis.call 执行多条命令，但脚本本身才是原子单位。实际工程中，Lua 脚本一旦启动就不应长时间执行，否则会阻塞整个 Redis 实例，影响所有请求。事务和 Lua 都会阻塞命令处理，所以要注意脚本的复杂度、数据量和超时设置。

另一个常见误区是认为 Lua 一定比事务“高级”或“性能更好”，其实性能提升来自正确的原子语义和减少网络往返，而不是 Lua 本身。如果业务逻辑只是批量写入且无需判断，事务可能更直接；如果只是想提高吞吐，Pipeline 足够。关键是别再拿 Pipeline 当原子方案，也别拿事务做它做不了的条件分支。

## 07、行动

回到团队里，建议做几件事。

第一，把“单命令原子性”和“业务动作原子性”分开。让每个开发者明白：Redis 的一条命令是原子的，但业务动作通常由多条命令组成，需要显式选择 Pipeline、事务或 Lua。

第二，梳理项目中所有涉及 Redis 的多命令流程。重点找出“先读后写”的库存、余额、计数、限流等场景，确认是否存在并发窗口。若存在，优先评估用 Lua 脚本实现原子读改写。

第三，在 Spring Boot 项目中规范 Redis 用法。可以沉淀一个 RedisScript 配置类，把常用脚本集中管理；库存扣减脚本要包含充分的返回值约定，比如 1 成功、0 库存不足、-1 key 不存在，方便调用方处理。执行 Lua 时优先使用 EVALSHA，利用脚本缓存减少网络传输。

第四，避免把 Lua 当万能药。脚本要短小、快速、只操作必要的 key，禁止在脚本中执行阻塞操作或遍历大量数据。可以通过压测观察慢查询，必要时限制脚本参数数量和执行时间。Redis 单线程模型意味着 Lua 执行期间所有请求都会排队，脚本一旦变慢，影响面极大。

第五，对 Pipeline 和事务的使用补充团队规范。Pipeline 只用于批量查询或批量写入且不需要中间结果，可以显著降低 RTT；事务用于需要连续执行一组命令且不依赖中间返回值的情形；不要用 Pipeline 实现原子性，也不要试图在事务内部做复杂条件判断。

最后，通过一次小范围技术分享或代码评审，把这次超卖案例和三个工具的边界讲清楚。让团队以后看到这类代码时，能条件反射式地问一句：这是一个原子的业务动作吗？如果是，应该用什么工具保证原子性？

## 08、小结

这次从一次库存超卖说起，核心结论是：单条 Redis 命令的原子性，不等于多条命令组成的业务动作的原子性。Pipeline、事务和 Lua Script 是三件完全不同的事：Pipeline 解决网络 RTT，事务解决命令批量执行的原子性，Lua 解决需要判断逻辑的服务端原子业务。

在 Spring Boot 中，三者都有对应支持：executePipelined()、SessionCallback 和 RedisScript。理解服务端数据流之后，选型思路会更清晰：只优化网络用 Pipeline，批量执行不需要中间结果用事务，读改写加判断用 Lua。实战中的库存扣减就是典型场景，一段 Lua 脚本把库存判断、扣减和订单标记写入变成了原子动作。

记住两个常见问题的答案：Pipeline 不能代替事务，因为它根本没有原子性；事务不能完全代替 Lua，因为它无法在事务内部基于读取结果做分支。工具各有边界，守住边界，才能在高并发下不翻车。

## 09、链接与概念说明

以下概念在理解 Redis 多命令原子性时经常出现，做简要说明。

- Pipeline：客户端将多条命令打包发送，减少网络往返次数，不提供原子性，命令之间可插入其他请求。
- MULTI/EXEC：Redis 事务的基础命令，MULTI 开启事务，命令入队，EXEC 执行队列。执行期间不会被其他客户端命令打断，但命令集合在 EXEC 前确定，且无法基于前面命令结果做分支。
- WATCH：乐观锁机制，可监视一个或多个 key，在 EXEC 前如果被监视 key 发生变化，事务将被放弃。常与事务配合实现 CAS 式逻辑，但需要客户端处理重试。
- EVAL/EVALSHA：执行 Lua 脚本的命令。EVAL 直接发送脚本内容，EVALSHA 发送脚本 SHA1 摘要，服务端缓存脚本，减少传输。
- 单线程执行模型：Redis 服务端在命令执行层面是单线程事件循环，单条命令是原子的；但多个命令之间会回到事件循环处理其他请求。
- SessionCallback：Spring Data Redis 提供的回调接口，允许在同一连接内执行多个操作，常用于事务和需要连接隔离的场景。
- RedisScript：Spring Data Redis 中表示 Lua 脚本的接口，DefaultRedisScript 可设置脚本资源、结果类型等。

推荐阅读官方文档：Redis 官方文档中关于 Transactions、Pipelining 和 Scripting 的章节，以及 Spring Data Redis Reference 中关于 RedisTemplate、SessionCallback、Scripting 的部分。这些资料能帮助进一步理解命令执行的底层语义。

上周三凌晨，订单服务突然开始超卖：一款库存 100 的爆款商品，最终卖出 130 件。我是老李，被拉进排查群时，第一反应是看库存扣减代码。开发小哥写的逻辑很“朴素”：先 GET 库存，判断是否大于 0，再 DECR 扣减，最后 SET 一条订单标记。他坚持认为 Redis 每条命令都是原子的，所以这个流程不会出问题。

《Redis 8.10 + Spring Boot 实战》第8招 原子性、Pipeline、事务与 Lua——从一次命令升级到一组可靠操作

单条 Redis 命令原子性不够。结合库存扣减实战，说清 Pipeline、事务与 Lua 的边界、原理和 Spring Boot 用法。

架构师

数据库

后端

开发工具

Redis多命令操作中，单命令原子性不等于业务动作原子性，Pipeline只解决网络RTT、事务无法做条件判断、Lua脚本才是原子读改写的正解。本文从库存超卖事故出发，对比三种工具的边界，并给出SpringBoot中RedisScript实战代码，助你避开并发陷阱。

消息队列

往返时间

代码解释

服务器

数据流

Redis

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

《Redis 8.10 + Spring Boot 实战》第8招 原子性、Pipeline、事务与 Lua——从一次命令升级到一组可靠操作-腾讯云开发者社区-腾讯云

《Redis 8.10 + Spring Boot 实战》第8招原子性、Pipeline、事务与 Lua——从一次命令升级到一组可靠操作

《Redis 8.10 + Spring Boot 实战》第8招原子性、Pipeline、事务与 Lua——从一次命令升级到一组可靠操作

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《Redis 8.10 + Spring Boot 实战》第8招 原子性、Pipeline、事务与 Lua——从一次命令升级到一组可靠操作

《Redis 8.10 + Spring Boot 实战》第8招 原子性、Pipeline、事务与 Lua——从一次命令升级到一组可靠操作

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《Redis 8.10 + Spring Boot 实战》第8招原子性、Pipeline、事务与 Lua——从一次命令升级到一组可靠操作

《Redis 8.10 + Spring Boot 实战》第8招原子性、Pipeline、事务与 Lua——从一次命令升级到一组可靠操作