Redis三种集群模式：主从模式、哨兵模式和Cluster模式

1、背景及介绍

Redis 支持三种不同的集群模式：主从模式、哨兵模式和Cluster模式，各具特色，应对不同的应用场景。

初始阶段，Redis 采用主从模式进行集群构建。在此模式中，主节点（master）负责数据写入，而从节点（slave）则用于数据读取和备份。若主节点发生故障，需人工介入，将某个从节点提升为新的主节点。但这种模式在故障恢复上效率较低，无法实现高度自动化。

为了提升系统的高可用性，Redis 推出了哨兵模式。在此模式下，通过一个哨兵集群来监控主从节点的健康状态。一旦主节点故障被侦测到，系统会自动选举出一个从节点，晋升为新的主节点，从而实现故障恢复的自动化，提高系统的稳定性和可靠性。

然而，哨兵模式仍然存在一定的局限性，例如内存容量和写入性能都受限于单个节点。为了克服这些限制，Redis 在 3.x 版本后推出了Cluster模式。这一模式通过数据分片（sharding）和多节点水平扩展，有效提高了内存利用率和写入性能，适用于更大规模和更高要求的数据处理场景。总体来说，Cluster模式为Redis集群的性能和扩展性提供了重要的支撑。

2、 Redis 主从复制

2.1、主从复制特点

Redis的主从复制架构通过定义主库（master）和从库（slave）的角色，实现了数据的高效同步和备份，具备以下几个显著特点：

• 主库的读写能力：主库（master）是数据操作的中心。它处理所有的写请求，并且也能处理读请求。任何在主库上执行的数据修改操作，都会实时且自动地同步到所有从库（slave）。
• 单向数据流：数据同步流程是单向的，即数据仅从主库流向从库。这种单向流动保证了数据同步的一致性和可靠性。
• 从库的只读特性：从库通常被配置为只读模式，用于接收并存储从主库传来的数据。这种设计主要用于分担读取负载，从而提升整个系统的读取性能。
• 主从关系的配置：一个主库可以对应多个从库，形成一对多的关系，有利于数据冗余备份和读取负载的分散。反之，一个从库仅对应一个主库，以维护数据同步的一致性。
• 从库的容错能力：若某个从库故障，其对系统其他部分的影响极小。即使在从库宕机的情况下，其他从库仍可提供读服务，主库也能继续正常的读写操作。故障的从库在恢复后，能自动从主库同步缺失数据。
• 主库故障的影响：主库故障可能导致Redis暂停处理新的写请求，但已连接的从库可继续提供读服务。主库恢复后，Redis将重新提供完整的读写服务。
• 应对主库故障的机制：在当前主库故障时，系统不会自动在从库中选举新的主库。这需要借助额外的高可用性解决方案，例如Redis Sentinel或Redis Cluster，来管理主库的选举和故障转移。

Redis的主从复制架构有效地提供了高可用性、数据冗余以及读写分离的功能，确保了在保持高性能的同时，数据安全和一致性得到保障。

2.2、Redis主从复制原理

在本文档中，我们将重点介绍Redis版本2.8及其后续版本的主从复制机制。

无是哪种场景，Redis 的主从复制机制均采用异步复制，也称为乐观复制，因此不能完全保证主从数据的一致性。

不论在什么场景下，Redis的主从复制机制都采用了所谓的“异步复制”或“乐观复制”。这种复制方式意味着不能完全保证主库和从库数据的实时一致性。

Redis的主从复制机制可以根据不同的运行场景和条件采取不同的实现方式。以下是一些主要场景及其对应的复制实现和说明：

• 第一次启动：在从库第一次连接到主库时，将采用psync复制方式进行全量复制。这意味着从库会从头开始复制主库中的全部数据。
• 正常运行期间：在正常运行状态下，从库通过读取主库的缓冲区来进行增量复制。这个过程涉及复制主库上发生的新的数据变更。
• 从库第二次启动（主库缓冲区未溢出） ：当从库重新启动且主库的缓冲区未溢出时，将通过读取主库的缓冲区进行部分复制。这种方式能够快速同步中断期间发生的数据变更，而不会对主库造成重大影响。
• Redis 2.8及以上版本的从库第二次启动（针对主库） ：当从库第二次启动且系统版本为Redis 2.8或以上时，将采用psync复制进行全量复制。这种情况通常发生在主库的缓冲区数据无法满足从库需要同步的数据量时。

通过上述不同的复制策略，Redis能够在保证数据备份和减少系统负载的同时，灵活应对各种运行场景。尽管异步复制机制可能导致主从数据存在短暂的不一致，但这种设计在绝大多数应用场景中已被证明是既高效又可靠的。

PS：异步复制是Redis的复制方式，而psync是实现这种复制方式的具体命令。乐观复制或乐观并发控制则是另一种与Redis的异步复制机制不同的数据库事务处理概念。不少博客或说明介绍异步复制和乐观复制是同一个概念。

2.3 PSYNC 工作原理

