保证缓存数据库数据一致性

更新数据时的操作主要分为两种：写时更新和读时更新

什么是写时更新和读时更新

写时更新：当我们往数据库写数据的时候我们去更新缓存，包括先更新缓存再更新数据库和先更新数据库再更新缓存。
写时删除，读时更新：当我们往数据库写数据的时候我们直接删除缓存，然后其他请求读数据的时候更新缓存。包括先删除缓存再更新数据和先更新数据库再删除缓存。

缓存更新到底是读更新好还是写更新好？

对比写时更新方案，读时更新更好，为什么？

如果你是一个写数据库场景比较多，而读数据场景比较少的业务需求，采用这种方案就会导致，数据压根还没读到，缓存就被频繁的更新，浪费性能。
同时有请求A和请求B进行更新操作，那么会出现（1）线程A更新了数据库（2）线程B更新了数据库（3）线程B更新了缓存（4）线程A更新了缓存。这就出现请求A更新缓存应该比请求B更新缓存早才对，但是因为网络等原因，B却比A更早更新了缓存。这就导致了脏数据，因此不考虑。

那么也就是说，如果是写更新的话，不管从性能的角度还是从线程安全的角度来说这种方案都不好。

读时更新有没有什么问题？

前面我们说了，如果是写更新，会有效率和线程安全性的问题，那如果是读更新又会有什么问题呢？
读时更新：当我们往数据库写数据的时候我们直接删除缓存，然后其他请求读数据的时候更新缓存。读时更新又包括如下2种方案。

先删除缓存再更新数据库
先更新数据库再删除缓存。

先更新数据库再删除缓存

问题一、如果在高并发的场景下，会出现数据库与缓存数据不一致

缓存刚好失效线程 A 查询数据库，得一个旧值
线程 B 将新值写入数据库
线程 B 删除缓存
线程 A 将查到的旧值写入缓存

但出现的概率特别低，为什么呢？

我们需要线程A读操作必需在B线程写操作前进入数据库操作，而又要晚于B写操作更新缓存，所有的这些条件都具备的概率基本并不大。那么如何解决这个低概率问题呢？
设置缓存的过期时间，这样可以达到最终一致性

问题二、如果删除缓存失败或更新数据库失败了会怎样？

第一步操作数据库成功，第二步删除缓存失败，会导致数据库里是新数据，而缓存里是旧数据。
第一步操作数据库就失败了，第二步更新缓存不会执行，不会出现数据不一致。

如何解决删除缓存失败的问题？

将需要删除的 key 发送到消息队列中自己消费消息，获得需要删除的 key 不断重试删除操作，直到成功

先删除缓存再更新数据库

问题一、如果在高并发的场景下，会出现数据库与缓存数据不一致

线程 A 删除了缓存线程 B 查询，发现缓存已不存在
线程 B 去数据库查询得到旧值
线程 B 将旧值写入缓存
线程 A 将新值写入数据库

如何解决？设置缓存的过期时间，这样可以达到最终一致性

问题二、如果删除缓存失败或更新数据库失败了会怎样？

第一步删除缓存成功，第二步更新数据库失败，数据库和缓存的数据还是一致的。
第一步删除缓存就失败了，第二步更新数据库不会去执行，数据库和缓存的数据还是一致的。

也就是说并不会导致数据不一致问题。

小总结：对比两种策略

先删除缓存，再更新数据库：在高并发下相对更容易出现数据不一致问题，但在原子性被破坏时（删除缓存失败或更新数据库失败）并不会出现数据一致性问题
先更新数据库，再删除缓存：在高并发下相对出现数据不一致问题概率很低，但在原子性被破坏时（删除缓存失败或更新数据库失败）会出现数据一致性问题

要解决这一切的比较简单的解决方案就是要给KEY设置过期时间

方案延申

延时双删策略

在写库前后都进行redis.del(key)操作，并且设定合理的超时时间。具体步骤是：

1）先删除缓存

2）再写数据库

3）休眠500毫秒（根据具体的业务时间来定）

4）再次删除缓存。

那么，这个500毫秒怎么确定的，具体该休眠多久呢？

需要评估自己的项目的读数据业务逻辑的耗时。这么做的目的，就是确保读请求结束，写请求可以删除读请求造成的缓存脏数据。

当然，这种策略还要考虑 redis 和数据库主从同步的耗时。最后的写数据的休眠时间：则在读数据业务逻辑的耗时的基础上，加上几百ms即可。比如：休眠2秒。

为什么这种方式可以解决脏缓存（缓存数据与数据库不一致）的问题呢？要造成脏缓存，就需要在缓存被删除后，数据库被更新前有请求读取到了旧数据并更新了缓存，那么这边睡眠一秒后再次删除缓存就可以把这个短暂的时间间隔内产生的脏缓存再次删除掉。

/**
 * 延迟双删代码案例
 * @author xiaowu
 */
@Component
@Aspect
@Slf4j
public class DoubleClearCacheAop {

    /**
     * 声明一个用于延时的定时线程池代替线程sleep
     */
    ScheduledExecutorService task = new ScheduledThreadPoolExecutor(10, new ThreadPoolExecutor.AbortPolicy());

    @Pointcut("@annotation(ClearCache)")
    private void clearCachePoint() {
    }

    @Around("clearCachePoint()")
    public Object clearCacheAop(ProceedingJoinPoint proceeds) throws Throwable {
        Method method = ((MethodSignature) proceeds.getSignature()).getMethod();
        ClearCache annotation = method.getAnnotation(ClearCache.class);
        Object proceed = null;
        //如果清除注解开启了
        if (annotation.open()) {
            //上下文获取信息
            //执行清除缓存的动作
            _clearCache();
            //业务处理,更新数据库操作
            proceed = proceeds.proceed();
            //延时两秒后再删
            task.schedule(() -> {
                _clearCache();
                if (log.isInfoEnabled()) {
                    log.info(Thread.currentThread().getName() + ":double delete cache completed");
                }
            }, 2L, TimeUnit.SECONDS);
        }
        if (Objects.isNull(proceed)){
            proceed = proceeds.proceed();
        }
        return proceed;
    }
}

/**
 *@author xiaowu
 *延时双删
 **/
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Target(ElementType.METHOD)
@interface ClearCache {
    boolean open() default true;
}