redis设计与实现读书笔记（三）

2021-01-18  本文已影响0人  peareaden

本文内容为《redis设计与实现》一书学习笔记。本文主要概述九到十一章内容。

第九章 数据库

9.1 服务器中的数据库

所有数据库都保存在服务器状态redisServer结构的db数组中：

struct redisServer {
// ...
redisDb *db; // 一个数组，保存着服务器中的所有数据库
int dbnum; // 服务器的数据库数量
// ...
};

初始化服务器的时候，可以通过dbnum属性指定需要创建的数据库的数量。dbnum属性的值由服务器配置的database选项决定，默认情况下，该选项的值是16。


9.2 切换数据库

默认情况下，目标数据库为0号数据库，可以通过执行SELECT命令来切换数据库客户端状态；redisClient结构的db属性记录了客户端当前的目标数据库：

typedef struct redisClient {
// ...
redisDb *db; // 记录客户端当前正在使用的数据库（指向服务器中的数据库）
// ...
} redisClient;

通过修改redisClient.db指针，让它指向服务器中的不同数据库，从而实现切换目标数据库的功能——这就是SELECT命令的实现原理。

9.3 数据库键空间

redis是一个键值对（key-value pair）数据库服务器，redisDb结构的dict字典保存了数据库中的所有键值对，这个字典也称为键空间（key space）：

typedef struct redisDb {
// ...
dict *dict; // 数据库键空间，保存着数据库中的所有键值对
// ...
} redisDb;

键空间的键也就是数据库的键，每个键都是一个字符串对象。 键空间的值也就是数据库的值，每个值可以是字符串对象、列表对象、哈希表对象、集合对象和有序集合对象中的任意一种Redis对象。
举个例子，在空白的数据库中执行以下命令：

redis> SET message "hello world"
OK
redis> RPUSH alphabet "a" "b" "c"
(integer) 3
redis> HSET book name "Redis in Action"
(integer) 1
redis> HSET book author "J.L.C"
(integer) 1
redis>HSET book publisher "Manning"
(integer) 1

alphabet是个列表键，book是一个哈希键，message是一个字符串键；这些命令执行后，数据库的键空间如下图：



所有针对数据库的操作实际上都是通过对键空间字典进行操作来实现的：

读写键空间时的维护操作：
当使用Redis命令对数据库进行读写时，服务器不仅会对键空间执行指定的读写操作，还会执行一些额外的维护操作，其中包括：

9.4 设置键的生存时间或过期时间

redisDb结构的expires字典保存了数据库中所有键的过期时间，这个字典也称为过期字典。键是一个指针，指向某个数据库键；值是long long类型的整数，保存了键所指向的数据库键的过期时间（一个毫秒精度的UNIX时间戳）。



上图中为了展示方便，键空间和过期字典中重复出现了两次alphabet键对象和book键对象，实际中，键空间的键和过期字典的键都指向同一个键对象，没用空间浪费。

PERSIST命令可以移除一个键的过期时间。TTL命令以秒为单位返回键的剩余生存时间，而PTTL命令则以毫秒为单位返回键的剩余生存时间

9.5 过期键删除策略

过期键的判定：
通过过期字典，程序可以用以下步骤检查一个给定键是否过期：

过期键删除策略：
定时删除：在设置键的过期时间的同时，创建一个定时器（timer），让定时器在键的过期时间来临时，立即执行对键的删除操作。
惰性删除：放任键过期不管，但是每次从键空间中获取键时，都检查取得的键是否过期，如果过期的话，就删除该键；如果没有过期，就返回该键。
定期删除：每隔一段时间，程序就对数据库进行一次检查，删除里面的过期键。至于要删除多少过期键，以及要检查多少个数据库，则由算法决定。

各个策略优缺点：
定时删除优点：内存最友好。定时器可以保证过期键会尽可能快的删除并释放占用的内存。
定时删除缺点：对CPU时间最不友好。过期键比较多时删除过期键会占用很多CPU时间；在内存不紧张但CPU时间紧张的情况下，将CPU时间用在删除和当前任务无关的键上，会影响服务器的响应时间和吞吐量。
惰性删除优点：CPU时间最友好。只在取出键时才进行过期检查，保证了只在非做不可的情况下删除过期键；且删除目标仅限于当前任务的键，不会在删除与当前任务无关的过期键上花费任何CPU时间。
惰性删除缺点：内存最不友好。如果键已经过期且恰好没有被访问到，那么永远不会被删除。这种情况甚至可以看作内存泄漏——无用的垃圾数据占用了大量内存，服务器却不会自己去释放。
定期删除优点：前两种策略的整合和折中。
定期删除缺点：如果删除操作太频繁或执行时间太长，定期删除策略会退化成定时删除策略。如果删除操作太少或执行时间太短，定期删除策略会退化成惰性删除策略。因此服务器必须根据情况，合理地设置删除操作的执行时长和执行频率。

9.6 Redis过期键删除策略

