微信代运营协议,奢侈品网站怎么做tuig优化,app制作费用一览表,东莞市市场监督管理局官网目录 1.概述1.1.Redis 的持久化功能是指什么#xff1f;1.2.Redis 有哪些持久化机制#xff1f; 2.RDB2.1.什么是 RDB 持久化#xff1f;2.2.Redis 中使用什么命令来生成 RDB 快照文件#xff1f;2.3.如何在 Redis 的配置文件中对 RDB 进行配置#xff1f;2.4.✨RDB 持久化… 目录 1.概述1.1.Redis 的持久化功能是指什么1.2.Redis 有哪些持久化机制 2.RDB2.1.什么是 RDB 持久化2.2.Redis 中使用什么命令来生成 RDB 快照文件2.3.如何在 Redis 的配置文件中对 RDB 进行配置2.4.✨RDB 持久化的工作流程是什么样的 AOF3.1.什么是 AOF 持久化3.2.✨AOF 工作基本流程是怎样的如何开启 AOF3.3.AOF 的持久化方式有哪几种3.4.AOF 持久化过程中为什么要使用缓冲区可能会带来什么问题3.5.AOF 持久化的效率和安全性主要受什么因素影响3.6.使用 AOF 持久化可能会带来什么问题如何解决3.7.✨AOF 重写的具体过程是什么样的3.8.✨AOF 文件的载入与数据还原的过程是什么样的3.9.AOF 文件的校验机制是什么样的 4.RDB AOF4.1.✨RDB 和 AOF 这两种持久化方式有什么区别如何选择合适的持久化方式4.2.AOF 文件和 RDB 文件可不可以同时存在 参考《Redis 设计与实现》 1.概述
1.1.Redis 的持久化功能是指什么
因为 Redis 是内存数据库它将自己的数据储存在内存里面所以如果不想办法将储存在内存中的数据库状态保存到磁盘里面那么一旦服务器进程退出服务器中的数据也会消失不见。为了解决这个问题Redis 提供了持久化功能即将 Redis 内存中的数据保存到磁盘上以保证数据在 Redis 服务器重启后不会丢失。
1.2.Redis 有哪些持久化机制
Redis 提供了两种持久化机制RDB (Redis DataBase) 持久化和 AOF (Append Only File) 持久化。
2.RDB
2.1.什么是 RDB 持久化
RDB 是 Redis 的默认持久化机制它可以在指定的时间间隔内或在满足一定条件时将 Redis 内存中的数据快照保存到磁盘上以生成 RDB 文件。RDB 文件是以 Redis 数据库的数据结构和状态为基础以二进制格式保存在硬盘上。当 Redis 重启时可以通过加载 RDB 文件将数据恢复到内存中。
2.2.Redis 中使用什么命令来生成 RDB 快照文件
1Redis 提供了以下两个命令来生成 RDB 快照文件
save该命令会阻塞 Redis 服务器直到快照过程完成期间不会处理其他客户端的请求。它会将当前数据库的数据保存到一个 RDB 文件中。bgsave该命令会在后台执行快照过程不会阻塞 Redis 服务器。它会创建一个子进程来执行 RDB 快照并在子进程完成后继续处理其他客户端请求默认选项。bgsave 中的 bg 是指 background即将数据快照操作放到后台执行以确保 Redis 服务器不会停止响应其他命令请求。
2使用 save 命令会阻塞服务器直到快照完成适用于对服务器负载影响较小且可以容忍阻塞的情况。而 bgsave 命令则不会阻塞服务器适用于对服务器负载有较高要求或不能容忍阻塞的情况。生成的 RDB 快照文件会保存在 Redis 服务器指定的路径下通常是由配置文件中的 dir 选项指定的路径。文件名类似于 dump.rdb并且会覆盖之前生成的快照文件。
2.3.如何在 Redis 的配置文件中对 RDB 进行配置
1在 Redis 的配置文件 redis.conf 文件中默认有 RDB 持久化配置
save 900 1
save 300 10
save 60 10000这些配置称为检查点。上面 3 个检查点的解释依次为
每隔 900s如果有至少 1 个 key 发生了变更就生成一个新的 dump.rdb 文件这个 dump.rdb 文件就是 redis 内存中完整的数据快照也叫做 snapshotting。每隔 300s检查是否有 10 个key 发生了变更如果有则生成 dump.rdb 文件。每隔 60s检查是否有 10000个 key 发生了变更如果有则生成 dump.rdb 文件。
2可以配置多项检查点也可以移除所有检查点只需要如下配置即可
save 2.4.✨RDB 持久化的工作流程是什么样的
1RDB 是 Redis 中的一种持久化方式用于将数据库中的数据保存到硬盘上。下面是 RDB 持久化的一般工作流程
触发保存指令生成快照文件RDB 持久化的过程可以通过手动触发或配置自动触发。手动触发可以使用 SAVE 或 BGSAVE 指令而自动触发可以通过配置 Redis 的参数来实现例如通过设置 save 配置项。创建子进程当保存指令被触发后Redis 会创建一个子进程来执行实际的持久化操作。子进程的创建通常会通过 fork 系统调用在子进程中执行持久化操作而父进程则继续处理客户端请求。写入数据子进程开始执行持久化操作后会遍历数据库中的所有键值对并将数据写入到一个临时文件中。这个过程中Redis 会将数据库的所有写操作都缓存到内存中以保证数据的一致性。写入完成后替换文件当子进程将数据写入临时文件后会通过一个原子操作用临时文件替换掉原来的 RDB 文件。这样做可以保证在持久化过程中其他客户端对数据的访问不受影响只有在替换完成后才会对外提供最新的 RDB 文件。完成持久化子进程完成文件替换后会终止自身进程并返回结果给父进程。父进程会相应地更新相关的元数据标识持久化操作已经完成。
2总的来说RDB 持久化的工作流程是由触发指令、创建子进程、写入数据、替换和持久化完成这几个步骤组成。通过这个流程Redis 可以将内存中的数据保存到硬盘上实现数据的持久化和恢复。需要注意的是RDB 持久化是一种快照方式保存的是数据在某个时间点的状态因此在进行恢复时会使用最新的 RDB 文件进行加载。
AOF
3.1.什么是 AOF 持久化
AOF 持久化是指在每次写操作时将操作记录追加到 AOF 文件末尾。这样当 Redis 重启时可以通过重新执行 AOF 文件中的操作来恢复 Redis 数据库中的数据。
3.2.✨AOF 工作基本流程是怎样的如何开启 AOF
1AOF 持久化功能的实现可以分为以下几步
命令追加 (append)服务器在执行完一个写命令之后会以协议格式将被执行的写命令追加到服务器状态的 aof_buf 缓冲区的末尾:文件写入 (write)将 AOF 缓冲区的数据写入到 AOF 文件中。这一步需要调用 write 函数系统调用write 函数将数据写入到了系统内核缓冲区之后直接返回延迟写。需要注意的是此时并没有同步到磁盘。文件同步 (fsync)AOF 缓冲区根据对应的持久化方式fsync 策略向硬盘做同步操作。这一步需要调用 fsync 函数系统调用 fsync 针对单个文件操作对其进行强制硬盘同步fsync 将阻塞直到写入磁盘完成后返回保证了数据持久化。文件重写 (rewrite)随着 AOF 文件越来越大需要定期对 AOF 文件进行重写达到压缩 AOF 文件的目的。重启加载 (load)当 Redis 重启时可以加载 AOF 文件进行数据恢复。
2AOF 持久化配置默认是关闭的所以需要手动开启即在 Redis 配置文件 redis.conf 中添加如下配置即可
appendonly yes同理如果上述配置为 appendonly no则表示关闭 AOF 持久化。开启 AOF 持久化后就可以写入持久化文件 appendonly.aof 中当然这个文件名字也是可以通过配置项 appendfilename 来设置的。
3.3.AOF 的持久化方式有哪几种
1在 Redis 的配置文件中存在三种不同的 AOF 持久化方式即 appendfsync 选项的值它们分别是 2如果用户没有主动为 appendfsync 选项设置值那么 appendfsync 选项的默认值为 everysec其原因在于 everysec 兼顾了数据和写入性能。它让 Redis 每秒同步一次 AOF 文件Redis 性能受到的影响较小。而且这样即使出现系统崩溃用户最多只会丢失一秒之内产生的数据。当硬盘忙于执行写入操作的时候Redis 还会放慢自己的速度以便适应硬盘的最大写入速度。
3.4.AOF 持久化过程中为什么要使用缓冲区可能会带来什么问题
1为了提高文件的写入效率在现代操作系统中当用户调用 write 函数将一些数据写入到文件的时候操作系统通常会将写入数据暂时保存在一个内存缓冲区里面等到缓冲区的空间被填满、或者超过了指定的时限之后才真正地将缓冲区中的数据写入到磁盘里面。
2这种做法虽然提高了效率但也为写入数据带来了安全问题因为如果计算机发生停机那么保存在内存缓冲区里面的写入数据将会丢失。为此系统提供了 fsync 和 fdatasync 两个同步函数它们可以强制让操作系统立即将缓冲区中的数据写入到硬盘里面从而确保写入数据的安全性。
3.5.AOF 持久化的效率和安全性主要受什么因素影响
1服务器配置 appendfsync 选项的值直接决定 AOF 持久化功能的效率和安全性:
当 appendfsync 的值为 always 时服务器在每个事件循环都要将 aof_buf 缓冲区中的所有内容写入到 AOF 文件并且同步 AOF 文件所以 always 的效率是 appendfsync 选项三个值当中最慢的一个但从安全性来说always 也是最安全的因为即使出现故障停机AOF 持久化也只会丢失一个事件循环中所产生的命令数据。当 appendfsync 的值为 everysec 时服务器在每个事件循环都要将 aof_buf 缓冲区中的所有内容写入到 AOF 文件并且每隔一秒就要在子线程中对AOF 文件进行一次同步。从效率上来讲everysec 模式足够快并且就算出现故障停机,数据库也只丢失一秒钟的命令数据。当 appendfsync 的值为 no 时服务器在每个事件循环都要将 aof_buf 缓冲区中的所有内容写入到 AOF 文件至于何时对 AOF 文件进行同步则由操作系统控制。因为处于 no 模式下的 flushAppendonlyFile 调用无须执行同步操作所以该模式下的 AOF 文件写入速度总是最快的不过因为这种模式会在系统缓存中积累一段时间的写入数据所以该模式的单次同步时长通常是三种模式中时间最长的。
2从平摊操作的角度来看no 模式和 everysec 模式的效率类似当出现故障停机时使用 no 模式的服务器将丢失上次同步 AOF 文件之后的所有写命令数据。
3.6.使用 AOF 持久化可能会带来什么问题如何解决
1如果使用 AOF 持久化可能会带来以下两个问题
因为 Redis 会不断地将被执行的写命令记录到 AOF 文件里面所以随着 Redis 不断运行AOF 文件的体积也会不断增长在极端情况下体积不断增大的 AOF 文件甚至可能会用完硬盘的所有可用空间。因为 Redis 在重启之后需要通过重新执行 AOF 文件记录的所有写命令来还原数据集所以如果 AOF 文件的体积非常大那么还原操作执行的时间就可能会非常长。
2为了解决 AOF 文件体积不断增大的问题用户可以向 Redis 发送 BGREWRITEAOF 命令这个命令会通过移除 AOF 文件中的冗余命令来重写 (rewrite) AOF 文件使 AOF 文件的体积变得尽可能地小。BGREWRITEAOF 的工作原理和 BGSAVE 创建快照的工作原理非常相似Redis 会创建一个子进程然后由子进程负责对 AOF 文件进行重写。 注意因为 AOF 文件重写也需要用到子进程所以快照持久化因为创建子进程而导致的性能问题和内存占用问题在 AOF 持久化中也同样存在。更糟糕的是如果不加以控制的话AOF 文件的体积可能会比快照文件的体积大好几倍在进行 AOF 重写并删除旧 AOF 文件的时候删除一个体积达到数十 GB 大的旧 AOF 文件可能会导致操作系统挂起 (hang) 数秒。 3AOF 持久化也可以通过设置下面两个选项来自动执行 BGREWRITEAOF
auto-aof-rewrite-min-size该值表示触发 AOF 重写的 AOF 文件最小值。如果 AOF 文件大小小于该值则不会触发 AOF 重写默认值为 64 MBauto-aof-rewrite-percentage该值表示当前 AOF 大小 aof_current_size 和上一次重写时 AOF 大小 aof_base_size 的比值。如果当前 AOF 文件大小增加了这个百分比值将触发 AOF 重写。将此值设置为 0 将禁用自动 AOF 重写默认值为 100 举个例子假设用户对 Redis 设置了配置选项 auto-aof-rewrite-percentage 100 和 auto-aof-rewrite-min-size 64mb并且启用了 AOF 持久化那么当 AOF 文件的体积大于 64 MB并且 AOF 文件的体积比上一次重与之后的体积大了至少一倍的时候Redis 将执行 BGREWRITEAOF 命令。如果 AOF 重写执行得过于频繁的话用户可以考虑将 auto-aof-rewrite-percentage 选项的值设置为 100 以上这种做法可以让 Redis 在 AOF 文件的体积变得更大之后才执行重写操作不过也会让 Redis 在启动时还原数据集所需的时间变得更长。 3.7.✨AOF 重写的具体过程是什么样的
1AOF 是 Redis 里面的一种数据持久化方式它采用了指令追加的方式近乎实时地去实现数据指令的持久化因为 AOF 持久化会把每个数据更改的操作指令追加存储到 AOF 文件里面。所以很容易导致 AOF 文件出现过大造成 I/O 性能问题。
2Redis 为了解决这个问题设计了 AOF 重写机制也就是说把 AOF 文件里面相同的指令进行压缩只保留最新的数据指令。简单来说如果 AOF 文件里面存储了某个 key 的多次变更记录但是实际上最终在做数据恢复的时候只需要执行最新的指令操作就行了历史的数据就没必要存在这个文件里面占空间。
3AOF 文件重写的具体过程分为以下几步
首先根据当前 Redis 内存里面的数据重新构建一个新的 AOF 文件然后读取当前 Redis 里面的数据写入到新的 AOF 文件里面最后重写完成以后用新的 AOF 文件覆盖现有的 AOF 文件
4在这个过程有三个需要注意的地方
因为 AOF 在重写的过程中需要读取当前内存里面所有的键值数据再生成对应的一条指令进行保存。而这个过程是比较耗时的对业务会产生影响。所以 Redis 把重写的过程放在一个后台子进程里面来完成这样一来子进程在做重写的时候主进程依然可以继续处理客户端请求。为了避免子进程在重写过程中主进程的数据发生变化导致 AOF 文件和 Redis 内存中的数据不一致的问题Redis 做了一层优化即子进程在重写的过程中主进程的数据变更需要追加到 AOF 重写缓冲区里面。等到 AOF 文件重写完成以后再把 AOF 重写缓冲区里面的内容追加到新的 AOF 文件里面。在进行 AOF 文件重写时需要新建一个 AOF 文件并将重写后的结果写入到该文件中而不能直接在原 AOF 文件上进行操作这样做的目的在于防止在重写过程中系统出现异常从而导致在数据还原时原 AOF 文件中的出现数据不一致的情况。
3.8.✨AOF 文件的载入与数据还原的过程是什么样的
1AOF 文件的载入于数据还原的过程如下
① 创建一个不带网络连接的伪客户端 (fake client)因为 Redis 的命令只能在客户端上下文中执行而载入 AOF 文件时所使用的命令直接来源于 AOF 文件而不是网络连接所以服务器使用了一个没有网络连接的伪客户端来执行 AOF 文件保存的写命令伪客户端执行命令的效果和带网络连接的客户端执行命令的效果完全一样。② 从 AOF 文件中分析并读取出一条写命令。③ 使用伪客户端执行被读出的写命令。④ 一直执行步骤 ② 和步骤 ③直到 AOF 文件中的所有写命令都被处理完毕为止。
2当完成以上步骤之后AOF 文件所保存的数据库状态就会被完整地还原出来整个过程如下图所示 3.9.AOF 文件的校验机制是什么样的
1Redis 的 AOF 持久化机制中存在校验和 (checksum) 的校验机制用于确保 AOF 文件内容的完整性。
2在 Redis 的 AOF 持久化过程中每次写入操作完成后Redis 都会计算校验和并将其附加到 AOF 文件的结尾。当 Redis 重新读取 AOF 文件时它会根据文件内容计算校验和并将其与 AOF 文件结尾附加的校验和进行比较。如果两者不相等则意味着 AOF 文件已经被损坏或者篡改Redis 将拒绝加载文件并退出。Redis 使用的校验和算法是 CRC64 校验和算法这是一种广泛应用于数据传输和存储中的校验和算法能够提供较高的校验精度并具有较高的执行效率。
3因为校验和机制的存在Redis 的 AOF 文件具有较高的数据完整性和安全性可以有效避免硬件故障、操作系统错误以及网络攻击等因素对 AOF 文件内容的破坏。在 Redis 的实际应用场景中AOF 文件的校验机制为用户提供了一种有效的保护机制帮助用户保障数据的安全和完整性。
4.RDB AOF
4.1.✨RDB 和 AOF 这两种持久化方式有什么区别如何选择合适的持久化方式
1RDB 和 AOF 这两种持久化方式的区别如下所示
RDBAOF文件格式将 Redis 的数据结构以二进制格式保存在磁盘上将 Redis 服务器接收到的每个写操作以文本格式追加到 AOF 文件末尾是一种易于理解和解析的格式包含所有操作的日志我们可以轻松地导出 AOF 文件进行分析也可以直接操作 AOF 文件来解决一些问题文件大小生成的文件较小因为它是以快照的方式保存 Redis 数据库的状态适合做数据的备份灾难恢复AOF 文件通常比 RDB 文件大因为它需要保存每个写操作数据恢复速度通常比 AOF 持久化快因为 RDB 文件中的数据是 Redis 数据库的状态的快照直接解析还原数据即可不需要一条一条地执行命令速度非常快需要将文件中的每个操作依次执行才能将数据恢复到 Redis 内存中因此数据恢复速度比 RDB 慢数据丢失因为 RDB 文件是定期生成的快照如果 Redis 在快照生成之后崩溃就可能会丢失一部分数据无法做到实时备份数据AOF 持久化可以在每个写操作后追加到 AOF 文件中实时记录操作历史避免数据丢失对性能的影响对性能影响相对较小因为它是在指定的时间间隔内进行快照不会在每次写操作时执行。但是在进行快照时Redis 会 fork 出一个子进程来处理快照生成的过程如果 Redis 内存中的数据量比较大fork 的过程会占用较高的 CPU 和内存资源影响 Redis 的正常运行对性能影响相对较大因为它会在每个写操作时执行将写操作记录到 AOF 文件中由于 AOF 文件需要频繁地写入如果磁盘的写入性能比较低可能会影响 Redis 的写入性能安全性RDB 的数据安全性不如 AOF没有办法实时或者秒级持久化数据AOF 支持秒级数据丢失取决 fsync 策略如果是 everysec最多丢失 1 秒的数据仅仅是追加命令到 AOF 文件操作轻量
2选择持久化方式的建议
Redis 保存的数据丢失一些也没什么影响的话可以选择使用 RDB不建议单独使用 AOF因为时不时地创建一个 RDB 快照可以进行数据库备份、更快的重启以及解决 AOF 引擎错误如果保存的数据要求安全性比较高的话建议同时开启 RDB 和 AOF 持久化或者开启 RDB 和 AOF 混合持久化
4.2.AOF 文件和 RDB 文件可不可以同时存在
AOF 和 RDB 是可以同时存在的只不过需要注意以下几点
同时生成了 RDB 和 AOF 文件先使用 AOF 进行数据恢复。如果 RDB 正在生成快照文件而用户又在执行 AOF 重写命令那么需要等到 RDB 快照生成之后才会执行 AOF 重写。如果 RDB 正在生成快照文件那么 Redis 不会去执行 AOF 重写相反也是。
