网站分享链接怎么做的,免费做mc皮肤网站,东营优化路网,做寂网站Redis 持久化操作详解
Redis 实现持久化的时候#xff0c;具体是按照什么样的策略来实现的呢#xff1f;
Redis支持两种方式的持久化#xff0c;一种是RDB方式、另一种是AOF#xff08;append-only-file#xff09;方式#xff0c;两种持久化方式可以单独使用其中一种具体是按照什么样的策略来实现的呢
Redis支持两种方式的持久化一种是RDB方式、另一种是AOFappend-only-file方式两种持久化方式可以单独使用其中一种也可以将这两种方式结合使用。
RDB(Redis DataBase)根据指定的规则将内存中的数据定期备份存储在硬盘上AOF(Append Only File)每次执行命令后将命令本身记录下来实时备份。
一、RDB 持久化
1.1 RDB 原理
RDB 持久化是通过生成数据快照Snapshot的方式将 Redis 内存中的数据写入到磁盘上的二进制文件中。这个文件被称为 RDB 文件。RDB 文件可以在 Redis 重启时用于恢复数据。 Redis 提供了两种生成 RDB 文件的命令SAVE 和 BGSAVE。
SAVE 命令在主线程中执行生成 RDB 文件的操作。由于 由于和执行操作命令在同一个线程如果写入 RDB 文件的时间太长中会阻塞主线程BGSAVE 命令创建一个子进程来生成 RDB 文件这样可以避免了阻塞主线程的情况
重点介绍一下BGSAVE的工作流程
Redis的BGSAVEe工作流程是通过创建子进程来实现异步生成快照。在这个过程中Redis使用了写时复制copy-on-write技术它的核心思想是在主进程发生写操作时会将相关的内存页复制一份然后交给子进程使用而主进程则继续进行正常的读写操作。这样可以保证只有在出现需要变更的数据时才进行数据复制从而减少额外内存消耗和提高性能。 当执行BGSAVE命令时Redis会创建一个子进程来执行实际的持久化工作同时父进程继续处理客户端的其他请求。子进程会将数据写入内存的临时文件中使用写时复制技术来保证数据的一致性。在生成RDB文件的过程中只有当发生需要变更的数据时才进行内存页的复制从而避免内存的额外占用。
1.2 RDB 自动化配置
Redis 可以通过配置文件的选项来实现自动化的 RDB 持久化
配置文件位置一般
具体配置如下
save 900 1
save 300 10
save 60 10000别看选项名叫 save实际上执行的是 bgsave 命令也就是会创建子进程来生成 RDB 快照文件。开启之后RDB的目录一般默认/var/lib/redis可以自行配置的
只要满足上面条件的任意一个就会执行 bgsave它们的意思分别是
900 秒之内对数据库进行了至少 1 次修改300 秒之内对数据库进行了至少 10 次修改60 秒之内对数据库进行了至少 10000 次修改。
只要满足以上任一条件Redis 就会执行一次 BGSAVE 操作。
Redis 的 RDBRedis Database快照是全量快照每次执行时都会将内存中的所有数据记录到磁盘。如果设置频率太高则会让成本变高负载较重频繁执行会影响 Redis 的性能而设置的频率太低则会在服务器故障时导致更多数据丢失。通常RDB 快照至少设置为每 5 分钟保存一次以在性能和数据丢失风险之间取得平衡。与 AOFAppend Only File持久化相比RDB 快照在故障时可能丢失更多数据因为 AOF 可以每秒记录操作减少数据丢失。
如果 Redis 服务器宕机在使用 RDB 快照时系统会丢失自上次快照以来的所有数据。例如如果快照每 5 分钟执行一次宕机时最多可能会丢失 5 分钟的数据。
1.3 RDB 的优缺点
优点
数据恢复速度快RDB 文件是紧凑的二进制文件加载速度很快。占用磁盘空间小RDB 文件经过压缩占用的磁盘空间较少。适合大数据恢复在数据量较大时RDB 文件的加载速度要比 AOF 快得多。
缺点
数据丢失风险较高由于 RDB 是定期快照如果 Redis 在两次快照之间发生故障所有在此期间的数据修改将会丢失。频繁快照对性能的影响频繁执行 BGSAVE 操作会导致额外的磁盘 I/O 操作和 CPU 资源消耗。
1.4 RDB 快照期间的数据修改
在执行 BGSAVE 过程中Redis 仍然可以继续处理写操作。这是通过写时复制技术Copy-On-Write, COW实现的。当 BGSAVE 命令执行时Redis 会通过 fork() 创建一个子进程子进程与主进程共享相同的内存数据。只有在修改数据时才会将被修改的数据复制一份从而主进程可以继续处理新的写操作而子进程可以继续读取原来的数据进行 RDB 快照。 Redis 的 BGSAVE 机制通过创建子进程在后台执行数据快照有效地减少了创建子进程时的性能损耗并避免了阻塞主线程。子进程与父进程共享内存数据使得子进程可以直接读取并写入 RDB 文件而不会影响主线程的只读操作。然而一旦主线程需要修改共享数据就会触发写时复制机制复制数据副本供主线程修改而子进程继续使用原始数据进行快照。这意味着在快照过程中主线程的修改不会即时反映到 RDB 文件中存在数据丢失的风险。此外极端情况下频繁的写操作可能导致内存占用翻倍因此在写操作密集的场景中需要密切监控内存使用以防止内存耗尽。总之bgsave 提供了一种高效的数据持久化方式但同时也需要谨慎管理内存资源和考虑数据一致性问题。
1.5 RDB 实践示例
在实际应用中可以通过以下命令和配置来实现 RDB 持久化 在命令行中手动生成 RDB 快照 SAVE或 BGSAVE配置文件设置自动生成 RDB 快照 save 900 1
save 300 10
save 60 10000二、AOF 持久化
2.1 AOF 原理
AOFAppend Only File持久化通过记录每次写操作的日志来实现数据的持久化。Redis 将每次写操作例如 SET、INCR 等记录到 AOF 文件中当 Redis 重启时可以通过重放 AOF 文件中的写操作来恢复数据。
AOF 的⼯作流程操作命令写⼊append、⽂件同步sync、⽂件重写rewrite、重启加载load 在 Redis 中 AOF 持久化功能默认是不开启的需要我们修改 redis.conf 配置文件中的以下参数
开启之后所在的位置和RDB的目录一样:/var/lib/redis可以自行配置的 AOF 文件是纯文本文件包含了所有修改 Redis 数据的命令。Redis 提供了三种不同的同步策略来控制 AOF 文件的写入频率
appendfsync always每次有数据修改时都同步到 AOF 文件性能最差但数据最安全。appendfsync everysec每秒同步一次 AOF 文件性能和数据安全性之间的折中方案。appendfsync no由操作系统决定何时同步 AOF 文件性能最好但数据安全性最差。
写回策略写回时机优点缺点Always同步写回可靠性高、最大程度保证数据不丢失性能开销大Everysec每秒写回性能适中宕机时会丢失1秒内的数据No由操作系统控制写回性能好宕机时丢失的数据可能会很多
2.2 AOF 重写
随着时间的推移AOF 文件会不断增长为了避免文件过大Redis 提供了 AOF 重写机制。AOF 重写通过创建一个新的 AOF 文件包含相同的数据但体积更小。
AOF 重写是在后台通过创建子进程来完成的不会阻塞主线程。 重写过程如下
创建一个子进程。子进程读取当前的数据库快照并将其写入到新的 AOF 文件中。主线程继续记录新的写操作到重写缓冲区中。重写完成后将重写缓冲区中的写操作追加到新的 AOF 文件中。用新的 AOF 文件替换旧的 AOF 文件。
在Redis执行AOF重写AOF rewrite过程中子进程负责创建新的AOF文件而父进程则继续处理客户端请求并将新请求产生的AOF数据写入到缓冲区随后刷新到原有的AOF文件中。子进程在创建时继承了父进程的内存状态因此其内存数据反映了父进程fork操作之前的状态。对于fork之后父进程接收的新请求及其对内存的修改子进程并不知情。为此父进程额外设置了一个名为aofrewrite_buf的缓冲区专门用于存放fork之后接收的数据。当子进程完成新AOF文件的写入后会通过信号通知父进程父进程随后将aofrewrite_buf缓冲区中的内容追加到新AOF文件中。这一过程完成后新的AOF文件将取代旧的AOF文件确保数据的完整性和一致性。
那么是如何让原本的数据但体积更小
重写机制的妙处在于尽管某个键值对被多条写命令反复修改最终也只需要根据这个「键值对」当前的最新状态然后用一条命令去记录键值对代替之前记录这个键值对的多条命令这样就减少了 AOF 文件中的命令数量。最后在重写工作完成后将新的 AOF 文件覆盖现有的 AOF 文件。 2.3 AOF 的优缺点
优点
数据持久性高AOF 可以记录每个写操作通过适当的同步策略几乎可以实现秒级的数据持久性。可读性好AOF 文件是纯文本文件可以很方便地查看和编辑。适合频繁写操作由于 AOF 是记录每次写操作不会像 RDB 那样生成大文件因此适合频繁写操作的场景。
缺点
文件体积大相比 RDBAOF 文件会更大因为它记录了所有的写操作。恢复速度较慢重放 AOF 文件中的写操作来恢复数据速度比加载 RDB 文件要慢。
2.4 AOF 实践示例
在实际应用中可以通过修改配置文件 开启 AOF 持久化 appendonly yes配置 AOF 同步策略 appendfsync everysec手动触发 AOF 重写 BGREWRITEAOF三、混合持久化
尽管 RDB 比 AOF 的数据恢复速度快但是快照的频率不好把握
如果频率太低两次快照间一旦服务器发生宕机就可能会比较多的数据丢失如果频率太高频繁写入磁盘和创建子进程会带来额外的性能开销。
那有没有什么方法不仅有 RDB 恢复速度快的优点和又有 AOF 丢失数据少的优点呢
当然有那就是将 RDB 和 AOF 合体使用这个方法是在 Redis 4.0 提出的该方法叫混合使用 AOF 日志和内存快照也叫混合持久化。
如果想要开启混合持久化功能可以在 Redis 配置文件将下面这个配置项设置成 yes
aof-use-rdb-preamble yes混合持久化工作在 AOF 日志重写过程。
当开启了混合持久化时在 AOF 重写日志时fork 出来的重写子进程会先将与主线程共享的内存数据以 RDB 方式写入到 AOF 文件然后主线程处理的操作命令会被记录在重写缓冲区里重写缓冲区里的增量命令会以 AOF 方式写入到 AOF 文件写入完成后通知主进程将新的含有 RDB 格式和 AOF 格式的 AOF 文件替换旧的的 AOF 文件。 也就是说使用了混合持久化AOF 文件的前半部分是 RDB 格式的全量数据后半部分是 AOF 格式的增量数据。
