一、Redis 持久化

1. RDB 快照（Snapshot）

   • 基本概念：RDB（Redis DataBase）快照是将 Redis 内存中的数据在某个时间点保存到磁盘中的一种持久化方式，默认保存到 dump.rdb 的二进制文件中。通过 RDB 快照，可以在服务器故障时恢复到某个时间点的数据状态。它在满足指定条件时自动保存，也可以手动执行 save 或 bgsave 命令生成快照。
   • 自动保存：Redis 可以配置在特定条件下自动生成 RDB 快照。例如，配置 save 60 1000，表示在 60 秒内有 1000 个键发生变化时，自动保存一次数据集。可以通过注释所有 save 配置来关闭自动保存功能。
   • 手动保存：使用 save 命令会阻塞 Redis 服务器，直到快照完成；而 bgsave 命令则在后台执行快照，使用写时复制（COW）机制，允许在生成快照时正常处理写命令。bgsave 子进程由主线程 fork 生成，开始读取主线程的内存数据并写入 RDB 文件。若主线程修改数据，该数据会被复制一份给 bgsave 子进程，避免主线程阻塞。

2. AOF（Append-Only File）

   • 基本概念：AOF（Append-Only File）将修改的每一条指令记录进文件appendonly.aof中(先写入os cache，每隔一段时间 fsync到磁盘)，以实现持久化。AOF 提供了比 RDB 更高的数据安全性，确保在 Redis 意外停机时，丢失的数据量最小。通过配置文件可以开启 AOF 功能，并设置数据同步（fsync）策略。
   • AOF 配置：可以通过修改配置文件打开 AOF 功能，设置 appendonly yes。AOF 支持三种 fsync 策略：always 表示每次有新命令追加时都进行 fsync，非常慢但非常安全；everysec 表示每秒 fsync 一次，兼顾速度和数据安全；no 表示不执行 fsync，由操作系统决定何时将数据写入磁盘，速度最快但最不安全。
   • AOF 重写：AOF 文件可能会随着时间推移变得很大，Redis 支持 AOF 重写机制，通过 bgrewriteaof 命令重写 AOF 文件，仅保留最新的数据状态。重写过程中，Redis 会 fork 一个子进程来创建新的 AOF 文件，不影响正常命令处理。可以通过配置 auto-aof-rewrite-min-size 和 auto-aof-rewrite-percentage 控制 AOF 文件的重写频率。

3. RDB 和 AOF 的对比

   • 启动优先级：Redis 启动时，如果既存在 RDB 文件又存在 AOF 文件，则优先使用 AOF 文件恢复数据，因为 AOF 文件通常记录的数据更完整。
   • 文件体积：RDB 文件是数据的二进制快照，通常较小；而 AOF 文件记录每个写命令，文件体积较大。
   • 恢复速度：RDB 文件直接加载到内存，恢复速度较快；AOF 文件需要重放日志，恢复速度较慢。
   • 数据安全性：RDB 可能会丢失最近一次快照后的数据，数据安全性较低；AOF 根据 fsync 策略，可以提供更高的数据安全性。

4. 混合持久化

   • Redis 4.0 引入混合持久化：为了解决 RDB 恢复丢失数据和 AOF 恢复慢的问题，Redis 4.0 引入了混合持久化，将 RDB 快照与增量的 AOF 日志结合。重写 AOF 时，会将 RDB 快照和新的 AOF 命令一起写入新的 AOF 文件。这样在 Redis 重启时，先加载 RDB 快照，然后重放增量 AOF 日志，极大提高了恢复效率。可以通过 aof-use-rdb-preamble yes 配置开启混合持久化。

二、Redis 主从架构

