读写分离场景下的缓存一致性问题

前言

对于一些并发较高，且读多写少的场景，为了提高性能，降低DB压力，大家肯定会想到缓存，这也是我们最常见的提高并发能力的手段；还有就是DB的读写分离，将一些对实时性没有这么高的请求，分流到从库，降低主库的压力。 对于大部分的业务场景来说，使用缓存就足够了（可能在业务发展初期，缓存都没有太大必要）。但是随着业务的发展，请求在经过缓存过滤了一层之后，DB主库负载还是很高，那么可能会再上读写分离，来分流请求。那么问题来了，这时候如果你的缓存是使用懒加载的模式，那么就很有可能会遇到缓存一致性的问题。

DB缓存一致性

在正常的场景下，DB缓存如何保证一致性？ 一般有两种模式，Cache Aside 和 Cache Through， 我们基本上都是使用Cache Aside模式，即我们的程序直接和DB以及缓存打交道。

Cache Through（Read/Write Through）的方式一般是我们应用程序只和缓存进行交互，缓存再去通过各种方式去持久化数据到硬盘，这种方式正常场景下我们一般不会使用。它更多的是在类似于操作系统或缓存中间件中实现。

先更新缓存还是DB？

首先不管是更新缓存还是失效缓存，肯定是先更新DB再处理缓存，否则没办法保证数据一致性。

场景1