Redis 单线程、高新能、持久化（图灵学院）

╰+攻爆jí腚メ 2022-11-21 03:47 139阅读 0赞

# Redis的单线程和高性能 #

## Redis是单线程吗？ ##

**Redis 的单线程主要是指 Redis 的网络 IO 和键值对读写是由一个线程来完成的**，这也是 Redis 对外提供键值存储服务的主要流程。但 Redis 的其他功能，比如持久化、异步删除、集群数据同步等，其实是由额外的线程执行的。

## Redis 单线程为什么还能这么快？ ##

快的原因：  
**1. 所有的运算都是内存级别的运算**，  
**2. 单线程避免了线程间切换的损耗**， Redis 的其他功能，比如持久化、异步删除、集群数据同步等，其实是由额外的线程执行的。  
**3.同时可以响应多个客户端的链接**  
因为它所有的数据都在内存中，**所有的运算都是内存级别的运算**，而且单线程避免了多线程的切换性能损耗问题。正因为 Redis 是单线程，所以要小心使用 Redis 指令，对于那些耗时的指令(比如keys)，一定要谨慎使用，一不小心就可能会导致 Redis 卡顿。

## Redis 单线程如何处理那么多的并发客户端连接？ ##

Redis的IO多路复用：redis利用epoll来实现IO多路复用，将连接信息和事件放到队列中，依次放到文件事件分派器，事件分派器将事件分发给事件处理器。

# Redis持久化 #

## RDB快照方式持久化（snapshot） ##

**根据配置策略满足条件才持久化，服务器宕机有可能丢失数据**

在默认情况下， Redis 将内存数据库快照保存在名字为 dump.rdb 的二进制文件中。  
你可以对 Redis 进行设置， 让它在“ N 秒内数据集至少有 M 个改动”这一条件被满足时， 自动保存一次数据集。  
比如说， 以下设置会让 Redis 在满足“ 60 秒内有至少有 1000 个键被改动”这一条件时， 自动保存一次数据集：

# save 60 1000

关闭RDB只需要将所有的save保存策略注释掉即可  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGVuZ3dlaTIzMDYxMg_size_16_color_FFFFFF_t_70_pic_center]  
还可以手动执行命令生成RDB快照，进入redis客户端执行命令save或bgsave可以生成dump.rdb文件，每次命令执行都会将所有redis内存快照到一个新的rdb文件里，并覆盖原有rdb快照文件。

## AOF方式持久化（append-only file） ##

**基本不丢失数据，可以配置成每次修改一次数据，就持久化到磁盘**

快照功能并不是非常耐久（durable）： 如果 Redis 因为某些原因而造成故障停机， 那么服务器将丢失最近写入、且仍未保存到快照中的那些数据。从 1.1 版本开始， Redis 增加了一种完全耐久的持久化方式： AOF 持久化，将修改的每一条指令记录进文件appendonly.aof中(先写入os cache，每隔一段时间fsync到磁盘)  
你可以通过修改配置文件来打开 AOF 功能：

# appendonly yes

你可以配置 Redis 多久才将数据 fsync 到磁盘一次。  
有三个选项：

*  appendfsync always：每次有新命令追加到 AOF 文件时就执行一次 fsync ，非常慢，也非常安全。
 *  appendfsync everysec：每秒 fsync 一次，足够快（和使用 RDB 持久化差不多），并且在故障时只会丢失 1 秒钟的数据。（先把数据放在缓存，每秒持久化一次）
 *  appendfsync no：从不 fsync ，将数据交给操作系统来处理。更快，也更不安全的选择。（什么时候从持久化，由操作系统决定）

**推荐（并且也是默认appendfsync everysec）的措施为每秒 fsync 一次， 这种 fsync 策略可以兼顾速度和安全性。**

## 数据恢复 ##

这样的话， 当 Redis 重新启动时，通过AOF方式持久化数据， 程序就可以通过重新执行 AOF 文件中的命令来达到重建数据集的目的。  
而通过RDB快照方式持久化的数据是二进制文件，恢复数据的速度会比AOF方式要块

AOF方式持久化数据恢复数据速度优化：

AOF重写  
AOF文件里可能有太多没用指令，所以AOF会定期根据内存的最新数据生成aof文件  
例如执行了：

set yy 1
    set yy 2
    set yy 3

持久化的文件中会三条set命令的记录，AOF重写后就只会剩下set yy 3 这条命令的记录，及根据内存的最新数据生成aof文件

AOF重写redis会fork出一个子进程去做，不会对redis正常命令处理有太多影响

**如果RDB快照方式持久化和AOF方式持久化在配置中都进行了配置两种持久化方式都会被执行，只是保存的地方一样文件名称不一样**

持久化保存目录配置  
![在这里插入图片描述][2020102922200548.png_pic_center]

## RDB 和 AOF ##

生产环境可以都启用，redis启动时 如果既有rdb文件又有aof文件则优先选择aof文件恢复数据，因为aof一般来说数据更全一点。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGVuZ3dlaTIzMDYxMg_size_16_color_FFFFFF_t_70_pic_center 1]

## Redis 4.0 混合持久化 ##

重启 Redis 时，我们很少使用 RDB来恢复内存状态，因为会丢失大量数据。我们通常使用 AOF 日志重放，但是重放AOF 日志性能相对 RDB来说要慢很多，这样在 Redis 实例很大的情况下，启动需要花费很长的时间。 Redis 4.0 为了解决这个问题，带来了一个新的持久化选项——混合持久化。  
通过如下配置可以开启混合持久化：

# aof-use-rdb-preamble yes

如果开启了混合持久化，**AOF在重写时**，不再是单纯将内存数据转换为RESP命令写入AOF文件，而是将重写这一刻之前的内存做RDB快照处理，并且将RDB快照内容和增量的AOF修改内存数据的命令存在一起，都写入新的AOF文件，新的文件一开始不叫appendonly.aof，等到重写完新的AOF文件才会进行改名，原子的覆盖原有的AOF文件，完成新旧两个AOF文件的替换。  
于是在 Redis 重启的时候，可以先加载 RDB 的内容，然后再重写增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，因此重启效率大幅得到提升。

混合持久化AOF文件结构

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGVuZ3dlaTIzMDYxMg_size_16_color_FFFFFF_t_70_pic_center 2]

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGVuZ3dlaTIzMDYxMg_size_16_color_FFFFFF_t_70_pic_center 3]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGVuZ3dlaTIzMDYxMg_size_16_color_FFFFFF_t_70_pic_center]: /images/20221120/5a9a006897934663b2d67c2fdb5926b8.png
[2020102922200548.png_pic_center]: /images/20221120/9eb44f92ac254a6ab41255a67d524dc8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGVuZ3dlaTIzMDYxMg_size_16_color_FFFFFF_t_70_pic_center 1]: https://img-blog.csdnimg.cn/20201029224444877.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGVuZ3dlaTIzMDYxMg==,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGVuZ3dlaTIzMDYxMg_size_16_color_FFFFFF_t_70_pic_center 2]: https://img-blog.csdnimg.cn/20201029225121429.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGVuZ3dlaTIzMDYxMg==,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGVuZ3dlaTIzMDYxMg_size_16_color_FFFFFF_t_70_pic_center 3]: https://img-blog.csdnimg.cn/20201029225731383.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGVuZ3dlaTIzMDYxMg==,size_16,color_FFFFFF,t_70#pic_center