缓存更新策略

1. 什么是缓存更新

缓存更新是redis为了节约内存而设计出来的一个东西，主要是因为内存数据宝贵，当我们向redis插入太多数据，此时就可能会导致缓存中的数据过多，所以redis会对部分数据进行更新，或者把他称为淘汰更为合适。

2. 更新方式

1. 内存淘汰：由redis自动进行，当redis内存达到预设的max-memery时，会自动触发淘汰机制，淘汰掉一些不重要的数据（可以自己设置策略方式）。
2. 超时剔除：当我们给redis设置了过期时间ttl之后，redis会将超时的数据进行删除。
3. 主动更新：我们可以手动调用方法把缓存删掉，通常用于解决缓存和数据库不一致问题。

3. 数据库缓存不一致解决方案

由于我们的缓存的数据源来自于数据库,而数据库的数据是会发生变化的,因此,如果当数据库中数据发生变化,而缓存却没有同步,此时就会有一致性问题存在,其后果是:

用户使用缓存中的过时数据,就会产生类似多线程数据安全问题,从而影响业务,产品口碑等;怎么解决呢？有如下几种方案

1. Cache Aside Pattern 人工编码方式：缓存调用者在更新完数据库后再去更新缓存，也称之为双写方案
2. Read/Write Through Pattern : 由系统本身完成，数据库与缓存的问题交由系统本身去处理
3. Write Behind Caching Pattern ：调用者只操作缓存，其他线程去异步处理数据库，实现最终一致

4. 数据库和缓存不一致怎么解决

通常情况下建议使用方案一，有几个细节问题要处理

4.1

如果使用第一个方案，那么假设我们每次操作数据库后，都操作缓存，但是中间如果没有人查询，那么这个更新动作实际上只有最后一次生效，中间的更新动作意义并不大，我们可以把缓存删除，等待再次查询时，将缓存中的数据加载出来

• 删除缓存还是更新缓存？

  • 更新缓存：每次更新数据库都更新缓存，无效写操作较多
  • 删除缓存：更新数据库时让缓存失效，查询时再更新缓存

• 如何保证缓存与数据库的操作的同时成功或失败？

  • 单体系统，将缓存与数据库操作放在一个事务
  • 分布式系统，利用TCC等分布式事务方案

4.2

应该具体操作缓存还是操作数据库？我们应当是先操作数据库，再删除缓存，原因在于，如果你选择第一种方案，在两个线程并发来访问时，假设线程1先来，他先把缓存删了，此时线程2过来，他查询缓存数据并不存在，此时他写入缓存 ，当他写入缓存后，线程1再执行更新动作时，实际上写入的就是旧的数据，新的数据被旧数据覆盖了。

• 先操作缓存还是先操作数据库？
  • 先删除缓存，再操作数据库
  • 先操作数据库，再删除缓存

从图中可以清楚看出，如果是先删除缓存再操作数据库，会导致缓存不一致，其实先操作数据库再删除缓存也有这种风险，但是更新缓存所需的时间要远远少于更新数据库的时间，中间是不容易穿插第二个线程的，就安全许多。

5. 实现商铺和缓存与数据库双写一致

核心思路：

根据id查询店铺时，如果缓存未命中，则查询数据库，将数据库结果写入缓存，并设置超时时间

根据id修改店铺时先修改数据库，再删除缓存

代码示例

更新缓存策略：

选择删除策略，修改数据后，先将缓存中的数据删除，查询时发现缓存中没有数据，会从mysql中加载最新的数据，可以有效避免数据库和缓存不一致的问题

@Override
@Transactional
public Result update(Shop shop) {
    Long id = shop.getId();
    if (id == null){
        return Result.fail("id不能为空");
    }
    //1,更新数据库
    updateById(shop);
    //2.删除缓存
    stringRedisTemplate.delete(CACHE_SHOP_KEY + id);
    return Result.ok();
}
 stringRedisTemplate.delete(CACHE_SHOP_KEY + id);
    return Result.ok();
}