Redis知识点
一、Redis基础
1、什么是Redis?
2、Redis常用的数据类型?
-
Redis提供了丰富的数据类型
-
string(相当于与Java中的String) 它是一个二进制安全的字符串,意味着它不仅能够存储字符串、JSNO、还能存储图片、视频等多种类型(生成二进制或者序列化的对象), 最大长度支持512M
-
hash(相当于java中的HashMap)采用key-value 存储对象 ,hash类型下的value只能存储字符串,不允许存储其他类型数据,不存在嵌套现象。如果数据未获取到,对应的值为(nil)
-
list:(相当于Java中的Likelist) 存储有序集合,底层使用双向链表存储结构实现
-
set:(相当于Java中的HashSet)存储无序集合,不可存储重复数据
-
zse:(相当于Java中的TreeSet)存储有序集合,不可存储重复数据,zset对每个元素都会关联一个 double 类型的分数,利用该分数作为排序的依据。有序集合可以利用分数进行从小到大的排序。虽然有序集合的成员是唯一的,但是分数(score)却可以重复。就比如在一个班中,学生的学号是唯一的,但是每科成绩却是可以一样的,redis可以利用有序集合存储学生成绩快速做成绩排名功能
-
3、Redis持久化机制?
-
Rdis提供了两种持久化机制分别为:RDB AOF
-
RDB(默认持久化机制):采用快照的方式全量备份数据,以二进制序列化形式的文件存储,并且在存储上非常紧密,但是无法做到实时持久化
-
RDB持久化触发机制分为:手动触发和自动触发
-
手动触发:
save命令
:该命令会阻塞当前Redis服务器,执行save命令期间,Redis不能处理其他命令,直到RDB完成为止,如果数据量大的话会造成长时间的阻塞,所以线上环境一般禁止使用。bgsave命令
:执行该命令时,Redis会在后台异步进行快照操作,快照同时还可以响应客户端请求。具体流程如下:- 执行bgsave命令时,Redis主进程会fork一个子进程来完成RDB的过程,会先将数据写入到一个临时二进制文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件(可以理解为Copy On Write机制)。Redis主进程阻塞时间只有fork阶段的那一下。相对于save,阻塞时间很短。基本上 Redis 内部所有的RDB操作都是采用 bgsave 命令。
-
自动触发:配置redis.conf,触发规则,自动执行
# 当在规定的时间内,Redis发生了写操作的个数满足条件,会触发发生BGSAVE命令。 # save <seconds> <changes> # 当用户设置了多个save的选项配置,只要其中任一条满足,Redis都会触发一次BGSAVE操作 save 900 1 save 300 10 save 60 10000 # 以上配置的含义:900秒之内至少一次写操作、300秒之内至少发生10次写操作、 # 60秒之内发生至少10000次写操作,只要满足任一条件,均会触发bgsave
-
-
-
AOF:采用日志的方式记录对数据操作的命令,可做到实时持久化,AOF默认是关闭的,通过redis.conf配置文件进行开启
- AOF持久化触发机制:
- (1)每修改同步:appendfsync always 同步持久化,每次发生数据变更会被立即记录到磁盘,性能较差但数据完整性比较好
- (2)每秒同步:appendfsync everysec 异步操作,每秒记录,如果一秒内宕机,有数据丢失。
- (3)不同步:appendfsync no 从不同步
- AOF持久化触发机制:
二、Redis高级
1、什么是Redis的事务?
-
redis事务就是一次性、顺序性、排他性的执行一个队列中的一系列命令。
- **Redis事务没有隔离级别的概念:**批量操作在发送 EXEC 命令前被放入队列缓存,并不会被实际执行,也就不存在事务内的查询要看到事务里的更新,事务外查询不能看到
- **Redis不保证原子性:**Redis中,单条命令是原子性执行的,但事务不保证原子性,且没有回滚。事务中任意命令执行失败,其余的命令仍会被执行
-
Redis事务的三个阶段:
- 开始事务
- 命令入列
- 执行事务
-
Redis事务相关命令:
- watch key1 key2 … : 监视一或多个key,如果在事务执行之前,被监视的key被其他命令改动,则事务被打断 ( 类似乐观锁 )
- multi : 标记一个事务块的开始( queued )
- exec : 执行所有事务块的命令 ( 一旦执行exec后,之前加的监控锁都会被取消掉 )
- discard : 取消事务,放弃事务块中的所有命令
- unwatch : 取消watch对所有key的监控
2、Redis做缓存会遇到的问题?
1.缓存穿透
- 缓存穿透是指查询一个数据库一定不存在的数据,其次redis缓存中也没有该数据(比如id=-1)
- 解决方案:
- (1) 缓存空对象 :如果从数据库查询的对象为空,也放入缓存,key为用户提交过来的主键值,value为null,只是设定的 缓存过期时间较短,比如设置为60秒。这样下次用户再根据这个key查询redis缓存就可以查询到值了 (当然值为null),从而保护我们的数据库免遭攻击。
- (2) 布隆过滤器:判定不存在的数据,那么该数据一定不存在,利用它的这一特点可以防止缓存穿透。
- 解决方案:
2.缓存击穿
- 缓存击穿,是指一个key非常热点(例如双十一期间进行抢购的商品数据),在不停的扛着大并发,大 并发集中对这一个点进行访问,当这个key在失效的瞬间,持续的大并发就穿破缓存,直接请求到数据库 上,就像在一个屏障上凿开了一个洞。
- 解决方案:
- (1)设置热点数据永不过期
- (2)加互斥锁:使用分布式锁,保证对于每个key同时只有一个线程去查询后端服务,其他线程没有获得分布式锁的权 限,因此只能等待。这种方式将高并发的压力转移到了分布式锁,因此对分布式锁的考验很大。
- 解决方案:
3.缓存雪崩
- 缓存雪崩是指缓存中大批量的 key 同时过期,而此时数据访问量又非常大,从而导致后端数据库压力突然暴增,甚至会挂掉,这种现象被称为缓存雪崩。它和缓存击穿不同,缓存击穿是在并发量特别大时,某一个热点 key 突然过期,而缓存雪崩则是大量的 key 同时过期,因此它们根本不是一个量级
- 解决方案:
- (1)redis高可用:搭建集群
- (2)限流降级:在缓存失效后,通过加锁或者队列来控制读数据库写缓存的线程数量。比如对 某个key只允许一个线程查询数据和写缓存,其他线程等待。
- (3)数据预热:数据加热的含义就是在正式部署之前,我先把可能的数据先预先访问一遍,这样部分可能大量访问的数 据就会加载到缓存中。在即将发生大并发访问前手动触发加载缓存不同的key,设置不同的过期时间,让 缓存失效的时间点尽量均匀。
- 解决方案:
3、Redis的集群方案
- 单机Redis的读写速度非常快,能够支持大量用户的访问。虽然Redis的性能很高,但是对于大型网站来 说,每秒需要获取的数据远远超过单台redis服务所能承受的压力,所以我们迫切需要一种方案能够解决 单台Redis服务性能不足的问题。这就需要使用到Redis的集群了。Redis集群有多种方案,下面分别进行 讲解。
1.主从复制(Replication)
-
指将一台Redis服务器的数据,复制到其他的Redis服务器
-
角色:前者称为主节点(master/leader),后者称为从节点(slave/follower)
-
原则:数据的复制是单向的,只能由主节点到从节点
-
同步:Master以写为主,Slave 以读为主,Slave启动时会连接master来同步数据(读写分离)
-
默认情况下,每台Redis服务器都是主节点,且一个主节点可以有多个从节点(或没有从节点),但一个从节点只能有一个主节点
-
-
主从复制的作用:数据冗余:主从复制实现了数据的热备份,是持久化之外的一种数据冗余方式。
-
故障恢复:当主节点出现问题时,可以由从节点提供服务,实现快速的故障恢复;实际上是一种服务的冗余
- 负载均衡:在主从复制的基础上,配合读写分离,可以由主节点提供写服务,由从节点提供读服务
- 即写Redis数据时应用连接主节点,读Redis数据时应用连接从节点,分担服务器负载;尤其是 在写少读多的场景下,通过多个从节点分担读负载,可以大大提高Redis服务器的并发量。
- 负载均衡:在主从复制的基础上,配合读写分离,可以由主节点提供写服务,由从节点提供读服务
-
高可用(集群)基石:除了上述作用以外,主从复制还是哨兵和集群能够实施的基础,因此说主从复制是Redis高可用的基础
- 单台Redis最大的实用内存不应该超过20G
-
2.哨兵(sentinel)
-
sentinel(哨兵)是用于监控redis集群中Master状态的工具,其本身也是一个独立运行的进程,是Redis的高可用解决方案
- 原理:哨兵通过发送命令,等待Redis服务器响应,从而监控运行的多个Redis实例
-
故障切换(failover)
- 假设主服务器宕机,哨兵1先检测到这个结果,系统并不会马上进行 failover过程,仅仅是哨兵1主观的认为主服务器不可用,这个现象成为主观下线。当后面的哨兵也检测 到主服务器不可用,并且数量达到一定值时,那么哨兵之间就会进行一次投票,投票的结果由一个哨兵发起,进行failover操作。切换成功后,就会通过发布订阅模式,让各个哨兵把自己监控的从服务器实现 切换主机,这个过程称为客观下线。这样对于客户端而言,一切都是透明的
- 假设主服务器宕机,哨兵1先检测到这个结果,系统并不会马上进行 failover过程,仅仅是哨兵1主观的认为主服务器不可用,这个现象成为主观下线。当后面的哨兵也检测 到主服务器不可用,并且数量达到一定值时,那么哨兵之间就会进行一次投票,投票的结果由一个哨兵发起,进行failover操作。切换成功后,就会通过发布订阅模式,让各个哨兵把自己监控的从服务器实现 切换主机,这个过程称为客观下线。这样对于客户端而言,一切都是透明的
-
优点:
-
在Master主服务器发生故障的时候,可以实现Master和Slave服务器的切换,保证系统的高可用 (HA)(选举)
-
基于主从复制模式,所有的主从配置优点,它全有
-
哨兵可以做集群
-
主从自动切换,故障可以转移,提高系统可用性
-
-
缺点:
- Redis不好在线扩容,集群一旦到达上线,在线扩容就十分麻烦
- 哨兵模式的配置比较麻烦
切换,保证系统的高可用 (HA)(选举)
-
基于主从复制模式,所有的主从配置优点,它全有
-
哨兵可以做集群
-
主从自动切换,故障可以转移,提高系统可用性
-
缺点:
- Redis不好在线扩容,集群一旦到达上线,在线扩容就十分麻烦
- 哨兵模式的配置比较麻烦