Redis常见问题整理

一时失言乱红尘 2023-09-26 23:37 166阅读 0赞

## 一、Redis使用场景相关问题 ##

--------------------

![在这里插入图片描述][7d8f00e865ec49c7a8b4f55aa47d08e0.png]

### 0. 单机版Redis部署 ###

--------------------

> 系统环境：CentOS7

1、下载Redis所需要的镜像

yum install -y gcc tcl

2、下载redis安装包

mkdir /soft
    cd /soft
    wget https://download.redis.io/releases/redis-6.2.4.tar.gz

3、解压缩：

tar -xvf redis-6.2.4.tar.gz

![在这里插入图片描述][3db1489ef1bc43bb9b3723edb87c77f0.png]

4、进入redis目录：

cd  redis-6.2.4

5、运行编译命令：

make && make install

如果中间没有报错，就表示redis安装成功了。

6、修改redis.conf文件中的一些配置：

# 把绑定地址注释掉
    # bind 127.0.0.1
    
    # 把安全模式关了
    protected-mode no

7、启动Redis：

redis-server redis.conf
    
    # 进入redis客户端
    redis-cli

停止redis服务：

redis-cli shutdown

### 1. Redis的持久化策略有哪些 ###

--------------------

#### 1.1 Redis数据的持久化是怎么做的？ ####

*  Redis有两种持久化方案，分别是RDB和AOF；
 *  RDB是一个快照文件（Redis数据备份文件），它是把redis内存存储的数据写到磁盘上，当redis实例宕机恢复数据的时候，方便从RDB的快照文件中恢复数据；（RDB默认是开启的）
 *  AOF的含义是追加文件，当redis进行写操作时，都会把每一个写命令记录在AOF文件(命令日志文件)，当redis实例宕机恢复数据的时候，会从这个AOF文件中再次执行一遍命令来恢复数据；（AOF默认是关闭的，需要修改redis.conf配置开启AOF）

> RDB和AOF哪种恢复的比较快?

*  RDB因为是二进制文件，在保存的时候体积也是比较小的，它恢复的比较快，但是它有可能会丢数据；
 *  我们通常在项目中也会使用AOF来恢复数据，虽然AOF恢复的速度慢一些，但是它丢数据的风险要小很多，在AOF文件中可以设置刷盘策略，默认刷盘策略是everysec表示每秒批量写入一次命令。

#### 1.2 RDB执行时机和原理 ####

> Redis何时会创建rdb文件：

*  手动执行save命令；（由主进程执行rdb，会阻塞所有命令）
 *  手动执行bgsave命令；（开启子进程执行rdb，避免主进程受到影响）
 *  Redis停机时；
 *  触发RDB条件时。

> 示例：RDB持久化操作

（1）Redis停机时，会自动执行一次save命令，实现RDB持久化。

![在这里插入图片描述][7f3eeba9e11b494fb7c003090f8bda9e.png]

（2）手动执行save命令，实现RDB持久化。（由Redis主进程来执行RDB，会阻塞所有命令）

![在这里插入图片描述][c934c7f9bf8d4807a3d26bfe1a029531.png]  
![在这里插入图片描述][fa7f9493d3534aaba6ca839da084b4c3.png]

（3）手动执行bgsave命令，实现RDB持久化。（开启子进程执行RDB，避免主进程受到影响）

![在这里插入图片描述][c9107197398e4080b8f5f78580aca523.png]

![在这里插入图片描述][4f5c77172eee48f481a866bf36300df6.png]

（4）修改RDB触发条件，实现自动保存（Redis内部有触发RDB的机制，可以在redis.conf文件中找到，默认是开启的）

# 900秒内，如果至少有1个key被修改，则执行bgsave ， 如果是save "" 则表示禁用RDB
    save 900 1   
    save 300 10  #满足300秒内有10条数据修改,则执行bgsave存盘
    save 60 10000 
    #save "" #禁用RDB

RDB的其它配置也可以在redis.conf文件中设置：

# 是否压缩 ,建议不开启，压缩也会消耗cpu，磁盘的话不值钱（省磁盘费cpu）
    rdbcompression yes
    
    # RDB文件名称
    dbfilename dump.rdb  
    
    # 文件保存的路径目录, ./表示当前目录
    dir ./

修改配置文件后，重启redis服务即可。

