Redis数据持久化机制详解

Redis数据持久化机制详解

Redis是一个基于内存的数据库，所有的数据都存放在内存中。然而，如果Redis突然宕机，数据就会全部丢失。为了解决这个问题，Redis提供了数据持久化机制，以确保数据不会因为故障而丢失。Redis的持久化机制主要有两种：RDB（Redis Database）快照和AOF（Append Only File）日志。

一、持久化简介

持久化是指将数据保存到能够长期存储的存储介质上（如磁盘等），以便在需要时可以重新加载和使用。数据库持久化是指数据存储在数据库中，即使应用程序关闭，数据也不会丢失。持久化是确保数据不会因为系统故障或关闭而丢失的重要机制。它还具有以下作用：

1. 数据恢复：在系统崩溃或故障后，持久化数据可帮助快速恢复操作，减少损失。
2. 数据一致性：确保多个用户或系统访问数据时的一致性，避免数据冲突。
3. 长期存储：支持数据的长期保存，适用于需要历史记录的场景，如审计和合规。
4. 安全性：通过加密和备份，保护敏感数据免受丢失或未授权访问。
5. 数据分析：持久化数据为后续的数据分析和决策提供基础，支持商业智能和数据挖掘。

二、RDB持久化机制

RDB持久化是Redis默认的持久化方式，它会将内存的数据快照写入二进制文件，这个文件称为RDB文件。RDB持久化实现和数据恢复主要依靠两个核心函数：rdbSave和rdbLoad。rdbSave函数将数据快照写入到RDB文件，rdbLoad函数将数据从文件加载到内存。

1. RDB持久化触发机制

RDB持久化触发机制有三种：save、bgsave和自动触发。

• save命令：执行SAVE命令时，Redis服务器会阻塞客户端命令，直到rdbSave函数完成RDB文件的创建。在这个过程中，Redis无法接受新的命令请求，直到文件创建完成后才可以。由于这种方式会阻塞Redis服务器，导致无法处理其他客户端请求，因此在线上环境中一般不推荐使用。

• bgsave命令：BGSAVE命令通过主线程的fork创建一个子进程来执行rdbSave函数，而父进程（Redis服务器主进程）正常处理客户端的请求。这样Redis持久化操作就不会影响到正常的服务提供。BGSAVE命令的执行过程包括：

  1. 通过fork创建子进程，并继承主进程的内存空间（采用写时复制机制，减少内存空间）。
  2. 子进程遍历Redis内存中所有的键值对，并使用rdbSaveObject等函数将每个对象进行二进制序列化写入到RDB文件。
  3. 序列化过程中，Redis会对数据进行压缩，以加快写入文件的速度，并减少文件体积。
  4. RDB文件创建完成后，子进程会向父进程发送信号，通知父进程RDB文件创建完成。

• 自动触发：自动触发是可以在redis.conf配置文件中设置，当满足特定的条件时，会自动触发持久化。触发后，底层调用的其实是bgsave命令。默认触发的条件包括：

  1. 900秒（15分钟）内至少有1个key的值发生变化。
  2. 300秒（5分钟）内至少有10个key的值发生变化。
  3. 60秒（1分钟）内至少有10000个key的值发生变化。

2. RDB持久化配置

RDB持久化的配置主要在Redis的配置文件redis.conf中进行。常见的配置项包括：

• dbfilename：RDB文件的名称，默认为dump.rdb。
• dir：RDB文件的存放路径。
• save m n：设置自动触发RDB持久化的条件。表示在m秒内，如果有n个键发生改变，则自动触发持久化。
• stop-writes-on-bgsave-error：当BGSAVE持久化失败时，是否停止持久化数据到磁盘。yes表示停止持久化，no表示忽略错误继续写文件。
• rdbchecksum：写入文件和读取文件时是否开启RDB文件检查，检查是否有无损坏。如果在启动时检查发现损坏，则停止启动。
• rdbcompression：是否对RDB文件进行压缩。如果开启压缩，Redis会采用LZF算法进行压缩。如果不想消耗CPU性能来进行文件压缩，可以设置为关闭此功能，但缺点是需要更多的磁盘空间来保存文件。

3. RDB持久化的优缺点

优点：

1. 恢复速度快：由于RDB文件是一个紧凑的二进制文件，文件体积小，加载速度快。因此恢复数据的速度比AOF快。
2. 文件体积小：RDB文件在写入前进行了压缩，因此文件体积小，有利于文件传输和备份。
3. 适合灾备恢复：RDB文件体积小，适合文件传输到其他存储介质上，非常适合用于灾备恢复。

