20

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

在流介绍中，我们与 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/秒的内存，使用 512 GB RAM 服务器，我们为约 50 分钟的数据写入“保留”。因此，如果此时处理系统处于脱机状态，我们就会崩溃。

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

4

1 回答 1

5

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

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

于 2018-10-25T21:52:05.797 回答