1.redis 是什么?
redis 是 nosql(也是个巨大的 map) 单线程,但是可处理 1 秒 10w 的并发(数据都在内存中)
使用 java 对 redis 进行操作类似 jdbc 接口标准对 mysql,有各类实现他的实现类,我们常用的是 druid
其中对 redis,我们通常用 Jedis(也为我们提供了连接池 JedisPool) 在 redis 中 , key 就是 byte[](string)
redis 的数据结构(value): String , list , set , orderset , hash 。
每种数据结构对应不同的命令语句~
2.redis 怎么使用?
先安装好 redis,然后运行,在 pom 文件中引入依赖,在要使用 redis 缓存的类的 mapper.xml 文件配置 redis 的全限定名。引入 redis 的 redis.properties 文件(如果要更改配置就可以使用)
3.应用场景:
String :
1 存储 json 类型对象,2 计数器,3 优酷视频点赞等
list(双向链表)
1 可以使用 redis 的 list 模拟队列,堆,栈
2 朋友圈点赞(一条朋友圈内容语句,若干点赞语句)
规定:朋友圈内容的格式:
1 内容: user:x:post:x content 来存储;
2 点赞: post:x:good list 来存储;(把相应头像取出来显示)
hash(hashmap)
1 保存对象
2 分组
4.为什么 redis 是单线程的都那么快?
1.数据存于内存
2.用了多路复用 I/O
3.单线程
5.redis 也可以进行发布订阅消息吗?
可以,(然后可以引出哨兵模式(后面会讲)怎么互相监督的,就是因为每隔 2 秒哨兵节点会发布对某节点的判断和自身的信息到某频道,每个哨兵订阅该频道获取其他哨兵节点和主从节点的信息,以达到哨兵间互相监控和对主从节点的监控)和很多专业的消息队列系统(例如 Kafka、RocketMQ)相比,Redis 的发布订阅略显粗糙,例如无法实现消息堆积和回溯。但胜在足够简单。
6.redis 能否将数据持久化,如何实现?
能,将内存中的数据异步写入硬盘中,两种方式:RDB(默认)和 AOF
RDB 持久化原理:通过 bgsave 命令触发,然后父进程执行 fork 操作创建子进程,子进程创建 RDB 文件,根据父进程内存生成临时快照文件,完成后对原有文件进行原子替换(定时一次性将所有数据进行快照生成一份副本存储在硬盘中)
优点:是一个紧凑压缩的二进制文件,Redis 加载 RDB 恢复数据远远快于 AOF的方式。
缺点:由于每次生成 RDB 开销较大,非实时持久化。
AOF 持久化原理:开启后,Redis 每执行一个修改数据的命令,都会把这个命令添加到 AOF 文件中。
优点:实时持久化。
缺点:所以 AOF 文件体积逐渐变大,需要定期执行重写操作来降低文件体积,加载慢。
7.主从复制模式下,主挂了怎么办?
redis 提供了哨兵模式(高可用)
何谓哨兵模式?就是通过哨兵节点进行自主监控主从节点以及其他哨兵节点,发现主节点故障时自主进行故障转移。
8.哨兵模式实现原理?(2.8 版本或更高才有)
1.三个定时监控任务:
1.1 每隔 10s,每个 S 节点(哨兵节点)会向主节点和从节点发送 info 命令获取最新的拓扑结构。
1.2 每隔 2s,每个 S 节点会向某频道上发送该 S 节点对于主节点的判断以及当前 Sl 节点的信息,
同时每个 Sentinel 节点也会订阅该频道,来了解其他 S 节点以及它们对主节点的判断(做客观下线依据)
1.3 每隔 1s,每个 S 节点会向主节点、从节点、其余 S 节点发送一条 ping 命令做一次心跳检测(心跳检测机制),来确认这些节点当前是否可达。
2.主客观下线:
2.1 主观下线:根据第三个定时任务对没有有效回复的节点做主观下线处理。
2.2 客观下线:若主观下线的是主节点,会咨询其他 S 节点对该主节点的判断,超过半数,对该主节点做客观下线。
3.选举出某一哨兵节点作为领导者,来进行故障转移。选举方式:raft 算法。每个 S 节点有一票同意权,哪个 S 节点做出主观下线的时候,就会询问其他 S 节点是否同意其为领导者。获得半数选票的则成为领导者。基本谁先做出客观下线,谁成为领导者。
4.故障转移(选举新主节点流程)
9.redis 集群(采用虚拟槽方式,高可用)原理(和哨兵模式原理类似,3.0 版本或以上才有)?
1.Redis 集群内节点通过 ping/pong 消息实现节点通信,消息不但可以传播节点槽信息,还可以传播其他状态如:主从状态、节点故障等。因此故障发现也是通过消息传播机制实现的,主要环节包括:主观下线(pfail)和客观下线(fail)
2.主客观下线:
2.1 主观下线:集群中每个节点都会定期向其他节点发送 ping 消息,接收节点回复 pong 消息作为响应。如果通信一直失败,则发送节点会把接收节点标记为主观下线(pfail)状态。
2.2 客观下线:超过半数,对该主节点做客观下线
3.主节点选举出某一主节点作为领导者,来进行故障转移。
4.故障转移(选举从节点作为新主节点)
10.缓存更新策略(即如何让缓存和 mysql 保持一致性)
10.1 key 过期清除(超时剔除)策略
惰性过期(类比懒加载,这是懒过期):只有当访问一个 key 时,才会判断该 key 是否已过期,过期则清除。该策略可以最大化地节省 CPU 资源,却对内存非常不友好。极端情况可能出现大量的过期 key 没有再次被访问,从而不会被清除,占用大量内存。
定期过期:每隔一定的时间,会扫描一定数量的数据库的 expires 字典中一定数量的 key,并清除其中已过期的 key。该策略是前两者的一个折中方案。通过调整定时扫描的时间间隔和每次扫描的限定耗时,可以在不同情况下使得 CPU 和内存资源达到最优的平衡效果。
(expires 字典会保存所有设置了过期时间的 key 的过期时间数据,其中,key 是指向键空间中的某个键的指针,value 是该键的毫秒精度的 UNIX 时间戳表示的过期时间。键空间是指该 Redis 集群中保存的所有键。)
问:比如这么个场景,我设计了很多 key,过期时间是 5 分钟,当前内存占用率是 50%。但是 5 分钟到了,内存占用率还是很高,请问为什么?
Redis 中同时使用了惰性过期和定期过期两种过期策略,即使过期时间到了,但是有部分并没有真正删除,等待惰性删除。
为什么有定期还要有惰性呢?其实很简单,比如 10 万个 key 就要过期了,Redis 默认是 100ms 检查一波。如果他检查出 10 万个即将要清除,那他接下来的时间基本都是在干这些清空内存的事了,那肯定影响性能,所以他只会部分删除,剩下的等惰性。
10.2 Redis 的内存淘汰策略
Redis 的内存淘汰策略是指在 Redis 的用于缓存的内存不足时,怎么处理需要新写入且需要申请额外空间的数据。
noeviction:当内存不足以容纳新写入数据时,新写入操作会报错。
allkeys-lru:当内存不足以容纳新写入数据时,在键空间中,移除最近最少使用的 key。
allkeys-random:当内存不足以容纳新写入数据时,在键空间中,随机移除某个 key。
volatile-lru:当内存不足以容纳新写入数据时,在设置了过期时间的键空间中,移除最近最少使用的 key。
volatile-random:当内存不足以容纳新写入数据时,在设置了过期时间的键空间中,随机移除某个 key。
volatile-ttl:当内存不足以容纳新写入数据时,在设置了过期时间的键空间中,有更早过期时间的 key 优先移除。
11.缓存粒度控制?
下面这个图是很多项目关于缓存使用最常用的一个抽象,那么我们假设storage层为mysql, cache层为redis。
假如我现在需要对视频的信息做一个缓存,也就是需要对select * from video where id=?的每个id在redis里做一份缓存,这样cache层就可以帮助我抗住很多的访问量(注:这里不讨论一致性和架构等等问题,只讨论缓存的粒度问题)。
我们假设视频表有100个属性(这个真有,有些人可能难以想象),那么问题来了,需要缓存什么维度呢,也就是有两种选择吧:
(1)cache(id)=select * from video where id=#id
(2)cache(id)=select importantColumn1, importantColumn2 .. importantColumnN from video where id=#id
其实这个问题就是缓存粒度问题,我们在缓存设计应该佮预估和考虑呢?下面我们将从通用性、空间、代码维护三个角度进行说明。
全部数据和部分数据比较
1. 两者的特点是显而易见的:
2. 通用性:
如果单从通用性上看,全部数据是最优秀的,但是有个问题就是是否有必要缓存全部数据,认为以后会有这样的需求,但是从经验看除了非常重要的信息,那些不重要的字段基本不会在需求里出现,也就是说这种通用性 通常都是想象出来的。太多人觉得通用性是最重要的。vid拿一些基本信息,会想专辑明星。。要不要用通用性高的,于是加了全局的,通用性很重要,但是要想清楚。
3. 空间占用:
很显然,缓存全部数据,会占用大量的内存,有人会说,不就费一点内存吗,能有多少钱?而且已经有人习惯了把缓存当做下水道来使用,什么都框框的往里面放,但是我这里要说内存并不是免费的,可以说是很珍贵的资源。instagram21-->4G 的例子就说明了这个道理,好的程序员可以帮助公司节约大量的资源。
而且单个cache(id)也带来两个问题:序列化的开销和网络流量的开销(QPS,百倍),都是无容忽视的。
4. 代码维护:
代码维护性,全部数据的优势更加明显,而部分数据一旦要加新字段就会修改代码,而且还需要对原来的数据进行刷新。
缓存粒度问题是一个容易被忽视的问题,如果使用不当,可能会造成很多无用空间的浪费,可能会造成网络带宽的浪费,可能会造成代码通用性较差等情况,必须学会综合数据通用性、空间占用比、代码维护性 三点评估取舍因素权衡使用。
12.如何防止缓存穿透?
(缓存穿透指的是查询一个根本不存在的数据,缓存层不命中,又去查存储层,又不命中。但如果有大量这种查询不存在的数据的请求过来,会对存储层有较大压力,若是恶意攻击,后果就)
12.1:缓存空值存在的问题:
12.2:布隆过滤器:
布隆过滤器存在的问题:相对来说布隆过滤器搞起来代码还是比较复杂的,现阶段我们暂时还不需要,后面实在需要再考虑去做,什么阶段做什么样的事情,不是说这个系统一下子就能做的各种完美。
13.无底洞优化?
造成原因:redis 分布式越来越多,导致性能反而下降,因为键值分布到更多的节点上,所以无论是 Memcache 还是 Redis 的分布式,批量操作通常需要从不同节点上获取,相比于单机批量操作只涉及一次网络操作,分布式批量操作 会涉及多次网络时间。 即分布式过犹不及。
14.雪崩优化
如果缓存层由于某些原因不能提供服务,于是所有的请求都会达到存储层,存储层的调用量会暴增,造成存储层也会级联宕机的情况。
15.热点 key 优化
当前 key 是一个热点 key(例如一个热门的娱乐新闻),并发量非常大。