今天讲讲缓存的读写策略，你可能觉得很简单啊，查询缓存，不存在则查询数据库，然后回种缓存。实际上针对不同的业务场景缓存的读写策略是不同的。

选择读写策略的时候，需要考虑如下因素：缓存中是否可能写入脏数据，策略的读写性能，是否存在缓存命中率下降。下面我们就以标准的 缓存+数据库的 场景 带你剖析读写策略以及适用的场景。

Cache Aside（旁路缓存）策略

先考虑最简单的业务场景 ，更新数据，比如更加 id 更新 年龄信息。

你可能会产生以下思路：

这个思路会造成缓存和数据库中的数据不一致。

为什么会产生这个问题呢？因为变更数据和变更缓存是两个独立操作，没有做任何的并发控制，当两个线程并发的去更新时，就会出现因为顺序不同而导致不同的更新结果。

那么要如何解决这个问题呢？其实，我们可以在更新数据库的同时，不更新缓存，而是删除缓存中的数据，在读取缓存时发现没有数据，再从数据库中读取，更新到缓存中。

这个就是我们常见的Cache Aside 策略（也叫旁路缓存策略），这个以数据库为准，缓存中的按需加载。它可以分为读策略和写策略

读策略步骤：

从缓存中读取数据如果缓存命中则直接返回如果缓存不命中，则从数据库查询数据查询到数据后将数据回种缓存，返回用户数据

写策略步骤：

更新数据库中的数据删除缓存记录

那么问题来了，写策略的时候，是否可以先删除缓存，再更新数据库呢？不行，这样会导致 缓存跟数据库的数据不一致

那么 Cache Aside 策略这样先更新数据库，删除缓存就没有问题了吗？其实理论上还是有的，如下图：

不过这种问题出现的概率很低，因为就是缓存的写入远远快于数据库的写入，所以在实际中很难出现请求b已经操作完数据库并且写入缓存了前面请求还未写入缓存。

Cache Aside 策略是我们日常开发中最经常使用的缓存策略，存在问题就是当数据写入比较频繁时，缓存中数据会被频繁的清理，这样会对缓存的命中率产品一定影响。可以考虑两种解决方案：

更新数据同时更新缓存，更新缓存的时候加一个分布式锁，这样同一时间只允许一个线程更新，但是这样会对写入性能有影响。另一种做法同样更新数据更新缓存，只是缓存加一个极短过期时间，这样即使出现不一致，对业务的影响也较小（视具体的业务场景抉择）

当然除了这个策略，在计算机领域还有几种经典的缓存策略，他们也有自己各自的适用场景。

这个策略的核心原则是只与缓存打交道，由缓存跟数据库通信，写入或者读取数据。

write through 策略是这样的：先查询要写入的数据在缓存中是否存在，如果已经存在则更新缓存中的数据，并且由缓存组件同步更新到数据库，如果缓存中数据不存在我们把这种情况叫做写失效，write miss

Write Back（写回）策

这个策略的核心是写入数据时只写入缓存，并且把缓存块标记为 脏的，而脏块儿 只有被再次使用时才会将其中的数据写入数据库中。

划重点

Cache Aside 是我们在使用分布式缓存时最常用的策略，可以在实际业务中直接拿来使用。Read/Write Through 和 Write Back 策略需要缓存组件的支持，所以比较适合你在实现本地缓存组件的时候使用；Write Back 策略是计算机体系结构中的策略，不过写入策略中的只写缓存，异步写入后端存储的策略倒是有很多的应用场景。而且，你还需要了解，我们今天提到的策略都是标准的