aas 因为Redis 是内存数据库，它将自己的数据库状态储存在内存里面，所以如果不想办法将储存在内存中的数据库状态保存到磁盘里面，那么一旦服务器进程退出，服务器中的数据库状态也会消失不见。为了解决这个问题， Redis 提供了RDB 持久化功能，这个功能可以将Redis 在内存中的数据库状态保存到磁盘里面，避免数据意外丢失。
asdsadasdasdasdsadasdasdasdsadassdasdsasdsadsdasdasdsadasdasdsadasdsadassadasdas————《Redis设计与实现》
RDB持久化：
asdasa RDB 待久化既可以手动执行，也可以根据服务器配置选项定期执行。
asdasa 功能：将某个时间点上的数据库状态保存到一个RDB 文件。
asdasaRDB 持久化功能所生成的 RDB 文件是一个经过压缩的二进制文件，通过该文件可以还原生成RDB 文件时的数据库状态。
RDB 文件的创建与载入：
aa ⒈有两个 Redis 命令可以用于生成 RDB文件：
adsa ① SAVE： SAVE 命令会阻塞 Redis 服务器进程， 直到RDB 文件创建完毕为止（在服务器进程阻塞期间，服务器不能处理任何命令请求，即客户端发送的所有命令请求都会被拒绝。）。
sdssa② BGSAVE： BGSAVE 命令会派生出一个子进程，然后由子进程负责创建RDB 文件，服务器进程（父进程）继续处理命令请求。
aa ⒉RDB 文件的 载入工作是在 服务器启动时自动执行的。 只要Redis 服务器在启动时检测到RDB 文件存在，它就会自动载入RDB 文件。
aa ⒊启用流程：因为AOF文件的更新频率通常比RDB 文件的更新频率高，所以：
adsa ①、如果服务器开启了AOF 持久化功能，那么服务器会优先使用AOF 文件来还原数据库状态。
adsa ②、只有在AOF 持久化功能处于关闭状态时， 服务器才会使用RDB 文件来还原数据库状态。
aa ⒋BGSAVE 命令执行时的服务器状态：
aadsad因为BGSA VE 命令的保存工作是由子进程执行的，所以在子进程创建RDB 文件的过程中，Redis 服务器仍然可以继续处理客户端的命令请求。但是要注意：SAVE 、BGSAVE 、BGREWRITEAOF 这三个命令。
aadsdas①、服务器禁止 SAVE 命令和 BGSAVE 命令同时执行是为了避免父进程（ 服务器进程）和子进程同时执行两个rdbSave 调用，防止产生竞争条件。
aadsdas②、在BGSAVE 命令执行期间，客户端发送的BGSAVE 命令会被服务器拒绝，因为同时执行两个BGSAVE 命令也会产生竞争条件。
aadsdas③、BGREWRITEAOF 和BGSAVE 两个命令不能同时执行：因为 BGREWRITEAOF 和 BGSAVE 两个命令的实际工作都由子进程执行，所以这两个命令在操作方面并没有什么冲突的地方，不能同时执行它们只是一个 性能方面的考虑 一并发出两个子进程，并且这两个子进程都同时执行 大量的磁盘写入操作，这怎么想都不会是一个好主意。
aa ⒌自动 间隔性 保存
aadsad因为 BGSAVE 命令可以在不阻塞服务器进程的情况下执行，所以 Redis让服务器每隔一段时间自动执行一次BGSAVE 命令。 （用户可以通过save 选项设置多个保存条件，但只要其中任意一个条件被满足， 服务器就会执行BGSAVE 命令）
aadsdas①、服务器在900 秒之内，对数据库进行了至少1 次修改。
aadsdas②、服务器在300 秒之内，对数据库进行了至少10 次修改。
aadsdas③、服务器在6 0 秒之内，对数据库进行了至少10000 次修改。
aadsad这些条件保存到了 redisServer结构的saveparams 数组属性中：
aa ⒍dirty 计数器和lastsave 属性
aadsad除了 savepararns 数组之外，服务器状态还维持着一个 dirty 计数器，以及一个 lastsave 属性：
aadsdas①、dirty 计数器：记录距离上一次成功执行SAVE 命令或者 BGSAVE 命令之后，服务器对数据库状态（服务器中的所有数据库）进行了多少次修改（包括写入、删除、更新等操作）。
aadsdas②、lastsave 属性：是一个UNIX 时间戳，记录了服务器 上一次成功执行SAVE 命令或者BGSAVE 命令的时间。
aa ⒎检查保存条件是否满足：Redis 的服务器 周期性操作函数serverCron 默认每隔100 毫秒就会执行一次，该函数用于对正在运行的服务器进行维护，它的其中一项工作就是检查save 选项所设置的保存条件是否已经满足，如果满足的话，就执行BGSAVE命令。
ROB 文件结构：
aa ⒈RDB文件结构：
adsadsa 大写单词：标示常量。全小写单词：标示变量和数据。
adsadsaREDIS ： 长度为 5 字节，保存着" REDIS " 五个字符。程序可以在载入文件时，快速检查所载入的文件是否RDB 文件。（因为RDB保存的是二进制文件，而不是C 宇符串，所以尾部不用加’\0’ ）。
adsadsadb_version属性： 长度为 4 字节，记录了版本号，比如" 000 6" 就代表RDB 文件的 版本,为第六版。
adsadsadatabases 属性： 部分包含着零个或任意多个数据库，以及各个数据库中的键值对数据。
adsadsaEOF: 常量的长度为 1 字节，这个常扯标志着 RDB 文件 正文内容的结束。
adsadsacheck_sum: 是一个 8 字节长的无符号整数，保存着一个 校验和，这个校验和是程序通过对前四个部分的内容进行计算得出。
aa ⒉databases 部分：
adsadsa一个RDB 文件的databases 部分 可以保存任意多个非空数据库。
adsadsaeg：
adsadsaSELECTDB 属性： 长度为 1 字节，表示 接下来要读入的是一个数据库号码。
adsadsadb_number属性： 保存着一个数据库号码，根据号码的大小不同，这个部分的长度可以是 1 字节、2 字节或者5 字节。（服务器会调用SELECT命令，根据读入的数据库号码进行数据库切换）
adsadsakey_value_pairs属性： 部分保存了数据库中的所有键值对数据，如果键值对带有过期时间，那么过期时间也会和键值对保存在一起。
aa ⒊key_value_pairs 部分：
adsadsaRDB 文件中的每个key_value_pairs 部分都保存了一个或以上数量的键值对，如果键值对带有过期时间的话，那么键值对的过期时间也会被保存在内。
adsadsaeg：
adsdsaadsa①、不带过期时间的键值对 在RDB 文件中由三部分组成：
adsdsdsadasaadsaTYPE属性：记录了value 的类型。（REDIS_ROB_TYPE_STRING…）
adsdsaadsa②、带过期时间的键值对 在RDB 文件中由四部分组成：
adsdsdsadasaadsaEXPIRETIME_MS 属性： 长度为1 字节，是一个以毫秒为单位的过期时间。
adsdsdsadasaadsams属性： 是一个8 字节长的带符号整数，记录着一个以毫秒为单位的UNIX 时间戳，这个时间戳就是键值对的过期时间。
RDB持久化总结：
addsa①、RDB 文件用于保存和还原Redis 服务器所有数据库中的所有键值对数据。
addsa②、SAVE 命令由服务器进程直接执行保存操作，所以该命令会阻塞服务器。BGSAVE 令由子进程执行保存操作，所以该命令不会阻塞服务器。
addsa③、服务器状态中会保存所有用save 选项设置的保存条件，当任意一个保存条件被满足时，服务器会自动执行BGSAVE 命令。
addsa④、RDB 文件是一个 经过压缩的二进制文件，由多个部分组成。
addsa⑤、对于不同类型的键值对， RDB 文件会使用不同的方式来保存它们。
💖💗💗💗💗💗💗💗💗💗💖💖💖💖💖💖💖💖-💖💗💗💗💗💗💗💗💗💗💖💖💖💖💖💖💖💖-💖💗💗💗
AOF持久化：
addsa除了RDB 持久化功能之外， Redis 还提供了AOF持久化功能。与RDB 持久化通过保存数据库中的键值对来记录数据库状态不同， AOF 持久化是通过保存Redis 服务器所执行的写命令来记录数据库状态的。
addsa被写入AOF 文件的所有命令都是以Redis 的命令请求协议格式保存的，因为Redis 的命令请求协议是纯文本格式，所以我们 可以直接查看AOF文件。
aa ⒈AOF 持久化的实现：
addsaAOF 持久化功能的实现可以分为 命令追加、文件写入、文件同步 三个步骤。
adsddsa①、命令追加： 当AOF 持久化功能处于打开状态时，服务器在执行完一个写命令之后， 会以协议格式将被执行的写命令追加到服务器状态的 aof_buf 缓冲区 的末尾：
adsddsa②、AOF 文件的写入与同步： 当AOF 持久化功能处于打开状态时，服务器在执行完一个写命令之后， 会以协议格式将被执行的写命令追加到服务器状态的 aof_buf 缓冲区 的末尾。Redis 的服务器进程就是一个事件循环，在服务器每次结束一个事件循环之前，它都会调用 flushAppendOnlyFile 函数，考虑是否需要将aof_buf 缓冲区中的内容写入和保存到AOF 文件里面。
adsdddssa【注】：flushAppendOnlyFile 函数行为由服务器配置的appendfsync 选项的值来决定。如果用户没有主动为 appendfsync 选项设置值，那么appendfsync 选项的默认值为everysec。
adsddsaddssa 服务器配置 appendfsync 选项的值直接决定 AOF 持久化功能的 效率和安全性。always 的效率是 appendfsync 选项三个值当中最慢的一个， no 模式下的AOF 文件写入速度总是最快的，单次同步时长通常是三种模式中时间最长的。
adsddsa⑴ 文件写入： 为了提高文件的写入效率，在现代操作系统中，当用户调用 write 函数，将一些数据写入到文件的时候，操作系统通常会将写入数据暂时保存在一个内存缓冲区里面，等到缓冲区的空间被填满、或者超过了指定的时限之后，才真正地将缓冲区中的数据写入到磁盘里面。
adsddsa⑵ 文件写入带来的问题： 虽然 提高了效率，但也为写入数据带来了安全问题，因为如果计算机发生停机，那么保存在内存缓冲区里面的写入数据将会丢失。
adsddsa⑶ 解决方法： 系统提供了 fsync 和 fdatasync 两个 同步函数，它们可以强制让操作系统立即将缓冲区中的数据写入到硬盘里面，从而确保写入数据的安全性。
aa ⒉AOF 文件的载入与数据还原：
addsa AOF文件 的载入过程：
addssa 创建一个不带网络连接的伪客户端的理由： 因为Redis 的命令只能在客户端上下文中执行，而载入 AOF 文件时所使用的命令直接来源于 AOF 文件而不是网络连接，所以服务器使用了一个没有网络连接的伪客户端来执行 AOF 文件保存的写命令。
aa ⒊AOF 文件重写的实现：
addsa 虽然 Redis 将生成新AOF 文件替换旧AOF 文件的功能命名为"AOF 文件重写“，但实际上， AOF 文件重写并不需要对现有的AOF 文件进行任何读取、分析或者写入操作，这个功能是通过读取服务器当前的数据库状态来实现的。
addsaAOF文件重写的实现原理 ： 首先从数据库中读取键现在的值， 然后用一条命令去记录键值对，代替之前记录这个键值对的多条命令。
addsa因为 aof_rewrite 函数生成的 新 AOF 文件 只包含还原当前数据库状态所必须的命令，所以新AOF 文件不会浪费任何硬盘空间。
addsa 在实际中，为了避免在执行命令时造成客户端输入缓冲区溢出，重写程序在处理列表、哈希表、集合、有序集合这四种可能会带有多个元素的键时，会先检查键所包含的元素数量，如果元素的数量 ＞redis.h/REDIS_AOF_REWRITE_ITEMS_PER_CMD 常量的值，那么重写程序将使用多条命令来记录键的值，而不单单使用一条命令。
addsa在目前版本中， REDIS_AOF_REWRIT E_IT EMS _PER_CMD 常量的值为64，也就是说单条指令的元素数量最多64个。
aa ⒊AOF 后台重写：
addsa 因为 Redis 不希望 AOF 重写造成服务器无法处理请求，所以 Redis 决定将 AOF 重写程序放到 子进程（不是子线程） 里执行（因为Redis 服务器使用 单个线程 来处理命令请求，会造成阻塞）。
addsa AOF 重写程序放到 子进程 里执行的 目的：
adddsaasa①、子进程进行 AOF 重写期间，服务器进程（父进程）可以继续处理命令请求。
adddsaasa②、子进程带有服务器进程的数据副本，使用子进程而不是线程，可以在避免使用锁的情况下，保证数据的安全性。
addsa AOF 重写使用子进程带来的问题：
adddsaasa因为子进程在进行 AOF 重写期间，服务器进程还需要继续处理命令请求，而新的命令可能会对现有的数据库状态进行修改，从而使得服务器当前的数据库状态和重写后的 AOF 文件所保存的 数据库状态不一致。
adddssa 问题解决：
adddsaasa为了解决这种数据不一致问题， Redis 服务器设置了一个 AOF 重写缓冲区，这个缓冲区在服务器创建子进程之后开始使用，当 Redis 服务器执行完一个写命令之后，它会同时将这个写命令发送给 AOF 缓冲区 和AOF 重写缓冲区。
addsa AOF 重写缓冲区的作用：
adddsaasa①、AOF 缓冲区的内容会 定期 被写入和同步到 AOF 文件，对现有 AOF 文件的处理工作会如常进行。
adddsaasa②、从创建子进程开始，服务器执行的所有写命令都会被记录到 AOF 重写缓冲区里面。
addsa AOF 重写完成后 信号处理函数 的作用：
adddsaasa当子进程完成 AOF 重写工作之后，它会向父进程发送一个信号，父进程在接到该信号之后，会调用一个 信号处理函数，并执行以下工作：
adddsaasa①、写入：将 AOF 重写缓冲区中的所有内容写入到新 AOF 文件中，这时新 AOF 文件所保存的数据库状态将和服务器当前的数据库状态一致。
adddsaasa②、改名：对新的 AOF 文件进行改名，原子地 覆盖现有的 AOF 文件，完成新旧两个 AOF 文件的替换。
adddsaasa在整个 AOF 后台重写过程中，只有信号处理函数执行时会对服务器进程（父进程）造成阻塞，在其他时候， AOF 后台重写都不会阻塞父进程，这将AOF 重写对服务器性能造成的影响降到了最低。
AOF持久化总结：
addsa①、AOF 文件 通过保存所有修改数据库的写命令 请求来记录服务器的数据库状态。
addsa②、AOF 文件中的所有命令都以 Redis 命令请求协议的格式保存。
addsa③、命令请求会先保存到 AOF 缓冲区里面，之后再定期写入并同步到 AOF 文件。
addsa④、appendfsync 选项的不同值对 AOF 持久化功能的安全性以及 Redis 服务器的性能有很大的影响。
addsa⑤、服务器只要载入并重新执行保存在 AOF 文件中的命令， 就可以还原数据库本来的状态。
addsa⑥、AOF 重写可以产生一个新的 AOF 文件，这个新的 AOF 文件和原有的 AOF 文件所保存的数据库状态一样，但体积更小。
addsa⑦、AOF 重写是一个有歧义的名字，该功能是通过读取数据库中的键值对来实现的， 程序无须对现有 AOF 文件进行任何读入、分析或者写入操作。
addsa⑧、在执行 BGREWRITEAOF 命令时， Redis 服务器会维护一个AOF 重写缓冲区，该缓冲区会在子进程创建新AOF 文件期间，记录服务器执行的所有写命令。当子进程完成创建新 AOF 文件的工作之后，服务器会将重写缓冲区中的所有内容追加到新AOF文件的末尾，使得新旧两个 AOF 文件所保存的数据库状态一致。最后，服务器用新的 AOF 文件替换旧的 AOF 文件，以此来完成 AOF 文件重写操作。
1058
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
