目录
前言
在高并发的业务场景里，缓存是提升系统性能的 "利器"，但用不好也可能成为数据不一致的 "源头"。很多开发者在面对 "先操作缓存还是先操作数据库" 这个经典问题时，往往陷入两难。本文就从缓存的基础概念出发，一步步拆解缓存更新的核心策略，帮你彻底搞懂数据库缓存不一致的解决方案，避开生产环境里的那些常见陷阱。
一、什么是缓存
缓存( Cache),就是数据交换的缓冲区 ,俗称的缓存就是缓冲区内的数据,一般从数据库中获取,存储于本地代码
二、为什么要使用缓存
缓存数据存储于代码中,而代码运行在内存中,内存的读写性能远高于磁盘,缓存可以大大降低用户访问并发量带来的服务器读写压力
实际开发过程中,企业的数据量,少则几十万,多则几千万,这么大数据量,如果没有缓存来作为"避震器",系统是几乎撑不住的,所以企业会大量运用到缓存技术;
但是缓存也会增加代码复杂度和运营的成本:
优点：可以减少后端进行磁盘查询mysql数据库的次数，提高效率
缺点: 可能会造成数据的不一致性，出现雪崩、击穿、穿透等问题，需要维护成本
这里我们看一个黑马点评的例子
没有写入缓存前
写入缓存后，提高了查询效率
三、缓存更新策略
缓存更新是为了节约内存而设计出来的一个东西，因为内存空间相比于磁盘空间更加珍贵，当我们向redis插入太多数据，此时就可能会导致缓存中的数据过多，所以redis会对部分数据进行更新，或者把他叫为淘汰更合适。
三种更新策略
**内存淘汰：**redis自动进行，当redis内存达到咱们设定的max-memery的时候，会自动触发淘汰机制，淘汰掉一些不重要的数据(可以自己设置策略方式)
**超时剔除：**当我们给redis设置了过期时间ttl之后，redis会将超时的数据进行删除，方便咱们继续使用缓存
**主动更新：**我们可以手动调用方法把缓存删掉，通常用于解决缓存和数据库不一致问题
应用场景:
低需求场景:长时间不需要更新的，就可以用内存淘汰机制，不需要人为操作
高需求场景:可以把主动更新和超时剔除一起使用，来应对频繁的缓存更新状况
数据库缓存不一致解决方案：
由于我们的缓存的数据源来自于数据库 ,而数据库的数据是会发生变化的 ,因此,如果当数据库中数据发生变化,而缓存却没有同步 ,此时就会有一致性问题存在,其后果是:
用户使用缓存中的过时数据,就会产生类似多线程数据安全问题,从而影响业务,产品口碑等;怎么解决呢？有如下几种方案
Cache Aside Pattern 人工编码方式：缓存调用者在更新完数据库后再去更新缓存 ，也称之为双写方案
Read/Write Through Pattern : 由系统本身完成，数据库与缓存的问题交由系统本身去处理
Write Behind Caching Pattern ：调用者只操作缓存，其他线程去异步处理数据库，实现最终一致
由于方案二、三在市面上难以找到对应的系统，只能成本较高，所以我们综合采用方案一
而操作缓存和数据库时有三个问题需要考虑：
1.如果采用第一个方案，那么假设我们每次操作数据库后，都操作缓存，但是中间如果没有人查询，那么这个更新动作实际上只有最后一次生效，中间的更新动作意义并不大，我们可以把缓存删除，等待再次查询时，将缓存中的数据加载出来
2.删除缓存还是更新缓存？
更新缓存：每一次更新操作都需要操作缓存，无效操作太多
删除缓存：只在用户需要是更新缓存，有效操作率高
3.先操作缓存还是先操作数据库？
若一开始缓存和数据库存储的都是10
先删除缓存再操作数据库:
正常流程如下：
异常情况
若在线程1删除了缓存后，线程2马上进入查询缓存，此时缓存没有数据，数据库也没来得及更新数据为20，那么线程2就会查询到旧的数据10，写入到缓存也为10，就会出现数据的不一致
因为更新数据库的操作比操作缓存的时间和查询数据库的时间长，所以可能性大
先更新数据库再删除缓存
正常流程如下
异常情况
若在一开始线程2更新数据库之前，线程1的缓存失效了，同时又在查询缓存，那么线程2的数据库操作还没来得及修改为20，线程1已经根据数据库查询到了旧数据10，在线程1把10写入缓存前，线程2先执行了删除缓存的操作，那么线程1的写入缓存的数据最终还是10
