Redis单机数据库-RDB AOF持久化-文件事件

Dear 丶 2023-03-03 11:08 1阅读 0赞

读《Redis设计与实现》笔记

# 一、单机数据库 #

## 1.1数据库数据结构 ##

redis服务器默认会创建16个数据库。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpaHVheW9uZw_size_16_color_FFFFFF_t_70]  
默认情况下，redis客户端的目标数据库为0号数据库，通过select命令来切换目标数据库。  
redisdb结构的dict字典保存了数据库中的所有的键值对：

typedef struct redisDb { 
        // 保存着数据库以整数表示的号码
        int id;
        // 保存着数据库中的所有键值对数据
        // 这个属性也被称为键空间（key space）
        dict *dict;
        // 保存着键的过期信息
        dict *expires;
        // 实现列表阻塞原语，如 BLPOP
        // 在列表类型一章有详细的讨论
        dict *blocking_keys;
        dict *ready_keys;
        // 用于实现 WATCH 命令
        // 在事务章节有详细的讨论
        dict *watched_keys;
    } redisDb;

下图是数据库键空间例子  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpaHVheW9uZw_size_16_color_FFFFFF_t_70 1]  
图中重复出现了两次 number 键和 book 键。 在实际中， 键空间字典的键和过期时间字典的键都指向同一个字符串对象， 所以不会浪费任何空间。

## 1.2过期键删除策略 ##

Redis 使用的过期键删除策略是**惰性删除**加上**定期删除**， 这两个策略相互配合，可以很好地在合理利用 CPU 时间和节约内存空间之间取得平衡。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpaHVheW9uZw_size_16_color_FFFFFF_t_70 2]  
定期删除策略，在规定的时间限制内， 尽可能地遍历各个数据库的 expires 字典， 随机地检查一部分键的过期时间， 并删除其中的过期键。  
过期键对 AOF 、RDB 和复制的影响：

*  在执行save命令或者是bgsave命令，创建新的 RDB 文件时，程序会对键进行检查，过期的键不会被写入到更新后的 RDB 文件中。
 *  当服务器以AOF持久化模式运行时，AOF 文件追加一条 DEL 命令，来显式地记录该键已被删除。
 *  当服务器带有从节点时， 过期键的删除由主节点统一控制：如果服务器是主节点，那么它在删除一个过期键之后，会显式地向所有从节点发送一个 DEL 命令。如果服务器是从节点，那么当它碰到一个过期键的时候，它会向程序返回键已过期的回复，但并不真正的删除过期键。因为程序只根据键是否已经过期、而不是键是否已经被删除来决定执行流程，所以这种处理并不影响命令的正确执行结果。当接到从主节点发来的 DEL 命令之后，从节点才会真正的将过期键删除掉。从节点不自主对键进行删除是为了和主节点的数据保持绝对一致， 因为这个原因， 当一个过期键还存在于主节点时，这个键在所有从点的副本也不会被删除。

# 二、RDB持久化 #

## 2.1持久化命令 ##

Redis持久化既可以手动执行，也可以根据配置选项定期执行，该功能可以将某个时间点上的数据库状态保存到一个RDB文件中，RDB文件是一个经过压缩的二进制文件，通过该文件可以还原生成RDB文件时的数据库状态。  
有两个Redis命令可以用于生成RDB文件，一个是SAVE，一个是BGSAVE。

*  SAVE命令会阻塞Redis服务器进程，SAVE的过程不能处理任何命令请求，直到RDB文件创建完毕为止。
 *  BGSAVE命令会fork出一个子进程，子进程负责创建RDB文件，父进程仍然可以处理命令请求。

RDB文件的载入工作是在服务器启动的时候自动执行的，所以Redis没有专门用于载入RDB文件的命令，只要Redis服务器在启动时检测到RDB文件的存在，它就会自动载入RDB文件。RDB文件载入期间Redis服务器处于阻塞状态，直到载入工作完成。

因为AOF文件的更新频率比RDB文件的更新频率高，所以：

*  如果服务器开启了AOF持久化功能，那么服务器会优先使用AOF文件来还原数据库状态。
 *  只有在AOF持久化功能处于关闭状态时，服务器才会使用RDB文件来还原数据库状态。

