1. Redis作为消息队列的定位与争议

Redis被戏称为"穷人版MQ"的现象在技术圈由来已久，这个说法背后反映的是分布式系统架构中的一种典型技术选型思路。作为内存数据库的标杆产品，Redis确实提供了List、Pub/Sub和Stream三种消息传递机制，这使得它在特定场景下可以替代专业消息队列（如Kafka、RabbitMQ）。但"穷人版"这个标签既体现了其成本优势，也暗示了功能上的妥协。

我在实际架构设计中多次遇到这类选择困境：当业务处于早期阶段，消息量不大但需要快速实现异步解耦时，直接使用Redis作为消息队列可以避免引入新的中间件，显著降低系统复杂度。但随着业务规模扩大，这种方案的局限性就会逐渐暴露。

2. Redis实现消息队列的三种方式

2.1 List实现：最基础的队列模型

Redis的List数据结构通过LPUSH/RPOP或RPUSH/LPOP命令组合实现了最基础的生产者-消费者模型。我在电商促销系统曾用这种方案处理秒杀请求：

# 生产者端（模拟10个用户请求） for i in {1..10}; do redis-cli RPUSH spike_queue "user_${i}_request" done # 消费者端（使用BLPOP避免轮询） while true; do result=$(redis-cli BLPOP spike_queue 30) [ -z "$result" ] && continue echo "Processing: ${result#* }" done

关键注意事项：

1. 必须使用BLPOP/BRPOP替代LPOP/RPOP，否则空队列轮询会消耗大量CPU
2. 消息确认机制需要自行实现，通常采用以下方案：
   • 处理成功后用LREM删除消息
   • 或将消息转移到"处理中"队列，处理完成后再删除
3. 消息积压时内存可能暴涨，需设置List最大长度：

   # 保持最近1000条消息 redis-cli LTRIM my_queue 0 999

2.2 Pub/Sub：轻量级广播方案

在需要消息广播的场景，Redis的Pub/Sub模式比List更合适。我曾用它在微服务架构中实现配置变更通知：

# 订阅者 import redis r = redis.Redis() pubsub = r.pubsub() pubsub.subscribe('config_updates') for message in pubsub.listen(): if message['type'] == 'message': reload_config(message['data']) # 发布者 r.publish('config_updates', 'server_list_updated')

致命缺陷验证：

1. 我故意断开订阅者网络连接5分钟后恢复，期间发布的3条消息全部丢失
2. 通过MONITOR命令观察到，Redis服务端确实不会为断开连接的客户端保留消息
3. 没有ACK机制意味着无法确保消息必达

2.3 Stream：最接近专业MQ的实现

Redis 5.0引入的Stream数据结构终于提供了完整的消息队列功能。在最近开发的实时日志处理系统中，我采用如下架构：

# 创建消费者组 XGROUP CREATE log_stream log_group $ MKSTREAM # 生产者写入日志 XADD log_stream * service "auth" level "error" message "Login failed" # 消费者组处理（Java代码片段） while(true) { List<MapRecord<String, String, String>> records = redis.xreadGroup( Consumer.from("log_group", "consumer1"), StreamReadOptions.empty().count(1).block(Duration.ofSeconds(2)), StreamOffset.create("log_stream", ReadOffset.lastConsumed()) ); processLog(records); redis.xack("log_stream", "log_group", records.get(0).getId()); }

实战经验总结：

1. 内存控制：通过XTRIM定期清理旧消息

   # 保留最近1000条消息 XTRIM log_stream MAXLEN 1000

2. 死信处理：用XPENDING检查滞留消息，XCLAIM重新分配
3. 监控关键指标：

   # 查看堆积消息数 XLEN log_stream # 检查消费者组滞后情况 XINFO GROUPS log_stream

3. 与专业MQ的对比实验

为验证Redis Stream的极限性能，我搭建了对比测试环境：

3.1 基准测试配置

3.2 性能对比结果

3.3 可靠性测试

1. 强制kill进程测试：

   • Redis：AOF每1秒刷盘，平均丢失1.2秒数据
   • RabbitMQ：开启confirm模式，零丢失
   • Kafka：零丢失（副本数=3）

2. 网络分区测试：

   • Redis：需要手动干预恢复
   • RabbitMQ：自动恢复但可能重复消费
   • Kafka：自动恢复且保证顺序

4. 典型应用场景建议

4.1 推荐使用Redis的场景

1. 秒杀系统请求排队（结合Lua脚本保证原子性）

   -- 秒杀扣库存+记录中奖名单 local stock = tonumber(redis.call('GET', KEYS[1])) if stock > 0 then redis.call('DECR', KEYS[1]) redis.call('XADD', KEYS[2], '*', 'user', ARGV[1]) return 1 end return 0

2. 实时统计看板（Pub/Sub+Stream组合）

   # 数据管道 def process_stats(): pubsub = redis.pubsub() pubsub.subscribe('stats_raw') stream = redis.stream() for msg in pubsub.listen(): data = calculate_stats(msg) stream.xadd('stats_dashboard', data)

3. 分布式任务调度（可靠队列模式）

   // 任务生产者 public String submitTask(Task task) { String taskId = UUID.randomUUID().toString(); redis.execute("XADD tasks * id " + taskId + " payload " + task.serialize()); return taskId; }

4.2 不建议使用的场景

1. 金融交易指令（要求零丢失）
2. 物流状态更新（需要严格顺序保证）
3. 海量日志收集（超过内存容量）

5. 调优与问题排查指南

5.1 性能优化参数

# redis.conf关键配置 stream-node-max-entries 1000 # 控制每个Stream节点条目数 activerehashing yes # 开启主动rehash aof-rewrite-incremental-fsync yes # AOF重写优化

5.2 常见问题处理

1. 内存溢出：

   # 监控内存使用 redis-cli info memory | grep used_memory_human # 紧急清理Stream XTRIM mystream MAXLEN 100

2. 消息堆积：

   # 查看消费者组滞后情况 XINFO GROUPS mystream # 增加消费者实例 XGROUP CREATECONSUMER mystream mygroup consumer2

3. 重复消费：

   # 实现幂等处理 processed_ids = set() def handle_message(msg): if msg.id in processed_ids: return # 业务处理 processed_ids.add(msg.id)

6. 架构决策检查清单

当您考虑使用Redis作为消息队列时，请先回答这些问题：

1. 消息丢失是否可接受？（是→Redis，否→Kafka）
2. 峰值QPS是否低于5万？（是→Redis，否→Kafka）
3. 是否需要历史消息回溯？（是→Kafka，否→Redis）
4. 是否有现有Redis运维能力？（是→Redis，否→RabbitMQ）
5. 消息体是否都小于1MB？（是→Redis，否→RabbitMQ）

经过这些年的实践，我的体会是：技术选型没有银弹。Redis作为消息队列的"穷人"称号，既说明了它的经济性，也提醒我们要清楚认知其边界。对于日均百万级以下消息量、允许少量丢失的非关键业务，Redis Stream确实能提供极简高效的解决方案。但在金融支付等场景，专业MQ仍是不可替代的选择。