缓存redis

最新推荐文章于 2024-06-19 12:26:47 发布

endsofjava

最新推荐文章于 2024-06-19 12:26:47 发布

阅读量255

点赞数

分类专栏：面试补遗文章标签：缓存 redis

本文链接：https://blog.csdn.net/weixin_38219412/article/details/101050947

版权

面试补遗专栏收录该内容

3 篇文章 0 订阅

订阅专栏

缓存redis

内容来自于： https://www.jianshu.com/nb/32674042

1、为何要使用缓存？以及使用缓存带来的不良后果？

高性能

redis基于内存，查询数据 ms 级别

高并发

MySQL 支持2000每秒的查询就以及差不多了，redis可以支撑1W到10W之间

常见的缓存问题有以下几个：

缓存与数据库双写不一致
缓存雪崩、缓存穿透
缓存并发竞争

2、缓存与数据双写不一致

典型方案：

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

之所以是先删除缓存而不是更新缓存，是因为有些缓存是由多个表联合查询而来，此时更新太慢。

此方案不足之处：

高并发场景下，在删除缓存，还未更新数据库里数据的时候，
另外一个请求过来读取缓存数据，数据没有，去数据库里读取，然后更新缓存数据，这个请求结束后，
前一个请求才去更新数据库内容，如此导致不一致现象。

解决方案如下：

更新数据的时候，根据数据的唯一标识，将操作路由之后，发送到一个 jvm 内部队列中。读取数据的时候，如果发现数据不在缓存中，那么将重新读取数据+更新缓存的操作，根据唯一标识路由之后，也发送同一个 jvm 内部队列中。

一个队列对应一个工作线程，每个工作线程串行拿到对应的操作，然后一条一条的执行。这样的话，一个数据变更的操作，先删除缓存，然后再去更新数据库，但是还没完成更新。此时如果一个读请求过来，读到了空的缓存，那么可以先将缓存更新的请求发送到队列中，此时会在队列中积压，然后同步等待缓存更新完成。

这里有一个优化点，一个队列中，其实多个更新缓存请求串在一起是没意义的，因此可以做过滤，如果发现队列中已经有一个更新缓存的请求了，那么就不用再放个更新请求操作进去了，直接等待前面的更新操作请求完成即可。

待那个队列对应的工作线程完成了上一个操作的数据库的修改之后，才会去执行下一个操作，也就是缓存更新的操作，此时会从数据库中读取最新的值，然后写入缓存中。

如果请求还在等待时间范围内，不断轮询发现可以取到值了，那么就直接返回；如果请求等待的时间超过一定时长，那么这一次直接从数据库中读取当前的旧值。

高并发的场景下，该解决方案要注意的问题：

读请求长时阻塞

由于读请求进行了非常轻度的异步化，所以一定要注意读超时的问题，每个读请求必须在超时时间范围内返回。

该解决方案，最大的风险点在于说，可能数据更新很频繁，导致队列中积压了大量更新操作在里面，然后读请求会发生大量的超时，最后导致大量的请求直接走数据库。务必通过一些模拟真实的测试，看看更新数据的频率是怎样的。

另外一点，因为一个队列中，可能会积压针对多个数据项的更新操作，因此需要根据自己的业务情况进行测试，可能需要部署多个服务，每个服务分摊一些数据的更新操作。如果一个内存队列里居然会挤压 100 个商品的库存修改操作，每隔库存修改操作要耗费 10ms 去完成，那么最后一个商品的读请求，可能等待 10 * 100 = 1000ms = 1s 后，才能得到数据，这个时候就导致读请求的长时阻塞。

一定要做根据实际业务系统的运行情况，去进行一些压力测试，和模拟线上环境，去看看最繁忙的时候，内存队列可能会挤压多少更新操作，可能会导致最后一个更新操作对应的读请求，会 hang 多少时间，如果读请求在 200ms 返回，如果你计算过后，哪怕是最繁忙的时候，积压 10 个更新操作，最多等待 200ms，那还可以的。

读请求并发量过高

这里还必须做好压力测试，确保恰巧碰上上述情况的时候，还有一个风险，就是突然间大量读请求会在几十毫秒的延时 hang 在服务上，看服务能不能抗的住，需要多少机器才能抗住最大的极限情况的峰值。

但是因为并不是所有的数据都在同一时间更新，缓存也不会同一时间失效，所以每次可能也就是少数数据的缓存失效了，然后那些数据对应的读请求过来，并发量应该也不会特别大。

多服务实例部署的请求路由

可能这个服务部署了多个实例，那么必须保证说，执行数据更新操作，以及执行缓存更新操作的请求，都通过 nginx 服务器路由到相同的服务实例上。

热点商品的路由问题，导致请求的倾斜

万一某个商品的读写请求特别高，全部打到相同的机器的相同的队列里面去了，可能造成某台机器的压力过大。就是说，因为只有在商品数据更新的时候才会清空缓存，然后才会导致读写并发，所以更新频率不是太高的话，这个问题的影响并不是特别大，但是的确可能某些机器的负载会高一些。

3、缓存雪崩、缓存穿透预防、解决方案

雪崩

在这里插入图片描述
解决方案：
事前：redis高可用，主从+哨兵，redis cluster，避免全盘崩溃
事中：本地ehcache缓存 + hystrix限流&降级，避免MySQL被打死
事后：redis持久化，快速恢复缓存数据

穿透

