面试笔记-3.Redis

最新推荐文章于 2022-06-12 00:21:03 发布

Tiglle

最新推荐文章于 2022-06-12 00:21:03 发布

阅读量193

点赞数

分类专栏：面试笔记

本文链接：https://blog.csdn.net/Tiglle/article/details/114704521

版权

面试笔记专栏收录该内容

9 篇文章 1 订阅

订阅专栏

一
1.Memcache和Redis的区别

Memcache
1.只支持简单数据类型，代码层次类似于hash
2.不支持数据持久化
3.不支持主从
4.不支持分片
Redsi
1.支持多种数据类型
2.支持数据持久化
3.支持主从
4.支持分片

2.Redis的分片

分割数据到多个Redis实例

redis分片存储算法有两种：
-------1.最简单的分区方式为范围分区，就是映射一定范围的对象到特定的Redis实例。比如，ID从0到10000的用户会保存到实例R0，ID从10001到20000的用户会保存到R1，以此类推。
-------2.另外一种方式是hash一致算法实现分区，对key值进行hash一致性计算后得到结果，最终将数据保存到某一台redis实例中

3.为什么redis那么快
在这里插入图片描述

1.首先，采用了多路复用io阻塞机制
2.然后，数据结构简单，操作节省时间
3.最后，运行在内存中，自然速度快
4.redis采用的I/O多路复用模型

二.

1.redis的数据类型，redis的交集，并集，差集,Keys Pattern指令

看此文章

不常用的HyPerLogLog,Geo类型

用于计数的HyPerLogLog，用于支持地理位置的Geo

2.redis的单个操作的原子性

原子性是数据库的事务中的特性。在数据库事务的情景下，原子性指的是：一个事务（transaction）中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。

3.Scan cursor指令

在这里插入图片描述

1.SCAN 命令是一个基于游标的迭代器（cursor based iterator）： SCAN 命令每次被调用之后，都会向用户返回一个新的游标，用户在下次迭代时需要使用这个新游标作为 SCAN 命令的游标参数，以此来延续之前的迭代过程。
2.当 SCAN 命令的游标参数被设置为 0 时，服务器将开始一次新的迭代，而当服务器向用户返回值为 0 的游标时，表示迭代已结束。
3.SCAN 命令的回复是一个包含两个元素的数组，第一个数组元素是用于进行下一次迭代的新游标，而第二个数组元素则是一个数组，这个数组中包含了所有被迭代的元素。
4.返回数量不可控，约等于count。
5分类：
-------1.SCAN 命令返回的每个元素都是一个数据库键。
-------2.SSCAN 命令返回的每个元素都是一个集合成员。
-------3.HSCAN 命令返回的每个元素都是一个键值对，一个键值对由一个键和一个值组成。
-------4.ZSCAN 命令返回的每个元素都是一个有序集合元素，一个有序集合元素由一个成员（member）和一个分值（score）组成。

4.SETNX key value 指令
在这里插入图片描述

SETNX(Set if Not Exists): SETNX KEY_NAME VALUE:在键 key 不存在的情况下，添加一个 key 的值设置为 value 的数据。

5.Expire key seconds指令(已有)
在这里插入图片描述
6.SET key value指令的详细参数

7.JedisUtil类的方法详解

看此文章

四

1.什么是分布式锁以及分布式锁解决的问题

当多个进程不在同一个系统之中时，使用分布式锁控制多个进程对资源的访问。

2.Redis如何实现分布式锁

看此文章

3.redis大量key同事过期注意事项
在这里插入图片描述
五

1.如何使用Redis做异步队列

Redis做异步队列之RPUSH、LPOP

2.Redis做异步队列之BLPOP、RPUSH
3.使用Redis做异步队列之pub/sub.png

命令：
实例1：subscribe topicKey:订阅并开始监听topicKey，有消息就消费
实例2：subscribe topicKey:订阅并开始监听topicKey，有消息就消费
topicKey不用事先创建
实例3：publish topicKey:发布消息，实例1和实例2都会接受到消息
缺点：消息阿布无状态，发送者发送后不知道接受者有没有接受到

六
1.Redis持久化之RDB持久化

1.RDB持久化可以将某个时间点上的数据库状态保存到一个RDB文件中，既可以手动执行，也可以根据服务器配置选项定期执行。因为RDB文件是保存在硬盘中的，所以即使Redis服务器进程退出，甚至运行Redis服务器的计算机停机，但只要RDB文件还在，Redis服务器就可以用它来还原数据库状态

自动持久化
2.配置RDB属性：在Redis安装目录新下的redis.conf
1.
save 900 1 //900秒之内有一条写入指令，就执行RDB操作
save 300 10//300秒之内有10条写入指令，就执行RDB操作
save 60 10000//60秒之内有1w条写入指令，就执行RDB操作
save “”//禁用RDB功能
2.stop-writes-on-bgsave-error yes//当备份进程出错时主进程就停止写入操作。
3.rdbcompression yes//是否压缩RDB文件
4.rdb文件位置：安装目录/src/下

