跳到主要内容

认识

2025年02月22日
柏拉文
越努力，越幸运

一、认识​

一、认识​

Redis 单机 会出现 1. 单点故障（SPOF）, 一旦出现硬件故障、软件 Bug 或其他意外问题，整个服务将中断，可能导致业务不可用, 没有备份机制时，故障恢复周期长，容易造成数据丢失或长时间的服务中断; 2. 内存容量限制, Redis 是以内存为主的数据存储，单机内存容量决定了其能够存储的数据量。当数据量超出单机内存时，就需要考虑横向扩展; 3. 扩展性和性能瓶颈, 单机的 CPU、内存、网络等资源有限，难以应对大规模高并发的请求, 虽然 Redis 内部通过 I/O 多路复用实现高效运行，但其大部分操作依然依赖单线程处理，无法充分利用多核 CPU; 4. 灾难恢复能力不足, 单机部署下数据备份和恢复依赖有限的手段，若发生系统故障或数据损坏，恢复较为复杂且风险较高。

Redis 主从复制 机制是 Redis 高可用性与扩展性的重要基础，它允许一个 Redis 实例（主节点）将数据复制到一个或多个从节点上，从而实现数据的冗余备份和负载分摊。Redis 主从复制机制通过全量同步和增量复制相结合，确保数据在多个节点之间的快速分发和冗余备份。（主从复制, 不会将主节点和从节点部署到一台服务器上, 这样做没有任何价值）Redis 主从复制、读写分离, 1. 可以将读操作分摊到多个从节点上，降低主节点压力, 主节点专注于处理写操作，而从节点可以承载大量的读请求，从而分摊主节点压力，提高系统整体吞吐量和响应速度; 2. 多节点备份提高了系统的容错能力, 即使主节点出现故障, 从节点也可以接管, 确保业务持续运行（通常配合 Sentinel 或 Cluster 机制实现自动故障转移）; 3. 容易横向扩展，从节点可以根据业务需要灵活增加, 根据业务增长需求，可以通过增加从节点来扩展读操作的能力，不需要对单个实例进行大规模升级，从而实现系统的平滑扩展; 4. 数据在主从节点之间进行实时同步，从节点保存了一份冗余数据，降低了数据丢失的风险，同时在主节点故障后可以快速恢复数据。但是, Redis 主从复制、读写分离 由于复制是异步的，存在短暂的数据不一致性风险，即所谓的 最终一致性; 在高并发写入时，从节点可能会出现延迟，导致读取的数据与主节点数据不完全同步;

Redis 主从复制结构: 主节点（Master）, 负责处理写操作，接收客户端的更新请求; 从节点（Slave）, 复制主节点的数据，主要用于读取操作、数据备份或者作为故障转移的候选节点, 一个 Master 主节点可以有多个 Slave 从节点, 一个 Slave 从节点只能有一个 Master 主节点; 数据冗余与备份, 通过将数据复制到多个节点，即使主节点发生故障，从节点也能迅速接管，保障数据的高可用性。

Redis 主从复制流程:

  1. 当一个从节点连接到主节点时，会向主节点发送 SYNC 命令。主节点接收到同步请求后，会进行以下两步: 1. 全量同步, 主节点会生成一个数据快照（RDB 文件），将当前完整数据发送给从节点，从节点接收后载入数据; 2. 增量复制, 全量同步后，主节点会将之后发生的写操作记录到复制缓冲区，并实时推送给从节点，确保数据的持续同步。全量复制开销: 1. 主节点 bgsave 异步生成快照的时间, fork 操作, 生成一个子进程, 对 CPU、硬盘、内存都会有一定开销; 2. 主节点 RDB 文件网络传输时间; 3. 从节点清空数据时间, 如果数据量大的话, 需要消耗一定时间; 4. 从节点加载 RDB 的时间; 5. 如果开启了 AOF, 会做一次 AOF 重写, 保证 AOF 是最新状态。

  2. 当从节点与主节点之间的连接中断后，重新连接时，如果主节点的复制缓冲区中仍保留了断开期间的增量数据，从节点就可以执行部分重同步，避免全量同步带来的数据传输开销。但是, 如果复制缓冲区不足时, 还是会进行全量复制。这时, 我们可以增大复制缓冲区 rel_backlog_size。另外, 网络中断的情况下, 也会使部分复制无法进行, 后续会进行全量复制。

  3. Redis 默认使用异步复制，即主节点在发送数据后不会等待从节点的确认，这样能保证高性能，但也可能导致在主节点崩溃时，从节点丢失最近一部分数据。

Redis 主从复制故障转移: 在单机部署中，主节点故障会导致服务中断，而主从复制能通过复制数据提供冗余，但如果主节点宕机而没有及时切换，从节点无法主动承担写操作，业务仍会中断。故障转移确保当主节点发生故障后，系统能迅速恢复写操作，保证业务连续性，减少停机时间。当主节点发生故障时，能够自动（或半自动）将其中一个从节点提升为新的主节点，确保服务持续可用。这一过程涉及监控、检测故障、选举新主以及客户端重定向等多个环节。故障转移的实现机制:

  • Redis Sentinel 哨兵: Redis Sentinel 是 Redis 官方提供的高可用解决方案。它会定期监控主节点和从节点的运行状态，一旦检测到主节点不可用，就会发起故障转移流程。Sentinel 集群中的多个 Sentinel 实例会协同工作，通过投票选举出最合适的从节点作为新的主节点。选举过程会考虑从节点的响应速度、数据复制延迟等指标。选举完成后，Sentinel 会通知客户端和其他 Redis 节点，更新配置使客户端指向新的主节点，从而实现无缝切换。Redis Sentinel 故障检测和选举需要一定时间，期间可能会出现短暂的不可写状态。优化监控参数和选举策略可以在一定程度上缩短延迟。由于 Redis 复制是异步的，故障转移过程中可能存在部分数据丢失的问题，需要根据业务场景决定是否接受这种 最终一致性 的方案。

  • Redis Cluster 集群: Redis Cluster 是另一种高可用解决方案，它将数据分片存储在多个节点上，并内置自动故障转移机制。当集群中的主节点失败时，集群内其他从节点会通过协商自动晋升为主节点，并重新平衡集群状态。除了实现故障转移，Redis Cluster 同时支持数据分片，能够更好地应对大规模数据和高并发场景。Redis Cluster 故障检测和协商、晋升需要一定时间，期间可能会出现短暂的不可写状态。优化监控参数和协商、晋升策略可以在一定程度上缩短延迟。由于 Redis 复制是异步的，故障转移过程中可能存在部分数据丢失的问题，需要根据业务场景决定是否接受这种 最终一致性 的方案。

