Redis 缓存怎么用？TTL、过期策略与数据可靠性

Redis 不是关系数据库的同义替代

Redis 的键值与数据结构适合低延迟访问。把它用作缓存时，数据的权威来源通常仍是数据库；把它用来保存不能丢失的业务状态时，就必须认真设计持久化、备份、复制与故障恢复。两种用途的容错要求不同。

缓存一个查询结果的基本流程

1. 收到请求，先按可预测的 key 查 Redis。
2. 没有命中时查询数据库，把结果写回缓存并设置 TTL。
3. 更新原始数据时删除或更新对应缓存，避免旧结果长期存在。
4. 观察命中率、内存用量和过期行为，不能只看响应时间。

TTL 和淘汰策略不是一回事

TTL 表示键的过期时间，可以通过 EXPIRE 设置。内存达到限制时是否淘汰键，还取决于实例配置的内存策略。将“所有键都会自动过期”当作默认前提，容易造成缓存无限增长。

自己运维还是托管

自行管理要负责更新、监控与恢复。Redis Cloud 等托管方案可减轻部分基础设施工作，但访问控制、数据结构、命中率与成本仍需团队负责。

一次可观察的缓存过期实验

在隔离的本地测试实例里执行下面三条命令，观察一个缓存键如何设置和过期。这不是生产配置示例，切勿在不清楚影响时修改线上实例。

SET demo:article:42 "cached result" EX 30
TTL demo:article:42
GET demo:article:42

SET ... EX 30 为键设置 30 秒过期时间；TTL 返回剩余秒数。约 30 秒后再次 GET，预期结果是空值。这个实验能确认“过期”与数据库原始记录是两回事。

内存满了要看哪三个配置

实际排查先观察 INFO memory 的使用量、配置的 maxmemory，再确认 maxmemory-policy。设置了 TTL，不代表 Redis 在内存不足时一定会按你期望的方式淘汰键：不同策略可能回收键，也可能拒绝新的写入。服务必须容忍缓存未命中或写入失败，不能把缓存当成唯一数据来源。