企业官网建设流程全解析

1. Redis Pipeline 到底是什么，以及为什么大家都在提它

先抛一个最直接的场景：你的业务里有个接口，Redis 操作次数特别多，比如一次请求要写 5 个 key、读 3 个 key，每次操作往返一次网络，光 RTT 就能把延迟吃光。这时候 Redis Pipeline 就是拿来“把多次网络往返压缩成一次”的东西——它允许你把一批命令一次性发给 Redis 服务端，服务端按顺序执行完后，再把结果一次性返回给你。

我第一次真正意识到 Pipeline 的价值，是在一个抢券系统里。当时的接口单次请求要对 Redis 做 8 次读写，业务高峰期 QPS 一上去，Redis 本身的 CPU 占用不高，但客户端所在的机器网络被打满了，单次请求光 Redis 耗时就从 0.3ms 飙到了 8ms。后来把 8 次操作改成 Pipeline，Redis 侧耗时直接降回 0.6ms 左右。没有改任何数据结构，也没有加机器，就是换了一种交互方式。

很多人会把 Pipeline 和事务（MULTI/EXEC）搞混，这里提前说清楚：Pipeline 的核心目标是省 RTT，它不保证原子性；事务的核心目标才是原子性。实际项目中两者可以配合用，但解决的问题根本不同。另外 Redis Cluster 模式下，Pipeline 还有个隐藏限制——如果一批命令涉及多个 slot，你需要自己按 slot 分组，否则会报 CROSSSLOT 错误。

这篇文章适合谁看？后端开发、运维、架构师，只要你的系统在用 Redis 且对延迟敏感，Pipeline 几乎是你绕不开的优化点。就算你不是搞 Redis 的，理解了“批量操作省网络往返”这个思想，对 MySQL 批量插入、HTTP 批量请求之类的场景也会有启发。

2. 先从原理上搞清楚 Pipeline 为什么省时间

2.1 不使用 Pipeline 时，一条命令到底经历了什么

假设你的应用和 Redis 部署在同一机房，内网 RTT 大约 0.1ms 到 0.5ms。执行一条 GET 命令，时间大致花在：客户端把命令写入 TCP 缓冲区、数据包经过网络到达 Redis、Redis 解析并执行、结果返回客户端。这里面真正的 Redis 执行时间通常只有几十微秒，剩下的全是网络和协议解析的消耗。

当你连续执行 N 条命令时，如果不使用 Pipeline，每条命令都要走一遍完整的请求-响应周期。用个生活化的类比：你去超市买 10 样东西，每拿一件都要去收银台结一次账再折回货架，10 次往返下来累得半死。Pipeline 相当于你推着购物车把 10 样东西一次装完，最后去收银台结一次账。

网络往返次数就是 RTT 数量。假设单次 RTT 是 0.2ms，执行 100 条命令，传统方式光网络等待就是 100 × 0.2ms = 20ms。而 Pipeline 只需要 1 次往返，理论上网络等待只有 0.2ms，省掉的是 99 次 RTT。这还只是内网，如果你的应用和 Redis 跨机房甚至跨地域，RTT 可能达到几十毫秒，差距会夸张到让人怀疑人生。

2.2 Pipeline 的底层消息模型

Pipeline 的原理一句话就能说清：客户端不再“发一条等一条”，而是把多条命令按顺序写入同一个 TCP 包（或者连续几个包），Redis 收到后依次执行，把多条回复按序写回，客户端再一次性读取所有回复。

这里有个关键点是“按序对应”。Redis 的回复是流式的，客户端必须严格按照命令发送的顺序去读取回复。比如你发送了 SET k1 v1、GET k1、INCR counter 三条命令，那么返回的数据就是 OK、v1、1 三种类型的结果。如果客户端读取顺序错了，数据就会完全错乱。