Redis服务器实际使用的是惰性删除和定期删除两种策略：通过配合使用这两种删除策略，服务器可以很好地在合理使用CPU时间和避免浪费内存空间之间取得平衡。

过期键的惰性删除策略由expireIfNeeded函数实现。所有读写数据库的Redis命令在执行之前都会调用expireIfNeeded函数对输入键进行检查，它可以在命令真正执行之前，过滤掉过期的输入键，从而避免命令接触到过期键，如下图所示。

过期键的定期删除策略由activeExpireCycle实现。每当Redis的服务器周期性操作redis.c/serverCron函数执行时，activeExpireCycle函数就会被调用，它在规定的时间内，分多次遍历服务器中的各个数据库，从数据库的expires字典中随机检查一部分键的过期时间，并删除其中的过期键。

9.7 AOF、RDB和复制功能对过期键的处理

生成RDB文件：
在执行SAVE命令或者BGSAVE命令创建一个新的RDB文件时，程序会对数据库中的键进行检查，已过期的键不会被保存到新创建的RDB文件中。

载入RDB文件：
在启动Redis服务器时，如果服务器开启了RDB功能，那么服务器将对RDB文件进行载入：

AOF文件写入：
当服务器以AOF持久化模式运行时，如果数据库中的某个键已经过期，但它还没有被惰性删除或者定期删除，那么AOF文件不会因为这个过期键而产生任何影响。当过期键被惰性删除或者定期删除之后，程序会向AOF文件追加（append）一条DEL命令，来显式地记录该键已被删除。

AOF重写：
在执行AOF重写的过程中，程序会对数据库中的键进行检查，已过期的键不会被保存到重写后的AOF文件中。

复制：
当服务器运行在复制模式下时，从服务器的过期键删除动作由主服务器控制：

9.8 数据库通知

这个功能可以让客户端通过订阅给定的频道或者模式，来获知数据库中键的变化，以及数据库中命令的执行情况。
关注“某个键执行了什么命令”的通知称为键空间通知（key-space notification），除此之外，还有另一类称为键事件通知（key-event notification）的通知，它们关注的是“某个命令被什么键执行了”。

第十章 RDB持久化

Redis是一个键值对数据库服务器，服务器中包含任意个非空数据库，非空数据库中又包含任意个键值对，我们将服务器中的非空数据库以及它们的键值对统称为数据库状态。
Redis持久化可以将Redis在内存中的数据库状态保存到磁盘里，避免数据意外丢失。
RDB持久化既可以手动执行，也可以根据服务器配置选项定期执行，该功能可以将某个时间点上的数据库状态保存到一个RDB文件中。Redis服务器就可以用它来还原数据库状态。
Redis持久化功能所生成的RDB文件是一个经过压缩的二进制文件。

10.1 RDB文件的创建与载入

RDB文件的创建：
两个命令，SAVE和BGSAVE：
SAVE命令会阻塞Redis服务器进程，直到RDB文件创建完毕为止，在服务器进程阻塞期间，服务器不能处理任何命令请求。客户端发送的所有命令请求都会被拒绝。
BGSAVE命令会派生出一个子进程，然后由子进程负责创建RDB文件，服务器进程（父进程）继续处理命令请求。
RDB文件的载入：
RDB文件的载入工作是在服务器启动时自动执行的，所以Redis并没有专门用于载入RDB文件的命令，只要Redis服务器在启动时检测到RDB文件存在，它就会自动载入RDB文件。

因为AOF文件的更新频率通常比RDB文件的更新频率高，所以如果服务器开启了AOF持久化功能，那么服务器会优先使用AOF文件来还原数据库状态。只有在AOF持久化功能处于关闭状态时，服务器才会使用RDB文件来还原数据库状态。

SAVE命令执行时服务器状态：
SAVE命令执行时服务器会被阻塞，此时客户端发送的所有的请求都会被拒绝。只有当服务器执行完SAVE命令、重新开始接受命令请求后，客户端发送的命令才会被处理。

BGSAVE命令执行时服务器状态：
因为BGSAVE命令的保存工作是由子进程执行的，所以在子进程创建RDB文件的过程中，Redis服务器仍然可以继续处理客户端的命令请求。
但在BGSAVE命令执行期间，服务器处理SAVE、BGSAVE、BGREWRITEAOF三个命令的方式会和平时有所不同：

RDB文件载入时的服务器状态：
服务器在载入RDB文件期间，会一直阻塞，直到载入完成。

10.2 自动间隔性保存

Redis允许用户通过设置服务器配置的save选项，让服务器每隔一段时间自动执行一次BGSAVE命令。用户可以通过save选项设置多个保存条件，但只要其中任意一个条件被满足，服务器就会执行BGSAVE命令。
举例，如果向服务器提供以下配置

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

只要满足这三个条件（三条命令中后面的文字注释）中的一个，BGSAVE命令就会被执行。

