异常教程

redis 消息队列（长文讲解）

更新时间:

💡一则或许对你有用的小广告

欢迎加入小哈的星球 ，你将获得：专属的项目实战 / 1v1 提问 / Java 学习路线 / 学习打卡 / 每月赠书 / 社群讨论

  • 新项目:《从零手撸：仿小红书（微服务架构）》 正在持续爆肝中，基于 Spring Cloud Alibaba + Spring Boot 3.x + JDK 17...，点击查看项目介绍 ;
  • 《从零手撸：前后端分离博客项目（全栈开发）》 2 期已完结，演示链接： http://116.62.199.48/ ;

截止目前， 星球 内专栏累计输出 82w+ 字，讲解图 3441+ 张，还在持续爆肝中.. 后续还会上新更多项目，目标是将 Java 领域典型的项目都整一波，如秒杀系统, 在线商城, IM 即时通讯，权限管理，Spring Cloud Alibaba 微服务等等，已有 2900+ 小伙伴加入学习 ，欢迎点击围观

Redis 消息队列：从基础到实战的全面解析

前言：为什么需要消息队列？

在现代软件开发中，系统往往需要处理异步任务、解耦组件或应对突发流量。例如，用户下单后，系统需要同步处理订单、扣减库存、发送通知等操作。如果这些任务直接在订单接口中同步执行，一旦某个环节出错，整个流程将被阻塞，导致用户体验下降。此时，消息队列的作用就凸显出来——它像一个“任务中转站”，将耗时操作从主流程剥离，通过异步处理提升系统吞吐量和稳定性。

Redis 消息队列凭借其高性能、易集成和丰富的数据结构支持，成为开发者实现异步通信的热门选择。本文将从基础概念、实现方式、使用场景到实际案例，逐步解析如何利用 Redis 构建可靠的消息队列系统。

Redis 消息队列的基本原理

1. 核心数据结构：LIST

Redis 的消息队列主要基于 LIST 数据结构实现。LIST 是一个双向链表，支持在列表两端进行快速操作：

  • LPUSH key value：将元素推入列表头部
  • RPUSH key value：将元素推入列表尾部
  • LPOP key：弹出列表头部元素
  • RPOP key：弹出列表尾部元素

通过组合这些命令，可以模拟队列（FIFO）或栈（LIFO）的行为。例如，用 RPUSH 生产消息到队列尾部，用 LPOP 从头部消费消息，就实现了标准队列模型。

2. 阻塞式操作：BLPOP 和 BRPOP

在实际场景中，消费者可能需要等待消息到达。Redis 提供了 BLPOP（阻塞左弹出）和 BRPOP（阻塞右弹出）命令，允许客户端在消息队列为空时挂起，直到超时或有新消息到达。这避免了轮询带来的资源浪费，提升了系统效率。

示例对比： | 非阻塞模式 | 阻塞模式 | |--------------------------|---------------------------| | 需要循环检查队列是否为空 | 自动等待消息到达 | | 可能频繁消耗 CPU 资源 | 零 CPU 占用（阻塞期间） |

Redis 消息队列的实现方式

1. 基于 LIST 的简单队列模型

实现步骤：

  1. 生产者将消息通过 RPUSH key message 添加到队列尾部
  2. 消费者使用 BLPOP key timeout 阻塞等待消息，或用 LPOP 非阻塞获取

代码示例（Python）：

import redis

r = redis.Redis()
message = "订单支付成功"
r.rpush("order_queue", message)

while True:
    _, message = r.blpop(["order_queue"], timeout=0)
    print(f"处理消息: {message.decode()}")

2. 基于 PUB/SUB 的发布订阅模型

Redis 还支持 发布订阅（Publish/Subscribe） 模式，适合一对多的消息分发场景：

  • PUBLISH channel message：向指定频道发布消息
  • SUBSCRIBE channel：订阅频道，监听消息到达

适用场景：

  • 实时聊天系统
  • 系统监控告警
  • 多消费者场景（如多个服务监听同一事件）

代码示例（Python）：

r.publish("chat_channel", "用户A发送了消息")

ps = r.pubsub()
ps.subscribe("chat_channel")
for message in ps.listen():
    if message['type'] == 'message':
        print(f"收到消息: {message['data'].decode()}")