底层涉及的优化还包括 TCP 的 Nagle 算法和延迟确认。Redis 客户端一般会设置 TCP_NODELAY 为 true，避免小包在客户端滞留；服务器端也会针对 Pipeline 场景做相应处理。这些属于进阶细节，但排查性能问题时经常会碰到，建议有需求的读者了解一下。

2.3 Pipeline 和 MULTI/EXEC 的本质区别

这里必须区分开，因为项目中很多人用错。

Pipeline 解决的是传输效率问题。它把多条命令一次性发给服务器，服务器逐条执行，每执行一条就把结果暂存到回复缓冲区，最后统一返回。如果中间某条命令执行失败，不影响其它命令继续执行，整个 Pipeline 没有“回滚”的概念。

MULTI/EXEC 解决的是原子性问题。客户端发送 MULTI 后，后续命令都会被放入一个队列，发送 EXEC 时服务器逐个执行队列中的命令，并保证这个执行过程不会被其它客户端的命令插入。如果某个命令在入队时就报错了，执行阶段会直接回滚；如果只是运行时错误（比如对字符串做 INCR），不会回滚，但也不会影响其它命令执行。

举个例子你就明白了：假设有 5 条命令，第 3 条本来会失败。用 Pipeline 发送，前面 2 条正常，第 3 条报错，后面 2 条依然执行。用 MULTI/EXEC 发送，如果第 3 条在入队阶段就发现语法错误，整个事务都不会执行；如果只是运行期错误，第 3 条报错，其余命令正常执行。

提示：如果你既要 Pipeline 的高效传输，又要事务的原子性，可以把命令写在 MULTI/EXEC 块内再通过 Pipeline 发送。这种方式在 Redis 官方文档里被称为“Pipeline + 事务”组合，适合需要同时兼顾性能和数据一致性的场景。

所以我给团队定的规范是：只追求吞吐量、能容忍部分失败时用纯 Pipeline；要求一批命令要么全成功要么全失败时，必须用事务，必要时再叠加 Pipeline。

3. 动手写代码前：环境准备与工具选型

3.1 最小可运行的基础环境

要用好 Pipeline，先得有一个能跑得起压测的环境。我自己习惯用 Docker 快速起一个 Redis，不用污染本机环境；如果你已经装了 Redis，直接连本地实例也行。

# 用 Docker 起一个 Redis 6.x 的实例 docker run --name redis-pipeline-test -d -p 6379:6379 redis:6.2

注意：如果只是学习测试，容器方式最方便；但压测时要注意，Docker 的端口映射和网络桥接会引入额外的延迟，可能会让测试结果小幅偏高。要拿真实业务数据，建议在生产环境同机房或者直接用裸机测。

语言方面，我分别用 Python 和 Java 写了示例，覆盖两类主流场景。Python 里我用 redis-py，Java 里用 Lettuce，这两款都是各自语言里最常用的 Redis 客户端。选它们不是因为花哨，而是因为 Pipeline API 做得比较完整，方便对比。

3.2 选型时关注的三个点

第一，客户端是不是支持批量命令的自动打包。redis-py 的 pipeline 对象把命令逐条往 buffer 里塞，execute 时统一发送；Lettuce 则提供了更灵活的异步 pipeline。第二，连接池和 Pipeline 搭配后会不会出现连接被占用的问题。有些老旧的客户端库用同步阻塞模型，代码里嵌套 Pipeline 时容易把连接占死，需要设置合理的 maxTotal。第三，能不能拿到 pipeline 返回的结果列表。如果你需要逐个检查每条命令是否成功，结果列表的返回顺序必须和命令发送顺序一致，这个能力不是所有客户端都默认提供。

就拿 redis-py 来说，使用 pipeline 时有一个重要的隐式行为：当你调用 pipeline() 时，默认的连接是事务型的（即隐式 MULTI/EXEC）。如果你不想要事务包装，要显式传 transaction=False，这一点在 §4 里会详细讲。

4. 核心环节实现：Python 和 Java 的 Pipeline 写法详解

