DevOps知识中心
DevOps知识中心

何时应将 Redis 用作消息代理？

利用 Redis 的两种主要功能：发布/订阅 (Pub/Sub) 和流 (Streams)，发掘将其用作消息代理的理想场景。本综合指南详细介绍了 Redis 消息传递的性能优势、低延迟和基础设施优势。了解短暂的发布/订阅与持久化流之间的关键区别，理解它们与 Kafka 等专用代理相比的局限性，并找到实际用例——从简单的缓存失效到健壮、轻量级的任务队列——以帮助您为异步通信需求选择合适的工具。

52 浏览量

何时应将 Redis 用作消息代理？

Redis 以其超快的内存数据存储而闻名，主要用于缓存和会话管理。然而，其多功能的数据结构使其用途远超简单的键值存储。Redis 提供了强大的原语，使其能够有效地充当轻量级消息代理，即 Redis 发布/订阅 (Pub/Sub) 和 Redis 流 (Streams)。

决定 Redis 是否适合您的消息传递需求，需要理解其中的权衡。尽管像 RabbitMQ 或 Apache Kafka 这样的专用消息代理提供强大的保证、复杂的路由和卓越的持久性，但 Redis 提供了无与伦比的简单性、速度和低延迟——使其成为依赖现有基础设施有益的特定高性能用例的理想选择。本文将探讨 Redis 消息传递的机制，并帮助定义其表现出色的场景以及何时应考虑其他解决方案。

理解 Redis 消息传递原语

Redis 提供了两种不同的异步消息传递功能，每种都适用于不同级别的可靠性和复杂性。

1. Redis 发布/订阅 (Pub/Sub)

Redis Pub/Sub 是 Redis 提供的最简单的消息传递形式。它采用“即发即忘”模型，发布者将消息发送到频道，而监听这些频道的订阅者则接收它们。

机制和特点：

  • 短暂性： 消息 永不 持久化。如果订阅者断开连接或处理缓慢，它将错过在此期间发布的任何消息。
  • 无确认： 没有内置的消息确认或保证交付机制。
  • 低延迟： 由于其简单的内存特性，速度极快。
  • 扇出： 非常适合同时向多个监听者广播实时更新。

Pub/Sub 示例

这个简单的命令演示了交互过程：

# 终端 1：订阅者开始监听
REDIS> SUBSCRIBE updates:pricing

# 终端 2：发布者发送消息
REDIS> PUBLISH updates:pricing "Stock price updated to $150.00"

# 终端 1 收到：
1) "message"
2) "updates:pricing"
3) "Stock price updated to $150.00"

2. Redis 流 (Streams) (XSTREAM)

Redis 5.0 引入的 Redis Streams 提供了一种复杂、耐用且持久的类日志数据结构，使 Redis 能够更直接地与传统代理竞争，实现可靠的消息传递。

机制和特点：

  • 持久性： 消息（流条目）持久存储在 Redis 中，允许消费者读取历史数据或在断开连接后恢复错过的消息。
  • 消费者组： 流支持消费者组，允许多个消费者并发处理来自流的消息，分担负载并确保组内每条消息仅由一个消费者处理（竞争消费者模式）。
  • 至少一次交付： 流使用显式消息确认 (XACK)，保证消息至少被处理一次。如果处理失败，消息将保持待处理状态以供重新处理。
  • 排序： 消息严格按照其流 ID（时间戳加序列号）排序。

Streams 示例（生产者和消费者组）

1. 添加条目（生产者）： * 表示 Redis 应生成一个唯一的 ID。

XADD events:orders * item_id 42 user_id 99 amount 59.99

2. 创建消费者组：

XGROUP CREATE events:orders order_processors 0-0 MKSTREAM

3. 从组中读取（消费者）： > 仅读取新的、未读的消息。

XREADGROUP GROUP order_processors consumer_A COUNT 1 STREAMS events:orders >

将 Redis 用作代理的优势

选择 Redis 通常归结为性能和基础设施整合。

  1. 极低延迟： 对于需要即时数据分发的应用程序（例如，实时记分牌、实时警报），Redis 的内存特性提供了最小的开销和非专业解决方案中最快的消息传递速度。
  2. 基础设施整合： 如果您已经使用 Redis 进行缓存或会话管理，将其用于轻量级消息传递可以避免设置、扩展和维护独立专用代理集群（如 Kafka 或 RabbitMQ）的复杂性和运营成本。
  3. 流的简单性： 尽管与 Pub/Sub 相比，流引入了复杂性，但它们在配置和管理方面仍然比像 Kafka 这样的大规模分布式日志架构更简单，使其成为中小型消息工作负载的理想选择。
  4. 事务性和原子操作： Redis 可以使用 Redis 事务或 Lua 脚本将消息发布/流操作与其他原子数据修改（例如，更新计数器和发送通知）结合起来。

