Cache-Aside是最稳妥易落地的缓存方案，读操作先查缓存（cache.get），未命中则查DB并用setex设TTL回填；写操作只更新DB后删缓存，不改变原有逻辑，天然规避一致性雪崩风险。
直接结论：用 cache.get() + cache.setex() 组合做 Cache-Aside 模式，是最稳妥、最易落地的方案；别一上来就搞写穿透或双删，90% 的 DB 负载问题靠它就能压下去。
为什么 Cache-Aside 是首选模式
它不改变原有数据库写逻辑，只在读路径加一层判断，出错不影响主流程。写操作仍走数据库，缓存只负责“读加速”，天然规避了数据一致性雪崩风险。
常见错误现象：cache.set("user:1001", data) 不设过期时间，导致脏数据长期滞留；或 cache.get() 返回 None 后没查 DB 就直接返回空，造成业务异常。
- 必须搭配
setex()或set(..., ex=3600)显式设置 TTL，避免缓存永久化 - 缓存 key 命名要带业务前缀（如
"user:"、"article:"），方便批量清理 - 读取时检查返回值类型：redis-py 默认返回
bytes，若没开decode_responses=True，json.loads()会报TypeError: expected string or bytes-like object
如何避免缓存穿透和击穿
穿透是查了根本不存在的 ID（比如恶意构造 user:-1），击穿是热点 key 过期瞬间大量请求涌向 DB。两者都会让缓存形同虚设。
立即学习“Python免费学习笔记（深入）”；
实际场景中，用户中心接口被刷、商品详情页大促开抢，都容易触发。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 对空结果也缓存：查 DB 返回
None时，写入cache.setex("user:999999", 60, "NULL")，后续请求 60 秒内直接返回空，不打 DB - 用互斥锁（如
cache.set("lock:user:1001", "1", nx=True, ex=5)）控制重建缓存的并发，只放行一个请求去查 DB - 热点 key 不依赖自然过期：改用后台定时任务刷新（比如每 3500 秒
setex()一次），避免集中失效
连接和序列化必须注意的坑
本地开发跑得通，一上生产就超时或乱码，八成是连接或编码配置没对齐。
典型错误信息：ConnectionError: Error 111 connecting to localhost:6379. Connection refused.（Redis 没启）、UnicodeDecodeError: 'utf-8' codec can't decode byte 0x80（没开 decode_responses 却当字符串用）。
- 生产环境务必用连接池：
pool = redis.ConnectionPool(host="...", port=6379, db=0, max_connections=20)，否则高并发下创建连接耗尽资源 -
decode_responses=True要全局统一：如果部分地方开了、部分没开，get()返回类型不一致，json.loads()会随机报错 - 敏感字段（如密码、token）绝不能进 Redis；缓存内容建议用
json.dumps(obj, separators=(',', ':'))压缩体积
缓存预热不是“可选项”，而是上线前必做动作
新服务发布、DB 表结构变更、大促前扩容后，不做预热等于把首波流量全扔给数据库——缓存命中率从 95% 直接掉到 5%，DB CPU 瞬间拉满。
最容易被忽略的是：预热脚本没加限流，自己先把 Redis 打挂了。
- 用
pipeline批量写入：pipe = cache.pipeline(); [pipe.setex(k, v, ttl) for ...]; pipe.execute()，比单条快 10 倍以上 - 预热数据源优先走离线导出（如从 DB 导出 CSV），别实时查线上 DB
- 加 sleep 控制 QPS，例如每写 100 条
time.sleep(0.1)，防止压垮 Redis 或下游
真正难的不是写几行 setex，而是想清楚哪些数据算“热点”、TTL 设多长才不会引发业务误判、空值缓存的生命周期怎么跟业务 SLA 对齐。这些没法靠模板代码解决，得看监控里 keyspace_hits 和 keyspace_misses 的比值说话。
