【Redis】 Redis 缓存

1.将Spring Boot 与 Redis 整合

        1）在配置文件中注册Redis连接信息与缓存信息

        

        2）需要缓存到Redis中的实体类必须要序列化

        

        3）Spring Boot 启动类中要添加@EnableCaching注解

        4）查询方法上要添加@Cacheable注解

        5）对数据进行写操作的方法上添加@CacheEvict注解

        6）对于需要手工操作Redis的方法，需通过RedisTemplate来获取操作对象

2.高并发问题

        在高并发读会产生：缓存穿透、缓存击穿、缓存雪崩；而高并发写会产生：数据库缓存双写不一致

     2.1.缓存穿透

        1）概念：当用户访问的数据既不在缓存也不在数据库中时，就会导致每个用户查询都会“穿透” 缓存“直抵”数据库

        2）问题：当高并发的访问请求到达时，缓存穿透不仅增加了响应时间，而且还会引发对DBMS的高并发查询，这种高并发查询很可能会导致 DBMS的崩溃

        3）产生原因：数据库中没有相应的查询结果；查询结果为空时，不对查询结果进行缓存

        4）解决方法：对非法请求进行限制；对结果为空的查询给出默认值

     2.2.缓存击穿

        1）概念 ：对于某一个缓存，在高并发情况下若其访问量特别巨大，当该缓存的有效时限到达时， 可能会出现大量的访问都要重建该缓存，即这些访问请求发现缓存中没有该数据，则立即到 DBMS中进行查询，那么这就有可能会引发对DBMS的高并发查询，从而接导致DBMS的崩溃。该缓存数据称为热点数据

        2）解决方法：使用“双重检测锁”机制

     2.3.缓存雪崩

        1）概念：对于缓存中的数据，很多都是有过期时间的。若大量缓存的过期时间在同一很短的时间 段内几乎同时到达，那么在高并发访问场景下就可能会引发对DBMS的高并发查询，而这将 可能直接导致DBMS的崩溃

        2）解决方法：没有很直接的解决方案。最好的解决方案就是预防，即提前规划好缓存的过期时间。要么就是让缓存永久有效，当DB中数据发生变化时清除相应的缓存。如果DBMS 采用的是分布式部署，则将热点数据均匀分布在不同数据库节点中，将可能到来的访问负载均衡开来

     2.4.数据库缓存双写不一致

        1）修改DB更新缓存：对于具有缓存warmup功能的系统，DBMS中常用数据的变更，都会引发缓存中相关数据的更新。在高并发写请求场景下，若多个请求要对DBMS中同一个数据进行修改，修改后还需要更新缓存中相关数据，那么就有可能会出现缓存与数据库中数据不一致的情况

        2）修改DB删除缓存：在没有缓存warmup功能的系统，为了保持缓存与数据库数据的一致性，一般在对数据库执行了写操作后，就会删除相应缓存。在高并发读写请求场景下，若这些请求对DBMS中同一个数据的操作既包含写也包含读， 且修改后还要删除缓存中相关数据，那么就有可能会出现缓存与数据库中数据不一致的情况

        3）解决方法：

           a.延迟双删：专门针对于“修改DB删除缓存”，在写操作完毕后会立即执行一次缓存的删除操作，然后再停上一段 时间（一般为几秒）后再进行一次删除，两次删除中间的间隔时长，要大于一次缓存写操作的时长。但该方案并不能彻 底解决数据不一致的状况，其只可能降低发生数据不一致的概率

           b.队列：将请求写入到一个统一的队列，只有处理完一个请求后才可处理下一个请求，即使系统对用户请求的处理串行化，就可以完全解决数据不一致的问题。但系统失去了并发性，降低了性能

           c.分布式锁：使用分布式锁可以在不影响并发性的前提下，协调各处理线程间的关系，使数据 库与缓存中的数据达成一致性，只需要对数据库中的这个共享数据的访问通过分布式锁来协调对其的操作访问即可