Redis 8.10 BLMOVEM 阻塞搬运后任务仍堆积：批量条件与超时边界怎么排查

把单条列表搬运改成 Redis 8.10 的 BLMOVEM 后，最容易让人误判的现象不是报错，而是源列表一直有新任务，目标列表却间歇性断粮。客户端等到 timeout 后拿到空值，监控只看到等待连接增加，很像 Redis 变慢了。真正的问题常常藏在 COUNT 与 EXACTLY 的唤醒条件里：前者有一条就能动，后者必须攒够整批才会动。

任务没有丢，只是 EXACTLY 还在等整批

典型改动是把每次搬一个任务，换成下面这种批量命令：

BLMOVEM queue:ready queue:working RIGHT LEFT 2 EXACTLY 20 BULK

调用方想减少往返次数，于是要求每批 20 条、最多等 2 秒。低峰期每秒只有几条任务进入 queue:ready，列表长度迟迟不到 20，连接就一直保持阻塞；两秒内没凑够，返回空值，20 条任务仍留在源列表。生产者继续写入时，源列表看上去“明明不空”，消费者却没有拿到任务，这正是误判的起点。

这里别急着调大连接池。先把三项数据对齐：源列表长度、空值返回次数、命令使用的是 COUNT 还是 EXACTLY。只盯客户端超时，很容易把批量门槛当成网络抖动。

从参数变更到目标列表断粮，故障是怎样形成的

问题通常沿着一条很短的链路出现。最初用单条阻塞搬运，源列表来一条就处理一条；为了提高批量处理效率，调用改成 EXACTLY 20 BULK；高峰期一切正常，因为源列表很快超过 20；低峰期批量长期凑不齐，有限超时不断返回空值；调用方把空值记成“暂时无任务”，没有同步观察源列表长度，于是目标列表出现间歇性断粮。

Redis 8.10 的官方定义很明确：BLMOVEM 是 LMOVEM 的阻塞版本，时间复杂度为 O(N)，N 是本次移动的元素数。当源列表满足请求条件时，它与非阻塞版本行为相同；不满足时才等待新元素或等到超时。

COUNT 与 EXACTLY 的阻塞门槛并不相同

COUNT 20 的意思不是“等满 20 条”。只要源列表非空，它就解除阻塞，把当前能拿到的元素搬走，最多 20 条。EXACTLY 20 才会把 20 当成硬门槛，19 条也不会动。两者都可以配 OBO 或 BULK，但排序选项不会改变这个唤醒规则。

根因不是“阻塞命令太慢”，而是门槛与流量不匹配

如果业务低峰每两秒通常只到 6 到 12 条任务，那么 EXACTLY 20 配 timeout 2 本身就是矛盾组合。等待连接没有卡死，它只是在严格执行整批语义；空值也不是异常回复，而是“超时前未满足整批条件”。

第二个常见误区是把 timeout 0 当成立即返回。对阻塞命令来说，0 表示无限等待。若调用方没有单独的取消和连接回收策略，部署重启时会看到连接长时间留在阻塞状态。生产环境更适合给出有限超时，并把空值作为正常分支记录，而不是当成 Redis 故障。

还要注意集群边界。BLMOVEM 同时访问源键和目标键，官方文档提示它在 Redis Cluster 中属于多键操作，行为受多键规则约束。源键和目标键应按当前集群方案放到可共同处理的位置；否则不要把槽位问题和批量门槛混在一次排查里。

按下游语义选修复，不要只把 timeout 调大

延迟优先：换成 COUNT，允许小批次

BLMOVEM queue:ready queue:working RIGHT LEFT 2 COUNT 20 BULK

这适合图片转码、通知分发、索引更新等可以接受 1 到 20 条的小批任务。源列表一旦非空就会唤醒，低峰不会为了凑整批而空等。调用方按返回数组的真实长度处理，不要假定每次一定有 20 条。

整批优先：保留 EXACTLY，同时调整批量门槛

如果下游确实要求固定批次，例如每批必须组成完整文件或一次提交固定数量，就应保留 EXACTLY。修复点应是让 n 与低峰流量、等待上限和业务延迟目标相符，并显式监控“当前列表长度距离 n 还差多少”。单纯把超时从 2 秒改到 30 秒，只会把断粮变成长时间等待。

OBO 与 BULK：根据目标列表顺序核对

OBO 是逐个弹出再逐个压入，BULK 是整批移动并保持相对顺序。命令返回的数组按元素在目标列表中的顺序给出。排查“顺序反了”时，应同时看从 source 的哪一端取、向 destination 的哪一端放，以及使用哪种排序方式，不能只比较返回数组和原列表截图。

事务块和 Lua 脚本里为什么不会等待

阻塞语义只发生在普通连接调用中。官方文档说明，BLMOVEM 放进事务块或 Lua 脚本后不会挂起等待；当条件不满足时，它会像 LMOVEM 一样立即返回空值。原因很实际：事务或脚本不能把整个原子操作长期停在等待新元素的状态。

因此，把普通连接里的命令原样塞进事务，并不能获得“事务内等满一批”的效果。若代码刚做过这种封装调整，空值突然增多时，应先核对调用上下文，而不是继续放大 timeout。

上线前用这份清单防止同类积压

• 确认 Redis Open Source 版本支持 BLMOVEM；该命令从 8.10.0 开始提供。
• 记录选择器、批量 n、timeout、source 方向、destination 方向和 OBO/BULK。
• 分别观测源列表长度、目标列表增长、空值返回和阻塞连接数量。
• 使用 COUNT 时按实际返回长度处理；使用 EXACTLY 时给“未凑满”单独指标。
• 给有限超时设计正常重试和退出路径；不要把空值统一记成错误。
• 在事务块或 Lua 脚本中调用时，按非阻塞返回分支设计代码。
• 集群部署单独检查多键规则，不把槽位异常误归因于批量门槛。

延伸问答

BLMOVEM 超时后会搬走一部分元素吗？

使用 EXACTLY 时，数量不足会一直等待，超时返回空值，不会为了凑数先搬一部分。使用 COUNT 时，只要源列表至少有一个元素就会解除阻塞并搬走当前可用数量。

COUNT 20 会一直等到 20 条吗？

不会。COUNT 的 20 是上限，不是最低门槛。源列表有 1 条时就可以返回 1 条。

timeout 设置为 0 是不等待吗？

恰好相反，0 表示无限等待。需要周期性回到应用代码处理取消、健康检查或退出时，应使用有限超时。

为什么事务块里的 BLMOVEM 立即返回空值？

事务块和 Lua 脚本不采用阻塞等待语义；条件不满足时，它按非阻塞命令的方式立即返回空值。

迁移到 BLMOVEM 后第一项该监控什么？

先把源列表长度与空值返回放在同一张图上。如果源列表不空但 EXACTLY 长期返回空值，优先检查批量 n 与 timeout 是否符合低峰流量。

小结

BLMOVEM 把阻塞等待与批量搬运合到一个原子命令里，真正需要做决定的是批量语义。COUNT 适合“有多少先做多少”，EXACTLY 适合“必须完整一批”；timeout 决定最多等多久，OBO/BULK 决定目标列表中的顺序。把这四项和调用上下文一起记录，源列表明明有数据而目标列表断粮的现象就不再神秘。