何时使用 Redis 消息传递：定义的用例

Pub/Sub 和 Streams 之间的选择，以及 Redis 和专用代理之间的选择，完全取决于所需的可靠性和规模。

Redis Pub/Sub 的用例（短暂消息传递）

当消息丢失可接受且速度至关重要时，使用 Pub/Sub。

  • 缓存失效： 在多个应用程序实例之间广播通知，指示特定缓存键已更新并需要失效。
  • 实时通知： 简单的状态更新、聊天室消息（历史记录在其他地方处理），或消费者只关心 最新 值的实时数据流。
  • 无状态扇出： 将配置更改或系统健康检查分发给微服务，而无需确认接收。

Redis Streams 的用例（持久消息传递）

当您需要可靠性、持久性和并发处理，但不需要大规模消息吞吐量或复杂路由时，使用 Streams。

  • 简单任务队列： 实现后台工作队列，其中任务必须保证交付（例如，图像处理、电子邮件发送）。Streams 有效地管理任务历史和消费者状态。
  • 事件溯源（轻量级）： 存储持久、有序的操作事件日志，用于回放、审计或简单的状态重建——适用于小事件量。
  • 服务间通信（微服务）： 使用流连接松散耦合的服务，其中需要集中、持久的消息日志以实现可靠的数据交换。
  • 速率限制： 存储与用户行为或 API 调用相关的时序数据，用于快速分析和执行速率限制。

局限性及何时选择专用代理

尽管 Redis Streams 功能强大，但它们并不能在所有场景中取代企业级消息代理。如果您的应用程序属于以下类别，通常需要专用解决方案。

1. 高吞吐量和数据持久性要求

Redis 主要是一个内存存储。虽然它支持持久性（RDB 快照或 AOF 日志），但这些机制主要针对重启恢复进行优化，而不一定是像 Kafka 这样的解决方案所提供的持续的、PB 级的数据持久性和高度优化的磁盘 I/O。

如果出现以下情况，请选择 Kafka/Pulsar：
* 您需要每秒数十万条消息的保证交付。
* 您的消息数据量超出系统内存，并且您需要高效的基于磁盘的存储和分层归档。
* 您需要极长的消息历史保留期（数月或数年）。

2. 高级代理功能

专用代理提供了 Redis 缺乏的开箱即用型复杂功能。

功能 Redis Streams 专用代理（例如，RabbitMQ, Kafka）
死信队列 (DLQ) 必须通过应用程序逻辑手动实现。 原生支持自动路由失败消息。
复杂路由/过滤 基本过滤必须在客户端进行。 Exchange 类型 (RabbitMQ) 或复杂主题分区 (Kafka) 用于高级路由。
事务性 仅限于 Redis 实例内部。 支持跨消息发送和数据库更新的分布式事务。
安全性与监控 基本 ACL 和通用指标。 细粒度权限、专用监控工具和企业级审计。

3. 队列管理

尽管 Redis 列表 (LPUSH/RPOP) 可以充当基本队列，但它们仅支持 FIFO 且缺乏持久性保证，除非与 BRPOP 等功能和自定义逻辑结合使用。Streams 更好，但专用代理提供更高级的队列管理策略（例如，优先级队列、消息 TTL）。

总结和最佳实践

当操作简单性和极快的性能超越对复杂功能和 PB 级持久性的需求时，Redis 是消息代理的绝佳选择。

场景 消息传递原语 最佳实践
实时广播/缓存同步 Redis Pub/Sub 确保订阅者优雅地处理丢失的消息。
轻量级任务队列 Redis Streams 使用消费者组和严格的 XACK 来确保至少一次处理。
高吞吐量数据管道 专用代理 (Kafka/Pulsar) 如果消息必须在数 TB 的数据中可靠地持久化，请勿使用 Redis。
现有 Redis 基础设施 Redis Streams 使用现有 Redis 集群以节省设置开销。

警告： 使用 Redis Streams 时，请记住流条目会消耗内存。实施策略以使用 XTRIM（例如，根据长度或 ID）修剪旧条目，以防止过度内存使用，尤其是在高吞吐量流上。