对于非核心业务且对消息可靠性要求不极端的轻量级任务，推荐直接用 Redis 代替 RocketMQ，主要是为了减少运维组件数量和降低资源消耗。

快速处理思路

如果决定使用 Redis 替代 RocketMQ，不要直接用 Publish/Subscribe，建议根据需求选择 List 或 Stream 结构。List 适合简单 FIFO 队列，Stream 适合需要消费组确认的场景。

Redis List 实现简单队列：

LPUSH task_queue "task_data"
# 生产环境建议设置超时时间，避免连接假死阻塞线程
BRPOP task_queue 5

Redis Stream 实现可靠消费（含 ACK）：

# 1. 生产消息
XADD task_stream * task "task_data"

# 2. 消费组消费（BLOCK 避免空轮询，COUNT 控制批次）
XREADGROUP GROUP group1 consumer1 BLOCK 2000 COUNT 10 STREAMS task_stream >

# 3. 业务处理成功后确认（关键步骤，否则消息会留在 Pending 列表）
XACK task_stream group1 1715623400000-0

相比之下，RocketMQ 需要独立部署 NameServer 和 Broker，配置 Topic 和 Group，运维门槛明显更高。

核心差异分析

推荐 Redis 的核心原因不是性能绝对值更高，而是运维成本和资源占用的差异。RocketMQ 基于 JVM，启动通常需要至少 1GB 堆内存，且依赖磁盘顺序写保证可靠性；而 Redis 启动内存占用通常在 50MB 左右，且项目往往已经部署了 Redis，复用现有设施可以减少维护组件。

此外，Redis 是内存操作，消息投递延迟极低，适合对延迟敏感但对持久化要求不高的场景。RocketMQ 设计初衷是金融级可靠性，支持事务消息和复杂路由，对于简单任务队列属于功能过剩，反而增加了系统复杂度。

生产环境配置清单

在使用 Redis 作为队列前，必须调整 redis.conf 配置以确保数据安全：

# 开启 AOF 持久化，防止重启丢消息
appendonly yes

# 队列场景严禁使用淘汰策略，内存满应报错而非丢数据
maxmemory-policy noeviction

# 根据机器内存设置上限，防止 OOM 影响其他业务
maxmemory 2gb

# 持久化频率调整（根据业务容忍度）
appendfsync everysec

异常处理与验证

1. 检查内存增长：使用 INFO memory 观察 used_memory 是否随消息量线性增长，确认无内存泄漏。

2. 验证消息积压：使用 LLEN task_queue 或 XLEN task_stream 查看队列长度，确认消费者处理速度跟得上生产速度。

3. 处理 Pending 消息：若消费者宕机，消息会进入 Pending 列表。使用 XPENDING task_stream group1 查看未确认消息，必要时用 XCLAIM 将消息重新指派给其他消费者。

4. 模拟故障测试：手动重启 Redis 实例，检查 AOF 文件是否生效，确认重启后消息未丢失。

5. 监控延迟：记录消息生产时间与消费时间差，确认延迟在业务允许范围内（通常 Redis 可实现毫秒级）。

常见坑

1. Pub/Sub 消息丢失：Redis 的发布订阅模式要求订阅者必须在发布者之前启动，否则消息会丢失，生产环境严禁用于可靠队列。

2. 大 Key 问题：如果单个消息体过大（如超过 10KB），会占用网络缓冲区，导致 Redis 阻塞，建议消息体保持轻量。

3. 内存溢出风险：如果消费者宕机且未配置 maxmemory，消息积压可能撑爆内存。必须设置 maxmemory 并配合监控报警。

4. Stream 未 ACK 风险：只读不确认会导致 Pending 列表无限增长，消耗内存。务必确保业务逻辑成功后执行 XACK，或设置死信队列处理失败消息。