3. 高级特性：优先级队列

通过结合 ZSET（有序集合），可以实现支持优先级的消息队列：

  • 每个消息关联一个优先级分数
  • 使用 ZADD 插入消息到有序集合
  • 消费者通过 ZRANGE 按优先级顺序获取消息

优先级队列实现：

r.zadd("priority_queue", {"紧急任务": 1, "普通任务": 2})

messages = r.zrange("priority_queue", 0, -1, withscores=True)
for msg, priority in messages:
    # 处理逻辑

Redis 消息队列的典型使用场景

1. 异步任务处理

案例：订单处理系统 当用户提交订单后，系统需要执行以下操作：

  • 扣减库存
  • 生成电子发票
  • 发送短信通知

通过将这些任务封装为消息，推送到 Redis 队列中，由后台工作者进程异步处理，避免阻塞用户请求。

2. 削峰填谷

在秒杀、促销等高并发场景下，直接访问数据库可能导致服务崩溃。通过 Redis 队列缓存请求，将流量均匀分配到后续时间段处理。

3. 服务间解耦

微服务架构中，各服务通过消息队列传递事件（如用户注册成功后，通知邮件服务、推荐系统等），避免直接依赖。

4. 实时数据处理

日志收集系统（如 ELK）可使用 Redis 临时存储日志，再由处理程序批量写入存储系统。

实战案例：构建订单通知系统

系统设计

目标：当订单状态更新时，触发短信和邮件通知。要求：

  • 确保通知最终送达
  • 避免重复通知同一订单

实现步骤：

  1. 消息结构设计：
{
  "order_id": "20231001-001",
  "status": "PAID",
  "retry_count": 0
}
  1. 生产者代码（Python）：
import json

def publish_order_status(r, order_id, new_status):
    message = json.dumps({
        "order_id": order_id,
        "status": new_status,
        "retry_count": 0
    })
    r.rpush("order_notify_queue", message)
  1. 消费者逻辑：
def consume_order_notifications(r):
    while True:
        _, raw_message = r.blpop(["order_notify_queue"], timeout=5)
        if not raw_message:
            continue
        message = json.loads(raw_message)
        try:
            send_sms(message["order_id"])
            send_email(message["order_id"])
            # 处理成功，删除消息
            r.delete(f"retry:{message['order_id']}")
        except Exception as e:
            # 重试机制：记录失败次数，超限后标记为失败
            if message["retry_count"] < 3:
                message["retry_count"] += 1
                r.rpush("order_notify_queue", json.dumps(message))
            else:
                r.set(f"failed:{message['order_id']}", "3次重试失败")
  1. 持久化保障：
  • 开启 Redis 持久化（RDB/AOF）
  • 对失败消息单独存储，供人工干预

使用 Redis 消息队列的注意事项

1. 持久化配置

默认情况下 Redis 是内存数据库，断电或重启会导致消息丢失。需配置 appendonly yes 启用 AOF 持久化，并设置适当的 fsync 策略。

2. 消息顺序保证

Redis 不保证消息的绝对顺序，但在单线程处理场景下，使用 LIST 的 FIFO 特性可实现顺序消费。

3. 性能优化

  • 使用管道（Pipeline）批量操作减少网络延迟
  • 合理设置阻塞命令的超时时间（如 BLPOP 的 timeout 参数）
  • 对大数据量场景考虑分片策略

4. 重试与死信队列

通过记录消息重试次数，将失败消息转移至专用队列，避免无限循环消耗资源。

结论：Redis 消息队列的价值与适用性

Redis 消息队列凭借其低延迟、高吞吐和灵活的数据模型，成为构建轻量级消息系统的理想选择。它特别适合以下场景：

  • 需要快速开发的中小型项目
  • 对消息顺序要求不严格的场景
  • 与 Redis 其他功能（如缓存、计数器）结合使用的场景

然而，对于需要事务保证、跨数据中心容灾或海量消息的场景，建议选择 Kafka、RabbitMQ 等专用消息中间件。开发者应根据具体需求，选择最合适的工具组合，实现系统的高效与稳定。

最新发布

查看更多文章