Redis 流与 Kafka 流/NATS

Question

Redis 团队介绍新 Streams Redis 5.0 的数据类型。由于 Streams 乍一看很像 Kafka 主题，因此似乎很难找到使用它的真实示例。

在streams intro我们与 Kafka 流进行了比较:

1. 运行时消费者组处理。例如，如果三个消费者中的一个永久失效，Redis 将继续为第一个和第二个提供服务，因为现在我们只有两个逻辑分区(消费者)。
2. Redis 流速度更快。他们从内存中存储和操作，所以这一个是原样。

我们有一些与 Kafka、RabbitMq 和 NATS 相关的项目。现在我们正在深入研究 Redis 流，尝试将其用作“pre kafka 缓存”，并在某些情况下用作 Kafka/NATS 替代方案。现在最关键的一点是复制:

1. 使用 AOF 复制将所有数据存储在内存中。
2. 默认情况下，异步复制不会保证复制 XADD 命令或消费者组状态更改:在故障转移后，可能会丢失某些内容，具体取决于跟随者从主服务器接收数据的能力。这看起来像是要扼杀任何尝试高负载流的兴趣。
3. 由 Sentinel 或 Redis Cluster 操作的 Redis 故障转移过程仅执行最大努力检查以故障转移到最新的跟随者，并且在某些特定故障下可能会升级缺少某些数据的跟随者。

还有上限策略。 Redis Streams 的真正“上限资源”是内存，因此您要存储多少项或使用哪种上限策略并不那么重要。因此，每次您的消费者失败时，您都会遇到内存消耗峰值或消息因上限而丢失。

我们使用 Kafka 作为 RTB 投标程序前端，每秒处理约 1,100,000 条消息，负载约 120 字节。使用 Redis，我们在写入时消耗了大约 170 mb/sec 的内存，使用 512 gb RAM 服务器，我们已经写入“保留”大约 50 分钟的数据。因此，如果此时处理系统离线，我们就会崩溃。

您能否详细介绍一下 Redis Streams 在现实世界中的使用情况，并且在某些情况下您可能会尝试自己使用它？还是 Redis Streams 可以用于数据量不大的情况？

Answer 1

好久不见。这感觉像是属于 redis-db 邮件列表的讨论，但用例听起来很吸引人。

请注意，Redis Streams 无意成为 Kafka 的替代品 - 尽管它们有相似之处，但它们提供不同的属性和功能。关于复制的异步性质，您当然是正确的。至于扩展可用 RAM 的数量，您应该考虑使用集群并跨基于周期的键名称对您的流进行分区。