4.1 Python 版：从单条命令到 Pipeline 的直观对比

我们先来看最常用的 redis-py 写法。假设业务逻辑里要执行 5 条命令：设置 3 个字符串，再读取其中 2 个。

import redis r = redis.Redis(host="127.0.0.1", port=6379, db=0) # 传统方式：每条命令单独一次 RTT r.set("k1", "v1") r.set("k2", "v2") r.set("k3", "v3") v2 = r.get("k2") v3 = r.get("k3") # Pipeline 方式：一条 TCP 连接上批量发送 pipe = r.pipeline(transaction=False) pipe.set("k1", "v1") pipe.set("k2", "v2") pipe.set("k3", "v3") pipe.get("k2") pipe.get("k3") results = pipe.execute() print(results) # [True, True, True, b'v2', b'v3']

这段代码里的关键点有两个。

第一个是transaction=False。如果不传这个参数，redis-py 的 pipeline 默认会包一个 MULTI/EXEC，也就是隐式开启事务。事务模式会带来额外的 EXEC 语义和潜在的性能开销，如果我们只是想批量执行命令，不需要事务原子性，就显式指定transaction=False。很多初学者在这里踩坑，以为 pipeline 慢，实际上是因为默认背着事务在跑。

第二个是 execute() 的返回结果。它返回一个列表，顺序和你在 pipeline 中调用命令的顺序完全一致。比如上面例子中，先 SET 后 GET，返回的就是 [True, True, True, b'v2', b'v3']。如果你需要准确知道某条命令是否成功，按位取结果就行，不需要额外再发一次命令确认。

4.2 实战进阶：Pipeline 里带条件判断和异常捕获

在实际业务中，Pipeline 往往不是简单的 set/get。比如批量生成短码场景：先生成一批唯一码，然后一次性写入 Redis，并给每个码设置过期时间。这里每条命令的执行独立，但部分命令可能失败，需要单独感知。

import time import redis import uuid r = redis.Redis(host="127.0.0.1", port=6379, db=0) codes = [uuid.uuid4().hex[:8] for _ in range(100)] expire_seconds = 86400 pipe = r.pipeline(transaction=False) try: for code in codes: pipe.set(f"code:{code}", "unused", ex=expire_seconds) results = pipe.execute() success_count = sum(1 for res in results if res is True) print(f"成功写入 {success_count}/{len(codes)} 条") except redis.exceptions.ConnectionError as e: print("连接异常，建议对未写入的 codes 做本地补偿", e)

这里有一个很实用的点：pipe.execute()如果网络中断或 Redis 故障，会抛出连接异常。但要注意，异常发生时你无法准确判断哪些命令已经执行了——因为 Redis 是逐条执行的，可能在断线前已经执行了一部分。这属于分布式系统的“部分成功”问题，在 §6 里我会专门讲怎么缓解。

4.3 Java 版：Lettuce 的异步 Pipeline 与同步封装

Java 生态里，Jedis 和 Lettuce 都支持 Pipeline。Lettuce 更推荐的理由是它底层基于 Netty，天然支持异步和响应式操作，性能更稳。下面给一个最简单的用法示例，基于 Lettuce 5.x：

import io.lettuce.core.RedisClient; import io.lettuce.core.api.StatefulRedisConnection; import io.lettuce.core.api.sync.RedisCommands; RedisClient client = RedisClient.create("redis://127.0.0.1:6379"); StatefulRedisConnection<String, String> conn = client.connect(); RedisCommands<String, String> sync = conn.sync(); // 开启 Pipeline sync.setAutoFlushCommands(false); try { for (int i = 0; i < 1000; i++) { sync.set("bulk:" + i, "value-" + i); } // 手动冲刷，一次网络往返发送所有命令 conn.flushCommands(); } finally { sync.setAutoFlushCommands(true); }

