使用 注解 @Caching ，源码如下

@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@Documented
public @interface Caching {
    Cacheable[] cacheable() default {};

    CachePut[] put() default {};

    CacheEvict[] evict() default {};
}

//更新多个
@Caching(put = {
     @CachePut(value = "user",key = "#key"),
     @CachePut(value = "user",key = "#key2")
})
//删除多个
@Caching(evict = {
     @CacheEvict(value = "user",key = "#key"),
     @CacheEvict(value = "user",key = "#key2")
})

 

Redis之缓存雪崩、缓存穿透、缓存预热、缓存更新、缓存降级

1、缓存雪崩

发生场景：当Redis服务器重启或者大量缓存在同一时期失效时,此时大量的流量会全部冲击到数据库上面,数据库有可能会因为承受不住而宕机

解决办法：

1）缓存数据的过期时间设置随机，防止同一时间大量数据过期现象发生。

2）给每一个缓存数据增加相应的缓存标记，记录缓存的是否失效，如果缓存标记失效，则更新数据缓存。

3）一般并发量不是特别多的时候，使用最多的解决方案是加锁排队。

2、缓存穿透

发生场景：是指查询一个数据库一定不存在的数据。正常的使用缓存流程大致是，数据查询先进行缓存查询，如果key不存在或者key已经过期，再对数据库进行查询，并把查询到的对象，放进缓存。如果数据库查询对象为空，则不放进缓存。此时，若攻击者抓住这个漏洞不断请求数据库，就会对数据库造成压力，甚至压垮数据库。

解决办法：采用缓存空值的方式，也就是从数据库查询的对象为空，也放入缓存，只是设定的缓存过期时间较短，比如设置为60秒。

1. 接口层增加校验，如用户鉴权校验，id做基础校验，id<=0的直接拦截；

2. 从缓存取不到的数据，在数据库中也没有取到，这时也可以将key-value对写为key-null，缓存有效时间可以设置短点，如30秒（设置太长会导致正常情况也没法使用）。这样可以防止攻击用户反复用同一个id暴力攻击

3.采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的 bitmap 中，一个一定不存在的数据会被这个 bitmap 拦截掉，从而避免了对底层存储系统的查询压力

3、缓存预热

是一种机制, 就是系统上线后，提前将相关的缓存数据直接加载到缓存系统。避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题。

4、缓存更新

是一种机制,怎么样保证缓存中的key是实时有效的,以及及时的更新数据资源

解决办法：

1）缓存服务器自带的缓存失效策略

2）自定义：定时去清理过期的缓存；当用户请求过来时，再判断这个请求所用到的缓存是否过期，过期的话就去底层系统得到新数据并更新缓存。

5、缓存降级

发生场景：当访问量剧增、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级。降级的最终目的是保证核心服务可用，即使是有损的。而且有些服务是无法降级的（如加入购物车、结算）。

解决办法：

在进行降级之前要对系统进行梳理，看看系统是不是可以丢卒保帅；从而梳理出哪些必须誓死保护，哪些可降级；比如可以参考日志级别设置预案：

（1）一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级；

（2）警告：有些服务在一段时间内成功率有波动（如在95~100%之间），可以自动降级或人工降级，并发送告警；

（3）错误：比如可用率低于90%，或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级；

（4）严重错误：比如因为特殊原因数据错误了，此时需要紧急人工降级。

 

经常遇到后台线程定期更新缓存，而service线程却要实时查询缓存的功能。通常更新缓存的线程为一个，而读取缓存的线程有多个。

这正好符合读者写者模型，实际中可以用读写锁来处理。c++中也是推荐这个用法的。

实际操作中，有需要注意的细节。比如缓存不大而生成又耗时的情况下，可以先生成缓存对象，此时不需要加锁，然后在加锁的情况下去更新指针。这个指针可以是智能指针也可以是非智能指针，无论哪种情况都需要加锁。

对于智能指针情况，智能指针的拷贝、赋值以及析构等操作是线程安全的，这是因为拷贝和赋值只改变了引用计数，而析构根据引用计数可以确保是最后一个持有线程，因而也是线程安全的。reset操作需要修改指向对象的指针，因而不是线程安全。

如果是智能指针时，读取缓存的线程，只需要获zai得一个智能指针的拷贝。而如果是非智能指针模式，则需要拷贝整个对象。因为如果仍然只获得一个指针，那么谁将销毁这个指针指向对象的内容是个很大问题。

如果由写线程在更新时候销毁，那么此时可能别的读进程正持有这个指针，这个线程可能访问到delete后的内存区域，这造成了未定义行为。如果由读取线程来释放，这更不可能，因为读取线程不唯一。故如果对象很大，为了避免拷贝开销，

那么引用计数几乎是必然的选择。

至于java中，jdk5以后另有另外一种巧妙的办法：

采用一个volatile的引用保存缓存对象，这个缓存对象是不可变的，所有的字段都是final的，这保证了多线程下的构造安全性。由于java不需要考虑对象删除问题，所以有新数据时候，写线程构造一个新对象，然后直接更新这个volatile引用即可。

优点是不需要加锁操作。这也是java一个优势。这个模式一般都是应用单写多读，因为volatile不保证原子性。但是对象引用是32位，而且只牵涉到写，并不存在读改写，所以应用多写也是满足原子性的。

 

 

考虑多线程的场景

1.先删除缓存再更新DB

多线程下先删除缓存再更新DB会导致，一个线程更新缓存，一个线程进行查询，如果缓存中查询不到就会去DB中查询旧数据并放到缓存中，这样及时之后DB中是新数据，缓存中也是旧数据，就会导致脏数据的出现

 

2.先更新DB再更新缓存

多线程下一个线程更新DB，一个线程查询缓存，这样即使缓存查到的是旧数据之后更新完DB之后缓存也会更新，只会有短暂的数据不一致的问题