1. 主从架构搭建

   • 复制配置文件：搭建主从架构时，首先需要复制主节点的 redis.conf 文件，并修改相关配置。修改的内容包括端口号、数据存放目录等，以区分不同的实例。可以通过设置 port 指定新的端口号，dir 设置数据存放目录，确保每个实例的数据和日志文件不会混淆。
   • 配置主从关系：在从节点的配置文件中，添加 replicaof 主节点IP 主节点端口 配置，使从节点能够从主节点同步数据。可以通过 replica-read-only yes 配置设置从节点为只读模式，避免从节点上的数据被意外修改。
   • 启动从节点：使用 redis-server 启动从节点实例，并通过 redis-cli -p 从节点端口 连接从节点，验证从节点是否能够正确同步主节点的数据。在主节点上执行写操作，观察从节点是否能够及时同步数据变化。

2. 主从复制原理

   • 全量复制：当从节点首次连接主节点或主从断开后重新连接时，从节点会发送 PSYNC 命令请求全量复制。主节点接收到命令后，会在后台生成 RDB 快照，通过 bgsave 命令生成最新的快照文件，并将其发送给从节点。从节点接收到 RDB 文件后，持久化生成 RDB 文件并加载到内存中。主节点在生成快照期间继续接收写命令，并将这些命令缓存在内存中，待快照发送完毕后，再将缓存在内存中的命令发送给从节点。
   • 部分复制：从 Redis 2.8 版本开始，支持部分复制（断点续传）。主节点在内存中维护一个复制数据的缓存队列，记录最近一段时间的数据变化。主从节点通过维护一个复制偏移量和主节点的运行 ID 来实现断点续传。如果从节点重新连接时，主节点的运行 ID 未变且偏移量在缓存范围内，则进行部分复制；否则，将进行全量复制。部分复制减少了数据传输量和网络压力，提升了复制效率。

主从复制(全量复制)流程图

主从复制(部分复制，断点续传)流程图

三、Redis 哨兵架构

        sentinel哨兵是特殊的redis服务，不提供读写服务，主要用来监控redis实例节点。 哨兵架构下client端第一次从哨兵找出redis的主节点，后续就直接访问redis的主节点，不会每次都通过 sentinel代理访问redis的主节点，当redis的主节点发生变化，哨兵会第一时间感知到，并且将新的redis 主节点通知给client端(这里面redis的client端一般都实现了订阅功能，订阅sentinel发布的节点变动消息)

1. 哨兵架构搭建

   • 复制并修改配置文件：搭建哨兵架构时，首先需要复制 sentinel.conf 文件，并修改相关配置。修改的内容包括哨兵的端口号、日志文件、监控的主节点等。可以通过设置 port 指定哨兵的端口号，logfile 设置日志文件，sentinel monitor 配置监控的主节点信息及故障判定的 quorum 数量。
   • 启动哨兵：使用 redis-sentinel 命令启动哨兵实例，并通过 redis-cli -p 哨兵端口 连接哨兵，查看哨兵的 info 信息，确认哨兵已正确识别并监控主从节点。
   • 哨兵集群元数据：哨兵集群启动后，会自动发现并记录 Redis 集群的元数据信息，如主从节点的 IP 和端口。哨兵之间会通过发布订阅机制交换这些信息，并在主节点发生故障时，协同进行故障转移。哨兵的配置文件中会自动追加记录这些元数据信息。

2. 哨兵原理

   • 监控与通知：哨兵通过定期发送 PING 命令检测 Redis 实例的运行状态，当主节点未能在指定时间内响应时，哨兵会将其标记为失效，并在达到 quorum 数量的哨兵判定失效后，开始故障转移过程。故障转移完成后，哨兵会通过发布订阅机制通知客户端新的主节点信息。
   • 故障转移：当主节点被判定失效时，哨兵集群会进行选举，选出一个哨兵来负责故障转移过程。选出的哨兵会将其中一个从节点提升为新的主节点，并通知其他从节点重新复制新的主节点数据。故障转移完成后，哨兵会更新集群的配置信息，并将新的主节点信息写入所有哨兵的配置文件中。原主节点重新上线后，将被配置为新的从节点。

四、Redis 管道与 Lua 脚本

1. 管道（Pipeline）
   • 基本概念：Redis 管道（Pipeline）允许客户端一次性发送多个请求，而不需要