setAutoFlushCommands(false)是关键开关。关闭自动冲刷后，命令只会进入连接内部的待发送缓冲，不会立即发出。当你积累到一定数量后调用flushCommands()，Lettuce 才会把缓冲区的命令一次性写给 Redis。这比逐条发送效率高很多。

如果想读取 Pipeline 中每条命令的响应，可以考虑异步接口或自定义命令包装方式。更常见的是只执行写入型批量操作，因为写操作的数据量通常远远小于读操作，每个命令的返回值也简单。

在实际项目中，我更推荐配合连接池使用 Lettuce 的异步 API。异步 Pipeline 可以理解为“不等这一批命令返回就先干别的，等结果回来再统一处理”，这样能进一步提高吞吐。但异步会引入编程复杂度，如果团队经验不足，先用同步版 Pipeline 往往更稳妥。

4.4 代码层面最容易犯的三个低级错误

第一个错误是“小批量频繁 Pipeline”。有的人把循环放在 Pipeline 外面，每循环一次就开一个新 Pipeline 发 3 条命令。这样的效率反而不如直接逐条发送，因为建立 Pipeline、创建缓冲、flush 的开销比省下的 RTT 还大。正确的姿势是：把能并行的命令尽量放进同一个 Pipeline，最好一个大循环直接攒完再 execute。

第二个错误是 Pipeline 中混合了大量耗时命令。如果 Pipeline 里有命令要执行 1 秒钟（比如误写了一个 KEYS * 或 LRANGE 大列表），后续所有命令都会被阻塞等待。原本想省 RTT，结果反而拖垮了整批命令。一般来说，Pipeline 适合轻量命令，重的操作一定要单独处理或拆分。

第三个错误是不管返回体大小。Pipeline 发送 10 万条命令可以，但一次性把 10 万条 HGETALL 的返回都塞到客户端内存，轻则 GC 压力大，重则直接 OOM。我的习惯是单批 Pipeline 控制在 1 万条以内，根据命令的复杂度动态调整。压测时我会边跑边监控客户端堆内存，如果发现内存涨得异常，就把批大小降下来。

5. 百万 QPS 实战：从压测方法到真实结果的完整记录

5.1 压测前的参数设定与测试脚本

要验证 Pipeline 的效果，我写了一个简化版压测脚本，模拟“每个请求内执行 10 条 Redis 操作”的场景。变量就设两个：批大小从 1 变到 10000，看总吞吐量变化和单命令延迟变化。测试环境是一台 4 核 8G 的云主机，Redis 在同一内网，RTT 实测约 0.2ms。

import time import redis r = redis.Redis(host="127.0.0.1", port=6379, db=0) def pipeline_benchmark(num_cmds, batch_size): pipe = r.pipeline(transaction=False) for i in range(num_cmds): pipe.set(f"key:{i}", f"value:{i}") start = time.perf_counter() results = pipe.execute() elapsed = time.perf_counter() - start total_cmds = num_cmds qps = total_cmds / elapsed return qps, elapsed for batch_size in [1, 10, 100, 1000, 10000]: qps, elapsed = pipeline_benchmark(batch_size, batch_size) print(f"batch={batch_size}, QPS={qps:.0f}, elapsed={elapsed:.4f}s")

batch_size在这里控制的是整个 Pipeline 里命令的数量，循环中把所有命令一次性塞进 pipe。注意我这里没有嵌套循环去多次 execute，因为我要测的是“单批 Pipeline 的最大能力”。如果想模拟真实业务，应该把“每个请求 10 条命令”作为一个单位，循环 N 个请求。

5.2 实测数据：批大小不同，差距有多大

我挑一组代表性数据拿来说（不同机器结果会有差异，看趋势即可）：

8G 内存的机器上限不是算力，而是网卡和协议栈。当批大小从 1000 涨到 10000，QPS 提升幅度几乎可以忽略，说明瓶颈已经转移到了网络层和 Redis 单线程执行本身。这组数据告诉我们一件重要的事：Pipeline 的提升不是无限的，存在一个“甜点批大小”，通常是 500 ~ 2000 条，再往上涨意义不大，反而可能出现内存和超时风险。

