向爬虫而生---Redis 拓宽篇4 ＜redis持久化 --- RDB章＞

前言:

继续上一章:向爬虫而生---Redis 拓宽篇3 ＜GEO模块＞-CSDN博客

这章讲 RDB持久化(快照)

当涉及到Redis的持久化时，有两种主要的实现方法：

快照（Snapshot）和写日志（Write-ahead logs）。

持久化是一种将数据保存在磁盘上，以便在Redis重启后仍然可用的机制。Redis默认将数据保存在内存中，但也提供了持久化来避免数据在内存中丢失。

持久化比较重要,在优化集群数据的时候能派上用场,小规模的数据,可能大家没什么感觉; 但我觉得有必要提一下!!! 以便后期,知道怎么更好优化自己程序.  

正文:

概念:

快照快照（Snapshot）是指将Redis内存中的数据以某种格式（如RDB文件）保存到磁盘上的过程。快照可以在Redis服务器重启、数据备份、数据迁移等场景下使用，以便在需要时能够恢复数据。

快照持久化的过程：

1. 创建快照：Redis通过fork()系统调用创建一个子进程，然后该子进程负责将当前内存中的数据库数据写入到临时文件中。
2. 写入临时文件：子进程将内存中的数据按照一定的格式写入临时文件。在此过程中，Redis服务器使用子进程的Copy-on-Write（写时复制）技术，确保父子进程之间的数据共享没有冲突。
3. 替换原始文件：一旦子进程完成写入临时文件的操作，它将临时文件重命名为持久化文件，通常是RDB文件。然后，Redis会将新的持久化文件替换原始的RDB文件，以实现数据的持久化。

快照持久化在Redis中的优点：

1. 快速恢复：快照持久化使得Redis能够在重启时迅速加载RDB文件并还原数据，减少了服务停机时间。
2. 数据压缩：RDB文件是二进制格式，可以通过压缩机制减小文件的大小，节省磁盘存储空间。
3. 数据备份和迁移：通过保存RDB文件，可以将Redis的数据进行备份，并在需要时将数据迁移到其他环境中。

快照可通过使用SAVE指令同步执行，或者使用BGSAVE指令进行异步执行。

• SAVE指令是同步的，它会阻塞Redis服务器，直到快照过程完成。
• 而BGSAVE指令是异步的，它会通过创建一个子进程（fork()）来执行快照，允许Redis服务器在后台继续处理其他命令。

   -------上面两个点,记清楚!!!! 一个是同步,一个是异步!!!

---

RDB的定义和配置方法:

RDB指的是Redis数据库的快照文件，它是Redis使用快照持久化机制生成的文件。这个文件保存了Redis的数据状态，包括键值对以及它们的相关元数据。RDB文件的默认名称是dump.rdb，可以通过配置文件中的dbfilename选项进行修改。

修改配置文件:

1. 打开Redis的配置文件（通常位于/etc/redis/redis.conf）。
2. 在文件中找到# dbfilename dump.rdb这一行。注意，前面有一个#符号，表示该行是注释，并且配置项是被禁用的。
3. 移除前面的#符号，取消注释。
4. 将dbfilename后面的值修改为你想要的名称，例如：dbfilename mydata.rdb。
5. 保存并关闭文件。
6. 重新启动Redis服务器使其加载新的配置文件。

ps:在修改配置文件后，需要重新启动Redis服务器才能使新的配置生效!!

---

save和bgsave 的优缺点

触发RDB持久化的方式包括SAVE指令和BGSAVE指令，具体如下：

  1.SAVE指令是同步方式触发RDB持久化。它会让Redis服务器创建一个RDB文件，并将数据写入其中，期间会阻塞Redis服务器的主线程，直至持久化完成。如果已经存在RDB文件，SAVE指令将会替换它。

redis-cli
> SAVE

  2.BGSAVE指令是异步方式触发RDB持久化。它会创建一个子进程，在新的Redis实例中执行RDB持久化过程。这种方式不会阻塞Redis服务器的主线程，允许服务器继续处理其他命令。

redis-cli
> BGSAVE

SAVE和BGSAVE有各自的优缺点。SAVE的优点是简单直观，可直接通过执行指令进行持久化。然而，它的缺点是会造成阻塞，因为持久化的过程会导致主线程无法处理其他命令。而BGSAVE虽然不会阻塞Redis服务器，但会通过创建子进程增加系统负担。

---

关于持久化的配置选项

如何修改配置,对应是是.conf文件,这里用代码的样子展示,大家可能更直观:

config_file = '/path/to/redis.conf'  # Redis配置文件的路径

# 打开配置文件并读取内容
with open(config_file, 'r') as f:
    lines = f.readlines()

# 修改配置文件中的选项
for i in range(len(lines)):
    line = lines[i].strip()
    
    if line.startswith('save'):
        # 修改自动触发快照持久化的条件
        lines[i] = 'save 900 1\n'
    elif line.startswith('dir'):
        # 修改持久化文件的保存目录
        lines[i] = 'dir /path/to/save\n'
    elif line.startswith('dbfilename'):
        # 修改快照文件的名称
        lines[i] = 'dbfilename mydata.rdb\n'
    elif line.startswith('rdbcompression'):
        # 开启RDB文件的压缩
        lines[i] = 'rdbcompression yes\n'
    elif line.startswith('appendonly'):
        # 启用AOF持久化
        lines[i] = 'appendonly yes\n'
    elif line.startswith('appendfilename'):
        # 修改AOF文件的名称
        lines[i] = 'appendfilename mydata.aof\n'

# 将修改后的配置写回文件
with open(config_file, 'w') as f:
    f.writelines(lines)

# 重启Redis服务器使配置生效
# 请根据实际情况使用Redis服务器的重启方法，例如通过命令行或启动脚本进行重启

