总结一期Redis

• redis

  • 好处

    • 主要就是缓存热点数据的,减轻服务器压力, 在详情页还有单点登录都用到过. 我们在项目的活动模块用过,APP端的首页展示的数据都是使用redis存储的热点数据,因为用户进入APP的时候首先进入是首页,使用的hash数据类型存储首页信息.

      • 为什么快 主要有这么几点,第一呢就redis的数据都是存储到内存中的加载比较快,第二点呢是redis中数据结构比较简单,还有第三个原因是他是单线程的,避免了上下文进行切换和竞争条件,第四点他使用的是多路I/O复用模型,非阻塞IO(红色字体作为理解).第五来说redis使用的底层模型不同,Redis直接自己构建的VM机制

  • 使用

  • 数据类型

    • redis常用数据类型 我了解的有String,list、set、hash、sortedSet list，我们可以向list的两端添加数据 集合set，存放的数据是无序的，集合中的数据是不重复的，由于它是无序的，所以不能通过下标来获取制定元素、order set有序集合、 hash 我们项目中常用的也就是string 和hash还有list redis是通过key-value存储的 set key value string hset key value hget key value

    • redis操作使用 项目中SpringBoot整合的Redis,操作的时候是用Spring给提供的那个模版RedisTemplate去操作的Redis<第一展开>，我们开发的时候用的是单机版,项目上线用的是集群版本<第二展开>我们mysql和redis的数据同步<第三展开>

      • 第一展开

        • redis实现消息队列 我知道的redis实现消息队列的方式有两种，第一种是用他本身的list数据类型，他有一个lpush和rpuop命令，可以使用lpush从集合左边添加进去数据,使用rpop命令从右边拿取数据。 第二种实现方式：redis还提供了一组命令可以让开发者实现"发布/订阅"(publish/subscribe)模式。"发布/订阅"模式也可以实现进程间的消息传递，我们项目中的消息队列都是用RabbitMQ实现的。

          • redis持久化

            • 数据存储 有RDB和AOF这两种，RDB是一种快照的方式来存储的，这也是redis的默认的持久化方式，每隔一段对数据进行一次存储， 还有一种是AOF是，只要数据发生改变都会保存到硬盘一份,这种方式对数据的保存完整性比较高，但是性能比较差。而RDB存在的问题主要是服务器宕机或者断电，会造成数据丢失,<redis持久化数据丢失>我们项目上使用的是RDB,因为rdb的性能好一些.

              • redis持久化数据丢失 - RDB：Redis 会周期性地将内存中的数据快照存储到硬盘上的 RDB 文件中。如果存储到硬盘的 RDB 文件被删除了，Redis 可以通过最近一次的 RDB 文件进行恢复。但是，如果最近一次的 RDB 文件也被删除了，那么 Redis 就无法进行恢复，数据会丢失。 - AOF：Redis 会将每个写操作追加到 AOF 文件中，如果存储到硬盘的 AOF 文件被删除了，Redis 可以通过重放 AOF 文件中的操作进行恢复。因此，即使存储到硬盘的 AOF 文件被删除了，Redis 也可以通过重放 AOF 文件中的操作进行恢复，数据不会立即丢失。 总之，如果 Redis 使用了持久化机制，即使存储到硬盘的数据被删除了，Redis 也可以通过持久化文件中的数据进行恢复，数据不会立即丢失。但是，如果最近一次的持久化文件也被删除了，那么 Redis 就无法进行恢复，数据会丢失。

      • 第二展开

        • redis集群 Redis本身就支持集群操作redis_cluster，另外redis还支持主从复制，以前的老版本中有一个哨兵模式，在主服务器宕机时，从服务器可以自动转换为主服务器。我们公司搭建的redis集群是用的ruby脚本配合搭建的,我们一共搭建了6台服务器,3主3备,他们之间通信的原理是有一个乒乓协议进行通信的,他们判断一个节点的状态是用投票选举机制判断的,半数以上判断一个接口是宕机了的话,备用节点就会启动,对,我再给你说下一他们往里存储数据的机制吧,其实这个redis搭建好集群以后每个节点都存放着一个hash槽,每次往里存储数据的时候,redis都会根据存储进来的key值算出一个hash值,通过这个hash值可以判断到底应该存储到哪一个哈希槽中,取的时候也是这么取的<集群之间的复制>

          • 集群之间复制 是通过在从服务器的redis.conf文件里配置主服务器的节点ip他们之间采用的是心跳机制,说白了就是每隔一秒钟发送一个 replconf ack命令,

      • 第三展开

        • redis数据同步 数据是存在redis中的，数据库里的数据更新以后，我们会把redis里的缓存清空一下。让他第一次查的时候从数据库里查，第二个用户再进来的时候就是从Redis中取了,同步的时候有可能会出现数据错乱问题,我们项目中用的是分布式锁解决的.

          • redis缓存处理机制 你是说的是redis服务器内存满了如何清理是吧,可以在配置文件中设置： redis最大内存不足"时,数据清除策略,默认为"volatile-lru"。volatile-lru ->对"过期集合"中的数据采取LRU(近期最少使用)算法.还有一个策略是volatile-random ->对"过期集合"中的数据采取"随即选取"算法,并移除选中的K-V,直到"内存足够"为止.

    • redis缓存预热 知道，缓存预热我们是系统上线后，提前将相关的缓存数据直接加载到缓存系统。避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题！用户直接查询事先被预热的缓存数据！ 缓存预热解决方案: 直接写个缓存刷新页面，上线时手工操作下；数据量不大，可以在项目启动的时候自动进行加载；定时刷新缓存。

    • Redis 的内存回收机制

      • redis最大内存不足"时,数据清除策略,默认为"volatile-lru"。volatile-lru ->对"过期集合"中的数据采取LRU(近期最少使用)算法.还有一个策略是volatile-random ->对"过期集合"中的数据采取"随即选取"算法,并移除选中的K-V,直到"内存足够"为止.

  • 问题

    • 雪崩穿透 你是说的那个缓存雪崩和缓存穿透,,我知道缓存雪崩是因为redis中多个key同时失效后,又遇到高并发后就会造成大量的请求直接请求数据库,导致数据库服务器宕机的情况,一般这种情况我们会给redis中的key设置不同的生命周期就能解决,或者是我们给使用分布式锁来解决;还有缓存穿透的话就是大并发请求过来,查询一个连数据库都没有的数据,频繁的请求数据库导致数据库宕机,这种解决方案是我们会存到redis一个key值value为null,给个失效时间,也可以避免这种问题.

  • 分布式锁

    • redis分布式锁 我们使用redis 我们用的是Redis的分布式锁,用过里面的setnx结合的lua脚本去使用的,但是这种锁单个的Redis服务器使用没有问题,测试时候单机没有问题,如果是Redis集群就不行了,因为他那个锁有可能在主服务还没有同步到从服务器的时候,主服务器宕机了,锁就找不到了,我们就得用Redisson这个框架去实现了,他里面提供的一个监控锁的机制,这个框架提供了很多种分布式锁的解决方案,比如可重入锁,还有读写锁,还有什么异步锁,直接使用就行.里面我的记的有trylock和unlock这些个方法.这个分布式锁的使用场景,是在把数据库里的数据同步到redis的时候使用的.

      • redis看门狗机制 守护线程检测server是不是还在执行业务，如果业务还在执行而且锁要过期了，重新给锁设置过期时间

      • 可重入锁 可重入锁这种锁可以允许多个线程同时获取锁，但在任何给定时间只有一个线程可以执行受保护的代码块。 他借助底层的一个voaltile的一个state变量来记录重入的状态的，比如当前没有人持有这把锁，那么state=0，假如有人持有这把锁，那么state=1，如果持有这把锁的人再次持有这把锁，那么state就会+1 ，释放一次就-1 ，直到减少成0 时，表示当前这把锁没有被人持有