PSYNC 命令是Redis中用于从节点与主节点之间数据同步的关键命令。它的工作原理包括以下几个步骤：

2.3.1、启动或重连判断：

当从节点（Slave）启动或者与主节点（Master）的连接断开后重连时，从节点需要确定是否曾经同步过。

如果从节点没有保存任何主节点的运行 ID（runnid），它将视为第一次连接道主节点。

2.3.2、第一次同步处理：

在第一次同步的情况下，从节点会发送 PSYNC -1 命令给主节点，请求进行全量数据同步。

全量同步是指主节点将其所有数据完整地复制一份给从节点。

2.3.3、断线重连处理：

对于之前已经同步过的从节点，它会发送 PSYNC runid offset 命令，其中runid是主节点的唯一标识符，offset是从节点上次同步数据的偏移量。

2.3.4、主节点响应

主节点接收到PSYNC命令后，会检查runid是否匹配，以及offset是否在复制积压缓冲区的范围内。

如果匹配且offset有效，主节点将回复CONTINUE，并发送自从节点上次断开连接以来的所有写命令。

2.3.5、全量同步触发条件：

如果runid不匹配，或offset超出了积压缓冲区的范围，主节点将通知从节点执行全量同步，回复FULLRESYNC runid offset。

2.3.6、复制积压缓冲区的作用：

1. 主节点会在处理写命令的同时，将这些命令存入复制积压队列，同时记录队列中存放命令的全局offset。
2. 当从节点断线重连，且条件允许时，它可以通过offset从积压队列中进行增量复制，而不是全量复制。

2.3.7、数据一致性保障

PSYNC机制允许从节点在网络不稳定或其他意外断开连接的情况下，能够以增量方式重新同步数据，保持主从节点数据的一致性。

2.4、Redis 主从模式环境搭建

在Redis的主从架构中，主节点的数据更新会自动被复制到从节点，确保数据的一致性。这种设置既是一种数据备份策略——从节点存储了主节点的数据备份，也提高了数据安全性。此外，通过主从架构实现读写分离，主节点负责处理写请求，而读请求可以分散到一个或多个从节点，这样既提高了系统的处理能力，又优化了资源的利用。

3、Redis 哨兵机制

3.1、概述

在本文档中，我们将重点介绍Redis版本2.8及其后续版本的哨兵机制。

哨兵模式是主从复制模式的一种进阶形式，继承了主从复制的所有优势，如数据一致性和读写分离。它的核心优点在于能够自动实现主从切换和故障转移，从而提升了系统的可用性和稳定性。在哨兵模式下，系统能够从手动切换转变为自动切换，极大地增强了系统的自动化程度和稳定性。然而，哨兵模式也存在一定的局限性，特别是在在线扩容方面。当集群容量接近或达到上限时，进行扩容操作相对较为复杂和困难。

注意事项：Redis 在 Windows 平台上不受官方支持，Redis 官方只提供了源码包（zip、tar.gz 格式）。

• Redis 官网地址：redis.io/ Redis
• 源码地址：github.com/redis/redis

3.2、Redis哨兵原理

自Redis 2.8版本起，官方引入了Sentinel（哨兵）架构，旨在提升系统的高可用性。哨兵模式主要通过后台监控机制来确保Redis服务的稳定性。在这一模式中，哨兵负责实时监控主节点的运行状况。一旦主节点出现故障，哨兵将基于预设的投票机制，自动将某个从节点晋升为新的主节点，以保持服务的连续性和数据的可用性。

**哨兵本身是一个独立的进程，运行在Redis本身进程之外。它通过周期性地向Redis节点发送命令，并等待节点的响应，来判断被监控的Redis实例是否正常运行。**通过这种方式，哨兵能够监控和管理一个或多个Redis实例，确保整个Redis服务的高可用性和稳定性。

3.3、哨兵模式环境搭建

4、Redis Cluster

4.1、概述

Redis Cluster，采用了去中心化的多主多从架构，以提高数据的可用性和伸缩性。这一架构使得Redis Cluster能够在保持高性能的同时，支持更大规模的数据存储和管理。以下是Redis Cluster的几个关键特点和优势的详细阐述：

• 去中心化的多主多从架构：
  • 每个从节点都复制主节点的数据，但不直接参与读写操作，主要用于数据备份和故障恢复。
  • 这种架构使得每个节点都可以在需要时承担主节点的角色，从而提高了整体系统的可靠性和容错能力。
• 数据处理与性能：
  • Redis Cluster在处理涉及多个键的操作时可能面临性能挑战，尤其是在数据量大和高并发的场景下。这是因为多key操作可能需要跨多个节点进行，从而增加了操作的复杂性。
    然而，对于单key操作，Redis Cluster能够保持其一贯的高性能，特别是在读操作上。
• 动态扩容和收缩能力：
  • Redis Cluster支持动态地添加或移除节点，这意味着可以根据实际需求调整集群的规模，无需停机或中断服务。
  • 这一特性对于处理不断变化的负载和数据量非常重要，使得Redis Cluster在大型应用中更具弹性。