---

redis自动持久化

当针对持久化进行配置时，Redis提供了一种自动触发RDB持久化的方式。这意味着在特定条件下，Redis会自动执行RDB持久化操作，而无需手动触发。以下是这些自动触发RDB持久化的条件的详细说明：

1. 全量复制（Full Resynchronization）：当Redis作为主节点与一个或多个从节点建立全量复制关系时，主节点会自动执行一次RDB持久化操作，并将RDB文件传输给从节点，以便从节点能够初始化自己的数据集。这是因为在建立复制关系时，使用RDB文件可以更有效地将初始数据传输给从节点。

2. 调试重载（Debug Reload）：在某些情况下，开发人员可能需要在调试模式下重新加载Redis服务器。当Redis服务器在调试重载时，它会自动执行RDB持久化，以确保加载后的数据与重启前的数据保持一致。

3. 关闭服务器（Shutdown）：当Redis服务器接收到关闭指令时，它会自动执行RDB持久化，将数据保存到磁盘上。这样，在下次启动Redis服务器时，可以通过加载RDB文件来恢复数据，以避免数据丢失。

在这些情况下，自动触发RDB持久化可以帮助确保数据的一致性和完整性。通过自动执行RDB持久化，Redis能够将数据保存到磁盘上，以便在重启、复制或调试重载等操作后能够恢复数据。

ps:这些自动触发RDB持久化的条件是内置的，无需额外的配置。当满足这些条件时，Redis服务器会自动执行RDB持久化操作。

配置的 自动保存

在Redis配置文件中，通过设置save选项的条件，指定了在特定时间间隔或写操作数量达到一定阈值时自动执行RDB持久化。这意味着无需手动触发RDB持久化，Redis会在满足指定条件时自动执行。

save 900 1
save 300 10
save 60 10000

1. 自动触发条件：配置指定了三个自动触发条件：900秒内至少有1次写操作、300秒内至少有10次写操作、60秒内至少有10000次写操作。
2. 一致性和完整性：通过自动触发RDB持久化，Redis可以定期将数据保存到磁盘上的RDB文件中，从而确保数据的一致性和完整性。在Redis执行重启、复制或调试重载等操作后，可以从RDB文件中恢复数据。
3. 内置条件：这些自动触发RDB持久化的条件是内置的，并无需额外的配置。只需将条件添加到Redis配置文件中，Redis服务器会在满足指定条件时自动执行RDB持久化操作。

好处:

Redis会在特定条件下自动保存数据，减少手动干预的需要，并确保数据的一致性。此机制可提供方便性和保护数据的重要性。

坏处:

1. 数据丢失风险： 由于自动触发RDB持久化是基于时间间隔或写操作数量的条件来进行的，这意味着在持久化发生之前，如果Redis服务器遇到故障或非正常关闭，可能会导致数据丢失。因为自动触发可能不会实时保存所有最新的修改。
2. 持久化延迟：自动触发RDB持久化是基于条件触发的，而不是实时进行的。如果在持久化触发之前发生故障，可能会丢失最新的修改。另外，当触发条件较高时，持久化操作可能会延迟服务器的响应，特别是在大型数据集上。
3. 不灵活的触发条件：使用自动触发RDB持久化时，只能通过设定时间间隔或写操作数量来触发持久化操作。这可能无法满足特定业务需求，例如需要基于其他类型条件触发持久化的情况。
4. 持久化文件大小较大：当自动触发RDB持久化执行时，会生成一个完整的RDB快照文件。对于大型数据集，这可能导致生成的RDB文件非常大，增加了磁盘存储的需求和持久化操作的时间。
5. 持久化对服务器性能的影响：自动触发RDB持久化可能会对Redis服务器的性能产生一定影响，特别是在持久化过程中，当生成RDB文件、写入磁盘等I/O操作执行时，可能会导致短暂的性能下降。

---

明明有了自动持久化,为什么还要手动持久化?

虽然Redis已经提供了自动触发RDB持久化的方式，但手动配置持久化仍然具有一些优点和灵活性，这取决于使用场景和需求。

下面是一些手动配置持久化的原因：

1. 控制持久化频率：自动触发的RDB持久化方法可能不符合特定的数据保存要求。通过手动配置持久化，可以更精确地控制持久化的频率和时机，以满足特定的业务需求。

2. 备份和恢复：手动配置持久化使得用户可以根据需要执行数据备份，并在需要时恢复数据。这对于处理故障恢复、数据迁移或快速回滚等任务非常关键。

3. 数据迁移和复制：手动配置持久化使得可以将持久化文件（如RDB文件）用于数据迁移、复制或分发到其他Redis实例或集群。这样可以更方便地管理和共享数据。

4. 高级持久化机制：除了RDB持久化，Redis还提供了AOF持久化。手动配置持久化可以让用户选择使用什么持久化方式，并按需配置相关选项，以满足更高级的数据持久化需求。

5. 多重备份：通过手动配置持久化，可以在多个位置保存多个备份文件，以提高数据的安全性和容灾性。这对于需要更高级别的数据保护和备份策略的环境非常重要。

尽管Redis的自动持久化机制具有可靠性和简便性，手动配置持久化可以提供更加灵活和精确的控制，以满足特定需求。因此，在某些场景下，手动配置持久化仍然是一个有用的选项。

需要根据具体的业务需求和数据安全性的要求来选择是否进行手动配置持久化。

总结:

  文章的最后,需要明白几个概念

        1.快照概念

        2.RDB是个啥

        3.如何配置RDB

        4.自动保存 在哪里设置,怎么设置

        ... 其他的,看一看 图一乐就好...

因为RDB模式下,容易耗时/耗性能;且容易丢失数据!!!