## 2.2自动间隔性保存 ##

用户可以通过save选项设置多个保存条件，只要其中任何一个条件被满足，服务器就会执行BGSAVE命令。  
举个例子，如果我们向服务器提供以下配置：

save 900 1
    save 300 10
    save 60 10000

那么只要服务器满足以下三个条件中的任意一个，BGSAVE命令就会被执行。

*  服务器在900秒以内，对数据库进行了至少1次修改。
 *  服务器在300秒以内，对数据库进行了至少10次修改。
 *  服务器在60秒以内，对数据库进行了至少10000次修改。

## 2.3RDB文件结构 ##

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

*  RDB 文件的最开头是 REDIS 部分， 这个部分的长度为 5 字节， 保存着 “REDIS” 五个字符。 通过这五个字符，程序可以在载入文件时， 快速检查所载入的文件是否 RDB 文件。
 *  db\_version 长度为 4 字节， 它的值是一个字符串表示的整数， 这个整数记录了 RDB 文件的版本号， 比如 “0006” 就代表 RDB 文件的版本为第六版
 *  EOF 常量的长度为 1 字节， 这个常量标志着 RDB 文件正文内容的结束， 当读入程序遇到这个值的时候， 它知道所有数据库的所有键值对都已经载入完毕了。
 *  check\_sum 是一个 8 字节长的无符号整数， 保存着一个校验和， 这个校验和是程序通过对 REDIS 、 db\_version 、 databases 、 EOF 四个部分的内容进行计算得出的。 服务器在载入 RDB 文件时， 会将载入数据所计算出的校验和与 check\_sum 所记录的校验和进行对比， 以此来检查 RDB 文件是否有出错或者损坏的情况出现。

一个 RDB 文件的 databases 部分可以保存任意多个非空数据库。比如说， 如果服务器的 0 号数据库和 3 号数据库非空， 那么服务器将如下图所示的 RDB 文件， 图中的 database 0 代表 0 号数据库中的所有键值对数据， 而 database 3 则代表 3 号数据库中的所有键值对数据。  
![在这里插入图片描述][20200801114454269.png]  
以下展示了一个完整的 RDB 文件， 文件中包含了 0 号数据库和 3 号数据库。  
![在这里插入图片描述][2020080111460641.png]  
RDB 文件中的每个 key\_value\_pairs 部分都保存了一个或以上数量的键值对， 如果键值对带有过期时间的话， 那么键值对的过期时间也会被保存在内。  
不带过期时间的键值对在 RDB 文件中对由 TYPE 、 key 、 value 三部分组成。TYPE 记录了 value 的类型， 长度为 1 字节， 值可以是以下常量的其中一个：

REDIS_RDB_TYPE_STRING
    REDIS_RDB_TYPE_LIST
    REDIS_RDB_TYPE_SET
    REDIS_RDB_TYPE_ZSET
    REDIS_RDB_TYPE_HASH
    REDIS_RDB_TYPE_LIST_ZIPLIST
    REDIS_RDB_TYPE_SET_INTSET
    REDIS_RDB_TYPE_ZSET_ZIPLIST
    REDIS_RDB_TYPE_HASH_ZIPLIST

每个 TYPE 常量都代表了一种对象类型或者底层编码， 当服务器读入 RDB 文件中的键值对数据时， 程序会根据 TYPE 的值来决定如何读入和解释 value 的数据。

带有过期时间的键值对在 RDB 文件中的结构 EXPIRETIME\_MS 、 ms、TYPE 、 key 、 value

*  EXPIRETIME\_MS 常量的长度为 1 字节， 它告知读入程序， 接下来要读入的将是一个以毫秒为单位的过期时间。
 *  ms 是一个 8 字节长的带符号整数， 记录着一个以毫秒为单位的 UNIX 时间戳， 这个时间戳就是键值对的过期时间。

