咱们一起来看看 redis 常问常用的面试题
http://www.redis.cn/ redis 中文网给了很明确且清晰的定义
[图片上传失败...(image-ff92fa-1650460734395)]
Redis 是一个开源(BSD许可)的,内存中的数据结构存储系统
Redis 可以用作数据库、缓存和消息中间件
支持的数据结构有 8 种
字符串(strings), 散列(hashes), 列表(lists), 集合(sets), 有序集合(sorted sets), bitmaps, hyperloglogs 和 geospatial
我靠这份pdf拿下了华为、科大讯飞等大厂的offer,比啃八股文要好太多了!https://blog.csdn.net/2401_87878486/article/details/144143953?spm=1001.2014.3001.5501
首先 redis 是单线程的,很多人认为单线程就一定慢,多线程就一定快,这是一个误解
可以持久化,有 2 种方式, RDB 和 AOF , redis 默认是支持 RDB 持久化
在指定时间间隔内将内存中的数据集快照写入到磁盘中,这就是快照 snapshot ,恢复快照的时候,是把快照文件读入到内存中。
redis 通过 fork 的方式创建一个子进程来专门做持久化的动作
[图片上传失败...(image-ef78c9-1650460734395)]
优势
劣势
AOF 是 redis 的另外一种持久化方式,以日志的形式记录每一个写操作,将 redis 执行过的写操作全部记录下来,只允许追加文件,不允许改写文件
[图片上传失败...(image-33c706-1650460734395)]
优势
劣势
简单的消息队列做发布订阅的功能,使用到 redis 中 List 数据结构,可以通过 lpush 和 rpop 写入和读取消息,这个仅仅适用于简单的消息队列,如果数据量大,要求数据一致性,性能要好等等,当然首选专业的消息队列组件
将经常需要访问的数据访问 redis 中,并且要设置好 redis 的内存最大限制和删除 key 的策略
例如网页访问量,点赞量等等,redis 支持自增和自减操作,数据都是在内存中,很适合做计数
redis 自带的命令 SETNX ,天然可以做分布式锁,用于管控多个节点的有序运行,当然 redis 自己也提供了 RedLock 给大家使用
RedLock 是个啥
Redis 官方站提供的基于 Redis 实现分布式锁的方式,它有如下特性:
- 容错性
只要大部分 Redis 节点存活就可以正常提供服务
- 安全特性
RedLock 是互斥访问的,永远只有一个 redis 客户端能拿到锁,执行操作
- 避免死锁
最终 redis 客户端都可能拿到锁,不会出现死锁的情况
使用 zset 做排行榜,top xx 等应用
redis 提供集合 set ,可以计算出共同的好友,共同的兴趣,等等应用
有 3 种方式:
定时过期,就是每当设置一个 key 的时候,都给这个 key 设置对应的定时器,当这个 key ttl 到期时,就将这个 key 删除掉
每个 key 都设置了过期时间就要弄一个定时器,这样非常消耗 cpu 资源,进而影响 redis 性能
定期过期,就是设置每隔一段时间,扫描 redis 中设置过期时间的 key,并且删除掉其中已经过期的 key。
惰性过期,就是每当访问这个 key 的时候,才去判断这个 key 是否失效,失效就删掉,若不访问,则这个 key 就一直存在内存中,会占用大量的内存
就是一组命令的集合,一个事务中所有的命令都会被序列化,在事务执行的过程,是按照顺序执行命令的,他们拥有
redis 的事务没有隔离级别的概念
redis 事务中,命令是这样执行的
命令放在事务中,并没有马上执行,而是发起执行命令的时候才会执行,通过 exec 触发
[图片上传失败...(image-5d1be3-1650460734395)]
redis 是单条指令保证原子性,但是事务不保证原子性
执行一个事务的流程是这个样子的:
原子性指的是,事务是一个不可分割的整体,要么一起成功,要么一起失败
执行事务前和执行事务后,数据的完整性都必须保持一致
多个事务同时在处理的时候,互不干扰,互补影响,各玩各的
指的是,事务一旦被提交,那么影响的数据是持久性的
Slave 启动成功连接到 master 后会发送一个 sync 命令
master 收到命令后,启动后台存盘进程,同时收集所有接收到用于修改数据库集命令,在后台进程执行完毕后,master 进程将传送整个数据文件给到 slave ,并完成一次同步
全量复制
slave 服务接收到 master 传过来的数据后,将其存盘并加载到内存
增量复制
master 将新的收集到的所有修改的命令依次传递给 slave ,并完成同步
一旦重新连接 master 节点,一次完全的全量同步就会被执行
哨兵模式,主要是用于实现 redis 集群的高可用
因为使用主从复制的方式,当 redis 主机宕机时,没有办法选举出一个主机出来,哨兵模式可以
[图片上传失败...(image-292f1e-1650460734395)]
哨兵的作用:
主观下线
如果 master 服务器宕机了,那么其中一个哨兵就会检测到,系统并不会马上执行 failover 的过程,仅仅是当前这个哨兵,判断 master 不可用,这个就是主观下线
客观下线
集群中一般哨兵也是集群的,若部署了 3 个哨兵
当其他两个哨兵也发现 master 服务器不可用的时候,那么哨兵之间就会产生投票,具体的投票算法我们后续再写,投票的结构由一个哨兵发起,进行 failover 故障转移的操作,切换成功之后,就会通过发布订阅模式,让每一个监控的哨兵把自己监控的服务器切换到这个 master 服务器上, 这个就是 客观下线