Redis BLMOVEM 的 EXACTLY 怎样等待足量元素再转移

如果一个消费者必须等到一批元素凑齐后再转移，Redis 8.10 的 BLMOVEM 可以用 EXACTLY 表达这个约束：源列表少于指定数量时继续阻塞，达到数量后一次性移动；如果只是“有数据就尽量取”，则使用 COUNT。关键不是把 timeout 写得很大，而是先选对批量条件。

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

本文只讨论源列表到目标列表的阻塞式批量转移，不把普通单元素 BLMOVE 队列模式混进来。

EXACTLY 和 COUNT 解决的是两种不同的批处理语义

BLMOVEM source destination source-side destination-side timeout 的前半部分决定从哪里取、放到哪里；可选的数量块决定“凑多少才算满足”。

• COUNT n：源列表只要不是空的就可以解除阻塞，最多移动 n 个，实际不足时允许少于 n。
• EXACTLY n：源列表必须至少有 n 个，数量不够时继续等待；满足后恰好移动 n 个。

因此，订单批处理、固定大小的向量拼接、需要保持一批输入完整性的消费者适合 EXACTLY；日志汇聚、尽快清空队列或允许小批量降级时，COUNT 更合适。

先用最小命令看懂 EXACTLY 的等待条件

下面的例子从源列表右端取出，按批次顺序从目标列表左端放入。命令中的 0 表示无限等待；实际服务中通常应换成有限秒数。

# 准备两个元素；此时还不满足 EXACTLY 3
redis-cli DEL queue:ready queue:processing
redis-cli RPUSH queue:ready job-1 job-2

# 源列表不足 3 个时继续阻塞，直到补齐或 timeout 到期
redis-cli BLMOVEM queue:ready queue:processing RIGHT LEFT 10 EXACTLY 3 BULK

# 另一个连接补入第 3 个元素后，上面的阻塞调用才具备返回条件
redis-cli RPUSH queue:ready job-3

这里的 EXACTLY 3 是“解除阻塞的最低数量”，不是“最多读三条”。如果只想在有一条数据时立即拿走当前最多三条，应改成 COUNT 3。

COUNT 和 EXACTLY 怎么选

四个方向参数决定数据最终的顺序

BLMOVEM 有两个方向：第一个是源列表从左端还是右端弹出，第二个是目标列表从左端还是右端推入。以 FIFO 队列为例，常见组合是 RIGHT LEFT：从源队尾取最早入队元素，再放到目标队头。

# FIFO：右端出、左端入；EXACTLY 4 要求一次凑够 4 个
redis-cli BLMOVEM queue:ready queue:processing RIGHT LEFT 5 EXACTLY 4 BULK

# 栈式转移：左端出、右端入；元素相对顺序由 OBO/BULK 决定
redis-cli BLMOVEM stack:in stack:out LEFT RIGHT 5 COUNT 2 OBO

BULK 把一批元素作为整体转移并保持文档定义的相对顺序；OBO 按元素逐个移动。若目标列表的消费顺序很重要，方向和顺序选项必须一起写进接口契约，不能只凭“看起来像队列”来猜。

timeout 到期时不要把空结果当成成功批次

timeout 是最大阻塞秒数，写成 0 会无限等待。使用有限 timeout 时，调用可能因为源列表始终凑不够而返回空值；这表示本次没有完成转移，不应当提交一个“已处理 n 条”的业务批次。

# 最多等待 3 秒，凑不够 8 个就让调用返回
# 业务层应把空返回记为超时或稍后重试，而不是确认消费成功
redis-cli BLMOVEM queue:ready queue:processing RIGHT LEFT 3 EXACTLY 8 BULK

生产消费者通常还要为 timeout 配合取消、重试和幂等键。EXACTLY 只保证这次 Redis 列表转移的数量条件，不会替你完成业务数据库提交、重复消费保护或跨系统事务。

事务、脚本和集群环境要单独留意

BLMOVEM 的阻塞行为适合独立连接上的消费者。放进 MULTI/EXEC 或 Lua 脚本时，阻塞命令不会真正等待，而是按非阻塞的 LMOVEM 语义处理；如果你的方案依赖“等到足量再执行”，不要把它包进事务或脚本后再期待同样的等待效果。

它涉及源、目标两个 key，在 Redis Cluster 中还需要遵守多 key 操作的槽位约束。跨槽时不要只修改 timeout 或数量参数，应该先规划 hash tag 或改用能够落在同一槽位的 key 设计。

另外，BLMOVEM 是 Redis Open Source 8.10.0 起提供的能力。老版本服务器不认识该命令时，客户端会收到未知命令错误；上线前应以服务器版本和客户端命令支持情况为准，不要只看本地工具版本。

一张决策表记住最小用法

常见问题

EXACTLY 需要源列表一开始就有足够元素吗？

不需要。只要调用仍在阻塞窗口内，其他客户端把元素追加到源列表后，数量达到要求就可以满足条件。

COUNT 3 会永远等到三条吗？

不会。COUNT 的含义是最多移动三条，源列表只要有可用元素就可能返回；必须凑满时要用 EXACTLY。

EXACTLY 超时后源列表会被部分删掉吗？

没有满足数量条件而超时时，本次转移不会因为“差一点”而完成部分移动。业务层仍应把空返回当作未完成处理，并设计下一次拉取策略。

总结一下：把 EXACTLY 当成“批次完整性”开关，把 COUNT 当成“最多取多少”的上限；再根据两端方向、BULK/OBO 和有限 timeout 写出完整契约，BLMOVEM 才适合放进稳定的批量消费流程。