Redis 发布订阅与 Apache Kafka：如何选择合适的消息系统

在为您的分布式架构选择消息系统时，Redis Pub/Sub 和 Apache Kafka 都提供了强大的发布/订阅功能。然而，它们针对不同的使用场景，取决于消息持久性、可扩展性以及交付保证等因素。让我们来看看它们各自的特点，并看看它们各自的优缺点！

Redis 发布/订阅是一种轻量级的消息模式，发布者将消息发送到频道（channels），订阅者则监听这些频道。具体来说，它的工作方式是这样的：

• 基于频道的通信：Redis 发布订阅通过频道进行操作，这些频道可以有任意数量的订阅者，包括零个。发布者会把消息广播到这些频道，订阅者会实时收到消息。
• 松耦合：发布者和订阅者互不知晓对方，因此这种架构是松耦合的。

1. 关联递送语义

• 只有在消息被送达时连接到该频道的订阅者才能收到消息。

• 如果一个订阅者断开连接，他们将会错过在此期间发送的消息。

• Redis 发布/订阅不会存储消息。消息送达后会立刻从频道中移除。

2. 交付说明：

• Redis 为已连接的订阅者提供最多一次的投递。
• 如果在发送消息时没有订阅者处于连接状态，消息将丢失且不会被再次投递。
• 随着订阅者数量的增加，Redis 发布订阅功能可能会因必须在删除消息之前将其投递给所有订阅者而导致性能下降。

• 实时、低延迟的消息传递：适用于需要即时传递且仅在发送时相关的消息（例如聊天应用、股票行情更新）。
• 消息丢失可接受的应用：适用于消息丢失可接受的情况，如实时分析、通知等。
• 间歇性连接：适用于频繁连接和断开的移动物联网设备（如智能手机、平板电脑等），消息丢失不会造成关键影响。

• 消息不持久化：如果订阅者断开连接，他们将错过这段时间内发送的所有消息。
• 可扩展性问题：随着订阅者数量的增多，性能会下降，因为推送消息给所有已连接的客户端。
• 单线程代理：Redis 大多是单线程的，除非通过增加节点来扩展，否则会限制其并发处理能力。

虽然这两个系统都支持发布-订阅模型，Apache Kafka 在可扩展性、持久性和可靠性上与 Redis 的发布/订阅相比具有显著的不同。我们来看看它们的关键特性：

1. 消息发送与接收：

• Redis 发布订阅：仅将消息发送给当前已连接的订阅者，且不具有持久性。消息一旦被发送，就会从频道中删除，不再保留。
• Kafka：消息存储在磁盘上，允许消费者重新读取。即使消费者离线一段时间，Kafka 仍能确保消息的可靠和持久性传递。

2. 可扩展性：

• Redis ：由于其单线程架构，可扩展性有限。当订阅者数量增多时，Redis 的性能会变差。
• Kafka ：Kafka 被设计用于处理高吞吐量和可扩展性。Kafka 通过使用分区和消费者组来高效处理高并发和均衡负载。

3. 延迟：

• Redis ：提供低延迟的消息传递，特别是在订阅者数量较少的情况下。消息通常在毫秒级内送达。
• Kafka ：一般来说，比 Redis 具有更高的延迟，但更适合大规模且持久的消息系统。典型的延迟在几毫秒的范围内，更适合大规模事件处理。

4. 耐用性，和值得信赖性

• Redis ：Redis 的发布订阅机制是一个 内存中的 系统，这意味着消息没有持久性。如果 Redis 崩溃或订阅者掉线，消息将会丢失。
• Kafka ：Kafka 通过将消息存储在磁盘并跨代理复制，提供了 高度持久性 。这确保了即使在故障期间也不会丢失任何数据。

5. 吞吐量

• Redis : 可以通过消息管道来提高吞吐量，但会增加延迟时间。但由于其单线程的特性，Redis 仍受限于此。
• Kafka : Kafka 在吞吐量方面表现出色，每秒可以处理数百万条消息，得益于其分区日志模型和消费者组的特性。它能够轻松处理高流量的数据流。

• 实时应用：非常适用于快速实时通信，其中消息存在时间较短（例如聊天应用、股票价格更新、游戏得分榜）。
• 容错系统：非常适用于可以容忍消息丢失的系统，例如分析仪表板或临时通知。

• 高性能系统：当你需要可靠和持久的消息传递时（例如金融交易处理、订单管理系统或日志收集）。
• 长时间处理消息：适合存储和重放消息，供消费者在稍后的时间处理数据（例如数据仓库、数据分析流程）。

1. 向多个订阅者重复投递

   Kafka支持多个消费者群组，确保每个组中的一个消费者接收到每条消息。每个消费者组独立处理这些消息。

2. 关键信息未传达

*Kafka 允许使用 可选的键。当没有提供键时，Kafka 会使用轮转分发算法将消息分布在每个消费组内的消费者之间。

3. 不可靠的消息传递

*Kafka 允许消费者从特定偏移量（offset）处查找（seek）消息，从而实现可靠的消息传递或跳过消息来追上进度。这对于追不上进度的消费者来说非常有用。

4. 低延迟通讯:

*Kafka 提供低延迟，一般来说在数十毫秒的范围内，但是设计用于高吞吐量和消息持久化，这可能会导致比 Redis 的发布订阅稍高的延迟。

5. 吞吐量 ：

Kafka 由于采用了分区日志模型和消费者组架构，在高吞吐量环境中表现出色，能处理分布在各个节点上的海量数据。

6. 耐久性和可靠性：

• Kafka 非常耐用，内置消息持久化、复制以及自动故障转移功能。Kafka Connect 通过自动重启失败的任务以提高可靠性，从而进一步提高系统的可靠性。

两者，Redis 发布订阅 和 Apache Kafka，各有优势，取决于使用场景。Redis 发布订阅非常适合低延迟、实时消息，并且需求简单且订阅者数量不多。另一方面而言，Kafka 专为高吞吐量、可靠且持久的消息传递设计，适用于大型分发系统的场景。

选择取决于你是否需要快速的实时沟通还是可靠且可扩展的消息处理。