BullMQ 提示 volatile-lru：队列能否共用缓存 Redis

BullMQ 启动时打印 Eviction policy is volatile-lru. It should be "noeviction"，但 Redis 连接正常，任务也暂时能执行。这个提示指出的是内存达到上限后的淘汰规则：队列使用的键可能被 Redis 删除。暂时没有出错，不能证明当前配置适合长期运行队列。

BullMQ 6.3.12 的连接检查会对非 noeviction 策略输出警告。它本身不是 Redis 返回的 ReplyError；如果日志还有命令失败，需另外保留具体错误、操作及发生时间，不能把所有异常都归到这条警告。

volatile 策略也会影响队列

volatile-lru 在内存压力下，从设置了过期时间的键里选择淘汰对象。BullMQ 的锁、限流等协调数据会使用过期时间，因此“只淘汰缓存、队列没有 TTL 就安全”的判断不成立。协调键提前消失，可能影响锁续期、恢复与任务处理。

allkeys-lru 的候选范围更广，也不满足 BullMQ 对后端的要求。修改客户端 prefix、换 Redis 的逻辑数据库编号，都不会给队列创建一套独立的内存淘汰策略：maxmemory 和 maxmemory-policy 属于实例配置。

用现有认证、TLS 和数据库选择连接到实际的队列后端，再检查以下信息。命令用于 Redis 管理连接，托管服务可能禁止读取配置，需要从服务控制台核对。

CONFIG GET maxmemory
CONFIG GET maxmemory-policy
INFO memory
INFO stats

核对实际目标实例，查看内存使用与 evicted_keys 的变化。淘汰计数上升只证明发生过键淘汰，不会告诉你哪些任务受影响；当前计数没有上升，也不代表未来达到内存上限时没有风险。

共享缓存后端先确认谁依赖淘汰

如果同一实例还为网站缓存提供 volatile-lru，直接改成 noeviction 会影响其他业务：内存满后，需要增加内存的写入可能返回 OOM，原来依靠淘汰继续写入的缓存也会失败。

先盘点共享实例的使用方、容量限制与配置权限。无法统一改动时，给 BullMQ 选择独立、支持 noeviction 的后端；缓存继续使用它原来的策略。搬迁需要另行安排停止或切换生产者、处理旧队列和恢复消费者，换一个连接地址不会自动迁移已有任务。

如果该实例专用于队列，经过容量与业务影响确认后，在其持久配置中设置：

maxmemory-policy noeviction

具体配置文件、托管参数和生效方式以当前部署为准。不要在共享实例上盲目执行 CONFIG SET，也不要用跳过版本检查或隐藏日志替代后端调整。

noeviction 之后仍要处理容量上限

noeviction 不会增加内存，也不保证任务永远写入成功。给成功、失败任务设置符合业务追查要求的有界保留策略，监控内存、写入失败、积压与任务恢复；生产者必须处理 queue.add() 失败，避免接口返回成功而任务根本没有入队。

保留策略的调整可能删除历史任务，先确认审计和重试需求，不能为了降低内存直接清空队列。需要长期留存的业务记录应放在对应的业务存储中。

验收时确认所有 Queue、Worker 和 QueueEvents 已连接到预期后端，策略确实为 noeviction，并检查正常入队、消费、失败恢复及受控容量不足时的处理。任务持久性还取决于 Redis 的持久化、备份和恢复配置；这条策略警告消失，只代表淘汰规则这一项得到修正。