缺点：

1. 数据丢失风险：若Redis在两次RDB持久化之间发生故障，则最后一次RDB持久化后的数据就会丢失（数据不一致）。
2. 内存占用：在fork创建的子进程进行RDB持久化过程中，子进程会占用与父进程相同的内存资源，可能会导致Redis性能下降。
3. 版本兼容：RDB文件为一个二进制文件，不同版本的Redis之间可能存在兼容性问题。

三、AOF持久化机制

AOF持久化机制是通过记录Redis服务器所执行的写命令来记录数据库状态。AOF文件以追加的方式记录Redis所执行过的所有修改的命令，将每一条修改命令记录进文件appendonly.aof中（先写入os cache，每隔一段时间fsync到磁盘）。Redis服务重启时会重新执行AOF文件中的命令来实现数据恢复到内存中。

1. AOF持久化实现原理

AOF持久化功能实现主要分为命令追加、文件写入、文件同步、文件重写、重启加载五个部分。

• 命令追加：当AOF持久化开启时，服务器在执行完一个写命令后，Redis不会直接阻塞服务器来等待AOF文件写入完成。Redis采用异步写入策略，会将这个命令以RESP协议格式追加到AOF缓冲区（aof_buf，一个内存中的数据结构）中。

• 文件写入：Redis服务器进程是一个事件循环，在每个事件循环结束前，会使用后台一个线程（或进程）会调用flushAppendOnlyFile函数将AOF缓冲区（aof_buf）中的命令内容写到AOF文件中。这个后台过程不会阻塞Redis主线程处理新的命令。

• 文件同步：AOF文件会根据appendfsync参数设置的持久化策略同步到磁盘。appendfsync参数有三种设置：

  1. appendfsync always：每次有新命令写入到AOF缓冲区时，执行一次fsync将命令追加到AOF文件中，非常慢，也非常安全。
  2. appendfsync everysec：每次写命令写入到aof_buf后，每隔一秒同步到磁盘（默认设置推荐），足够快并且在故障时只会丢失1秒的数据。
  3. appendfsync no：每次写命令写入到aof_buf后，从不fsync，将数据交给操作系统来处理，更快，也更不安全。

• 文件重写：随着服务器运行时间增加，AOF文件会越来越大，这会影响Redis重启时间。因此Redis提供了AOF重写机制，通过创建一个新的AOF文件来替代旧文件，新文件只包含恢复当前数据集所需的最小命令集。重写过程也是异步进行的，并且不会阻塞Redis处理新命令。重写操作由后台子进程进行，不阻塞主进程处理客户端的命令。重写期间，新的写命令会被同时追加到现有AOF文件和重写文件的AOF缓存区（aof_buf）中。重写完成后，主进程会将重写缓存区中的命令追加到新的AOF文件中，并替代旧文件。

• 重启加载：Redis重启后，会加载AOF文件，并重新执行文件中写命令来恢复内存数据。

2. AOF持久化配置

AOF持久化的配置也在Redis的配置文件redis.conf中进行。常见的配置项包括：

• appendonly：是否开启AOF持久化功能，yes表示开启，no表示关闭。
• appendfilename：AOF文件的名称，默认为appendonly.aof。
• appendfsync：设置AOF文件同步到磁盘的策略。
• no-appendfsync-on-rewrite：在AOF重写期间是否禁用fsync。如果设置为yes，则在AOF重写期间不会进行fsync操作，可以提高重写速度，但可能会增加数据丢失的风险。
• auto-aof-rewrite-percentage：触发AOF重写增长的百分比阈值。当AOF文件的大小比上一次AOF重写后的大小大指定的百分比时，将触发AOF重写。
• auto-aof-rewrite-min-size：触发AOF重写所需的最小文件大小。只有当AOF文件的大小大于此值时，才会触发AOF重写。

3. AOF持久化的优缺点

优点：

1. 提供多种持久化策略：可以根据需要选择合理的策略。
2. AOF文件是一个纯文本文件：易于理解、修改和恢复。
3. 对于误操作的数据：可以通过修改AOF文件来恢复。
4. 数据更加安全：即使出现宕机，也只是丢失最近一次AOF文件写入之后的数据。

缺点：

1. **文件

原文地址：https://blog.csdn.net/shiming8879/article/details/143078988

免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！