Kafka 和 Redis 之间有何区别？
Redis 是内存中的键值数据存储，而 Apache Kafka 是流处理引擎。但是，这两种技术的可比性在于两者都可用于创建发布-订阅（pub/sub）消息传递系统。在现代云架构中，应用程序被分解为多个规模较小且独立的构建块，称为服务。Pub/sub 消息收发可以为这些分布式系统提供即时事件通知。Kafka 支持基于拉取的系统，在这种系统中，发布者和订阅者共享一个公共消息队列，订阅者根据需要从中提取消息。Redis 支持基于推送的系统，其中发布者在事件发生时向所有订阅者分发消息。
工作原理：Kafka 与Redis 发布/订阅
Apache Kafka 是事件流式传输平台，可让多个应用程序相互独立地流式传输数据。这些应用程序称为生产者和使用者，用于向某些数据分区（称为主题）发布和订阅信息。
同时，Redis 设计为内存数据库，支持应用程序之间的低延迟数据传输。Redis 将所有消息存储在 RAM（而非硬盘）上，以减少数据读取和写入时间。类似于 Kafka，多个使用者可以订阅 Redis 流来检索消息。
尽管可以将两者都用于发布/订阅消息收发，但 Kafka 和 Redis 的工作原理有所不同。
Kafka 工作流程
Apache Kafka 通过计算集群连接生产者和使用者。每个集群由驻留在不同服务器上的多个 Kafka 代理组成。
Kafka 出于以下目的创建主题和分区：
- 主题用于对属于感兴趣主旨（例如电子邮件、付款、用户和购买）的类似数据进行分组
- 跨不同代理进行分区以实现数据复制和容错
生产者向代理发布消息。当代理收到消息时，它会将数据归类为一个主题，并将数据存储在分区中。使用者连接到相关主题并从其分区中提取数据。
Redis 工作流程
Redis 使用作为 NoSQL 数据库系统的客户端-服务器架构运行。生产者和使用者之间采用松散耦合的架构，在发送消息时不必彼此了解。
Redis 将密钥和主要-辅助节点用于以下目的：
- 密钥用于对类似消息进行分组。例如，“电子邮件”是指向仅保存电子邮件消息的数据存储的密钥。
- 主要-辅助节点用于消息复制。
当生产者向特定节点发送消息时，Redis 会通过检查消息密钥将消息传送给所有连接的订阅者。使用者必须始终启动并保持与 Redis 服务器的活跃连接，才能接收消息。这称为连接式传送语义。
消息处理：Kafka 与Redis 发布/订阅
Apache Kafka 为开发人员提供高度可扩展的分布式消息收发系统。同时，Redis 提供丰富的数据结构，可让应用程序将数据快速推送到多个节点。这两个系统的消息排队机制存在一些区别。
消息大小
在使用者和订阅者之间发送小型数据包时，Kafka 和 Redis 可提供最佳性能。
特别是，Redis 并非设计为处理处理大数据量而不影响吞吐量。Redis 也无法存储大量数据，因为 RAM 的容量小于磁盘存储空间。
与此同时，Kafka 可以支持相当大的消息，尽管其并非专门为此目的而构建。如果 Kafka 压缩消息并将其配置为分层存储，则它可以处理最大 1 GB 的消息。Kafka 不是将所有消息存储在本地存储器中，而是使用远程存储来存储已完成的日志文件。
消息传输
Kafka 使用者从消息队列中拉取数据。每个 Kafka 使用者都会使用偏移跟踪其读取的消息，并更新该偏移以检索后续消息。使用者可以检测和跟踪重复的消息。
另一方面，Redis 会自动将消息推送给连接的订阅者。Redis 订阅者被动地等待从服务器引导给它们的传入消息。由于采用最多一次的传送设置，因此 Redis 订阅者无法检测到重复的消息。
消息保留
Kafka 会在使用者阅读消息后将其保留。因此，如果客户端应用程序丢失已检索的数据，它可以从其订阅的分区再次请求该数据。通过设置消息保留策略，用户可以确定 Kafka 将数据保留多长时间。
相反，Redis 不会在消息传送后进行存储。如果没有订阅者连接到流，Redis 会丢弃这些消息。即使订阅者稍后连接到 Redis，也无法恢复丢弃的消息。
错误处理
Kafka 和 Redis 都可让应用程序缓解不可靠的消息传送风险，但它们的处理方式有所不同。
Redis 中的错误处理侧重于客户端应用程序和 Redis 服务之间的交互。借助 Redis，开发人员可以解决客户端超时、内存缓冲区容量超出以及最大客户端限制等情况。由于其采用键值对数据库架构，Redis 无法像 Kafka 那样提供强大的消息错误处理。
Kafka 开发人员可以将错误事件存储在死信队列中，重试或重定向这些事件，以便将消息一致地传送到客户端应用程序。开发人员还可以使用 Kafka Connect API，在出现某些错误时自动重新启动连接器任务。
性能差异：Kafka 与Redis 发布/订阅
总体而言，Apache Kafka 在发布/订阅消息收发方面的表现优于 Redis，因为 Kafka 是专门为数据流式传输而设计的。在 Redis 可处理的几种不同使用案例中，我们无法使用 Kafka。
并行性
并行性是指多个使用者能够同时接收同一条消息。
Redis 不支持并行性。
另一方面，Kafka 允许将同一条消息同时分发给多个使用者。 通常，Kafka 使用者组中的使用者轮流从分区检索新消息。如果多个使用者组中只有一个使用者，则该使用者会检索所有消息。通过利用此设置和分区复制，您可以在每个分区副本上为每个使用者组分配一个使用者。这可让所有使用者检索类似的消息序列。
吞吐量
吞吐量衡量每个系统每秒可以处理的消息数量。
Kafka 的吞吐量通常高于 Redis 发布/订阅。Kafka 可处理更多的数据，因为它不必等待每个订阅者收到消息，即可转移到另一个订阅者。相反，Kafka 将当前消息存储在内存缓存和存储器上，从而优化读取速度。
但是，如果使用者检索消息的速度不够快，Kafka 的性能可能会降低，因为缓存中的未读取消息最终会被移除。在这种情况下，使用者必须从磁盘读取，从而降低速度。
同时，Redis 必须等待每个使用者的确认，在有更多连接节点时会显著降低吞吐量。解决方法是使用名为管道的流程发送多个请求，但这可以降低其消息收发延迟。
延迟
Kafka 和 Redis 都适用于低延迟的数据处理。Redis 提供较短的消息收发时间（以毫秒为单位），而 Kafka 的平均消息收发时间为数十毫秒。
考虑到 Redis 主要在 RAM 上读取和写入数据，它的处理速度自然要快于 Kafka。但是，Redis 在处理较大的消息时可能无法保持超低延迟的数据操作。同时，Kafka 需要更多时间在不同的物理驱动器上复制分区以实现数据持久性，这会增加消息传送时间的开销。
可以优化 Redis 和 Kafka 的延迟，但必须谨慎行事。例如，您可以压缩 Kafka 消息以降低延迟，但生产者和使用者需要更多时间来解压缩这些消息。
Redis 中的延迟可能由多种因素引起，包括操作环境、网络操作、缓慢执行的命令或分叉。为了降低分叉延迟，Redis 建议在基于硬件虚拟机（HVM）的现代 EC2 实例上运行发布/订阅传送系统。
容错能力
Kafka 将所有数据写入领先代理的存储磁盘，然后在不同的服务器上进行复制。当服务器出现故障时，多个订阅者会从备份分区检索数据。
与 Kafka 不同，Redis 默认不备份数据，并且用户必须手动启用该功能。Redis 使用内存中数据存储，在计算机断电时会丢失所有数据。为了避免数据丢失，开发人员开启 Redis 数据库（RDB）持久性，定期捕获 RAM 数据的快照并将其存储在磁盘上。
使用时机：Kafka 与Redis 发布/订阅
Apache Kafka 是构建流式传输大型数据集且需要高可恢复性的应用程序的更理想选择。Kafka 最初作为单一的分布式数据管道开发，能够处理数万亿条传递的消息。Kafka 在不同的服务器上复制分区，以防止节点出现故障时丢失数据。组织使用 Kafka 来支持应用程序、移动物联网（IoT）设备和微服务之间的实时通信。Kafka 也是日志聚合、流处理和其他基于云的数据集成任务的更理想选择。
同时，Redis 为需要即时数据传输但允许少量数据丢失的应用程序提供超低延迟的事件分发。Redis 通常用作会话缓存，用于存储经常访问的数据或传送紧急消息。Redis 还适用于存储游戏、电子商务或社交媒体数据，以提供更流畅的用户体验。
差异摘要：Kafka 与Redis 发布/订阅
| Apache Kafka |
Redis |
|
| 消息大小 |
通过压缩和分层存储，支持最大 1 GB 的消息大小。 |
支持较小的消息大小。 |
| 消息传输 |
订阅者从队列中拉取消息。 |
Redis 服务器向连接的订阅者推送消息。 |
| 消息保留 |
检索后保留消息。 |
不保留消息。 |
| 错误处理 |
消息收发级别的强大错误处理。死信队列、事件重试和重定向。 |
您必须在应用程序级别处理 Redis 异常，包括超时、客户端限制和内存缓冲容量。 |
| 并行性 |
Kafka 支持并行性。多个使用者可以同时检索同一条消息。 |
不支持并行性。 |
| 吞吐量 |
由于采用异步读/写，吞吐量较高。 |
由于 Redis 服务器在向其他订阅者发送消息之前需要等待回复，吞吐量较低。 |
| 延迟 |
低延迟。由于默认会进行数据复制，因此比 Redis 稍慢一些。 |
分发较小的消息时延迟极低。 |
| 容错能力 |
自动将分区备份到不同的代理。 |
默认情况下不备份。用户可以手动启用 Redis 持久性。存在少量数据丢失的风险。 |
AWS 如何支持您的 Kafka 和 Redis 要求？
Amazon Web Services（AWS）提供可扩展的托管基础设施，以支持您的发布-订阅（pub/sub）消息收发需求。
使用 Amazon Managed Streaming for Apache Kafka（Amazon MSK），可以轻松地实时提取和处理大量数据。可以构建私有访问的数据总线，以大规模提供高可用性的流式传输节点。还可以无缝连接其他 AWS 服务，例如 AWS IoT Core、Amazon Virtual Private Cloud (Amazon VPC) 和适用于 Apache Flink 的亚马逊托管服务。
使用 Amazon MemoryDB 为 Redis 工作负载提供高可用性的内存存储。可以运行高并发流式传输数据源来提取用户活动。此外，每天可以支持数百万个媒体和娱乐应用程序请求。
除了使用 Redis 或 Kafka 之外，还可以使用 Amazon Simple Notification Service（Amazon SNS）来构建发布/订阅消息收发系统。可以在自己的应用程序中以可扩展而且经济高效的方式直接发送消息给客户或其他应用程序。Amazon SNS 提供多项功能，例如：
- 分布式系统、微服务和事件驱动型无服务器应用程序之间的高吞吐量、基于推送的多对多消息收发。
- 消息加密和流量隐私。
- 跨 AWS 类别的扇出功能。这些功能包括分析、计算、容器、数据库、物联网（IoT）、机器学习（ML）、安全和存储。
立即创建账户，开始在 AWS 上使用发布/订阅、Redis 和 Kafka。
