14天 -- Redis 的持久化机制有哪些？Redis 主从复制的实现原理是什么？ Redis 数据过期后的删除策略是什么？

Redis 的持久化机制有哪些？

Redis 是一种高性能的键值存储系统，主要用于缓存、消息队列等场景。为了防止数据丢失，Redis 提供了多种持久化机制，主要包括以下两种：

1. RDB（Redis Database Backup）

RDB 是一种快照持久化机制，它会在指定的时间间隔内将内存中的数据集快照保存到磁盘上的一个 RDB 文件中（通常是 .rdb 文件）。RDB 文件是一个紧凑的二进制文件，适合用于备份和灾难恢复。

RDB 的优点：

• 数据恢复速度快：由于 RDB 文件是紧凑的二进制格式，恢复数据时速度较快。
• 适合备份和迁移：RDB 文件可以方便地用于备份和迁移，因为它是一个完整的数据快照。
• 对性能影响小：RDB 的持久化操作可以通过 fork 子进程完成，不会阻塞主进程的正常操作。

RDB 的缺点：

• 数据丢失风险：如果 Redis 服务器在两次快照之间发生故障，可能会丢失最后一次快照之后的数据。
• 文件大小可能较大：随着数据量的增加，RDB 文件可能会变得很大，对磁盘空间有一定要求。

配置 RDB：

RDB 的持久化可以通过 Redis 配置文件（redis.conf）进行设置，例如：

save 900 1
save 300 10
save 60 10000

上述配置表示：

• 如果至少有 1 个键发生变化，900 秒后保存一次快照。
• 如果至少有 10 个键发生变化，300 秒后保存一次快照。
• 如果至少有 10000 个键发生变化，60 秒后保存一次快照。

2. AOF（Append Only File）

AOF 是一种日志持久化机制，它会将每个写操作命令追加到一个日志文件（通常是 appendonly.aof 文件）中。当 Redis 重启时，它会重新执行 AOF 文件中的命令来恢复数据。

AOF 的优点：

• 数据安全性高：AOF 会记录每个写操作，因此在发生故障时，数据丢失的可能性极小。
• 可配置性高：可以通过配置文件调整 AOF 的写入策略，例如同步频率（appendfsync 参数）。

AOF 的缺点：

• 文件体积可能较大：AOF 文件会记录所有的写操作，因此文件体积可能会比 RDB 文件大很多。
• 恢复速度较慢：由于需要重新执行 AOF 文件中的命令，恢复数据的速度可能比 RDB 慢。

配置 AOF：

AOF 的持久化也可以通过 Redis 配置文件进行设置，例如：

appendonly yes
appendfsync everysec

上述配置表示：

• 开启 AOF 持久化。
• 每秒将 AOF 日志同步到磁盘一次（everysec）。其他可选值包括：
  • always：每次写操作都同步到磁盘，数据安全性最高，但性能开销较大。
  • no：由操作系统决定何时同步，性能最好，但数据丢失风险较高。

3. 混合持久化（RDB + AOF）

Redis 4.0 以后引入了混合持久化模式，允许同时使用 RDB 和 AOF。在这种模式下，AOF 文件会以 RDB 文件为基础，然后追加后续的写操作。这种方式结合了 RDB 和 AOF 的优点，既能快速恢复数据，又能保证数据的完整性。

配置混合持久化：

appendonly yes
save 900 1

开启 AOF 并设置 RDB 快照保存规则。

总结

• 如果对数据丢失的容忍度较高，可以使用 RDB。
• 如果需要更高的数据安全性，建议使用 AOF 或混合持久化。
• 在实际使用中，可以根据业务需求和性能要求选择合适的持久化策略。

Redis 主从复制的实现原理是什么？

Redis 的主从复制（Master-Slave Replication）是一种常见的高可用性和数据冗余机制，用于将数据从主节点（Master）同步到一个或多个从节点（Slave）。主从复制的实现原理主要涉及以下几个关键步骤和机制：

1. 连接建立与初始化

