本文转载自微信公众号「IT界农民工」，作者莱乌。转载本文请联系IT界农民工公众号。
日常生产场景中，为了避免大量请求同时打在数据库上导致故障，数据库+缓存的方式已经成了日常标配。
对于读取的部分，大家都很熟悉。但是对于写的部分，到底是先写库还是先写缓存，这点可能困扰着很多人。
各位看官请跟随小莱往下看：
- 思维导图 -
旁路缓存策略
提到这个有逼格的名词你可能不是很熟悉，但是说到它的使用方式，你肯定用过。
这是一种最经典的缓存+数据库读写的模式，英文是这样 Cache Aside Pattern，可能你见过。
这种模式对应的使用方式有两种情况，一读一写：
- 基本读取方式;
- 先更新数据库，后删除缓存。
1、基本读取方式
这部分相信大家已经轻车熟路：先读缓存，缓存中没有数据的话就去数据库读取，然后再存入缓存中，同时返回响应。
这没什么可说的，平时都这么用。如果还不清楚，看下小莱为大家画的图：
那我们再看写的部分。
2、先更新数据库，后删除缓存
你可能会问了，为什么不在更新完数据库后，采取更新缓存的方案，而是将其删除。原因有这么几点：
- 频繁更新浪费资源
你想想，如果修改库中的某个字段，一段时间内频繁进行更新。那么你修改多少次，缓存也跟着更新多少次。但是这个缓存数据在这段时间内也就被偶尔使用了几次。
那么你看，是不是就会导致资源浪费了。
- 缓存数据计算复杂
还有一种情况，如果这个缓存的数据计算成本比较高。比如为了一个数据，要通过多张表来计算才能得到结果。那么每修改一次，为了更新缓存还要再查询多张表来算一次，我的天。
- 两种情况都具备
这种情况最为致命，不但修改频繁，同时缓存数据还要经过复杂计算。
生产环境里要是这么搞的话，那估计你就可以准备简历了。
既然更新缓存的方式不可行，那么我们换个思路，删除掉呢?
还是按照上边的步骤，先更新数据库，只是我们把更新缓存的操作换成了删除。
在这种情况下，读请求过来的时候，发现 Redis 中没有数据，就会去数据库里读取，然后写入缓存中。
这也是一种懒加载方式，只有缓存被需要的时候才会去计算。这样可以避免大量计算及频繁更新。
但是，这样会有什么隐患的问题?是不是看着没什么毛病。你想想，如果数据更新成功，但是删除缓存失败怎么办?
如图中所示，刚开始时(初始)，数据库和缓存中的数据是一致的，但是在写请求过来后，数据库更新成功，而缓存删除失败。这就导致数据库中的数据是最新的，但缓存中却依然存着旧数据。
这时，如果读请求过来，就会直接读取缓存中的旧数据返回了。
双写一致方案
1、先删除缓存，后更新数据库
既然问题的原因是删除缓存失败了，那么我们先确保把缓存删除成功了，再去更新数据库。也就是说我们先删除缓存，后更新数据库。
可能你会问了，如果我数据库更新失败了呢?
我们不妨通过图来看下这种情况：
缓存删除成功后为空了，但是数据库却失败了，还是原来的旧数据。
如果这时候有请求过来的话，一看缓存中没有数据，于是就到数据库读取了旧数据更新到缓存中。
如果你的项目并发量很低的话，每天访问量就那么点，那这么用没毛病，很少情况下才会出现数据不一致的问题。
这种策略只能算作初级的解决方案，为什么这么说呢?
2、缓存延时双删策略
如果同时来了两个请求，一个写请求，一个读请求。
写请求先删除Redis中的数据，然后去数据库进行更新操作。
读请求判断Redis中有没有数据，没有数据时去请求数据库，拿到数据后写入缓存中。
但是写请求此时并没有更新成功，或者执行了一个事务还没有成功。
这样的话，读请求拿到未修改的旧数据写入缓存。过了一会儿，写请求将数据库更新成功了，那么此时缓存与库中的数据就不一致了。
解决方案呢?延时双删策略：
写请求过来先把 Redis缓存删掉，等数据库更新成功后，异步等待一段时间再次把缓存删掉。
这种方案读取速度快，但是会出现短时间的脏数据。
总结
旁路缓存策略
- 读的时候，先读缓存，缓存没有的话，再去读数据库，然后取出来放入缓存中，同时返回响应。
- 更新的时候，先更新数据库，再删除缓存。
双写一致方案
- 先删除缓存，后更新数据库：
解决了缓存删除失败导致库与缓存不一致的问题，适用于并发量不高的业务场景。
- 缓存延时双删策略：
这种方案解决了高并发情况下，同时有读请求与写请求时导致的不一致问题。读取速度快，但是可能会出现短时间的脏数据。
每种方案各有利弊，对于不同的业务来说没有通用的技术方案。在选择技术方案时需要根据业务自身来定。没有最好的，只有最合适的。