在这里插入图片描述
解决方案：
1、布隆过滤无效的key
2、返回结果为null，并写入redis中，并且设置过期时间
3、对于设置了过期时间的某个Key导致的缓存击穿，可以考虑使用双重检查加锁的方法来避免高并发下的数据库访问的增加，代码示例如下：

    public List<UsersDO> getAllUserWithNoPage(){

            try{
     
                //序列化器，将key的值设置为字符串
                RedisSerializer redisSerializer=new StringRedisSerializer();
                redisTemplate.setKeySerializer(redisSerializer);
     
                //查缓存
                List<UsersDO> list=(List<UsersDO>)redisTemplate.opsForValue().get("allUsers");
     
                if(null==list){
                    //双重检测 锁
                    synchronized (this) {
     
                        List<UsersDO> list1 = (List<UsersDO>) redisTemplate.opsForValue().get("allUsers");
                        if (null == list1) {
     
                            UsersQuery query=new UsersQuery();
                            list=usersDOMapper.selectByExample(query);
                            redisTemplate.opsForValue().set("allUsers", list);
     
                            System.out.println("从数据库中取数据");
                        }
                        else{
                            System.out.println("从缓存中取数据");
                        }
                    }
                }
                else{
                    System.out.println("从缓存中取数据");
                }
                return list;
            }
            catch (Exception e) {
                logger.error("UserService.getAllUserWithNoPage error",e);
            }
            return null;
        }

4、redis 的线程模型是什么？为什么 redis 单线程却能支撑高并发？

redis 内部使用文件事件处理器 file event handler，这个文件事件处理器是单线程的，所以 redis 才叫做单线程的模型。它采用 IO 多路复用机制同时监听多个 socket，根据 socket 上的事件来选择对应的事件处理器进行处理。

文件事件处理器的结构包含 4 个部分：

多个 socket
IO 多路复用程序
文件事件分派器
事件处理器（连接应答处理器、命令请求处理器、命令回复处理器）

多个 socket 可能会并发产生不同的操作，每个操作对应不同的文件事件，但是 IO 多路复用程序会监听多个 socket，会将 socket 产生的事件放入队列中排队，事件分派器每次从队列中取出一个事件，把该事件交给对应的事件处理器进行处理。

来看客户端与 redis 的一次通信过程：
在这里插入图片描述
客户端 socket01 向 redis 的 server socket 请求建立连接，此时 server socket 会产生一个 AE_READABLE 事件，IO 多路复用程序监听到 server socket 产生的事件后，将该事件压入队列中。文件事件分派器从队列中获取该事件，交给连接应答处理器。连接应答处理器会创建一个能与客户端通信的 socket01，并将该 socket01 的 AE_READABLE 事件与命令请求处理器关联。

假设此时客户端发送了一个 set key value 请求，此时 redis 中的 socket01 会产生 AE_READABLE 事件，IO 多路复用程序将事件压入队列，此时事件分派器从队列中获取到该事件，由于前面 socket01 的 AE_READABLE 事件已经与命令请求处理器关联，因此事件分派器将事件交给命令请求处理器来处理。命令请求处理器读取 socket01 的 key value 并在自己内存中完成 key value 的设置。操作完成后，它会将 socket01 的 AE_WRITABLE 事件与命令回复处理器关联。

如果此时客户端准备好接收返回结果了，那么 redis 中的 socket01 会产生一个 AE_WRITABLE 事件，同样压入队列中，事件分派器找到相关联的命令回复处理器，由命令回复处理器对 socket01 输入本次操作的一个结果，比如 ok，之后解除 socket01 的 AE_WRITABLE 事件与命令回复处理器的关联。

这样便完成了一次通信。
为啥 redis 单线程模型也能效率这么高？

纯内存操作
核心是基于非阻塞的 IO 多路复用机制
单线程反而避免了多线程的频繁上下文切换问题

5、redis数据类型，使用场景

redis 主要有以下几种数据类型：

string
hash
list
set
sorted set

详情参考：https://www.runoob.com/w3cnote/redis-use-scene.html

6、redis 的过期策略都有哪些？内存淘汰机制都有哪些？

Redis的过期策略

我们都知道，Redis是key-value数据库，我们可以设置Redis中缓存的key的过期时间。Redis的过期策略就是指当Redis中缓存的key过期了，Redis如何处理。
过期策略通常有以下三种：

定时过期：每个设置过期时间的key都需要创建一个定时器，到过期时间就会立即清除。该策略可以立即清除过期的数据，对内存很友好；但是会占用大量的CPU资源去处理过期的数据，从而影响缓存的响应时间和吞吐量。
惰性过期：只有当访问一个key时，才会判断该key是否已过期，过期则清除。该策略可以最大化地节省CPU资源，却对内存非常不友好。极端情况可能出现大量的过期key没有再次被访问，从而不会被清除，占用大量内存。
定期过期：每隔一定的时间，会扫描一定数量的数据库的expires字典中一定数量的key，并清除其中已过期的key。该策略是前两者的一个折中方案。通过调整定时扫描的时间间隔和每次扫描的限定耗时，可以在不同情况下使得CPU和内存资源达到最优的平衡效果。

(expires字典会保存所有设置了过期时间的key的过期时间数据，其中，key是指向键空间中的某个键的指针，value是该键的毫秒精度的UNIX时间戳表示的过期时间。键空间是指该Redis集群中保存的所有键。)
Redis中同时使用了惰性过期和定期过期两种过期策略。