我是否遗漏了什么，或者没有办法使用 Redis 流产生背压？如果生产者将数据推送到流中，消费者可以更快地消费它，则没有明显的方法可以向生产者发出信号表明它应该停止或放慢速度。
我预计会有XADD 的阻塞版本，它会阻塞客户端，直到空间在有上限的流中可用（类似于XREAD 的阻塞版本，它允许消费者等待数据可用） ，但似乎并非如此。
人们如何处理上述情况 - 向生产者发出信号，表示它应该推迟向流中添加更多项目？
据我了解，Kafka 等一些数据流系统不需要背压，但 Redis 似乎没有可比的解决方案，而且对于许多 Redis 流用例来说，这似乎是一个相对常见的问题。
【问题讨论】：
如果您启用了持久性（RDB 或 AOF），您的流消息将被持久化，因此不需要背压。
而且，如果您使用副本，您将获得另一个级别的冗余。
只有当 Redis 没有足够的内存（或副本的网络带宽不足）来保存消息时，才需要背压。
而且，老实说，我从未见过这种情况。
【讨论】：
你为什么想要？除非你的内存用完了，否则这不是问题，每个消费者都可以在闲暇时阅读。
请注意，不要使用仅通过 XADD 发布的消费者组，而读者通过 XRANGE 通过存储在更接近 Kafka 的键中的位置读取。每个分区使用一个流。
生产者可以检查表大小是否每 1K 消息（通过 XLEN）变得太大而无法减速，如果这是一个问题，并且你不能向它扔硬件 5 个节点，每个节点 20 Gig 非常容易，因为流分布在集群..不明白这应该很容易，所以我可能遗漏了一些东西。
还有一个 XADD 版本可以修剪表格的大小，以确保您不会过度填充上面的内容，但这个世界需要一些非常极端的东西。对我们来说，对于发送最新状态的频繁内容来说，这值得 2 天，而对于其他人来说，这需要 9 个月。
另一件事不要在流中存储大消息，使用 blob 或单独的密钥/存储。
【讨论】：