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

本文内容为《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对象。
删除键：在键空间里面删除键所对应的键值对对象。
更新键：对键空间里面键所对应的值对象进行更新，根据值对象的类型不同，更新的具体方法也会有所不同。
对键取值：在键空间中取出键所对应的值对象，根据值对象的类型不同，具体的取值方法也会有所不同。
FLUSHDB：删除键空间中的所有键值对。
RANDOMKEY：在键空间中随机返回一个键。
DBSIZE：返回数据库键数量，其实就是返回键空间中包含的键值对的数量，类似的还有EXISTS、RENAME、KEYS等。

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

在读取一个键之后，服务器会根据键是否存在来更新服务器的键空间命中（hit）次数或键空间不命中（miss）次数。
在读取一个键之后，服务器会更新键的LRU（最后一次使用）时间，这个值可以用于计算键的闲置时间。
如果服务器在读取一个键时发现该键已经过期，那么服务器会先删除这个过期键，然后才执行余下的其他操作。
如果有客户端使用WATCH命令监视了某个键，那么服务器在对被监视的键进行修改之后，会将这个键标记为脏（dirty），从而让事务程序注意到这个键已经被修改过。
服务器每次修改一个键之后，都会对脏（dirty）键计数器的值增1，这个计数器会触发服务器的持久化以及复制操作。
如果服务器开启了数据库通知功能，那么在对键进行修改之后，服务器将按配置发送相应的数据库通知。

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

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

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

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

9.5 过期键删除策略

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

检查给定键是否存在于过期字典：如果存在，那么取得键的过期时间。
检查当前UNIX时间戳是否大于键的过期时间：如果是的话，那么键已经过期；否则的话，键未过期。

过期键删除策略：
定时删除：在设置键的过期时间的同时，创建一个定时器（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文件进行载入：

如果服务器以主服务器模式运行，那么在载入RDB文件时，程序会对文件中保存的键进行检查，未过期的键会被载入到数据库中，而过期键则会被忽略，所以过期键对载入RDB文件的主服务器不会造成影响。
如果服务器以从服务器模式运行，那么在载入RDB文件时，文件中保存的所有键，不论是否过期，都会被载入到数据库中。不过，因为主从服务器在进行数据同步的时候，从服务器的数据库就会被清空，所以一般来讲，过期键对载入RDB文件的从服务器也不会造成影响。

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

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

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

主服务器在删除一个过期键之后，会显式地向所有从服务器发送一个DEL命令，告知从服务器删除这个过期键。
从服务器在执行客户端发送的读命令时，即使碰到过期键也不会将过期键删除，而是继续像处理未过期的键一样来处理过期键。
从服务器只有在接到主服务器发来的DEL命令之后，才会删除过期键。
通过由主服务器来控制从服务器统一地删除过期键，有利于保证主从服务器数据的一致性。也正是因为这个原因，当一个过期键仍存在于主服务器的数据库时，这个过期键在从服务器里的复制品也会继续存在。

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三个命令的方式会和平时有所不同：

在BGSAVE命令执行期间，客户端发送的SAVE命令会被服务器拒绝。防止竞争。服务器禁止SAVE命令和BGSAVE命令同时执行是为了避免父进程（服务器进程）和子进程同时执行两个rdbSave调用。
在BGSAVE命令执行期间，客户端发送的BGSAVE命令会被服务器拒绝。防止竞争。同时执行两个BGSAVE命令也会竞争。
BGREWRITEAOF和BGSAVE两个命令不能同时执行。性能原因。BGREWRITEAOF和BGSAVE两个命令都是由子进程执行，这两个命令在操作方面没有冲突的地方。但并发出两个子进程，并且这两个子进程都同时执行大量的的磁盘写入操作，不是好主意。

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持久化的效率和安全性：
我的理解：效率要综合看文件写入和文件同步，安全性看文件同步。

当appendfsync的值为always时。
效率最慢：服务器在每个事件循环都要将aof_buff缓存区中的所有内容写入到AOF文件，并同步AOF文件。
最安全：即使出现故障停机，AOF持久化也只会丢失一个事件循环中产生的命令数据。
当appendfsync的值为everysec时，
效率足够快：服务器在每个事件循环都要将aof_buff缓存区中的所有内容写入到AOF文件，并且每隔一秒种就要在子线程中同步AOF文件。
安全性足够：就算出现故障停机，数据库也只丢失一秒钟的命令数据。
当appendfsync的值为no时，
效率与everysec类似：服务器在每个事件循环都要将aof_buff缓存区中的所有内容写入到AOF文件，至于何时对AOF文件进行同步则由操作系统控制。因为no模式下无需执行同步操作，所以该模式下AOF文件写入是最快的。这种模式会在系统缓存中积累一段时间的写入数据，单次同步时长是三种中最长的。从平摊操作的角度来看，效率与everysec类似。
安全性：出现故障停机时，使用no模式的服务器丢失上次同步AOF文件之后的所有写命令数据。

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

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

创建一个不带网络连接的伪客户端（fake client）（因为Redis的命令只能在客户端上下文中执行）；载入AOF文件时所使用的命令直接来源于AOF文件而不是网络连接，使用一个没有网络连接的伪客户端来执行AOF文件保存的写命令和带网络连接的客户端执行命令的效果一样。
从AOF文件中分析并读取出一条写命令。
使用伪客户端执行被读出的写命令。
一直执行步骤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文件，对现有AOF文件的处理工作会如常进行。
从创建子进程开始，服务器执行的所有写命令都会被记录到AOF重写缓冲区里面。

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

将AOF重写缓冲区中的所有内容写入到新AOF文件中，这时新AOF文件所保存的数据库状态将和服务器当前的数据库状态一致。
对新的AOF文件进行改名，原子地（atomic）覆盖现有的AOF文件，完成新旧两个AOF文件的替换。

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