• 从节点发起连接：从节点（Slave）主动连接到主节点（Master），并发送 REPLCONF listening-port <port> 命令，告知主节点自己的监听端口。
• 主节点接受连接：主节点接受从节点的连接请求，并为从节点分配一个客户端连接。
• 从节点发送复制命令：从节点发送 REPLICAOF <master_ip> <master_port> 命令，正式请求开始复制操作。

2. 全量复制（Full Sync）

全量复制是主从复制的初始阶段，用于将主节点的完整数据同步到从节点。这个阶段主要包括以下步骤：

（1）主节点生成 RDB 文件

• 当从节点请求复制时，主节点会启动一个后台进程（bgsave），生成一个 RDB 文件。这个 RDB 文件包含了主节点当前内存中的所有数据。
• 在生成 RDB 文件的过程中，主节点会继续处理客户端的写请求，并将这些写操作记录到一个缓冲区（称为 复制积压缓冲区，Replication Backlog Buffer）。

（2）发送 RDB 文件

• 一旦 RDB 文件生成完成，主节点会将这个文件发送给从节点。
• 从节点接收到 RDB 文件后，会加载该文件，将其内容加载到内存中，从而恢复主节点的数据快照。

（3）同步缓冲区中的命令

• 在 RDB 文件传输完成后，主节点会将复制积压缓冲区中的所有命令发送给从节点。
• 从节点会依次执行这些命令，以确保其数据与主节点一致。

3. 部分复制（Partial Sync）

部分复制用于处理主从复制过程中可能出现的网络中断等情况。在全量复制完成后，主从节点会进入部分复制阶段，主节点会持续将写操作同步给从节点。

（1）复制积压缓冲区（Replication Backlog Buffer）

• 主节点维护一个固定大小的环形缓冲区，用于存储最近执行的写操作命令。这个缓冲区的大小可以通过 repl-backlog-size 参数配置。
• 当从节点重新连接时，主节点会检查从节点请求的偏移量是否在缓冲区范围内。如果在范围内，则主节点会从缓冲区中恢复丢失的命令并发送给从节点。

（2）偏移量同步

• 主节点和从节点各自维护一个复制偏移量（replication offset），用于记录已经同步的命令数量。
• 从节点在请求部分复制时，会发送自己的偏移量给主节点。主节点根据偏移量判断是否可以进行部分复制。

4. 命令传播（Command Propagation）

在主从复制过程中，主节点会将所有写操作命令实时发送给从节点，从节点会依次执行这些命令以保持与主节点的数据一致性。

• 命令传播的时机：主节点在执行写操作后，会立即将命令发送给从节点。
• 从节点的写入模式：从节点在执行命令时，会以只读模式运行，不会接受外部的写操作。

5. 故障转移（Failover）

在主从复制中，如果主节点发生故障，从节点可以被提升为主节点（通过哨兵 Sentinel 或集群 Cluster 实现）。故障转移的机制包括：

• 从节点选举：从多个从节点中选择一个作为新的主节点。
• 数据同步：新的主节点可能会触发一次全量复制，以确保其他从节点与自己保持一致。

6. 配置与优化

• 主节点配置：在主节点的 redis.conf 文件中，可以通过 slaveof 或 replicaof 指定从节点。
• 从节点配置：从节点需要配置 masterauth（如果主节点有密码）和 repl-ping-slave-period 等参数，以优化复制性能。
• 复制积压缓冲区大小：通过 repl-backlog-size 参数调整缓冲区大小，以平衡内存占用和部分复制的能力。

总结

Redis 主从复制的实现原理包括全量复制、部分复制、命令传播和故障转移等机制。全量复制用于初始数据同步，部分复制用于处理网络中断后的数据恢复，命令传播用于实时保持数据一致性。通过这些机制，Redis 能够实现高效的数据冗余和高可用性。

Redis 数据过期后的删除策略是什么？

Redis 提供了多种数据过期机制，允许用户为键设置生存时间（TTL，Time To Live）。当键的生存时间到期后，Redis 会根据其内部的删除策略来处理这些过期的键。Redis 的删除策略主要分为三种：惰性删除（Lazy Deletion）、定期删除（Periodic Deletion） 和 内存淘汰（Memory Eviction）。以下是它们的具体实现和特点：