以下是一个集合对象TYPE 、 key 、 value的例子：TYPE 的值为 REDIS\_RDB\_TYPE\_SET ， 那么 value 保存的就是一个集合对象， RDB 文件保存这种对象的结构如图所示：  
![在这里插入图片描述][20200801115509729.png]  
set\_size 是集合的大小， 它记录集合保存了多少个元素， 读入程序可以通过这个大小知道自己应该读入多少个集合元素。图中以 elem 开头的部分代表集合的元素， 因为每个集合元素都是一个字符串对象，以下展示了一个包含四个元素的集合：  
![在这里插入图片描述][20200801115657189.png]  
结构中的第一个数字 4 记录了集合的大小， 之后跟着的是集合的四个元素：  
第一个元素的长度为 5 ，值为 “apple” 。  
第二个元素的长度为 6 ，值为 “banana” 。  
第三个元素的长度为 3 ，值为 “cat” 。  
第四个元素的长度为 3 ，值为 “dog” 。

# 三、AOF持久化 #

AOF持久化是通过保存服务器所执行的命令来记录数据库状态。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpaHVheW9uZw_size_16_color_FFFFFF_t_70 3]

## 3.1AOF文件的载入与数据还原 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpaHVheW9uZw_size_16_color_FFFFFF_t_70 4]

## 3.2AOF重写 ##

因为AOF持久化是通过保存被执行的写命令来记录数据库数据的，所以随着Redis服务器运行时间的增加，AOF文件中的内容会越来越多，文件的体积会越来越大，如果不做控制，会有以下2点坏处：

*  过多的占用服务器磁盘空间，可能会对Redis服务器甚至整个宿主计算机造成影响。
 *  AOF文件的体积越大，使用AOF文件来进行数据库还原所需的时间就越多。

为了解决AO文件体积越来越大的问题，Redis提供了AOF文件重写功能，即Redis服务器会创建一个新的AOF文件来替代现有的AOF文件，新旧两个AOF文件所保存的数据库数据相同。但新AOF文件不会包含任何浪费空间的冗余命令，所以新AOF文件的体积通常会比旧AOF文件的体积要小很多。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpaHVheW9uZw_size_16_color_FFFFFF_t_70 5]  
如上图所示，重写前要记录名为list的键的状态，AOF 文件要保存五条命令，而重写后，则只需要保存一条命令。  
AOF文件重写功能的实现原理为：首先从数据库中读取键现在的值，然后用一条命令去记录键值对，代替之前记录这个键值对的多条命令。

在实际过程中，为了避免在执行命令时造成客户端输入缓冲区溢出，AOF 重写在处理列表、哈希表、集合和有序集合这四种可能会带有多个元素的键时，会先检查键所包含的元素数量，如果数量超过 REDIS\_AOF\_REWRITE\_ITEMS\_PER\_CMD ( 一般为64 )常量，则使用多条命令记录该键的值，而不是一条命令。

Redis将AOF文件重写功能放到子进程里执行，这样做有以下2个好处：

1.  子进程进行AOF文件重写期间，服务器进程（父进程）可以继续处理命令请求。
2.  子进程带有服务器进程的数据副本，使用子进程而不是线程，可以在避免使用锁的情况下，保证数据的安全性。

使用子进程也有一个问题需要解决： 因为子进程在进行 AOF 重写期间， 主进程还需要继续处理命令， 而新的命令可能对现有的数据进行修改， 这会让当前数据库的数据和重写后的 AOF 文件中的数据不一致。

为了解决这个问题， Redis 增加了一个 AOF 重写缓冲区。这个缓冲区在服务器创建出子进程之后开始使用， Redis 主进程在接到新的写命令之后， 会同时将这个写命令发送给AOF缓冲区和AOF重写缓冲区。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpaHVheW9uZw_size_16_color_FFFFFF_t_70 6]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpaHVheW9uZw_size_16_color_FFFFFF_t_70 7]  
当子进程完成AOF重写工作，向父进程发送一个信号，父进程在接收到该信号后，会调用一个信号处理函数，会执行以下操作：

1.  将AOF重写缓冲区中的所有内容写入到新AOF文件中，这样就保证了新AOF文件所保存的数据库数据和服务器当前的数据库数据是一致的。
2.  对新的AOF文件进行改名，原子地覆盖现有的AOF文件，完成新旧两个AOF文件的替换。

在整个 AOF 后台重写过程中，只有信号处理函数执行时会对 Redis 主进程造成阻塞，在其他时候，AOF 后台重写都不会阻塞主进程。