等待每个请求的响应。这种方式可以显著减少客户端与服务器之间的网络往返时间，提升执行效率。管道中的命令会在服务器端按照顺序执行，结果也会按顺序返回给客户端。

• 使用场景：管道特别适用于需要执行大量命令且对执行顺序有严格要求的场景。例如批量插入数据、批量获取数据等。通过管道，可以将多条命令打包发送，大幅降低网络传输开销。需要注意的是，管道中的每个命令都是独立执行的，不保证所有命令一起成功，即使前面的命令失败，后面的命令仍然会继续执行。
• 注意事项：虽然管道可以提高执行效率，但也需要注意命令的打包数量。打包的命令过多，服务器需要缓存的命令结果也会增加，可能导致内存消耗过大。因此，打包命令的数量需要根据具体场景合理设置。

1. Lua 脚本
   • 基本概念：Redis 从 2.6 版本开始支持 Lua 脚本，通过内置的 Lua 解释器，允许开发者使用 Lua 语言编写脚本并在 Redis 服务器中执行。使用 Lua 脚本可以将多个命令合并为一个脚本执行，从而减少网络开销，并提供原子操作的特性。
   • 使用方式：可以使用 EVAL 命令执行 Lua 脚本，格式为 EVAL script numkeys key [key ...] arg [arg ...]。script 是 Lua 脚本内容，numkeys 是脚本中用到的键名参数数量，key 和 arg 分别是键名参数和附加参数。在 Lua 脚本中，可以通过全局变量 KEYS 和 ARGV 访问这些参数，通过 redis.call() 函数调用 Redis 命令。
   • 优势：使用 Lua 脚本可以减少客户端与服务器之间的网络往返次数，提高执行效率。脚本在 Redis 中执行时是原子的，不会被其他命令插入。相比 Redis 的事务功能，Lua 脚本更为灵活和高效，被官方推荐为实现事务功能的替代方案。需要注意的是，不要在脚本中出现死循环或耗时运算，否则会阻塞 Redis，导致无法处理其他命令。

五、Redis 高可用与扩展

1. 高可用架构

   • 主从复制：Redis 主从复制通过将数据从主节点复制到一个或多个从节点，实现数据冗余和读写分离。主从复制可以提高系统的可用性，当主节点发生故障时，从节点可以提升为新的主节点，继续提供服务。同时，读写分离可以减轻主节点的读请求压力，从节点可以处理读请求，提高系统的并发能力。
   • 哨兵模式：Redis 哨兵模式通过监控 Redis 实例的运行状态，自动进行故障转移，确保系统的高可用性。哨兵集群负责监控主节点和从节点的状态，在主节点发生故障时，自动选举新的主节点，并通知客户端更新连接信息。哨兵模式的自动故障转移机制，使 Redis 集群在面对节点故障时能够快速恢复，提高系统的稳定性。

2. 扩展性

   • 分片（Sharding）：分片是将数据分散存储在多个 Redis 实例上的一种方式，可以支持大规模数据和高并发访问。通过分片，可以将大数据集拆分成多个小块，每个块存储在不同的 Redis 实例上，分散读写压力。客户端在访问数据时，根据数据的键计算出对应的分片，从而定位到具体的 Redis 实例。分片机制使 Redis 能够处理大规模数据和高并发请求，是实现水平扩展的基础。
   • 集群模式：Redis Cluster 提供自动分片和高可用的解决方案，适用于大规模分布式系统。Redis Cluster 将数据分布在多个节点上，每个节点负责一定范围的数据槽（slot），通过自动分片实现数据的水平扩展。同时，Redis Cluster 具备内置的高可用机制，支持主从复制和故障转移，当节点发生故障时，自动选举新的主节点，保证系统的高可用性。Redis Cluster 的自动分片和高可用机制，使其能够应对大规模数据和高并发访问，是构建分布式系统的理想选择。

通过以上内容的详细总结，我们对 Redis 的持久化、主从架构、哨兵架构、管道与 Lua 脚本、高可用与扩展性有了更全面的理解。