• 节点间的通信与故障转移：
  • 在Redis Cluster中，主节点之间会进行定期的健康检查和状态同步，确保数据的一致性。
  • 当主节点出现故障时，其他主节点可以通过选举机制快速选出新的主节点，实现故障的自动转移，从而确保服务的连续性。

4.2、cluster原理

4.2.1、Redis Cluster 节点分配与主从模式

Redis Cluster 通过高效的节点分配和稳健的主从模式，确保了数据的高可用性和稳定性。以下是对其核心机制的详细解释：

4.2.1.1、节点间的哈希槽分配

Redis Cluster 使用哈希槽（hash slot）机制来分配数据。假设我们有三个主节点：A、B、C，它们可以部署在同一台机器的不同端口上，或分布在三台不同的服务器上。在这种设置下，16384个哈希槽将被如下分配：

• 节点A负责管理0至5460号槽；
• 节点B负责管理5461至10922号槽；
• 节点C负责管理10923至16383号槽。

在 Redis Cluster 中，节点之间通过 gossip 协议进行通信，并通过选举机制实现故障转移。

Gossip 协议
Redis Cluster 使用 Gossip 协议来实现节点之间的通信。Gossip 协议是一种去中心化的通信协议，每个节点定期与其他节点交换信息，从而在整个集群中传播状态信息。

具体步骤如下：

• 心跳消息：
  • 每个节点会定期向其他节点发送心跳消息（HELO 消息）。
  • 心跳消息包含发送节点的状态信息，如节点 ID、IP 地址、端口号、槽位分配情况等。
• 信息传播：
  • 接收到心跳消息的节点会更新自己的状态表，并将这些信息进一步传播给其他节点。
  • 这种多对多的通信方式确保了信息在整个集群中的快速传播。
• 节点发现：
  • 新加入集群的节点会通过初始配置或现有节点的推荐来发现其他节点。
  • 一旦发现其他节点，新节点会开始发送心跳消息，逐步融入集群。
• 节点状态监控
  • 每个节点都会定期检查其他节点的状态。
  • 如果一个节点在一段时间内没有收到某个节点的心跳消息，它会标记该节点为疑似故障（PFAIL）。
• 集群共识
  • 当多个节点标记某个节点为 PFAIL 时，其中一个节点会发起一次投票，询问其他节点是否也认为该节点故障。
  • 如果大多数节点同意，则该节点被标记为已知故障（FAIL）。

4.2.1.2、数据的保存和获取

• 存入数据：例如，存储一个键值对，键名为“key”，其哈希值按照 CRC16(‘key’) % 16384 = 6782 计算。根据这个哈希槽号，数据将被存储在节点B上。
• 获取数据：无论连接哪个节点（A、B、C），获取键名为“key”的数据时，都会根据同样的哈希算法路由到节点B上提取数据。

CRC16(‘key’) % 16384 是 Redis Cluster 中用于确定键（key）所属槽位的计算公式。CRC16（Cyclic Redundancy Check 16）是一种常用的校验算法，用于检测数据传输中的错误。在 Redis Cluster 中，CRC16 用于生成一个 16 位的哈希值，这个哈希值可以唯一标识一个键。计算 CRC16(‘key’) 会得到一个 16 位的整数。

通过这个公式，可以将键均匀地分布到 16384 个槽位中。每个槽位最终会被分配给集群中的某个主节点。

4.2.1.3、新增或删除主节点

新增节点：假设新增一个节点D，Redis Cluster 会将部分哈希槽从其他节点迁移至D节点。这可能导致哈希槽分布如下调整：

• 节点A：1365-5460
• 节点B：6827-10922
• 节点C：12288-16383
• 节点D：0-1364，5461-6826，10923-12287

为了平衡负载，需要将一些哈希槽从现有节点（A、B、C）迁移到新节点 D。

删除节点：删除节点时，其管理的哈希槽会被迁移到其他节点上。迁移完成后，该节点即可被安全移除。

4.2.2、Redis Cluster主从模式

• 主从的重要性：为了保障数据的高可用性，Redis Cluster 引入了主从模式。在这种模式下，每个主节点都有一个或多个从节点。主节点处理所有的读写操作，而从节点主要负责数据备份。如果主节点发生故障，从节点中的一个将被提升为新的主节点，以确保集群的稳定运行。
• 未设置从节点的风险：以ABC三个主节点的集群为例，如果这些主节点都没有配置从节点，当其中一个（如B）发生故障时，整个集群的可用性将受到影响。A和C节点的哈希槽也将无法访问。

实例说明

在建立集群时，为每个主节点配置从节点是非常重要的。例如，集群包含主节点A、B、C，及其对应的从节点A1、B1、C1。这样，即使B节点出现故障，B1节点可以被提升为新的主节点，保证集群的持续运行。当B节点恢复时，它将成为B1的从节点。然而，需要注意的是，如果B节点和其对应的从节点B1同时出现故障，Redis Cluster 将无法提供服务。

4.3、cluster架构