做网站武汉下载百度到桌面
本内容是对知名性能评测博主 Anton Putra Redis Streams vs Pub/Sub: Performance 内容的翻译与整理, 有适当删减, 相关指标和结论以原作为准
在这个视频中，我们首先将介绍 Redis Streams 和 Redis Pub/Sub 之间的区别。然后，我们将在 AWS 上运行一个基准测试，对这两者的性能进行比较，测量它们的 延迟、吞吐量以及饱和度。
此外，我还会解释，如何通过单线程 Redis 实例，在仅使用一个 CPU 的虚拟机上，实现每秒超过 100 万条消息的处理能力。
比较
这两者之间最大的区别在于：Redis Pub/Sub 是完全无状态的。它就像一个无状态的代理。
消息只有在被发布到 Redis 主题（topic）时，消费者才能接收到。因此，如果没有消费者，或者消费者因某些原因崩溃了，当生产者把消息发送到没有监听者的主题时，这些消息将会永远丢失。
另一方面，Redis Streams 是一种独立的数据结构。当生产者发布消息时，这些消息会被放入队列中并存储在内存中。这样，即使消费者断开连接之后，也仍然可以读取这些消息。同时，你还可以创建消费者组来从同一个主题中读取消息。
测试
我在 AWS 上运行了所有的基准测试。可以看到，我为 Redis 使用了基于 Graviton 的中等配置实例，配备了 1 个 CPU 和 4GB 内存。
同时，我还创建了一个 EKS 集群，包含多个节点，用于运行客户端和监控组件。
好了，现在我们开始测试。首先，我将为 Redis Streams 和 Pub/Sub 各创建 1 个生产者和 1 个消费者。
我们将从每秒大约 1,000 条消息开始测试。你会立刻注意到，Redis Streams 在处理这个吞吐量时，占用了更多的 CPU。
这也可以理解，因为 Redis Streams 是一个持久化队列，而 Pub/Sub 只是一个无状态的代理，只提供最小功能来支持生产者和消费者。
虽然 Redis Streams 的延迟也更高一些，但两者的延迟都非常低，在 100 到 200 微秒之间。
我会将这个测试运行大约一分钟，然后我们来看每张图表的情况。
你可以看到一个趋势：Pub/Sub 非常轻量，能够处理更多的消息量。
在尝试达到最大吞吐量之前，让我们逐个分析图表：
- 首先是延迟图表，我们使用 p90 分位数来测量延迟。即使在这个级别下，延迟也非常低，不到 1 毫秒。
- 此时，我们每秒的请求数仅为 17,000，这还远没有达到最大吞吐量。
- 接下来是CPU 使用率图表。从 CPU 趋势可以看出，Streams 的吞吐量会明显更低。
- 然后是内存使用图表：
- Pub/Sub 不存储任何内容，因此内存使用量保持平稳；
- 而 Streams 中的消息不会自动过期，你需要手动删除这些消息，或者在发布消息时使用 MAXLEN 属性 来限制消息长度。
最终测试结果
接下来，我展示最终的测试结果：我尝试创建尽可能多的客户端，以实现 Streams 和 Pub/Sub 的最高吞吐量。
由于 Pub/Sub 是无状态的，我能够将吞吐量提升到每秒超过 100 万条消息，这是在一个 单线程、1 个 CPU 的 Redis 实例上完成的。
我认为目前没有其他方案可以接近这个水平。
而使用 Redis Streams，我最多只能实现 每秒约 54,000 个请求，这个结果是预期内的，并且对于单个实例来说也已经是一个非常不错的表现了。
因此，如果你能够容忍消息丢失，那你最好选择 Pub/Sub；如果不能容忍丢失，那就选择 Redis Streams。