本内容是对知名性能评测博主 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。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。