## 3.3RDB、AOF持久化的区别 ##

总结为以下4点：

*  实现方式：RDB持久化是通过将某个时间点Redis服务器存储的数据保存到RDB文件中来实现持久化的。AOF持久化是通过将Redis服务器执行的所有写命令保存到AOF文件中来实现持久化的。
 *  文件体积：RDB持久化记录的是结果，AOF持久化记录的是过程，所以AOF持久化生成的AOF文件会有体积越来越大的问题，Redis提供了AOF重写功能来减小AOF文件体积。
 *  安全性：AOF持久化的安全性要比RDB持久化的安全性高，即如果发生机器故障，AOF持久化要比RDB持久化丢失的数据要少。因为RDB持久化会丢失上次RDB持久化后写入的数据，而AOF持久化最多丢失1s之内写入的数据（使用默认everysec配置的话）。
 *  优先级：由于上述的安全性问题，如果Redis服务器开启了AOF持久化功能，Redis服务器在启动时会使用AOF文件来还原数据，如果Redis服务器没有开启AOF持久化功能，Redis服务器在启动时会使用RDB文件来还原数据，所以AOF文件的优先级比RDB文件的优先级高。

# 四、文件事件 #

如下图所示，文件事件处理器有四个组成部分，它们分别是套接字、I/O多路复用程序、文件事件分派器以及事件处理器。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpaHVheW9uZw_size_16_color_FFFFFF_t_70 8]  
尽管多个文件事件可能会并发地出现， 但 I/O 多路复用程序总是会将所有产生事件的套接字都**放到一个队列**里面， 然后通过这个队列， 以**有序、同步、每次一个套接字**的方式向文件事件分派器传送套接字： 当上一个套接字产生的事件被处理完毕之后， I/O 多路复用程序才会继续向文件事件分派器传送下一个套接字。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpaHVheW9uZw_size_16_color_FFFFFF_t_70 9]

参考：  
[数据库][Link 1]  
[Redis 事件机制详解][Redis]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpaHVheW9uZw_size_16_color_FFFFFF_t_70]: /images/20230208/c8b955b4654148ab89381a5ebd4e5b51.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpaHVheW9uZw_size_16_color_FFFFFF_t_70 1]: /images/20230208/cd4456d7171742d581d769a49d7fe295.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpaHVheW9uZw_size_16_color_FFFFFF_t_70 2]: /images/20230208/8e16cc70e4f8488192beb2d588cd54da.png
[20200801114048209.png]: /images/20230208/8702a3d67668414484d44fa09851eff9.png
[20200801114454269.png]: /images/20230208/551771b8c3294866a26c73b7baf9d970.png
[2020080111460641.png]: /images/20230208/5ec3bbfe9e724076b1de9fb81276cbc1.png
[20200801115509729.png]: /images/20230208/7ed24a5ea31a420ab9d40ac4c3069b05.png
[20200801115657189.png]: /images/20230208/367c205c2acc4d649e9f7cf9b1d69d0f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpaHVheW9uZw_size_16_color_FFFFFF_t_70 3]: /images/20230208/9c0eb22f32e048998a30d6f8e7ccafa9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpaHVheW9uZw_size_16_color_FFFFFF_t_70 4]: /images/20230208/28cde195b7e14d26bcd7bceb13e6f3a3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpaHVheW9uZw_size_16_color_FFFFFF_t_70 5]: /images/20230208/17f4c05d475f466d9db0d75235b8a00b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpaHVheW9uZw_size_16_color_FFFFFF_t_70 6]: /images/20230208/94b4a497644c4fa6b2ab322682e47f22.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpaHVheW9uZw_size_16_color_FFFFFF_t_70 7]: /images/20230208/d1b368e6f0a24d5d89c048b210a446e3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpaHVheW9uZw_size_16_color_FFFFFF_t_70 8]: /images/20230208/662c2cc65cb7486cb35e5443fa72dfd3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpaHVheW9uZw_size_16_color_FFFFFF_t_70 9]: /images/20230208/26149cb4e68746649aebd5b8f22468b2.png
[Link 1]: https://redisbook.readthedocs.io/en/latest/internal/db.html
[Redis]: https://segmentfault.com/a/1190000020014518