百度网站优化公司,海北公司网站建设,wordpress侧边栏提示,企业邮箱是qq邮箱吗4 Redis持久化 Redis 是一个内存数据库#xff0c;然而内存中的数据是不持久的#xff0c;若主机宕机或 Redis 关机重启#xff0c;则内存中的数据全部丢失。 当然#xff0c;这是不允许的。Redis 具有持久化功能#xff0c;其会按照设置以快照或操作日志的形式将数据持…4 Redis持久化 Redis 是一个内存数据库然而内存中的数据是不持久的若主机宕机或 Redis 关机重启则内存中的数据全部丢失。 当然这是不允许的。Redis 具有持久化功能其会按照设置以快照或操作日志的形式将数据持久化到磁盘。 4.1 持久化基本原理 Redis 持久化也称为钝化是指将内存中数据库的状态描述信息保存到磁盘中。 只不过是不同的持久化技术对数据的状态描述信息是不同的生成的持久化文件也是不同的。但它们的作用都是相同的避免数据意外丢失。 通过手动方式或自动定时方式或自动条件触发方式将内存中数据库的状态描述信息写入到指定的持久化文件中。当系统重新启动时自动加载持久化文件并根据文件中数据库状态描述信息将数据恢复到内存中这个数据恢复过程也称为激活。 这个钝化与激活的过程就是 Redis 持久化的基本原理。 不过从以上分析可知对于 Redis 单机状态下无论是手动方式还是定时方式或条件触发方式都存在数据丢失问题在尚未手动/自动保存时发生了 Redis 宕机状况那么从上次保存到宕机期间产生的数据就会丢失。不同的持久化方式其数据的丢失率也是不同的。 4.2 Redis默认RDB持久化 Redis默认使用RDB方式进行持久化, 即若不进行任何配置, 那么每次开机系统会自动加载Redis安装目录下的dump.rdb文件, 复原数据库到上一个记录点 同时 , 尽管RDB为Redis的默认持久化方式但 Redis 允许 RDB 与 AOF 两种持久化技术同时开启此时系统会优先使用 AOF 方式做持久化即加载AOF持久化文件进行数据库复原. 4.3 RDB 持久化 RDB(Redis DataBase)是指将内存中某一时刻的数据快照全量写入到指定的 rdb 二进制文件的持久化技术。 RDB 持久化默认是开启的。当 Redis 启动时会自动读取 RDB 快照文件将数据从硬盘载入到内存以恢复 Redis 关机前的数据库状态。 4.3.1 RDB持久化的执行 RDB 持久化的执行有三种方式手动 SAVE 命令、手动 BGSAVE 命令与自动条件触发。 4.3.1.1 手动SAVE命令 执行 SAVE 命令可立即进行一次持久化保存。 SAVE 命令在执行期间会阻塞 redis-server 进程直至持久化过程完毕。即在执行SAVE命令的过程中 , Redis不能处理任何读写请求无法对外提供服务。 4.3.1.2 手动BGSAVE命令 background save后台运行 save。 执行BGSAVE 命令会使服务器进程 redis-server 生成一个子进程由该子进程负责完成保存过程。 在子进程进行保存过程中不会阻塞 redis-server 进程对客户端读写请求的处理。 4.3.1.3 自动条件触发 动条件触发的本质仍是 BGSAVE命令的执行。只不过是用户通过在配置文件中做相应的设置后Redis 会根据设置信息自动调用 BGSAVE 命令执行。具体配置方式后面会详解。 4.3.1.4 LASTSAVE查看最近一次什么时候执行过持久化 通过 LASTSAVE 命令可以查看最近一次执行持久化的时间其返回的是一个 Unix 时间戳。 4.3.2 RDB优化配置 RDB 相关的配置在 redis.conf 文件的 SNAPSHOTTING 部分。 4.3.2.1 sava 该配置用于设置快照的自动保存触发条件即 save point保存点。该触发条件是在指定时间段内发生了指定次数的写操作。除非另有规定默认情况下持久化条件为 save 3600 1 300 100 60 10000。其等价于以下三条 save 3600 1 # 在 3600 秒(1 小时)内发生 1 次写操作save 300 100 # 在 300 秒(5 分钟)内发生 100 次写操作save 60 10000 # 在 60 秒(1 分钟)内发生 1 万次写操作 如果不启用 RDB 持久化只需设置 save 的参数为空串即可save “”。 Redis7之前 , 自动触发条件为: 4.3.2.2 stop-write-on-bgsave-error 默认情况下如果 RDB 快照已启用至少一个保存点且最近的 bgsave 命令失败Redis将停止接受写入。 这样设置是为了让用户意识到数据没有正确地保存到磁盘上否则很可能没有人会注意到并会发生一些灾难。 当然如果 bgsave 命令后来可以正常工作了Redis将自动允许再次写入。 4.3.2.3 rdbcompression 当进行持久化时启用 LZF 压缩字符串对象。 虽然压缩 RDB 文件会消耗系统资源降低性能但可大幅降低文件的大小方便保存到磁盘加速主从集群中从节点的数据同步。 4.3.2.4 rdbchecksum 从 RDB5 开始RDB 文件的 CRC64 校验和就被放置在了文件末尾。这使格式更能抵抗 RDB文件的损坏但在保存和加载 RDB 文件时性能会受到影响约 10%因此可以设置为 no禁用校验和以获得最大性能。在禁用校验和的情况下创建的 RDB 文件的校验和为零这将告诉加载代码跳过校验检查。默认为 yes开启了校验功能。 4.3.2.5 sanitize-dump-payload 该配置用于设置在加载 RDB 文件或进行持久化时是否开启对 zipList、listPack 等数据的全面安全检测。 该检测可以降低命令处理时发生系统崩溃的可能。其可设置的值有三种选择 no不检测yes总是检测clients只有当客户端连接时检测。排除了加载 RDB 文件与进行持久化时的检测。默认值本应该是 clients但其会影响 Redis 集群的工作所以默认值为 no不检测。 4.3.2.6 dbfilename 指定 RDB 文件的默认名称默认为 dump.rdb。 4.3.2.7 rdb-del-sync-files 主从复制时是否删除用于同步的从机上的 RDB 文件。 默认是 no不删除。 不过需要注意只有当从机的 RDB 和 AOF 持久化功能都未开启时, 这个设置才会被系统检测并应用。 4.3.2.8 dir 指定 RDB 与 AOF 文件的生成目录。默认为 Redis 安装根目录。 4.3.3 RDB文件结构 RDB 持久化文件 dump.rdb 整体上有五部分构成 1 SOF SOF 是一个常量一个字符串 REDIS仅包含这五个字符其长度为 5。用于标识 RDB文件的开始以便在加载 RDB 文件时可以迅速判断出文件是否是 RDB 文件。 2 rdb_version 这是一个整数长度为 4 字节表示 RDB 文件的版本号。 3 EOF EOF 是一个常量占 1 个字节用于标识 RDB 数据的结束校验和的开始。 4 check_sum 校验和 check_sum 用于判断 RDB 文件中的内容是否出现数据异常。其采用的是 CRC 校验算法。 CRC 校验算法 在持久化时先将 SOF、rdb_version 及内存数据库中的数据快照这三者的二进制数据拼接起来形成一个二进制数假设称为数 a然后再使用这个 a 除以校验和 check_sum此时可获取到一个余数 b然后再将这个 b 拼接到 a 的后面形成 databases。 在加载时需要先使用 check_sum 对 RDB 文件进行数据损坏验证。 验证过程只需将RDB 文件中除 EOF 与 check_sum 外的数据除以 check_sum。只要除得的余数不是 0就说明文件发生损坏。当然如果余数是 0也不能肯定文件没有损坏。 这种验证算法是数据损坏校验而不是数据没有损坏的校验。 即: 除得余数不为0, 一定损坏 ; 除得余数不为0 , 也未必完好 5 databases databases 部分是 RDB 文件中最重要的数据部分其可以包含任意多个非空数据库。而每个 database 又是由三部分构成 SODB是一个常量占 1 个字节用于标识一个数据库的开始。db_number数据库编号。key_value_pairs当前数据库中的键值对数据。 进一步的 , 对于每一个键值对, 还分为带过期时间和不带的版本 4.3.4 RDB持久化过程 对于 Redis 默认的 RDB 持久化在进行 bgsave 持久化时redis-server 进程会 fork 出一个 bgsave 子进程由该子进程以异步方式负责完成持久化。而在持久化过程中redis-server进程不会阻塞其会继续接收并处理用户的读写请求。 bgsave 子进程的详细工作原理如下 由于子进程可以继承父进程的所有资源且父进程不能拒绝子进程的继承权。所以 bgsave 子进程有权读取到 redis-server 进程写入到内存中的用户数据使得将内存数据持久化到 dump.rdb 成为可能。 bgsave 子进程在持久化时首先会将内存中的全量数据 copy 到磁盘中的一个 RDB 临时文件copy 结束后再将该文件 rename 为 dump.rdb替换掉原来的同名文件。 不过在进行持久化过程中如果 redis-server 进程接收到了用户写请求则系统会将内存中发生数据修改的物理块 copy 出一个副本。等内存中的全量数据 copy 结束后会再将副本中的数据 copy 到 RDB 临时文件。这个副本的生成是由于 Linux 系统的写时复制技术Copy-On-Write实现的。 4.3.5 写时复制(Copy-On-Write 原本在 Unix 系统中当一个主进程通过 fork()系统调用创建子进程后内核进程会复制主进程的整个内存空间中的数据然后分配给子进程。这种方式存在的问题有以下几点 这个过程非常耗时这个过程降低了系统性能如果主进程修改了其内存数据子进程副本中的数据是没有修改的。即出现了数据冗余而冗余数据最大的问题是数据一致性无法保证。 现代的 Linux 则采用了更为有效的方式写时复制。 子进程会继承父进程的所有资源其中就包括主进程的内存空间。即子进程与父进程共享内存。只要内存被共享那么该内存就是只读的写保护的。而写时复制则是在任何一方需要写入数据到共享内存时都会出现异常此时内核进程就会将需要写入的数据 copy 出一个副本写入到另外一块非共享内存区域。 4.4 AOF持久化 AOFAppend Only File是指 Redis 将每一次的写操作都以日志的形式记录到一个 AOF文件中的持久化技术。 当需要恢复内存数据时将这些写操作重新执行一次便会恢复到之前的内存数据状态。 4.4.1 AOF基础配置 4.4.1.1 AOF的开启 默认情况下 AOF 持久化是没有开启的通过修改配置文件中的 appendonly 属性为 yes可以开启。 4.4.1.2 文件名配置(Redis7新变化) Redis 7 在这里发生了重大变化。原来只有一个 appendonly.aof 文件现在具有了三类多个文件 基本文件可以是 RDF 格式也可以是 AOF 格式。其存放的内容是由 RDB 转为 AOF 当时内存的快照数据。该文件可以有多个。增量文件以操作日志形式记录转为 AOF 后的写入操作。该文件可以有多个。清单文件用于维护 AOF 文件的创建顺序保障激活时的应用顺序。该文件只有一个。 4.4.1.3 混合持久化开启 对于基本文件可以是 RDF 格式也可以是 AOF 格式。通过 aof-use-rdb-preamble 属性可以选择。其默认值为 yes即默认 AOF 持久化的基本文件为 rdb 格式文件也就是默认采用混合式持久化。 后续对混合持久化有详细介绍. 4.4.1.4 配置AOF持久化文件存放位置 4.4.2 AOF文件格式 AOF 文件包含三类文件基本文件、增量文件与清单文件。其中基本文件一般为 rdb 格式在前面已经研究过了。下面就来看一下增量文件与清单文件的内容格式。 4.4.2.1 Redis协议(.aof文件) 增量文件扩展名为.aof采用 AOF 格式。AOF 格式其实就是 Redis 通讯协议格式AOF持久化文件的本质就是基于 Redis 通讯协议的文本将命令以纯文本的方式写入到文件中。 Redis 协议规定Redis 文本是以行来划分每行以\r\n 行结束。每一行都有一个消息头以表示消息类型。 4.4.3 rewrite机制 AOF 持久化是通过保存被执行的写命令来记录数据库状态的随着写入命令的不断增加AOF 文件中的内容会越来越多文件的体积也会越来越大。 如果不加以控制体积过大的 AOF 文件可能会对 Redis 服务器、甚至整个宿主机造成影响并且 AOF 文件的体积越大使用 AOF 文件来进行数据还原所需的时间就越多。 举个例子 如果你对一个计数器调用了 100 次 INCR 那么仅仅是为了保存这个计数器的当前值 AOF 文件就需要使用 100 条记录。 然而在实际上 只使用一条 SET 命令已经足以保存计数器的当前值了 其余 99 条记录实际上都是多余的。 4.4.3.1 什么是rewrite 因此, AOF 重写就是 : 在不打断服务端处理请求的情况下 对 AOF 文件进行重建rebuild。这个新的 AOF 文件包含重建当前数据集所需的最少命令。 具体过程是遍历所有数据库的所有键从数据库读取键现在的值然后用一条命令去记录键值对代替之前记录这个键值对的多条命令。 当 Rewrite 开启后主进程 redis-server创建出一个子进程 bgrewriteaof由该子进程完成 rewrite 过程。其首先对现有 aof 文件进行rewrite 计算将计算结果写入到一个临时文件写入完毕后再 rename 该临时文件为原 aof文件名覆盖原有文件。 4.4.3.2 rewrite计算(rewrite策略) rewrite计算(rewrite策略)遵循的原则 读操作命令不写入文件无效命令不写入文件过期数据不写入文件多条命令合并写入文件 4.4.3.3 手动开启rewrite 4.4.3.4 条件触发开启rewrite 由于 Rewrite 过程是一个计算过程需要消耗大量系统资源会降低系统性能。 所以Rewrite 过程并不是随时随地任意开启的而是通过设置一些条件当满足条件后才会启动以降低对性能的影响。 4.4.4 AOF优化配置 4.4.4.1 appendfsync 4.4.5 AOF持久化过程 Redis 接收到的写操作命令并不是直接追加到磁盘的 AOF 文件的而是将每一条写命令按照 redis 通讯协议格式暂时添加到 AOF 缓冲区 aof_buf。根据设置的数据同步策略(appendfsync)当同步条件满足时再将缓冲区中的数据一次性写入磁盘的AOF 文件以减少磁盘 IO 次数提高性能。当磁盘的 AOF 文件大小达到了 rewrite 条件时redis-server 主进程会 fork 出一个子进程bgrewriteaof由该子进程完成 rewrite 过程。子进程 bgrewriteaof 首先对该磁盘 AOF 文件进行 rewrite 计算将计算结果写入到一个临时文件全部写入完毕后再 rename 该临时文件为磁盘文件的原名称覆盖原文件。如果在 rewrite 过程中又有写操作命令追加那么这些数据会暂时写入 aof_rewrite_buf缓冲区。等将全部 rewrite 计算结果写入临时文件后会先将 aof_rewrite_buf 缓冲区中的数据写入临时文件然后再 rename 为磁盘文件的原名称覆盖原文件。 4.5 混合持久化 为什么要采用混合持久化? 重启Redis时我们很少使用RDB来恢复内存状态因为会丢失大量数据。我们通常使用AOF日志恢复。但是AOF日志性能相对RDB来说要慢很多这样在Redis实例很大的情况下启动需要花费很长的时间。 当redis 重启时候会优先载入AOF文件来恢复原始的数据因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整 RDB镜像做全量持久化AOF做增量持久化 先使用RDB进行快照存储然后使用AOF持久化记录所有的写操作当重写策略满足或手动触发重写的时候将最新的数据存储为新的RDB记录。这样的话重启服务的时候会从RDB和AOF两部分恢复数据既保证了数据完整性又提高了恢复数据的性能。简单来说混合持久化方式产生的文件一部分是RDB格式一部分是AOF格式。----》AOF包括了RDB头部AOF混写 fork 出的子进程先将当前全量数据以 RDB 方式写入新的 AOF 文件然后再将 AOF 重写缓冲区aof_rewrite_buf_blocks的增量命令以 AOF 方式写入到文件写入完成后通知主进程将新的含有 RDB 格式和 AOF 格式的 AOF 文件替换旧的的 AOF 文件。 4.5.1 开启混合持久化 # 同时开启RDB和AOF持久化 save 900 1 save 300 10 save 60 10000appendonly yesaof‐use‐rdb‐preamble yes如果开启了混合持久化AOF在重写时不再是单纯将内存数据转换为RESP命令写入AOF文件而是将重写这一刻之前的内存做RDB快照处理并且将RDB快照内容和增量的AOF修改内存数据的命令存在一起都写入新的AOF文件新的文件一开始不叫appendonly.aof,等到重写完新的AOF文件才会进行改名覆盖原有的AOF文件完成新旧两个AOF文件的替换。于是在Redis重启的时候可以先加载RDB的内容然后再重放增量AOF日志就可以完全替代之前的AOF全量文件重放因此重启效率大幅得到提升4.6 RDB和AOF比较 RDB的优势 RDB 文件较小数据恢复较快, 因此适合大规模的数据恢复 RDB的缺点 数据安全性较差写时复制会降低性能RDB 文件可读性较差 AOF优势 数据安全性高AOF 文件可读性强 AOF缺点 AOF 文件较大写操作会影响性能数据恢复较慢 4.7 技术选型 官方推荐使用 RDB 与 AOF 混合式持久化。若对数据安全性要求不高则推荐使用纯 RDB 持久化方式。不推荐使用纯 AOF 持久化方式。若 Redis 仅用于缓存则无需使用任何持久化技术。