一、Redis的数据结构及应用场景

  • String:存储字符串类型数据,一般用来存储json格式的对象数据
  • List:存储列表数据,应用场景可以用来做秒杀场景,提前将商品放到list中,因为redis的pop操作是原子性的,多个用户同时请求也是依次pop,list为空了则说明商品卖完了
  • Hash:存储结构体数据,类似于java的HashMap,底层数据结构是数组+链表,应用场景同样是存储结构化的对象数据,不同于string类型的是,hash可以将每个字段单独存储,需要取的时候可以根据字段只取对应的数据,无需像string类型那样全部取出
  • Set:存储不重复且无序的数据,类似于java的HashSet,底层用的是HashMap,其value为null,应用场景用于对数据去重
  • Zset:存储有序的不重复的数据,是java的sortedSet和HashMap的结合体,一方面是set,保证了内部value的唯一性,另一方面对每个value设置了一个score权重值,根据score进行排序,应用场景是各类热门排序场景,比如音乐的榜单,歌曲ID是value,根据播放次数是score,这样就可以根据播放次数score进行排序

二、redis的持久化机制

  • RDB:
    • 持久化原理:全称是Redis DataBase,将数据以快照的形式保存在磁盘上,是某个时间点上所有数据的备份,是redis默认的持久化方式。
    • 触发条件:手动触发:通过命令save或者bgSave持久化,自动触发:在redis.conf文件中配置触发的条件,比如900秒内有一个key值变化
    • 优点:因为RDB是保存的快照,特别适合容灾恢复,直接将快照导入到redis中即可恢复数据
    • 缺点:因为RDB是进行全量备份,对于数据集比较大的场景,需要好几分钟才能备份完成,因此设置的触发条件时间也必须是几分钟,当节点故障时,就要丢失几分钟的数据
  • AOF:
    • 描述:全称是Append-Only File,全量备份往往是比较耗时的,这时我们需要一种比较高效的备份方式。
    • 持久化原理:AOF是将写入数据的命令通过write函数追加到文件中。
    • 触发条件:每次修改触发、每秒触发、不触发,默认是每秒触发
    • 优点:鉴于AOF的触发条件,当发生系统故障时,最多只会丢失一秒钟的数据
    • 缺点:AOF存储的是写入的命令,因此文件会比RDB大很多,并且在进行故障恢复时,效率也低于RDB
  • 参考RDB与AOF的区别Redis持久化之RDB与AOF

三、redis雪崩、击穿和穿透

  • 雪崩
    • 描述:redis缓存大面积失效,导致请求直接落到数据库上,数据库承受不住压力,直接挂了
    • 原因:造成雪崩的原因有两种,一:redis故障,无法接受请求;二:redis上的缓存有效期大面积到期
    • 解决:对于第一种原因,可以提高redis的高可用,做缓存降级,在本地使用EhCache缓存,第二种原因,可以随机设置缓存的有效期,使其在不同的时间失效
  • 击穿
    • 描述及原因:redis热点缓存失效,热点key在承受着高并发,当这个热点key失效之后,所有请求会直接落在数据库上,导致数据库宕机
    • 解决:
      • 1、设置热点key永不过期
      • 2、加互斥锁,请求A访问数据库时,其他请求需要等待,等请求A查询完成,添加到redis中,其他请求发现redis已经有数据了,就不会再请求数据库了
  • 穿透
    • 描述及原因:请求的数据在缓存和数据库中都不存在,请求就一直落到数据库中,导致数据库压力过大宕机
    • 解决:
      • 1、对不存在的数据,将key和value为null的数据缓存起来,并设置一个较短的过期时间,防止过期时间过长,影响其他用户使用
      • 2、做接口参数校验,拦截掉非法的请求
      • 3、对同一时间内请求次数过多的非法请求IP做封号处理
  • 参考:redis缓存雪崩,击穿,穿透,到底是什么?

四、保证redis高可用

  • 主从架构
    • 主从复制:
      • 1、一个slave节点第一次连接或者重新连接到master节点时,会发送一个SYNC命令给master
      • 2、master收到这个命令之后,会干两件事,1)执行bgsave,即将缓存中的数据创建一个RDB快照文件,2)将新收到的写入和修改数据集命令保存到缓冲区
      • 3、master节点将创建的RDB文件传输给slave节点,slave节点则清空自己的内存,加载RDB文件的内存中
      • 4、master节点缓冲区的命令传送给slave节点,slave节点执行这些命令,达到主从数据的一致性
      • 5、此后master/slave节点会通过异步请求方式同步master收到的命令
    • 读写分离:master节点只处理写入和修改请求,并同时同步给slave节点,slave节点只处理查询请求
  • 哨兵模式
    • 描述:主从架构中,只有一个主节点,一旦主节点发生异常宕机,整个系统将瘫痪不可用,于是需要一个哨兵模式来检测主节点状态及主从切换
    • 监测:哨兵周期性地向所有节点发送类似ping命令,看是否能正常应答,如果不能,则主观判定为下线,如果哨兵群的多数(n/2+1)判定主观下线,则认为客观下线
    • 选主:一旦认定主节点下线,就要开始选择新的主节点。一般会将选择主节点的过程分为“筛选+打分”,就是从所有从节点中过滤掉经常掉线的和网络不好的,然后将剩下的节点按照从库优先级从库复制进度从库ID依次判定,即从库优先级最高的作为新的主节点,如果全都一样,则判定从库从主库上的复制进度,进度最高的当选主节点,如果进度全都一样,则判定从库ID,ID小的当选主节点,选定好新的主节点时,就可以开始进行主从切换了
  • 拓展
    • 1、哨兵模式中,哨兵宕机了,怎么保证主从切换?:哨兵模式中,哨兵也会采取集群模式,至少需要三个哨兵组成集群,当一个哨兵宕机,另外的哨兵依然可以正常工作
    • 2、主从切换进行中,客户端能正常请求操作吗?:如果redis采用的是读写分离,那么读请求可以正常响应,写请求则会失败
  • 参考redis高可用之哨兵模式

五、redis实现分布式锁

  • 加锁
    • 加锁其实就是在redis新增一个键值,为避免死锁,设置过期时间
    • 发送命令set key value nx px time
    • 命令解释:nx-设置成功返回1,失败返回0,px-过期时间,time-毫秒时间
    • 加锁过程:使用上面命令尝试执行,如果返回1则说明加锁成功,返回0则说明加锁失败,遇到加锁失败,本地不断尝试加锁,直到成功,即可完成分布式锁的实现
  • 解锁
    • 使用del命令将key删除,达到解锁目的
内容来源于网络如有侵权请私信删除

文章来源: 博客园

原文链接: https://www.cnblogs.com/jorry-yun/p/14752313.html

你还没有登录,请先登录注册
  • 还没有人评论,欢迎说说您的想法!