Redis不再独领风骚:揭秘Python缓存新选择

Redis 一直是 Python 缓存的首选。处理 API 响应、数据库提速、会话管理、速率限制，Redis 似乎无所不能。然而最近测试了四种缓存工具，使用相同的 FastAPI 应用、相同的工作负载、相同的硬件，在真实的生产环境中。

结果出人意料，Redis 并没有一骑绝尘。

下面我们来看看实际表现更佳的工具，以及它为何对你的技术栈至关重要。

测试环境

我们的应用程序是一个 FastAPI 服务，需要满足三个缓存需求：对昂贵的 API 端点进行响应缓存，存储已认证用户的会话，以及在公共端点上进行速率限制。

我测试了每个工具在这三个场景下的表现，并跟踪了四个关键指标：在 500 个并发请求下的吞吐量、每个缓存操作的平均延迟、每 100,000 个缓存项目使用的内存，以及从零开始工作所需的时间。

Redis

Redis 是全球部署最广泛的内存中数据存储系统。它支持字符串、哈希、列表、集合、有序集合等多种数据结构，已经在生产环境中稳定运行超过十五年。

「配置：」

import redis.asyncio as redisfrom fastapi import FastAPIapp = FastAPI()cache = redis.from_url("redis://localhost", decode_responses=True)@app.get("/products/{product_id}")asyncdefget_product(product_id: int):    cached = await cache.get(f"product:{product_id}")if cached:return json.loads(cached)    product = await fetch_from_db(product_id)await cache.setex(f"product:{product_id}", 300, json.dumps(product))return product

「500 个并发请求下的性能表现：」 平均延迟：每次操作 0.8 毫秒，吞吐量：每秒 142,000 次操作，每 100K 项目内存：48MB

「优点：」

Redis 在每个场景中都表现出色。响应缓存、会话存储、速率限制都可靠地工作。Python 库的生态系统成熟，每个边缘情况都有文档记录。

「不足之处：」

Redis 需要单独的服务器进程，对于小型应用或开发环境，运行和维护 Redis 实例增加了操作开销。连接池需要仔细配置。在极高并发下，我遇到了连接限制问题，需要调整。

「设置工作时间：」 15 分钟。

「结论：」 可靠、快速、经过实战考验。操作开销是唯一的真正成本。

Memcached

Memcached 是 Redis 的老对手，以其简单的数据模型、简单的操作和在简单键值操作上的原始速度而闻名。

「配置：」

from aiomcache import Clientcache = Client("127.0.0.1", 11211)@app.get("/products/{product_id}")asyncdefget_product(product_id: int):    key = f"product:{product_id}".encode()    cached = await cache.get(key)if cached:return json.loads(cached)    product = await fetch_from_db(product_id)await cache.set(key, json.dumps(product).encode(), exptime=300)return product

「500 个并发请求下的性能表现：」 平均延迟：每次操作 0.6 毫秒，吞吐量：每秒 168,000 次操作，每 100K 项目内存：31MB

「优点：」

Memcached 在纯键值操作上比 Redis 快，且使用的内存更少。如果你的缓存需求简单，并且你想要在基本的获取和设置操作上获得最大吞吐量，Memcached 在原始数字上获胜。

「不足之处：」

没有对复杂数据结构的原生支持。会话存储需要将所有内容序列化为字符串。速率限制需要我自己实现逻辑，因为 Memcached 没有带有过期的原子增量。没有持久性意味着重新启动会清除一切。这些限制使其不适合我的三个测试场景中的两个。

「设置工作时间：」 20 分钟，包括解决限制。

「结论：」 在简单情况下比 Redis 快。对于有多样化缓存需求的生产应用程序来说太有限了。

DragonflyDB

DragonflyDB 是一个与 Redis 兼容的内存中存储，被设计为现代的 Redis 替代品。它与 Redis 客户端和命令完全兼容，但是构建在不同的架构上，声称具有 25 倍更好的内存效率和更高的吞吐量。

我包括它是因为预期营销声明不会成立。我错了。

「配置：」

import redis.asyncio as rediscache = redis.from_url("redis://localhost:6379", decode_responses=True)

这是整个设置变化。DragonflyDB 讲 Redis 协议，所以每个现有的 Redis 客户端都可以在不做修改的情况下工作。在现有应用程序中用 DragonflyDB 替换 Redis 只需要在你的配置中更改一行。

