缓存与库先写哪个？

生产环境中，为了避免⼤量请求同时冲击在数据库上导致宕机，数据库+缓存减少服务器压力的⽅式已经成了⽇常标配。对于读取的部分，⼤家都很熟悉，咱就不献丑了，但是对于写的部分，到底是先写库还是先写缓存，各路大神都有自己的看法，而本文仅代表个人观点哈。

⼀、旁路缓存策略

这个有逼格的名词咱们可能不是很熟悉，但是说到它的使⽤⽅式，咱们大多数人肯定有⽤过。这是⼀种最经典的缓存+数据库读写的模式，这种模式对应的使⽤⽅式有两种情况，⼀读⼀写，读就是基本读取方式，写就是先更新数据库后删除缓存。

1、基本读取⽅式

套路大家都差不多清楚，先读缓存，缓存中没有数据的话就去数据库读取，然后再存⼊缓存中，同时返回响应。这没什么可说的，来看下图就清楚了：

2、先更新数据库，后删除缓存

为什么不在更新完数据库后，采取更新缓存的⽅案，⽽是将其删除？原因如下：

（1）频繁更新浪费资源

如果修改库中的某个字段，⼀段时间内频繁进⾏更新，缓存也跟着更新，但是这个缓存数据在这段时间内也就被偶尔使⽤了⼏次，那这就会导致资源浪费了。

（2）缓存数据计算复杂

假如⼀个数据的计算成本⽐较⾼，要通过多张表来计算才能得到结果，那么每修改⼀次，为了更新缓存还要再查询多张表来算一次，这酸爽，大家都清楚的哈。

（3）两种情况都具备

这就致命了，不但修改频繁，同时缓存数据还要经过复杂计算。⽣产环境⾥要是这么搞的话，那咱们还是提前准备简历了。

既然更新缓存的⽅式不可⾏，那么我们换个思路，删除掉呢？

还是按照上边的步骤，先更新数据库，只是把更新缓存的操作换成了删除。在这种情况下，读请求过来的时候，发现Redis中没有数据，就会去数据库⾥读取，然后写⼊缓存中。这是⼀种懒加载⽅式，只有缓存被需要的时候才会去计算。这样可以避免⼤量计算及频繁更新。

但这还有一些隐患，譬如数据更新成功，但是删除缓存失败怎么办？

如图，刚开始时，数据库和缓存中的数据是⼀致的，但是在写请求过来后，数据库更新成功，⽽缓存删除失败，这就导致数据库中的数据是最新的，但缓存中却依然存着旧数据。这时，如果读请求过来，就会直接读取缓存中的旧数据返回了。

⼆、双写⼀致⽅案

1、先删除缓存，后更新数据库

既然我们确认了问题的原因是删除缓存失败了，我们先删除缓存，后更新数据库应该可以吧。也有人会说了，我数据库更新失败了咋办呢？咱们通过图来看下：

如图，缓存删除成功后为空了，但是数据库却失败了，还是原来的旧数据。这时候有请求过来的话，⼀看缓存中没有数据，于是就到数据库读取了旧数据更新到缓存中。如果咱的项⽬并发量很低的话，每天访问量就那么点，那这么⽤没⽑病，很少情况下才会出现数据不⼀致的问题。同时，这种策略只能算作初级的解决⽅案。

2、缓存延时双删策略

如果同时来了两个请求，⼀个写请求，⼀个读请求。写请求先删除Redis中的数据，然后去数据库进⾏更新操作，读请求判断Redis中有没有数据，没有数据时去请求数据库，拿到数据后写⼊缓存中，但是写请求此时并没有更新成功，或者执⾏了⼀个事务还没有成功。

这样一来，读请求拿到未修改的旧数据写⼊缓存。稍后，写请求将数据库更新成功了，此时缓存与库中的数据就不⼀致了。

解决⽅案就是延时双删策略：

      

写请求过来先把Redis缓存删掉，等数据库更新成功后，异步等待⼀段时间再次把缓存删掉，这种⽅案读取速度快，但是会出现短时间的脏数据。

三、总结

1、旁路缓存策略

读的时候，先读缓存，缓存不存在再去读数据库，然后写入缓存同时返回响应，在更新的时候，则是先更新数据库，之后再删除缓存。

2、双写⼀致⽅案

先删缓存，后更新库：解决缓存删除失败致库与缓存不⼀致问题，适⽤于并发量不⾼的业务场景。

缓存延时双删策略：解决⾼并发下，同时有读请求与写请求时导致的不⼀致问题，读取速度快，但是可能会出现短时间的脏数据。

不同的方案各有利弊，对于不同的业务来说没有通用的技术⽅案，所以我们在选择技术⽅案时需要根据业务⾃身来定。总之一句话，没有最好的，只有最合适的。

有兴趣的话，可以关注本公众号，获取更多优质内容。