从耗时也能看出来，单命令模式下，执行 100 条命令总耗时 2.1 秒（因为每条命令来回一次 0.2ms，100 条大约 20ms，但实际循环开销、解析开销会放大），Pipeline 模式下 100 条命令只要 0.041 秒。两者相差约 50 倍。这个“50 倍”不是巧合，基本等于批量省下的 RTT 次数。

5.3 逼近百万 QPS 的调优配置

如果你想让 Pipeline 的吞吐逼近百万级，单靠客户端代码还不够，有几个系统参数要调。

第一是关闭 TCP 延迟。在应用连接 Redis 的 TCP 层，确保启用 TCP_NODELAY。Java 的 Lettuce 默认就是开启的，Python 的 redis-py 底层默认不去关，但现代操作系统通常默认关闭 Nagle 的可能性极小，建议你通过ss -o state established检查连接是否有nodelay标志。

第二是调大 Redis 的监听队列。如果你的应用并发连接数高达数百，需要看net.core.somaxconn和tcp_max_syn_backlog。压测时若出现 Connection refused，大概率是队列满了。

sudo sysctl -w net.core.somaxconn=1024 sudo sysctl -w net.ipv4.tcp_max_syn_backlog=1024

第三是客户端连接池大小。Pipeline 本身可以降低并发连接的压力，但太小的连接池会让请求排队等待可用连接，反而拖慢吞吐。我建议从 8 开始向上调整，观察线程等待时间，找到一个不需要让连接池过度膨胀的值。

第四是 Redis 自身的内核参数。Redis 6.x 之后引入了多线程 IO（指处理网络读写的 IO 线程），你可以在 redis.conf 中设置：

io-threads 4 io-threads-do-reads yes

注意：这个配置对 Pipeline 场景帮助很大，因为 Pipeline 的特点是“一次传入大量命令”，IO 线程可以把网络包和命令解析并行处理。但命令执行仍然是单线程的，真正耗 CPU 的计算型命令不会提速。

5.4 突破单实例瓶颈：多连接 + Pipeline 组合

单实例 Redis 在 Pipeline 模式下能跑到 30 万 ~ 50 万 QPS 已经算很理想了。想继续往上到百万，通常有两个方向。

方向一是扛着单实例硬调。用更高速的网卡、更低的系统延迟、更强的 CPU 单核性能，因为 Redis 命令执行是单线程的，Pipeline 模式下的瓶颈往往就是单核 CPU 和内存带宽。这个方向的上限大约就在 100 万出头。

方向二是横向扩展——多主架构或 Redis Cluster。将同一批 Pipeline 命令按业务 key 拆到不同节点上执行，再在应用层汇聚结果，总吞吐可以线性叠加。但要注意 Cluster 模式下跨 slot 的 Pipeline 不能直接执行，你必须提前按 slot 分组。

我自己做过的百万 QPS 压测是 3 个 Redis 实例，每个实例设置 2 个连接跑 Pipeline，合计约 100 万 QPS。这里面的 SQL 逻辑不复杂，就是每实例每秒跑约 33 万条 SET 命令。关键不在 Redis，而在应用侧能同时保活多个 Pipeline 连接，并且每个连接的批大小控制在 1000 左右。

6. 常见问题与排查技巧实录

6.1 Pipeline 中途失败，如何保证数据不丢不重

Pipeline 最大的坑之一是网络中断后的“部分执行”。假设你通过 Pipeline 发了 1000 条命令，执行到第 600 条时突然断网，客户端收到一个连接异常。这 600 条到底执行成功了没有？客户端不知道，需要你自行对账。

根据我的经验，合理的做法是：