> RDB的执行原理：

当执行bgsave时，主进程会调用fork函数创建子进程，子进程共享主进程的内存数据（拷贝页表，页表里面存储映射数据）。最后子进程读取内存数据并写入RDB文件。

fork采用的是copy-on-write技术：

*  当主进程执行读操作时，访问共享内存；
 *  当主进程执行写操作时，则会拷贝一份数据，执行写操作。

![在这里插入图片描述][9fab8eefa8d54d0ab27ce9e9494f0ad3.png]

#### 1.3 AOF原理 ####

AOF全称为Append Only File（追加文件）。Redis处理的每一个写命令都会记录在AOF文件，可以看做是命令日志文件。

![在这里插入图片描述][f8d6e46903834462b62524ecd88a52a9.png]

#### 1.4 AOF配置和刷盘策略 ####

> AOF配置：

AOF默认是关闭的，需要修改redis.conf配置文件来开启AOF：

# 禁用RDB（去除rdb持久化配置）
    save ""
    
    # 是否开启AOF功能，默认是no
    appendonly yes
    # AOF文件的名称
    appendfilename "appendonly.aof"

![在这里插入图片描述][06cd176e185549fb963751a54afcf7fb.png]

重启redis:

# 关闭redis
    [root@localhost redis-6.2.4]# redis-cli shutdown
    
    # 开启redis
    [root@localhost redis-6.2.4]# redis-server redis.conf

> 刷盘策略：

AOF的命令记录的频率也可以通过redis.conf文件来配：

# 表示每执行一次写命令，立即记录到AOF文件
    appendfsync always 
    # 写命令执行完先放入AOF缓冲区，然后表示每隔1秒将缓冲区数据写到AOF文件，是默认方案（推荐使用）
    appendfsync everysec 
    # 写命令执行完先放入AOF缓冲区，由操作系   统决定何时将缓冲区内容写回磁盘
    appendfsync no

<table> 
 <thead> 
  <tr> 
   <th>配置项</th> 
   <th>刷盘时机</th> 
   <th>优点</th> 
   <th>缺点</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>always</td> 
   <td>同步刷盘</td> 
   <td>可靠性高，几乎不丢数据</td> 
   <td>性能影响大</td> 
  </tr> 
  <tr> 
   <td>everysec</td> 
   <td>每秒刷盘</td> 
   <td>性能适中</td> 
   <td>最多丢失1秒数据</td> 
  </tr> 
  <tr> 
   <td>no</td> 
   <td>操作系统控制</td> 
   <td>性能最好</td> 
   <td>可靠性较差，可能丢失大量数据</td> 
  </tr> 
 </tbody> 
</table>

![在这里插入图片描述][752e413c867c444a81df0d9007654019.png]

![在这里插入图片描述][2193ee4b33f5421aa7aef6221743686c.png]

#### 1.5 AOF文件重写 ####

--------------------

因为是记录命令，AOF文件会比RDB文件大的多。而且AOF会记录对同一个key的多次写操作，但只有最后一次写操作才有意义。通过执行bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到相同效果。

![在这里插入图片描述][7dac87efe74a42c495bf5b13d8b49229.png]

Redis也会在触发阈值时自动去重写AOF文件。阈值也可以在redis.conf中配置：

# 当前AOF文件比上次文件增长超过多少百分比时则触发重写，例如超过100%触发重写
    auto-aof-rewrite-percentage 100
    # AOF文件体积最小多大以上才触发重写 ，例如超过60m触发重写
    auto-aof-rewrite-min-size 64mb

#### 1.6 RDB与AOF对比 ####

