读写分离场景下，缓存层与数据库的关系是各司其职：缓存负责拦截高频读请求，数据库负责写操作与数据兜底，二者通过一套明确的更新策略保持最终一致。这套配合打好了，系统扛得住流量高峰，数据也不会乱套，本文直接拆解配合细节、踩坑点和落地步骤。
读写分离后，缓存和数据库的分工界限在哪
读写分离架构下，主库扛写、从库扛读，这是常规操作，但把从库直接暴露给业务层，隐患不小从库延迟、连接数被打满、大查询拖垮实例，缓存层介入后，分工变成三层：业务请求先打缓存，缓存未命中再查从库，写操作直连主库。
具体分工如下：
- 缓存层：承接热点数据的读流量，目标是把读请求的命中率维持在较高水位,减少底层数据库的压力。
- 从库：负责缓存未命中时的数据回源,以及一些无法缓存的大范围查询。
- 主库：只处理写操作，以及强一致性的读需求（比如订单支付状态）。
这里有个容易混淆的点：缓存不是用来替代从库的，从库承担的是"兜底读"，缓存承担的是"高频读"，如果缓存命中率低，所有请求穿透到从库，从库照样会被打垮,读写分离的意义就失去了。
读写分离缓存和数据库怎么配合：一条请求的完整路径
用一个具体场景说明，用户查看商品详情页,请求到达后端服务：
- 先查Redis，若存在则直接返回,走完整个流程。
- Redis未命中,查询从库获取商品数据。
- 将查询结果写入Redis，设置过期时间（比如30分钟）。
- 返回数据给前端。
写操作路径则不同：
- 业务请求直接写主库。
- 主库同步数据到从库（这一步有延迟，通常毫秒级）。
- 服务层主动删除Redis中对应的缓存key,而不是更新缓存。
- 下一次读请求发现缓存缺失，回源从库,再把新数据加载进缓存。
这套流程就是业内常说的Cache Aside模式，行业共识认为，这是读写分离场景下最稳妥的缓存配合方式，核心逻辑就一句话：读的时候先看缓存，写的时候只写库然后删缓存。
缓存与数据库一致性方案对比：更新缓存还是删除缓存
读写分离场景里，最大的坑是缓存和数据库数据不一致，先更新缓存还是先更新数据库，顺序错了就会出问题,对比几种常见方案：
| 方案 | 操作顺序 | 风险点 | 适用场景 |
|---|---|---|---|
| 先更新数据库，再删除缓存 | 写库 → 删缓存 | 删缓存失败会短暂脏读 | 绝大多数业务，配合重试机制 |
| 先删除缓存，再更新数据库 | 删缓存 → 写库 | 写库前有读请求会回源旧数据 | 不推荐，并发下容易脏读 |
| 延迟双删 | 删缓存 → 写库 → 休眠 → 再删缓存 | 实现复杂，休眠时间难把握 | 对一致性要求高的场景 |
| 订阅binlog异步删缓存 | 写库 → binlog → 消息队列 → 删缓存 | 引入额外组件，有延迟 | 大厂高并发标配 |
实际落地时，先更新数据库再删除缓存是最常见的做法，删缓存失败的问题，靠重试机制解决把删除操作丢进消息队列,失败自动重试。
读写分离缓存一致性方案，为什么推荐binlog订阅
读写分离有个特性：主从同步有延迟，即使主库写完马上删缓存，从库的数据可能还没更新，此时一个读请求过来，缓存缺失回源从库，读到的可能是旧数据，重新写回缓存后，脏数据就被"固化"了。
订阅binlog的异步删缓存方案能规避这个问题,流程是：
- 主库写入完成后,解析binlog变更事件。
- 将变更事件发送到消息队列（如RocketMQ、Kafka）。
- 消费端拿到消息后,延迟一小段时间再删除缓存。
- 此时从库大概率已经完成同步,删除缓存后的下一次回源能拿到新数据。
这个方案的优势在于不侵入业务代码，缓存删除逻辑和业务逻辑解耦，业界常用的工具是Canal，配合消息队列就能实现，如果团队技术储备足够,这是读写分离场景下最值得投入的一致性方案。
缓存穿透、击穿、雪崩：读写分离场景下的三种极端情况
缓存层和数据库配合，最怕的就是缓存失效瞬间，大量请求直接打到数据库，读写分离架构虽然分散了读压力,但极端情况下从库同样扛不住。
缓存穿透：查的数据根本不存在
用户查询一个不存在的商品ID，缓存没有，从库也没有，每次请求都穿透到数据库,攻击者可以利用这个漏洞打垮数据库。
解决思路：
- 缓存空值：从库查询结果为null时，也写入缓存，设置较短的过期时间（如5分钟）,防止恶意流量反复穿透。
- 布隆过滤器：启动时加载全量商品ID到布隆过滤器，请求先过过滤器，不存在的ID直接拦截,不再查询数据库。
对于读写分离架构，布隆过滤器更实用，因为从库的数据可能略有延迟，缓存空值在极端情况下会把"从库暂无数据"的状态也缓存住,影响后续正常请求。
缓存击穿：热点key过期瞬间
某个爆款商品的缓存正好过期，同一时刻大量用户请求这个商品，全部穿透到从库，从库连接数瞬间被打满,主从延迟加剧。
应对手段是互斥锁：当缓存未命中时，只允许一个请求去数据库回源，其他请求等待或直接返回旧值,实现方式：
- 缓存未命中时，尝试获取分布式锁（如Redis的SETNX）。
- 获取锁的请求执行回源和缓存重建。
- 未获取锁的请求sleep 50ms后重试查缓存，或者直接返回缓存的旧值（如果允许短暂不一致）。
缓存雪崩：大量key同时过期
缓存key设置了相同的过期时间，某一刻集体失效，所有请求同时打到从库，读写分离场景下,从库的读压力会瞬间翻倍。
解决思路：
- 过期时间加随机值：比如基础过期时间30分钟，再加上0到300秒的随机偏移,避免集体失效。
- 多级缓存：本地缓存（如Caffeine）做一级缓存，Redis做二级缓存,Redis失效时本地缓存还能扛一阵子。
读写分离主从延迟怎么解决：缓存层能帮上什么忙
主从延迟是读写分离的固有痛点，写主库后立即读从库，可能读到旧数据，缓存层在这个问题上能提供缓冲空间,但不能完全解决。
缓存层兜底策略
- 写后立即删缓存：写完主库后马上删除缓存，下一次读强制回源，但如果此时从库还没同步完,回源读到的还是旧数据。
- 延迟双删的变体：写完主库后删缓存，再延迟几百毫秒后删一次，第二次删除能清掉第一次删除后、从库同步前写入的脏缓存。
- 版本号控制：在缓存value中记录数据版本号或时间戳，回源时如果发现从库数据版本旧于缓存，则放弃更新缓存,等待下次同步完成后再刷新。
读己之写的一致性保障
如果是用户自己的写操作后立刻读取，要求强一致，那就不能依赖缓存和从库。强制读主库是唯一的硬保障，可以在业务层区分：读请求带上特定标识（比如刚提交过订单的userId），路由到主库查询，不走缓存，这种场景占比不大,但对一致性要求极高。
监控与运维：怎么判断缓存层配合得好不好
配合得好不好，不能靠感觉，要看数据，读写分离场景下,需要重点盯这几个指标：
- 缓存命中率：低于80%说明缓存配置不合理,大量请求穿透到从库。
- 从库延迟时间：延迟持续走高，说明从库压力大,可能需要扩容或调整缓存策略。
- 主从延迟秒级波动：秒级内的延迟是正常的，如果持续超过5秒,需要排查大事务或从库硬件问题。
- 缓存删除失败率：删除失败率升高，意味着脏数据风险增加,检查消息队列积压情况。
推荐做法：用Grafana + Prometheus搭建监控面板，将Redis的命中率、从库的Seconds_Behind_Master指标都纳入告警，据行业观察，多数读写分离架构的性能问题，不是数据库扛不住，而是缓存层没配合好,导致数据库承受了本不该承受的流量。
Q&A：读写分离场景缓存与数据库配合常见问题
读写分离下缓存和数据库数据不一致，怎么排查？
先确认不一致的表现形式，如果是缓存里有旧值、数据库是新值，大概率是删缓存失败或延迟双删的第二次删除没生效，排查步骤：检查消息队列中删除缓存的消息是否有积压，确认Canal或binlog订阅组件是否正常工作，查看Redis的键过期时间设置是否合理，如果是缓存里没有数据、数据库有数据，那就是回源逻辑出了问题,检查从库连接配置和超时设置。
读写分离场景必须用Redis吗？
不是必须，但多数团队选Redis，Memcached也能做缓存层，纯内存读写快，但Redis支持更丰富的数据结构，且分布式锁、布隆过滤器这些配套能力在防穿透防击穿时能复用，不用额外引入组件，对于读写分离架构，技术选型考虑的是生态完整性和问题排查效率,Redis在这两点上优势明显。