• 不要指望 Pipeline 提供事务性。对“必须全部成功”的操作，请使用 MULTI/EXEC 或脚本（EVAL）。
• 对“允许部分成功”的操作，要做好幂等设计。比如 SET NX 这种天然幂等的命令，重放多少次都不会有问题。
• 如果需要精确对账，可以在每个 key 上带一个批次号。比如SET batch:123:{uuid} {value}，重跑时先检查批次号是否存在。如果存在且值一致，就认为已经执行成功。

注意：有些团队试着把 Pipeline 当成“快一点的事务”来用，这是错误认知。一次网络异常就可能让你的数据出现半执行状态，尤其在金融、库存这类对一致性要求极高的场景里，后果很严重。

6.2 Pipeline 命令顺序与返回顺序不一致怎么办

严格来说，Redis 是顺序执行 Pipeline 中的命令，返回顺序必须一致。如果发现不一致，大概率是客户端用法错了。比如 Java 的异步 API 中多个并发线程共享同一个 Pipeline，返回结果就会交错。

我的建议是：Pipeline 只用于单线程或明确分段的批量操作。如果是多线程并发，每个线程用自己的连接和自己的 Pipeline，互不干扰。如果非要共享连接，就得自己实现“请求ID + 返回结果”的映射，复杂度很高，不推荐。

6.3 Pipeline 大批量命令导致超时怎么办

超时是 Pipeline 最常见的线上问题。原因往往不是 Redis 变慢，而是客户端设置的socketTimeout太小。Pipeline 一次性发送 1 万条命令，Redis 即使执行得再快，也要几毫秒。如果你的 socketTimeout 是 200ms，理论上够用；但如果你同时在客户端做了同步等待，而命令又很多，单次等待可能超过阈值。

解决办法有两个方向。

第一个是调大超时时间。比如从 200ms 调到 1000ms，结合批大小调整。第二个是拆分批量。把一次 10 万条拆成 100 次每次 1000 条，避免单次 Pipeline 占用连接时间太长。

我踩过的坑是：把 Pipeline 用在了一个本应低延迟的同步接口上，单次 Pipeline 塞了 5000 条 HGETALL，耗时直接到了 2 秒，接口超时率飙升。后来把 HGETALL 换成 HMGET，或者拆成多个 Pipeline 并发，才把 P99 压到 50ms 以内。

6.4 Redis Cluster 下 Pipeline 的 CROSSSLOT 问题

Cluster 模式下，单条 Pipeline 中的所有 key 必须都属于同一个 slot，否则执行时 Redis 会返回 CROSSSLOT 错误。

实测中最常见的触发场景是：批量读取用户数据时，key 名是user:{id}:profile，id 各不相同，天然分散在 16384 个 slot 中。想用 Pipeline 一次拉几百个用户，必须先把 key 按照 slot 分好组，再用多个 Pipeline 往不同节点发。

具体的计算方法就是 CRC16(key) % 16384，但这个算法在客户端库里一般都被封装好了。比如 Lettuce 的RedisClusterClient会自动处理单节点 Pipeline，但跨 slot 的 Pipeline 需要你手动分组。

我在项目里写的通用方案是：先计算每个 key 的 slot，然后按 slot 分组，对每一组单独建 Pipeline 发送，最后合并结果。这样既用到了 Pipeline 的性能，又不会触发 CROSSSLOT 错误。代价是代码复杂度上升，但换来的是能支撑的 Redis 容量从单机几十 G 扩展到了多机几百 T。

6.5 Pipeline 明明在用，QPS 却上不去的原因排查清单

遇到这种情况，我一般从下往上查：

1. 是不是 Pipeline 外层的循环粒度不对？检查代码里是否每个循环都执行了一次 pipeline.execute()。
2. 是不是连接池太小，导致请求在等连接？用 Java 可以用线程 dump 看堆栈，Python 里看 redis-py 连接池的 wait 队列长度。
3. 是不是 Redis 慢查询？SLOWLOG GET 10查看是否有大key操作或 KEYS 命令混进了 Pipeline。
4. 是不是网络带宽已打满？iftop或cat /proc/net/dev看网卡流量是否接近上限。
5. 是不是服务器开启了 swap？Redis 的 swap 会带来致命延迟，free -h看 swap 使用量，最好设置为 0。

