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

最新推荐文章于 2024-05-28 08:39:30 发布

lihuayong

最新推荐文章于 2024-05-28 08:39:30 发布

阅读量228

点赞数

分类专栏： Redis 文章标签： redis数据结构 RDB持久化 AOF持久化 RDB AOF区别 redis文件事件

本文链接：https://blog.csdn.net/lihuayong/article/details/107702749

版权

Redis 专栏收录该内容

4 篇文章 0 订阅

订阅专栏

读《Redis设计与实现》笔记

一、单机数据库

1.1数据库数据结构

redis服务器默认会创建16个数据库。
在这里插入图片描述
默认情况下，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;

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

1.2过期键删除策略

Redis 使用的过期键删除策略是惰性删除加上定期删除，这两个策略相互配合，可以很好地在合理利用 CPU 时间和节约内存空间之间取得平衡。
在这里插入图片描述
定期删除策略，在规定的时间限制内，尽可能地遍历各个数据库的 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文件结构

在这里插入图片描述

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 号数据库中的所有键值对数据。
在这里插入图片描述
以下展示了一个完整的 RDB 文件，文件中包含了 0 号数据库和 3 号数据库。

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 文件保存这种对象的结构如图所示：
在这里插入图片描述
set_size 是集合的大小，它记录集合保存了多少个元素，读入程序可以通过这个大小知道自己应该读入多少个集合元素。图中以 elem 开头的部分代表集合的元素，因为每个集合元素都是一个字符串对象，以下展示了一个包含四个元素的集合：
在这里插入图片描述
结构中的第一个数字 4 记录了集合的大小，之后跟着的是集合的四个元素：
第一个元素的长度为 5 ，值为 “apple” 。
第二个元素的长度为 6 ，值为 “banana” 。
第三个元素的长度为 3 ，值为 “cat” 。
第四个元素的长度为 3 ，值为 “dog” 。

三、AOF持久化

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

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

在这里插入图片描述

3.2AOF重写

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

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

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

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

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

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

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

为了解决这个问题， Redis 增加了一个 AOF 重写缓冲区。这个缓冲区在服务器创建出子进程之后开始使用， Redis 主进程在接到新的写命令之后，会同时将这个写命令发送给AOF缓冲区和AOF重写缓冲区。
在这里插入图片描述

当子进程完成AOF重写工作，向父进程发送一个信号，父进程在接收到该信号后，会调用一个信号处理函数，会执行以下操作：

将AOF重写缓冲区中的所有内容写入到新AOF文件中，这样就保证了新AOF文件所保存的数据库数据和服务器当前的数据库数据是一致的。
对新的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多路复用程序、文件事件分派器以及事件处理器。
在这里插入图片描述
尽管多个文件事件可能会并发地出现，但 I/O 多路复用程序总是会将所有产生事件的套接字都放到一个队列里面，然后通过这个队列，以有序、同步、每次一个套接字的方式向文件事件分派器传送套接字：当上一个套接字产生的事件被处理完毕之后， I/O 多路复用程序才会继续向文件事件分派器传送下一个套接字。
在这里插入图片描述