Lettuce管道中flushCommands()仅发送命令不返回结果，正确做法是先保留各操作返回的RedisFuture，再调用get()或thenApply()获取响应。
flushCommands 不是异步刷新管道的正确方式，它只是触发命令批量发送，但本身不返回结果、也不处理响应。真正在用 Lettuce 做管道（pipeline）时，容易把「发送」和「获取结果」两个动作混为一谈。
RedisPipeline.flushCommands() 为什么不能直接拿结果
flushCommands() 返回的是 CompletableFuture<Void>，只表示“命令已发出去”，不代表响应已收到或解析完成。它不等服务端返回，也不做任何结果映射——这跟 Jedis 的 sync() 完全不同。
- 常见错误现象：调用
flushCommands().thenAccept(...)却发现闭包里拿不到任何命令返回值 - 根本原因：Lettuce 的
RedisPipeline是基于RedisReactiveCommands构建的，所有命令结果必须通过CommandOutput显式收集 - 正确路径是：先调用各 set/get/hmset 等方法 → 它们各自返回
RedisFuture→ 再统一flushCommands()→ 最后await()或get()拿每个 future 的值
怎样用 RedisPipeline 正确批量写入并取结果
管道本质是攒一批命令一起发，但每个命令仍需独立等待响应。Lettuce 要求你保留每个操作返回的 RedisFuture 实例，再集中处理。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 必须用
RedisAsyncCommands或RedisReactiveCommands获取 pipeline，不能从sync()接口出发 -
pipeline.set("k1", "v1")返回RedisFuture<String>，不是 void；同理pipeline.hset("h", "f", "v")返回RedisFuture<Long> - 调用
flushCommands()后，要对每个 future 显式调用get()（阻塞）或thenApply()（非阻塞）才能拿到结果 - 示例片段：
RedisAsyncCommands<String, String> async = connection.async();
RedisPipeline pipeline = async.getStatefulConnection().getPipeline();
RedisFuture<String> f1 = pipeline.set("key1", "val1");
RedisFuture<Long> f2 = pipeline.hset("hash", "field", "value");
RedisFuture<Long> f3 = pipeline.lpush("list", "a", "b");
pipeline.flushCommands(); // 发送全部
// 阻塞等待（适合测试/短流程）
String r1 = f1.get();
Long r2 = f2.get();
Long r3 = f3.get();
异步管道 vs 同步批量：别为了 pipeline 而 pipeline
很多人以为 pipeline 就是“最快写法”，其实不然。Lettuce 提供了更轻量的替代方案，尤其在单 key 多 value 场景下：
-
sadd(key, v1, v2, v3...)、hmset(key, map)、mset(k1,v1,k2,v2)这类原生命令本身就批量，比 pipeline 少一层封装开销 - 管道真正有价值的地方是：跨类型命令混合（比如 set + hincrby + expire）、或需要强顺序保障（如先 set 再 getex）
- 如果只是往一个 set 插 10 万个元素，用
sadd(key, values...)比开 pipeline 快 20%+，且代码更直白 - 注意：Lettuce 默认对超长参数会分片（如 > 1024 个元素的
sadd），但分片逻辑不可控，建议业务层自己按 1000 元素/批切分
集群模式下 pipeline 的坑：MOVED 重定向不会自动重试
在 Redis Cluster 中，RedisPipeline 不支持自动处理 MOVED 或 ASK 重定向。一旦某条命令的 key 路由到错误节点，整个 pipeline 会失败并抛出 RedisCommandExecutionException，错误信息类似 MOVED 12345 10.0.1.5:6379。
- 这不是 bug，是设计使然：pipeline 要求所有命令必须落在同一 slot，否则违反 Redis Cluster 协议
- 解决办法只有两个：确保所有 key 使用相同哈希标签（如
{user:1001}.token和{user:1001}.profile）；或改用ClusterDistributionChannelWriter手动路由 - 不要试图在 pipeline 外围 catch MOVED 异常再重试——因为 pipeline 已发，重试逻辑无法对应到具体哪条子命令
flushCommands，而是判断该不该用 pipeline、以及在集群里怎么让 key 落在同一 slot。多数性能问题，其实出在没选对命令粒度，而不是没 flush。 