Redis 主从复制常见问题

  1. 配置不一致: 1. maxmemory 不一致, 导致丢失数据， 比如说主节点 maxmemory = 1G, 从节点 maxmemory = 500M, 进行全量复制时, 从节点触发驱逐策略（如 LRU、LFU 或 FIFO）来删除部分数据，确保从节点 Redis 不会超出内存限制, 从而导致数据丢失; 2. hash-max-ziplist-entries 数据结构优化参数配置不一致, 导致主从节点内存不一致

  2. 主从数据不一致: Redis 的主从复制机制通过全量同步和增量复制实现数据备份和读写分离，其异步复制模型为高性能提供了基础，但也不可避免地引入了数据不一致的问题。这种不一致主要来源于复制延迟、网络问题和故障转移过程中的数据缺失。原因和解决方案如下:

    • 原因:

      • 异步复制的特性: 1. 写入确认机制, 主节点在执行写操作后立即返回客户端成功，而将命令发送给从节点是异步进行的。如果主节点在命令尚未传输或尚未被从节点执行时出现故障，那么部分写操作可能只存在于主节点，或在主节点崩溃前未能完全同步到所有从节点; 2. 复制延迟（Replication Lag）, 在高并发或网络状况不佳时，从节点会滞后于主节点，导致数据暂时不一致，这种不一致被称为最终一致性问题。

      • 网络和系统因素: 1. 网络延迟与抖动, 网络的不稳定会加剧命令在主从之间传输的延迟，导致从节点数据与主节点存在时延差。2. 硬件性能差异, 从节点的硬件性能若不及主节点，处理命令的速度较慢，也会造成数据更新不及时。

      • 故障转移和选举问题: 1. 故障转移时的数据丢失, 在主节点故障转移过程中，从节点可能还没有完全接收到主节点的最新数据，当某个从节点被提升为新主节点时，可能会丢失那部分未同步的写入; 2. 部分重同步失败, 如果复制缓冲区保存的增量数据不足以完成从节点与主节点的对齐，系统将退化为全量同步，期间也可能产生数据短暂不一致。

      • 写操作与持久化策略: AOF 与 RDB 的影响, 如果使用 AOF 作为持久化方式，在 fsync 操作过程中也可能因为磁盘延迟而引起短暂的阻塞，从而在同步数据到从节点时产生差异。

    • 策略:

      1. 选择合适的同步模式, 在需要更高数据一致性的场景下，可以采用 同步复制 机制，但这会牺牲部分性能。部分第三方方案（如部分商业版 Redis）提供了同步复制的支持。

      2. 优化网络和硬件, 使用稳定高速的网络连接和高性能存储设备，降低复制延迟，从而缩小主从数据的时差。

      3. 监控和预警, 借助 Redis 内置的 INFO replication、LATENCY、SLOWLOG 等命令，实时监控主从复制状态和延迟，及时发现数据不同步的风险。

      4. 合理的故障转移机制, 部署 Redis Sentinel 或 Redis Cluster 等高可用方案，确保在主节点故障时能够选举出数据最接近最新的从节点作为新主节点，降低数据丢失风险。

二、配置​

2.1 主节点配置​

主节点（Master） 通常无需额外配置，但可以调整复制缓冲区参数，并启用安全设置。例如:

  1. 复制缓冲区大小: 通过配置 repl-backlog-size 来设置复制缓冲区大小，用于部分重同步。

  2. 复制缓冲区过期时间: 参数 repl-backlog-ttl 用于设置缓冲区的生存时间。

2.2 从节点配置​

从节点（Slave/Replica） 主要在 redis.conf 中设置 replicaof <master-ip> <master-port>（或 slaveof）、配置 masterauth（如果主节点要求认证）以及其他复制相关选项。调整如下:

  1. 指定主节点: 对于 Redis 5.0 及以上版本，推荐使用 replicalf。对于老版本 Redis，也可以使用 slaveof。

    replicaof <master-ip> <master-port>

    replicaof 192.168.1.100 6379

    对于老版本 Redis，也可以使用 slaveof。

  2. 主节点认证: 如果主节点配置了密码保护，则需要在从节点配置文件中添加:

    masterauth yourpassword

  3. 复制相关配置:

    • replica-read-only: 默认从节点只读

    • replica-serve-stale-data: 默认开启, 保持数据新鲜, 以让从节点在与主节点断开时继续服务已存在的数据。

2.3 检测复制状态​

使用 info replication 命令查看复制状态:

  1. 在主节点上，会显示当前连接的从节点信息。

  2. 在从节点上，会显示与主节点的连接状态、同步进度等信息。