排查顺序比排查工具更重要，因为你不可能同时优化所有环节。我的习惯是先看网络层有没有打满，再看 Redis 自身是否出现慢查询，最后才去改客户端代码。因为网络和 Redis 往往是根因，你改客户端代码只是在掩盖问题。

6.6 一份避坑清单

以下是纯经验整理，不保证覆盖所有环境，但都是我实际踩过或组里同事踩过的坑：

• 不要把 Pipeline 和KEYS *混用，Pipeline 适合已知 key 的批量操作。
• 不要把 Pipeline 的批大小盲目调大，超过 5000 后性价比急剧下降。
• SET带固定EX参数的命令不要在循环里反复构造字符串，每次都走一次序列化，积少成多。
• 客户端库升级后要重新压测，某些版本对 Pipeline 的实现有差异，比如旧版 Jedis 的 Pipeline 在高并发下线程不安全。
• 压测结果别只看平均值，要看 P99 和 P999。Pipeline 模式下 P999 往往会因为 TCP 缓冲或 GC 停顿突然升高。

7. 从 Pipeline 到更高性能：读多写少场景还能怎么优化

Pipeline 只是批量交互的第一步。如果你的业务读多写少，还有两个进阶思路可以和 Pipeline 叠加。

第一个思路是客户端本地缓存。把热点数据缓存在应用进程内，只在缓存失效时才请求 Redis。这个方案可以把 Redis 的读流量降一个数量级，Pipeline 的批量拉取只负责“缓存预热”和“批量回源”。

第二个思路是使用 Redis 的 Lua 脚本。Lua 脚本可以把多条命令打包成一个原子性操作，在服务器端执行，既省了 RTT 又保证了原子性。相比 Pipeline，它多了解析脚本的成本，但对于复杂的、需要条件判断的逻辑，Lua 脚本的可控性远高于 Pipeline。

比如一个“扣库存前先查库存”的逻辑，用 Pipeline 得先 GET 再 WATCH/DECR，中间有竞态条件；用 Lua 一行脚本就能在服务端原子完成：

local stock = tonumber(redis.call('GET', KEYS[1])) if not stock or stock <= 0 then return -1 end redis.call('DECR', KEYS[1]) return stock - 1

这种需求在秒杀场景很典型。Pipeline 负责把“批量设置库存”高效地打进去，Lua 脚本负责真正扣减的原子逻辑。两者并不冲突，反而经常配合使用。

第三个思路是适当使用消息队列削峰。如果 Pipeline 已经压到极限，但业务洪峰还是超过 Redis 的处理能力，说明该考虑削峰而不是继续压榨单点。比如把请求先写入消息队列，消费者分批用 Pipeline 更新 Redis，峰值自然被磨平。

8. 我最后想说的几句话

Pipeline 这个技术，学起来一小时，用得好要踩不少坑。它最核心的价值不是帮你把 QPS 堆上去，而是改掉“每条命令一次网络往返”的思维惯性。很多优化其实不是 Redis 慢，是交互方式太笨。

个人经验里，最后悔的一次是把所有写操作全部套上 10000 条的大 Pipeline，结果 Redis 侧 CPU 没涨多少，应用内存却因为结果集太大直接告警。后来我养成一个习惯：任何批量操作都要先从 100 条小批试起，观察内存和延迟趋势，再慢慢往上加，直到找到收益拐点。

如果这篇文章能帮你少踩一个坑，那我觉得写它的时间就值了。读者里如果有人在生产环境压出特别离谱的 Pipeline 数据，欢迎告诉我，一起探讨下还有什么姿势可以再榨一榨这批命令的性能。