redis 加速 mysql 的核心是解决缓存更新时机、方式与可靠性问题；需按热点性、计算成本、容忍 stale 程度筛选缓存数据，优先 Cache Aside 策略，辅以精准 key 管理、TTL 兜底及 binlog 最终一致性方案。
用 redis 加速 MySQL，核心不是简单加一层缓存，而是解决“数据什么时候更新、怎么更新、更新是否可靠”的问题。缓存快，但脏数据比慢更致命；MySQL 稳，但扛不住高频读。两者配合的关键，在于设计合理的缓存生命周期与一致性策略。
缓存哪些数据？优先级要分清
不是所有 MySQL 查询都值得缓存。重点缓存：
- 读多写少的热点数据：比如商品详情、用户资料、配置项、排行榜前100名
- 计算开销大的结果：关联多表、含 GROUP BY / ORDER BY / LIMIT 的聚合查询（缓存结果集，而非 SQL）
- 允许短时 stale 的数据：如文章阅读数、评论总数，延迟几秒更新无感
避免缓存：red”>频繁变更的字段（如库存余额）、强事务一致要求的数据（如支付状态）、单次查询极快的主键查（走索引已足够快）。
缓存更新策略选对才不翻车
常见三种方式，适用场景不同：
- Cache Aside（旁路缓存）——最常用也最可控：
读：先查 Redis，命中返回；未命中则查 MySQL，写入 Redis 后返回。
写：先更新 MySQL，再删 Redis 中对应 key（不是更新！删掉让下次读自动重建）。
✅ 优点：逻辑清晰、兼容性强、不易缓存与 DB 长期不一致。
⚠️ 注意：删除失败需有补偿（如发 MQ 重试），并发写时可能短暂出现旧值（可加分布式锁或延时双删缓解） - Read/Write Through —— 适合封装统一数据访问层：
由缓存服务代理读写，应用只和 Redis 交互，Redis 自己负责同步后端 MySQL。
✅ 优点：业务代码干净。
❌ 缺点：实现复杂、Redis 扩展性受限、故障时降级困难 - Write Behind（回写）——慎用：
写操作只落 Redis，异步批量刷回 MySQL。
⚠️ 风险高：Redis 故障会导致数据丢失；不适合金融、订单等强一致性场景
保证一致性的关键细节
策略选对只是开始，落地时这几个点常被忽略：
- 删除 key 要精准：不要用模糊匹配 DEL user:*，而应根据业务生成确定 key，如 user:12345:profile；关联数据（如用户订单列表）也要同步清理相关 key（如 order:list:12345）
- 设置合理过期时间（TTL）作为兜底：即使删除失败，TTL 也能让脏数据自动失效。建议设为业务可接受的 stale 时间 + 少量缓冲（如 10 分钟）
- 避免缓存穿透、击穿、雪崩：
穿透：用布隆过滤器拦截非法 ID 查询；
击穿：热点 key 加互斥锁（SETNX）或逻辑过期；
雪崩：给 TTL 加随机偏移（如 3600±300 秒） - 监控缓存命中率 & 数据差值：命中率长期低于 80% 要检查 key 设计；定期抽样比对 Redis 和 MySQL 中同一条记录的字段值，及时发现静默不一致
进阶：用 binlog 实现最终一致性
当业务对一致性要求极高，又无法接受 Cache Aside 的窗口期时，可引入 MySQL binlog：
- 用 canal / maxwell 监听 MySQL 变更日志
- 解析后投递到消息队列（如 kafka）
- 消费者服务收到消息，执行对应的 Redis 删除或更新操作
✅ 优势：解耦、可靠、支持重放、天然支持多级缓存同步
⚠️ 成本：架构变重，需维护中间件和消费逻辑；延迟通常在百毫秒级，仍是最终一致