首页 > 数据库 > > Redis 16 卷面试八股文重磅发布!
作者 | moon聊技术
出品 | moon聊技术(ID:onetraveller_llxz)
大家好,我是 moon。
redis 作为我们最常用的内存数据库,很多地方你都能够发现它的身影,比如说登录信息的存储,分布式锁的使用,其经常被我们当做缓存去使用。
可是,用了这么久的reids,你懂它吗?
1.什么是 redis?它能做什么?
2.redis 有哪八种数据类型?有哪些应用场景?
3.redis为什么这么快?
4.听说 redis 6.0之后又使用了多线程,不会有线程安全的问题吗?
5.redis 的持久化机制有哪些?优缺点说说
6. Redis的过期键的删除策略有哪些?
7. Redis的内存满了怎么办?
8.Redis 的热 key 问题怎么解决?
9.缓存击穿、缓存穿透、缓存雪崩是什么?怎么解决呢?
10.Redis 有哪些部署方式?
11.哨兵有哪些作用?
12.哨兵选举过程是怎么样的?
13.cluster集群模式是怎么存放数据的?
14.cluster的故障恢复是怎么做的?
15.主从同步原理是怎样的?
16.无硬盘复制是什么?

redis: redis 即 Remote Dictionary Server,用中文翻译过来可以理解为远程数据服务或远程字典服务。其是使用 C 语言的编写的key-value存储系统
应用场景:缓存,数据库,消息队列,分布式锁,点赞列表,排行榜等等
redis 总共有八种数据结构,五种基本数据类型和三种特殊数据类型。

五种基本数据类型:


官方数据 redis 可以做到每秒近10w的并发,这么快的原因主要总结为以下几点:
不会
其实 redis 还是使用单线程模型来处理客户端的请求,只是使用多线程来处理数据的读写和协议解析,执行命令还是使用单线程,所以是不会有线程安全的问题。
之所以加入了多线程因为 redis 的性能瓶颈在于网络IO而非CPU,使用多线程能提升IO读写的效率,从而整体提高redis的性能。
redis 有两种持久化的方式,AOF 和 RDB.

AOF:
AOF的优缺点


RDB:
RDB的优缺点

1.它是将某一时间点redis内的所有数据保存下来,所以当我们做「大型的数据恢复时,RDB的恢复速度会很快」
2.由于RDB的FROK子进程这种机制,队友给客户端提供读写服务的影响会非常小

过期策略通常有以下三种:

实际上Redis定义了「8种内存淘汰策略」用来处理redis内存满的情况:
热 key 就是说,在某一时刻,有非常多的请求访问某个 key,流量过大,导致该 redi 服务器宕机

解决方案:
缓存穿透:

解决方案:
缓存击穿:

解决方案:
缓存雪崩:

解决方案:

单机模式:这也是最基本的部署方式,只需要一台机器,负责读写,一般只用于开发人员自己测试
哨兵模式:哨兵模式是一种特殊的模式,首先Redis提供了哨兵的命令,哨兵是一个独立的进程,作为进程,它会独立运行。其原理是哨兵通过发送命令,等待Redis服务器响应,从而监控运行的多个Redis实例。它具备自动故障转移、集群监控、消息通知等功能。
cluster集群模式:在redis3.0版本中支持了cluster集群部署的方式,这种集群部署的方式能自动将数据进行分片,每个master上放一部分数据,提供了内置的高可用服务,即使某个master挂了,服务还可以正常地提供。
主从复制:在主从复制这种集群部署模式中,我们会将数据库分为两类,第一种称为主数据库(master),另一种称为从数据库(slave)。主数据库会负责我们整个系统中的读写操作,从数据库会负责我们整个数据库中的读操作。其中在职场开发中的真实情况是,我们会让主数据库只负责写操作,让从数据库只负责读操作,就是为了读写分离,减轻服务器的压力。
1.监控整个主数据库和从数据库,观察它们是否正常运行
2.当主数据库发生异常时,自动的将从数据库升级为主数据库,继续保证整个服务的稳定
1.第一个发现该master挂了的哨兵,向每个哨兵发送命令,让对方选举自己成为领头哨兵
2.其他哨兵如果没有选举过他人,就会将这一票投给第一个发现该master挂了的哨兵
3.第一个发现该master挂了的哨兵如果发现由超过一半哨兵投给自己,并且其数量也超过了设定的quoram参数,那么该哨兵就成了领头哨兵
4.如果多个哨兵同时参与这个选举,那么就会重复该过程,知道选出一个领头哨兵
选出领头哨兵后,就开始了故障修复,会从选出一个从数据库作为新的master
一个cluster集群中总共有16384个节点,集群会将这16384个节点平均分配给每个节点,当然,我这里的节点指的是每个主节点,就如同下图:

判断故障的逻辑其实与哨兵模式有点类似,在集群中,每个节点都会定期的向其他节点发送ping命令,通过有没有收到回复来判断其他节点是否已经下线。
如果长时间没有回复,那么发起ping命令的节点就会认为目标节点疑似下线,也可以和哨兵一样称作主观下线,当然也需要集群中一定数量的节点都认为该节点下线才可以,我们来说说具体过程:

1.当一个从数据库启动时,它会向主数据库发送一个SYNC命令,master收到后,在后台保存快照,也就是我们说的RDB持久化,当然保存快照是需要消耗时间的,并且redis是单线程的,在保存快照期间redis受到的命令会缓存起来
2.快照完成后会将缓存的命令以及快照一起打包发给slave节点,从而保证主从数据库的一致性。
3.从数据库接受到快照以及缓存的命令后会将这部分数据写入到硬盘上的临时文件当中,写入完成后会用这份文件去替换掉RDB快照文件,当然,这个操作是不会阻塞的,可以继续接收命令执行,具体原因其实就是fork了一个子进程,用子进程去完成了这些功能。
因为不会阻塞,所以,这部分初始化完成后,当主数据库执行了改变数据的命令后,会异步的给slave,这也就是我们说的复制同步阶段,这个阶段会贯穿在整个中从同步的过程中,直到主从同步结束后,复制同步才会终止。
我们刚刚说了主从之间是通过RDB快照来交互的,虽然看来逻辑很简单,但是还是会存在一些问题,但是会存在着一些问题。
1.master禁用了RDB快照时,发生了主从同步(复制初始化)操作,也会生成RDB快照,但是之后如果master发成了重启,就会用RDB快照去恢复数据,这份数据可能已经很久了,中间就会丢失数据
2.在这种一主多从的结构中,master每次和slave同步数据都要进行一次快照,从而在硬盘中生成RDB文件,会影响性能
为了解决这种问题,redis在后续的更新中也加入了无硬盘复制功能,也就是说直接通过网络发送给slave,避免了和硬盘交互,但是也是有io消耗
来源:https://mp.weixin.qq.com/s/w8y0EYO8rKIWiUVr3WwXRw
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/31535056/viewspace-3169699/ ,如需转载,请注明出处,否则将追究法律责任。