Redis Streams vs Kafka Streams/NATS

Question

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

在流介绍中,我们与Kafka流进行了比较:

1. 运行时使用者组处理.例如,如果三个cosumer中的一个永久失败,Redis将继续服务第一和第二因为现在我们只有两个逻辑分区(消费者).
2. Redis流更快.它们从存储器中存储和操作,因此这是一个案例.

我们与Kafka,RabbitMq和NATS有一些项目.现在我们深入研究Redis流,尝试将其用作"pre kafka cache",在某些情况下使用Kafka/NATS替代方案.现在最关键的一点是复制:

1. 使用AOF复制将所有数据存储在内存中.
2. 默认情况下,异步复制不保证复制XADD命令或使用者组状态更改:在故障转移之后,可能会丢失某些内容,具体取决于从服务器从主服务器接收数据的能力.这个看起来像杀死任何兴趣尝试高负荷流.
3. 由Sentinel或Redis群集运行的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 量，您应该考虑使用集群并跨基于周期的键名对流进行分区。