「500 个并发请求下的性能表现：」 平均延迟：每次操作 0.5 毫秒，吞吐量：每秒 198,000 次操作，每 100K 项目内存：19MB

「优点：」

DragonflyDB 在每个指标上都超过了 Redis。延迟低 39%，吞吐量高 39%，内存使用低 60%。所有三个测试场景都正确工作，因为它支持完整的 Redis 命令集。

内存效率差异在生产中最为重要。Redis 每 100,000 个项目使用 48MB 与 DragonflyDB 使用 19MB 相比，意味着你可以在相同的硬件上缓存更多的数据。

「不足之处：」

DragonflyDB 比 Redis 新。监控工具、调试指南和生产经验的故事的生态系统更小。我在集群模式下遇到了一个边缘情况，文档很少，需要直接支持。

「设置工作时间：」 12 分钟。比 Redis 快，因为客户端是相同的。

「结论：」 在每个可衡量的指标上都超过了 Redis，客户端代码无需更改。成熟度差距是唯一不立即切换的原因。

Cashews

Cashews 是一个专门为异步 Python 应用程序构建的 Python 缓存库。它包装了任何后端，包括 Redis、内存和磁盘，使用基于装饰器的 API，消除了大部分样板代码。

「配置：」

from cashews import cachecache.setup("redis://localhost")@app.get("/products/{product_id}")@cache(ttl="5m", key="product:{product_id}")asyncdefget_product(product_id: int):returnawait fetch_from_db(product_id)

整个端点的缓存逻辑就是一个装饰器。没有手动获取、设置或序列化。没有键构造。没有 TTL 管理。装饰器处理一切。

「500 个并发请求下的性能表现：」 平均延迟：每次操作 0.9 毫秒，吞吐量：每秒 128,000 次操作，每 100K 项目内存：取决于后端

「优点：」

Cashews 消除了我代码库中 80% 的缓存样板代码。以前需要 8 行手动缓存管理的端点变成了 1 行。装饰器模式是干净的，缓存失效 API 是四个测试工具中最友好的。

按模式缓存失效特别有用：

await cache.delete_match("product:*")

一行代码使所有缓存的产品失效。使用原始 Redis，这需要一个 SCAN 操作和多个 DEL 调用。

「不足之处：」

Cashews 是一个抽象层，不是一个缓存本身。它仍然需要 Redis 或另一个后端。由于抽象开销，性能略低于直接 Redis。对于原始缓存吞吐量是瓶颈的应用程序，开销很重要。

「设置工作时间：」 8 分钟。四个中最快的。

「结论：」 四个工具中最好的开发体验。在 DragonflyDB 上使用它，以获得性能和人体工程学的双重优势。

结果

原始性能数字：

吞吐量：DragonflyDB 198K ops/sec，Memcached 168K，Redis 142K，Cashews 128K

延迟：DragonflyDB 0.5ms，Memcached 0.6ms，Redis 0.8ms，Cashews 0.9ms

每 100K 项目内存：DragonflyDB 19MB，Memcached 31MB，Redis 48MB，Cashews 取决于后端

开发体验：Cashews 最好，Redis 好，DragonflyDB 好，Memcached 最差

生产成熟度：Redis 最好，Memcached 好，DragonflyDB 成长中，Cashews 新

为什么 Redis 没有赢

Redis 不慢。它不坏。它在这次比较中输了，因为 DragonflyDB 在客观上更快、更节省内存，同时完全兼容，而 Cashews 为异步 Python 应用程序提供了更好的开发体验。

“为什么不直接使用 Redis”的答案是 Redis 不错。是因为在 Redis 上构建和围绕 Redis 构建的工具在对现代 Python 应用程序重要的特定维度上超越了它。

我现在使用什么

对于新项目，我使用 DragonflyDB 作为后端，Cashews 作为 Python 接口。DragonflyDB 处理性能和内存效率。Cashews 处理开发体验。这种组合比 Redis 提供了更好的性能，比原始 Redis 客户端代码提供了更好的人体工程学。

对于已经运行 Redis 的现有项目，切换到 DragonflyDB 确实值得评估。客户端代码不变。性能提升是可衡量的。主要成本是对新工具的操作不熟悉。