Redis Streams vs Kafka Streams/NAT

Question

Redis团队为Redis 5.0引入了新的Streams数据类型。由于Streams从第一视角看起来像Kafka主题，因此似乎很难找到使用它的真实世界示例。

在streams intro中，我们与Kafka streams进行了比较：

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

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

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

和上限策略。Redis Streams真正的“上限资源”是内存，所以你想存储多少项或者你使用哪种上限策略并不重要。因此，每次消费者失败时，您将获得内存消耗峰值或消息丢失上限。

我们使用Kafka作为RTB投标人前端，每秒处理约1,100,000条消息，有效载荷约为120字节。使用Redis，我们在写入时有大约170 mb/秒的内存消耗，使用512 gb内存服务器，我们有大约50分钟的数据写入“储备”。因此，如果处理系统在此期间脱机，我们将崩溃。

你们能告诉我更多关于Redis Streams在现实世界中的使用情况吗？也许你们自己也在尝试使用它？或者Redis Streams是否可以用于数据量不大的情况？

Answer 1

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

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