Redis六种内存淘汰策略&&三种缓存淘汰策略(帮你彻底理清淘汰策略,在阅读文章时发现先淘汰缓存再更新数据库不可行,又有人说可行,其实真相是这样的)

一.前言

(1)注意区分六种内存淘汰策略和常用三种缓存淘汰策略,
前者在redis.conf里配置,后者则是java代码里体现
(2)六种策略
①noeviction: 不删除策略, 达到最大内存限制时, 如果需要更多内存, 直接返回错误信息。
②allkeys-lru: 所有key通用; 优先删除最近最少使用(less recently used ,LRU) 的 key。
③volatile-lru: 只限于设置了 expire 的部分; 优先删除最近最少使用又过期(less recently used ,LRU) 的 key。
④allkeys-random: 所有key通用; 随机删除一部分 key。
⑤volatile-random: 只限于设置了 expire 的部分; 随机删除一部分过期 key。
⑥volatile-ttl: 只限于设置了 expire 的部分; 优先删除剩余时间(time to live,TTL) 短的key。
注意:如果没有设置 expire 的key, 不满足先决条件(prerequisites); 那么 volatile-lru, volatile-random 和 volatile-ttl 策略的行为, 和 noeviction(不删除) 基本上一致。
(3)怎么设置六种淘汰策略
在redis目录下打开redis.windows.conf,找到下面黑色字
maxmemory

maxmemory-policy noeviction
解析:maxmemory 设置redis使用最大内存,比如设置成100mb,如下:
maxmemory 100mb
maxmemory-policy noeviction 设置redis在超最大内存时采取策略,默认是noeviction策略

二.redis删除key三种策略

①主动删除:
volatile-lru,、volatile-random 、 volatile-ttl、allkeys-lru、allkeys-random、noeviction
②被动删除:读写某个早就过期的key时才会删除这个key
③被动清理:内存满了会主动删除一大批key(maxmemory 100mb)

三.缓存淘汰策略(java代码体现逻辑)

1.Cache Aside Pattern（旁路缓存模式）

写 ：先更新 DB,更新好后直接删除 cache,当然也可以先更新DB,然后让cache过期,选中哪种都行反正都是能让缓存无效

读 :

从 cache 中读取数据，读取到就直接返回,cache中读取不到的话，就从 DB 中读取数据返回,再把数据放到 cache 中。(这是同步更新)

注意:

(1)使用同步更新操作(即读操作时把数据放到 cache 中)时不能更改步骤成"先删除 cache 再更新 DB",否则会造成数据不一致
(2)异步更新:****读操作**改成"删除cache再更新DB,不会把数据放到cache",写操作改成"更新数据库,把数据放到 cache 中",**异步更新会导致未执行完写操作时并发的读操作会一直直接访问数据库而不是缓存,加大对数据库压力因此不怎么推荐使用异步更新

@Service
public class CacheAsidePatternService {
  @Autowired
  private CacheService cacheService;

  @Autowired
  private DataDao dataDao;

  //读操作
  public Data getData(String key) {
    //1. 读缓存,如果命中则直接返回
    Data data = cacheService.loadDataFromCache(key);
    if (data != null) {
      return data;
    }

    //2. 缓存未命中,读数据库
    data = dataDao.loadDataFromDB(key);

    //3. 将读取到的数据放入缓存
    cacheService.putData(key,data);

    return data;
  }

  //写操作
  public void updateData(String key,Data data){
    //1. 更新数据库
    dataDao.updateData(key, data);

    //2. 删除缓存
    cacheService.evictData(key);
  }
}

————————————————
版权声明：本文为CSDN博主「张申傲」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_34452850/article/details/90232251

2.Read/Write Through Pattern（读写穿透）

写（Write Through）：

写方式分为Write Allocate(按写分配)和No-write allocate

Write Allocate

cache 中存在，则先更新 cache，然后 cache 服务自己更新 DB（同步更新 cache 和 DB）

No-write allocate

先查 cache，cache 中不存在，直接更新 DB。

读(Read Through)：

从 cache 中读取数据，读取到就直接返回 。
读取不到的话，先从 DB 加载，写入到 cache 后返回响应。

3.Write Behind Caching Pattern（异步缓存写入）:第一次写时只写缓存,第二次时更新数据区域还是上次缓存区域时才会cache服务自己更新DB

(1)Write Behind Caching Pattern貌似也称作Write Back(写回)策略
(2)这种策略不能被应用到我们常用的DB和缓存场景中,而是应用到:
操作系统层面的Page Cache，
日志的异步刷盘
消息队列中消息的异步写入磁盘
(3)写操作:写入数据时只写入缓存，并且把缓存块儿标记为“脏”的。而脏块只有被再次使用时才会cache 服务自己更新 DB
(4)读操作

(5)优点:性能上的优势毋庸置疑，它避免了直接写磁盘造成层的随机写问题，毕竟写内存和写磁盘的随机I/O的延迟相差了几个数量级

参考自

https://blog.csdn.net/qq_41204714/article/details/84578481
https://www.jianshu.com/p/cb620682b64d
https://blog.csdn.net/weixin_34452850/article/details/90232251