Redis的服务器周期性操作函数serverCron默认每隔100毫秒就会执行一次，该函数用于对正在运行的服务器进行维护，它的其中一项工作就是检查save选项所设置的保存条件是否已经满足，如果满足的话，就执行BGSAVE命令。

第十一章 AOF持久化

与RDB持久化通过保存数据库中的键值对来记录数据库状态不同，AOF（Append Only File）持久化是通过保存Redis服务器所执行的写命令来记录数据库状态的。被写入AOF文件的所有命令都是以Redis的命令请求协议格式保存的。服务器在启动时，可以通过载入和执行AOF文件中保存的命令来还原服务器关闭之前的数据库状态。

11.1 AOF持久化

AOF持久化分为命令追加（append）、文件写入、文件同步三个步骤。
命令追加：
当AOF持久化功能处于打开状态时，服务器在执行完一个写命令之后，会以协议格式将被执行的写命令追加到服务器状态的aof_buf缓冲区的末尾。
文件写入：
Redis的服务器进程就是一个事件循环（loop），这个循环中的文件事件负责接收客户端的命令请求，以及向客户端发送命令回复，而时间事件则负责执行像serverCron函数这样需要定时运行的函数。在服务器每次结束一个事件循环之前，它都会调用flushAppendOnlyFile函数，考虑是否需要将aof_buf缓冲区中的内容写入和保存到AOF文件里面。
flushAppendOnlyFile函数行为由服务器配置的appendfsync选项的值来决定：


appendfsync选项默认值是everysec。

现代操作系统为了提高文件的写入效率，通常会将写入数据暂时保存在内存缓存区里，等缓冲区满或者超过指定的时限后，再真正地将缓冲区数据写入到磁盘里。这样就给写入数据带入了安全问题，如果计算机停机，保存在内存缓冲区里的写入数据将会丢失。
所以系统提供了fsync和fdatasync两个同步函数，可以强制让操作系统立刻将缓冲区中的数据写入到硬盘里。

AOF持久化的效率和安全性：
我的理解：效率要综合看文件写入和文件同步，安全性看文件同步。

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

服务器只需读入并重新执行AOF文件里保存的写命令，就可以还原服务器关闭之前的数据库状态。
Redis读取AOF文件并还原数据库状态的详细步骤如下：

  1. 创建一个不带网络连接的伪客户端（fake client）（因为Redis的命令只能在客户端上下文中执行）；载入AOF文件时所使用的命令直接来源于AOF文件而不是网络连接，使用一个没有网络连接的伪客户端来执行AOF文件保存的写命令和带网络连接的客户端执行命令的效果一样。
  2. 从AOF文件中分析并读取出一条写命令。
  3. 使用伪客户端执行被读出的写命令。
  4. 一直执行步骤2和步骤3，直到AOF文件中的所有写命令都被处理完毕为止。

11.3 AOF重写

AOF持久化是通过保存被执行的写命令来记录数据库状态的，随着服务器运行时间流逝，AOF文件中的内容会越来越多，从而对Redis服务器、甚至整个宿主计算机造成影响；且AOF文件的体积越大，使用AOF文件来进行数据还原所需的时间就越多。

为了解决AOF文件体积膨胀的问题，Redis提供了AOF文件重写（rewrite）功能。通过该功能，Redis服务器可以创建一个新的AOF文件来替代现有的AOF文件，新旧两个AOF文件所保存的数据库状态相同，但新AOF文件不会包含任何浪费空间的冗余命令，所以新AOF文件的体积通常会比旧AOF文件的体积要小得多。

实际上AOF文件重写并不需要对现有的AOF文件进行任何读取、分析或者写入操作，而是通过读取服务器当前的数据库状态来实现的。从数据库中读取键现在的值，然后用一条命令去记录键值对，代替之前记录这个键值对的多条命令，这就是AOF重写功能的实现原理。（比如连续6条RPUSH命令会被整合成1条）

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

AOF后台重写：
Redis是单线程处理命令请求，如果由服务器直接调用AOF重写程序即aof_rewrite函数，那么在重写AOF文件期间，服务器无法处理客户端请求。
所以使用子进程进行AOF重写（子进程带有服务器进程的数据副本），在这同时主进程仍然在接受并处理客户端的请求。为了解决数据不一致问题（子进程在AOF重写期间，服务器进程继续处理命令对现有的数据库状态修改），Redis服务器设置了一个AOF重写缓冲区，这个缓冲区在服务器创建子进程之后开始使用，当Redis服务器执行完一个写命令之后，它会同时将这个写命令发送给AOF缓冲区和AOF重写缓冲区。 在子进程执行AOF重写期间，服务器进程需要执行以下三个工作：

这样一来可以保证：

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

在整个AOF后台重写过程中，只有信号处理函数执行时会对服务器进程（父进程）造成阻塞，在其他时候，AOF后台重写都不会阻塞父进程，这将AOF重写对服务器性能造成的影响降到了最低。

上一篇 下一篇

猜你喜欢

热点阅读