> 如果对数据安全性要求较高，在实际开发中往往会结合两者来使用。(也就是两都开启）

<table> 
 <thead> 
  <tr> 
   <th></th> 
   <th>RDB</th> 
   <th>AOF</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>持久化方式</td> 
   <td>定时针对整个内存做快照</td> 
   <td>记录每次执行的命令</td> 
  </tr> 
  <tr> 
   <td>数据完整性</td> 
   <td>不完整，两次备份之间会丢失</td> 
   <td>相对完整，取决于刷盘策略</td> 
  </tr> 
  <tr> 
   <td>文件大小</td> 
   <td>会有压缩，文件体积小</td> 
   <td>记录命令，文件体积很大</td> 
  </tr> 
  <tr> 
   <td>宕机恢复速度</td> 
   <td>很快</td> 
   <td>慢</td> 
  </tr> 
  <tr> 
   <td>数据恢复优先级</td> 
   <td>低，因为数据完整性不如AOF</td> 
   <td>高，因为数据完整性更高</td> 
  </tr> 
  <tr> 
   <td>系统资源占用</td> 
   <td>高，大量CPU和内存消耗</td> 
   <td>低，主要是磁盘IO资源，但AOF重写时会占用大量CPU和内存资源</td> 
  </tr> 
  <tr> 
   <td>使用场景</td> 
   <td>可以容忍数分钟的数据丢失，追求更快的启动速度</td> 
   <td>对数据安全性要求较高常见</td> 
  </tr> 
 </tbody> 
</table>

总结：RDB方式恢复数据速度快但会丢失数据基于快照实现，AOF恢复数据速度慢但数据完整性高基于命令实现。

### 2. 什么是缓存穿透 ###

--------------------

缓存穿透：就是黑客根据接口去请求缓存中不存在的数据，导致每次请求都查数据库，从而数据库宕机。

![在这里插入图片描述][903c1118ea544cd7afa937ca8bebbb49.png]

解决方案：

*  缓存空数据
 *  布隆过滤器

> 解决方案1：缓存空数据

缓存空数据：当数据库查询的数据为空，就把这个空结果进行缓存；例如 \{key:10010,value:null\}

*  优点：实现简单
 *  缺点：消耗内存，可能会发生数据不一致问题

> 解决方案2：布隆过滤器

![在这里插入图片描述][03caab3cc8f3474e9e315cf46d3a8d70.png]

优点：内存占用较少，没有多余key

缺点：实现复杂，存在误判

[7d8f00e865ec49c7a8b4f55aa47d08e0.png]: https://img-blog.csdnimg.cn/7d8f00e865ec49c7a8b4f55aa47d08e0.png
[3db1489ef1bc43bb9b3723edb87c77f0.png]: https://img-blog.csdnimg.cn/3db1489ef1bc43bb9b3723edb87c77f0.png
[7f3eeba9e11b494fb7c003090f8bda9e.png]: https://img-blog.csdnimg.cn/7f3eeba9e11b494fb7c003090f8bda9e.png
[c934c7f9bf8d4807a3d26bfe1a029531.png]: https://img-blog.csdnimg.cn/c934c7f9bf8d4807a3d26bfe1a029531.png
[fa7f9493d3534aaba6ca839da084b4c3.png]: https://img-blog.csdnimg.cn/fa7f9493d3534aaba6ca839da084b4c3.png
[c9107197398e4080b8f5f78580aca523.png]: https://img-blog.csdnimg.cn/c9107197398e4080b8f5f78580aca523.png
[4f5c77172eee48f481a866bf36300df6.png]: https://img-blog.csdnimg.cn/4f5c77172eee48f481a866bf36300df6.png
[9fab8eefa8d54d0ab27ce9e9494f0ad3.png]: https://img-blog.csdnimg.cn/9fab8eefa8d54d0ab27ce9e9494f0ad3.png
[f8d6e46903834462b62524ecd88a52a9.png]: https://img-blog.csdnimg.cn/f8d6e46903834462b62524ecd88a52a9.png
[06cd176e185549fb963751a54afcf7fb.png]: https://img-blog.csdnimg.cn/06cd176e185549fb963751a54afcf7fb.png
[752e413c867c444a81df0d9007654019.png]: https://img-blog.csdnimg.cn/752e413c867c444a81df0d9007654019.png
[2193ee4b33f5421aa7aef6221743686c.png]: https://img-blog.csdnimg.cn/2193ee4b33f5421aa7aef6221743686c.png
[7dac87efe74a42c495bf5b13d8b49229.png]: https://img-blog.csdnimg.cn/7dac87efe74a42c495bf5b13d8b49229.png
[903c1118ea544cd7afa937ca8bebbb49.png]: https://img-blog.csdnimg.cn/903c1118ea544cd7afa937ca8bebbb49.png
[03caab3cc8f3474e9e315cf46d3a8d70.png]: https://img-blog.csdnimg.cn/03caab3cc8f3474e9e315cf46d3a8d70.png