---

1. 惰性删除（Lazy Deletion）

惰性删除是指 Redis 不主动检查键是否过期，而是当用户尝试访问某个键时，Redis 才会检查该键是否已经过期。如果键已经过期，Redis 会删除该键并返回一个空值。

工作原理：

• 当用户执行 GET、SET、DEL 等命令时，Redis 会检查目标键是否过期。
• 如果键过期，则直接删除该键，并返回相应的结果（例如 nil 表示键不存在）。
• 如果键未过期，则正常处理用户的请求。

优点：

• 资源消耗低：惰性删除不会主动占用 CPU 资源去检查过期键，因此对性能的影响最小。
• 精确性高：只有当键被访问时，才会检查是否过期，不会误删未被访问的过期键。

缺点：

• 内存占用可能较高：如果大量键过期但未被访问，这些键可能会一直占用内存，直到被访问或 Redis 重启。
• 对业务逻辑有要求：依赖于用户主动访问键，如果某些键从未被访问，可能会导致内存泄漏。

---

2. 定期删除（Periodic Deletion）

定期删除是指 Redis 会定期检查过期键并删除它们。Redis 通过一个后台线程（serverCron）周期性地执行删除操作。

工作原理：

• Redis 设置了一个时间间隔（默认为每秒多次），在每个时间间隔内，后台线程会随机检查部分键的过期情况。
• 如果发现某个键已经过期，后台线程会将其删除。
• 为了防止删除操作占用过多 CPU 资源，Redis 会限制每次删除操作的执行时间。

优点：

• 内存占用可控：定期删除可以主动清理过期键，避免内存被大量过期键占用。
• 对性能影响有限：通过限制每次删除操作的执行时间，避免了对性能的过大影响。

缺点：

• 删除不及时：由于是定期检查，某些过期键可能在检查间隔内仍然占用内存。
• 资源占用：虽然有限制，但定期删除仍然会占用一定的 CPU 资源。

---

3. 内存淘汰（Memory Eviction）

内存淘汰是指当 Redis 的内存使用量达到配置的上限时，Redis 会根据一定的策略主动删除一些键，以释放内存空间。内存淘汰策略主要用于 Redis 作为缓存时的场景。

工作原理：

• 当 Redis 的内存使用量接近或超过配置的 maxmemory 限制时，Redis 会根据配置的淘汰策略选择要删除的键。
• 常见的淘汰策略包括：
  • LRU（Least Recently Used）：删除最久未使用的键。
  • LFU（Least Frequently Used）：删除使用频率最低的键。
  • TTL（Time To Live）：优先删除即将过期的键。
  • Random：随机删除键。
  • AllKeys LRU/LFU：从所有键中选择 LRU/LFU 的键删除。
  • volatile LRU/LFU：仅从设置了过期时间的键中选择 LRU/LFU 的键删除。

优点：

• 防止内存溢出：通过主动删除键，避免内存使用量超过限制，导致 Redis 崩溃。
• 灵活性高：用户可以根据业务需求选择合适的淘汰策略。

缺点：

• 数据丢失风险：某些重要数据可能会被误删，因此需要谨慎配置淘汰策略。
• 对性能影响：淘汰操作可能会占用一定的 CPU 资源，尤其是在内存压力较大时。

---

总结

Redis 的数据过期删除策略包括惰性删除、定期删除和内存淘汰。它们各有优缺点，适用于不同的场景：

• 惰性删除：适合对内存占用不敏感的场景，优点是性能开销小。
• 定期删除：适合需要主动清理过期键的场景，优点是内存占用可控。
• 内存淘汰：主要用于 Redis 作为缓存时，防止内存溢出。

在实际使用中，Redis 默认会同时使用惰性删除和定期删除策略，以平衡性能和内存占用。用户可以根据业务需求调整这些策略，例如通过配置 maxmemory 和淘汰策略来优化 Redis 的行为。