Redis 缓存实战：用好了效率提升

一、先说标准姿势：Cache Aside

业界最通用的就是"旁路缓存"——读时先查缓存，没有再查库并回写；写时先更库，再删缓存（不是更缓存，避免并发下脏数据）：

读：缓存有 → 返回；缓存无 → 查 DB → 写入缓存 → 返回
写：更新 DB → 删除缓存（下次读自动重建）

为什么删除而不是更新缓存？因为并发写时，谁先谁后不确定，删缓存最省心，反正下次读会重建。

二、三个经典翻车现场

三、过期时间一定打散

这是最容易被忽略、却最能救命的一点。如果所有缓存都设 1 小时，到点一起失效，DB 瞬间被压垮：

// 伪代码：基础 1 小时 + 随机 0~10 分钟
int ttl = 3600 + new Random().nextInt(600);
redis.set(key, value, ttl, TimeUnit.SECONDS);

四、别把 Redis 当数据库

Redis 是缓存，默认持久化未必及时。重要数据该落库的落库，缓存只加速读取。我见过有人把订单状态只放 Redis，一重启全丢，对账对到崩溃。

五、其他的选择

自己搭 Redis 要管主从、哨兵、扩容；嫌麻烦可以直接用华为云 GaussDB(for Redis)，兼容 Redis 协议，容量和可靠性交给平台。用法和原生 Redis 一模一样，上面那些坑照样要避开，只是运维省了。