【Redis】——双写一致性、过期策略（2）

最经典的缓存+数据库读写的模式，就是 Cache Aside Pattern。

• 读的时候，先读缓存，缓存没有的话，就读数据库，然后取出数据后放入缓存，同时返回响应。
• 更新的时候，先更新数据库，然后再删除缓存。

删除缓存而不是更新缓存主要是为了考虑性能的问题，一旦我们需要频繁的更新缓存，对资源的消耗是可观的，还不如一次性删除掉，下次的请求的时候直接查询数据库，然后更新缓存。

但是会出现一个问题，就是更新完数据库之后，删除缓存失败了，导致缓存与数据库数据不一致？

• 初级解决：先删除缓存，然后更新数据库
• 复杂问题：删除缓存，然后去修改数据库，但是还没有修改成功的时候请求来了，就之前的旧数据写到了缓存了，等到更新成功了就会出现缓存和数据库数据不一致的情况。解决方案就是修改的数据加一个唯一标识，之后更新完之后才能被请求，没有更新完之前所有的请求都会放到一个队列里面等待，但是问题就是在高并发的情况下主要这些请求的超时时间。

redis 过期策略是：定期删除+惰性删除

定期删除，指的是 redis 默认是每隔 100ms 就随机抽取一些设置了过期时间的 key，检查其是否过期，如果过期就删除。但是可能导致一些过期key到了时间并没有被删除掉，这个时候就需要惰性删除了，就是你请求某个key的值，redis会先检查这个key如果设置了过期时间，有没有过期，如果过期就不返回任何东西。但是这样这样还是会出现问题，加入有很多的过期key，但是你有没有主动查询，就没有惰性删除，那么就会堆积在内存中，那就要走内存淘汰机制。

redis 内存淘汰机制有以下几个：

• noeviction: 当内存不足以容纳新写入数据时，新写入操作会报错，这个一般没人用吧，实在是太恶心了。
• allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的 key（这个是最常用的）。
• allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个 key，这个一般没人用吧，为啥要随机，肯定是把最近最少使用的 key 给干掉啊。
• volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的 key（这个一般不太合适）。
• volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个 key。
• volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的 key 优先移除。

手写LRU算法：Least Recently Used的缩写，即最近最少使用，是一种常用的页面置换算法，选择最近最久未使用的页面予以淘汰。

/**
 * @author  2019/10/6 11:07
 */
public class LRUCache<K, V> extends LinkedHashMap<K, V> {
    private final int CACHE_SIZE;

    public LRUCache(int cacheSize) {
        // true 表示让 linkedHashMap 按照访问顺序来进行排序，最近访问的放在头部，最老访问的放在尾部。
        super((int) (Math.ceil(cacheSize / 0.75) + 1), 0.75f, true);
        CACHE_SIZE = cacheSize;
    }

    @Override
    protected boolean removeEldestEntry(Map.Entry<K, V> eldest) {
        // 当 map中的数据量大于指定的缓存个数的时候，就自动删除最老的数据。
        return size() > CACHE_SIZE;
    }
}