RabbitMQ 和 Redis 之间有什么区别？
RabbitMQ 是一种消息代理，而 Remote Dictionary Server（Redis）则是一种内存中键值数据存储。但是，这两种技术的可比性在于两者都可用于创建发布-订阅（pub/sub）消息传递系统。在现代云架构中，应用程序被分解为多个规模较小且独立的构建块，称为服务。Pub/sub 消息收发可以为这些分布式系统提供即时事件通知。RabbitMQ 是一种分布式消息代理，从多个来源收集流式处理数据，然后将其路由到不同的目标进行处理。Redis 支持基于推送的系统，其中发布者在事件发生时向所有订阅者分发消息。
工作原理：RabbitMQ 与Redis
RabbitMQ 和 Redis 都允许应用程序、微服务和软件组件以不同的方式交换消息。
RabbitMQ 工作流程
RabbitMQ 使用高级消息队列协议（AMQP），通过消息代理安全地发送消息。消息代理由交换和队列组成。该过程的工作原理是：
- 数据生产者向 RabbitMQ 发送消息
- 交换接收数据并根据一组称为绑定的规则将其路由到相应的队列
- 消息会一直驻留在队列中，直到 RabbitMQ 使用者选取该消息
当队列达到最大容量时，RabbitMQ 会阻止生产者发布消息，直到使用者处理未读的消息。如果在使用者阅读消息之前交换失败，RabbitMQ 也可以恢复消息。
Redis 工作流程
Redis 设计为支持列表、集合、哈希和位图等各种数据结构的数据结构服务器。Redis 允许客户端应用程序存储、检索和处理几乎任何类型的数据。Redis 将存储的数据组织成键值对，这可为订阅客户端应用程序提供结构化安排。
例如，可以将电子商务数据分为客户名称、电子邮件、购买的商品和反馈键。之后，发布每个键的相关数据。
Redis 支持短期保留消息的实时交换。其工作原理如下：
- 数据生产者向 Redis 发送消息
- Redis 节点检查消息键以识别感兴趣的订阅者
- Redis 将消息传送给所有连接的订阅者
消息处理：RabbitMQ 与Redis 发布/订阅
Redis 和 RabbitMQ 都为应用程序提供发布-订阅（发布/订阅）机制，以便在云环境中分发消息。但是，两者的消息处理存在显著差异。
消息传输
RabbitMQ 使用高级消息队列协议（AMQP）来支持复杂的路由逻辑。RabbitMQ 可以点对点或从一个生产者向多个使用者传输消息。无论使用哪种方法，所有使用者都会向生产者发送消息确认以确认读取成功。如果生产者没有收到确认消息，它会以不同的时间间隔进行几次重试。
同时，Redis 只是向所有连接的订阅者推送消息；它不能保证消息的送达。订阅者必须连接到 Redis 服务器才能接收传入的消息。如果 Redis 断开连接，它可能无法检索所有消息。
消息大小
RabbitMQ 可以传送更大的消息，而不会出现性能大幅下降。RabbitMQ 最初旨在处理大小不超过 2GB 的消息，但后来限制降低至 128MB。
相反，Redis 没有为存储的消息定义限制，但是对于大于 1MB 的消息，其会有明显的处理延迟。因此，开发人员通常使用 Redis 作为缓存来处理字符串、哈希、列表和集合等数据集。
消息持久性
RabbitMQ 支持持久消息和瞬态消息。向持久队列发送消息时，RabbitMQ 会在数据到达后立即将其写入永久存储空间。RabbitMQ 还会将瞬态消息写入磁盘，但前提是这些消息的大小超出内存的容量。
另一方面，Redis 默认不支持持久消息。开发人员必须启用一项名为 Redis 数据库（RDB）的功能，才能定期获取 RAM 的快照并将其存储在磁盘上。在 Redis 上启用数据持久性会增加数据操作的开销，从而减慢消息的传输速度。另一种选择是使用异步复制等恢复技术。
消息加密
RabbitMQ 使用 SSL 对在生产者、代理和使用者之间传输的数据进行加密。加密消息可帮助组织保护机密信息并降低数据风险。
与此同时，Redis 本身不支持 SSL。只有 Redis 版本 6.0 及更高版本提供 SSL 支持。要启用 SSL，开发人员必须从 Redis 集群获取 SSL 证书，并为其数据库创建客户端证书。
性能：RabbitMQ 与Redis 发布/订阅
消息处理差异会影响 RabbitMQ 和 Redis 在不同场景下的性能。
速度
Redis 比 RabbitMQ 更快速执行，因为它主要在内存上处理消息。但是，如果 Redis 服务器出现故障，则存在丢失未读消息的风险。
相比之下，在持久模式下运行时，RabbitMQ 会在发送下一条消息之前等待每个使用者的确认。RabbitMQ 还需要额外的时间将消息存储在磁盘上，这会降低平均消息交换速度。
作为比较，Redis 每秒最多可以发送数千万条消息，而 RabbitMQ 每秒最多可以处理数万条消息。
可用性
允许消息代理系统复制节点的集群在 RabbitMQ 和 Redis 中的处理方式有所不同。
使用 RabbitMQ，可以在集群中复制包含相关数据和函数的多个节点。但是，消息队列不会在这些共享对等关系的节点之间复制。为此，开发人员使用支持复制的特殊消息队列。
与此同时，Redis 集群是更高版本 Redis 中引入的一项功能。此功能将数据从每个领导节点复制到一个或多个从属节点。当领导节点出现故障时，从属节点会接管以提供高可用性消息传输。
使用时机：RabbitMQ 与Redis 发布/订阅
RabbitMQ 在许多领域的表现都优于 Redis，但这并不意味着 RabbitMQ 是适用于所有应用程序的更出色消息分发系统。
Redis 在需要实时数据处理和低延迟缓存的企业应用程序中效果更佳。凭借其内存数据存储和对不同数据结构的支持，Redis 适合执行低级别数据计算。例如，金融机构使用 Redis 缓存交易数据，以实现实时欺诈检测。
与此同时，如果您需要具有异步通信机制的专用微服务消息代理来支持代码和系统构建，请选择 RabbitMQ。RabbitMQ 也比 Redis 更适合在应用程序之间传输大型文件。例如，需要在许多微服务之间可靠地发送数据的系统可能会选择 RabbitMQ。该系统将受益于 RabbitMQ 的容错能力、更大的文件处理容量和得到保证的消息送达机制。
差异摘要：RabbitMQ 与Redis 发布/订阅
| RabbitMQ |
Redis |
|
| 消息传输 |
经过保证的消息送达。支持复杂逻辑。 |
不保证消息送达。需要来自订阅者的活跃连接。 |
| 消息大小 |
消息大小限制为 128MB。可以处理大型消息。 |
没有消息限制，但在处理大型消息（大于 1MB）时性能会降低。 |
| 消息持久性 |
支持持久和瞬态消息。将持久消息写入磁盘。 |
默认情况下不支持持久消息。 |
| 消息加密 |
支持 SSL 加密。 |
在 Redis 6.0 及更高版本中提供 SSL 加密。 |
| 速度 |
每秒多达数万条消息。 |
每秒多达数百万条消息。 |
| 可用性 |
在集群中创建多个点对点节点。 |
在集群中使用领导-从属模型。 |
AWS 如何帮助您满足 RabbitMQ 和 Redis 的要求？
Amazon Web Services（AWS）提供托管服务，以大规模运行您的开源消息代理系统。可以轻松设置发布-订阅（pub/sub）服务，并将它们与其他 AWS 服务集成。
以下是可以在 Redis 和 RabbitMQ 上使用的 AWS 产品：
- 使用适用于 Redis 的 Amazon MemoryDB，可在 Redis 上传送消息时增加持久性。可运行高并发串流数据馈送以提取用户活动，并支持媒体和娱乐应用程序的每天数百万次请求。
- 使用 Amazon MQ，可以预置您的 RabbitMQ 代理，无需执行耗时的设置。Amazon MQ 对传输中和静态的 RabbitMQ 消息进行加密，这有助于确保 AWS 可用区之间的高可用性数据管道。
除了使用 Redis 或 RabbitMQ 之外，还可以使用 Amazon Simple Notification Service（SNS）来构建发布/订阅消息收发系统。您可以直接在您的应用程序中以可扩展而且经济高效的方式发送消息给客户或其他应用程序。
Amazon SNS 提供多项功能：
- 分布式系统、微服务和事件驱动型无服务器应用程序之间的高吞吐量、基于推送的多对多消息收发
- 消息加密和流量隐私
- 跨 AWS 类别扇出功能，例如分析、计算、容器、数据库、物联网（IoT）、机器学习、安全性和存储
立即创建账户，开始使用 AWS 上的发布/订阅、Redis 和 RabbitMQ。