手动持久化命令：
1.save：当SAVE命令执行时，Redis服务器会被阻塞，所以当SAVE命令正在执行时，客户端发送的所有命令请求都会被拒绝。只有在服务器完成SAVE命令、重新开始接受命令请求之后，客户端发送的命令才会被处理
2.bgsave：fork一个子进程来执行RDB，不阻塞服务进程。
3.lastsave：上一次执行RDB的时间戳

2.BGSAVE原理
在这里插入图片描述

3.RDB持久化的缺点
在这里插入图片描述

七

1.AOF持久化

RDB持久化是将进程数据写入文件，而AOF持久化(即Append Only File持久化)，则是将Redis执行的每次写命令记录到单独的日志文件中，当Redis重启时再次执行AOF文件中的命令来恢复数据。

2.AOF的命令追加（append）

AOF 程序根据接收到的命令数据，将命令转换为网络通讯协议的格式，然后将协议内容追加到服务器的 AOF 缓存中。

1.开启AOF配置:
appendonly yes Redis服务器默认开启RDB，关闭AOF；要开启AOF，需要在Redis安装目录新下的redis.conf配置文件中配置
2.文件名配置：
appendfilename “appendonly.aof” 默认名，可修改
3.写入策略配置
appendfsync everysec 值为如下
-------1.always 一旦缓存区的内容发生变化，就及时将缓存区的内容写入到磁盘（消耗性能）
-------2.everysec 每隔一秒就将缓存区的内容写入到磁盘。
-------3.no 缓存区内容发生变化不会马上写入到磁盘，由操作系统决定什么时候写入，一般为缓存区被填满在写入到磁盘（不安全，如果服务器崩溃，此次还没装满的缓存的内容会丢失）

4.AOF日志重写原理（解决AOF文件过大的问题）为什么要重写：随着时间的增加，旧AOF文件会越来越大，比如一个递归了100次的命令，旧AOF会记录100条命令，而重写后至记录1条，但标识执行次数100次。

5.RDB和AOF的优缺点

RDB
-------1.可以分时间备份不同的文件，就能在还原的时候选择不同文件还原版本。
-------2.RDB保存的是数据，恢复的时候直接将数据加载进内存，比AOF快。
-------3.如果对数据完整性要求高，不适合使用RDB
-------4.一般来说，RDB数据快照文件，都是每隔5分钟，或者更长时间生成一次，这个时候就得接受一旦Redis进程宕机，那么会丢失最近5分钟的数据；
AOF
-------1.因为是1秒执行一次，所以能够保证数据的完整性
-------2.因为AOF保存的是所有更改的命令，如果有大量更改操作，AOF文件将会很庞大。
-------3.AOF恢复数据比RDB慢，因为恢复的时候需要执行所有的指令。

6.RDB和AOF共存情况下的恢复流程：Redis会先检查有没有AOF文件，有就只加载AOF文件，没有在检查有没有RDB文件。图：RDB和AOF共存情况下的恢复流程.png

2.RDB-AOF混合持久化

aof-use-rdb-preamble yes 表示开启 RDB-AOF 混合持久化模式

开启混合持久化后，AOF重写时，会先写入全量数据，然后在追加增量命令，所以AOF文件前半段为RDB数据，后半段为AOF数据。

八

1.Redis的Pipeline

1.redis客户端执行一条命令分4个过程：发送命令－〉命令排队－〉命令执行－〉返回结果
2.执行多条命令的时候都需要等待上一条命令执行完毕才能执行
3.Pipeline可以一次性发送多条命令并在执行完后一次性将结果返回

2.Redis的集群

Redis有三种集群模式，分别是：
1.主从模式
2.Sentinel模式
3.Cluster模式

3.主从模式

在Redis中，用户可以通过执行SLAVEOF命令或者设置slaveof选项，让一个服务器去复制另一个服务器，我们称被复制的服务器为主服务器(master)，而对主服务器进行复制的服务器则被称为从服务器(slave)。

2.Redis的主从同步

分类：
1.全量同步:Redis全量复制一般发生在Slave初始化阶段，这时Slave需要将Master上的所有数据都复制一份。

------- 1）从服务器连接主服务器，发送SYNC命令；
-------2）主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令；
-------3）主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令；
-------4）从服务器收到快照文件后丢弃所有旧数据，载入收到的快照；
-------5）主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令；
-------6）从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；
2.增量同步:Redis增量复制是指Slave初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程。增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令。

总结：主从模式的弊端就是不具备高可用性，当master挂掉以后，Redis将不能再对外提供写入操作，因此sentinel应运而生。

2.Redis Sentinel哨兵

哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。

1.Redis Sentinel哨兵解决分布式宕机主从切换问题

1.通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。
2.当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。

总结：sentinel模式基本可以满足一般生产的需求，具备高可用性。但是当数据量过大到一台服务器存放不下的情况时，主从模式或sentinel模式就不能满足需求了，这个时候需要对存储的数据进行分片，将数据存储到多个R edis实例中。cluster模式的出现就是为了解决单机Redis容量有限的问题，将Redis的数据根据一定的规则分配到多台机器。

3.Cluster模式