Redis集群部署模式的不同实现过程

redis集群就是多个redis节点一起工作的模式。它没有代理节点和中心节点，各个节点平等，强化redis的读写能力。

是一种分布式集群模式，它允许将数据分散存储在多个节点上，从而提供了横向扩展、高可用性和更大存储容量。

1、集群模式

通过添加服务器的数量，提供相同的服务，从而让服务器达到一个稳定、高效的状态。

1.1. 主从复制模式（master-slave replication）

1.描述：

在这种模式下，redis 实例可以设置为主节点（master）和从节点（slave）。主节点负责处理所有的读写请求，从节点负责部分读请求，从节点自动从主节点进行数据复制。

如下图所示：

2.原理：

根据从数据集id（继承master的id）和offset偏移量来进行判断。

如果是首次同步，会保存master的数据集id和offset，同时将rdb文件或者aof文件，发送baklog命令给从节点，增量同步数据。

如下图所示：

3.优点：

• 提高可用性：如果主节点宕机，可以快速将一个从节点提升为主节点。
• 提高性能：可以把读取请求分配给从节点，减少主节点的负载。

4.缺点：

• 写负载集中在主节点，可能成为性能瓶颈。
• 从节点的延迟：从节点数据同步存在延迟，读操作可能获得过时的数据。

1.2. redis 集群模式（cluster mode）

1.描述：

• redis 集群模式是 redis 提供的分布式数据库解决方案，允许将数据分布在多个 redis 实例上。它支持水平扩展（sharding），使得集群能够处理的数据量远超个别节点承载的能力。
• 每个分片由一组 master/slave 节点管理，而不是依赖于单一节点的垂直扩展。

如下图所示：

通常集群模式下：可以进行一主多从、一主一从的方式。下面会进行深入了解。

2.工作原理

• 数据被划分为 16384 个槽（slot），每个新的数据键会被映射到这些槽上。
• 每个主节点管理一些槽，从节点负责主节点的数据备份。
• 使用哈希槽将键映射到节点，确保数据均匀分配。

如下图所示：

3.优点

• 每个节点独立处理写请求，能够有效分散写负载。
• 横向扩展的方式更加灵活，可以适应不同的工作负载和数据规模。

4.缺点

• 集群管理相对复杂，要求一致性保证和槽管理。
• 节点间的网络分裂（network partition）会影响数据的可用性。

1.3. 哨兵模式（sentinel mode）

1.描述：

sentinel 是 redis 提供的高可用性解决方案，主要用于监控和故障转移。sentinel 可以监控主节点和从节点的健康状态，并在主节点宕机时进行自动切换。

如下图所示：

2.工作原理

• sentinel 监控 redis 实例的状态，确定主节点是否正常。
• 在主节点不可用时，sentinel 会选择一个从节点提升为新的主节点，并更新客户端的主节点信息。

如下图所示：

3.优点：

• 提高系统的可靠性和可用性，支持自动故障转移。
• sentinel 可以作为集群的监控和通知工具，支持集群的维护。

4.缺点：

• 需要更为复杂的配置和管理。
• 在多台 sentinel 实例中，复杂的选举过程可能会产生延迟。

1.4. redis cluster + sentinel

1.描述：

结合使用 redis 集群和 sentinel，充分利用二者的优势。redis 集群处理数据分片，sentinel 监控和维护集群的高可用性。

2.应用场景：

对于大型应用，需要高可用性和可扩展性的场景，结合使用集群模式和 sentinel 模式。

3.优点：

1、将数据自动切分(split)到多个节点

2、当集群中的某一个节点故障时，redis还可以继续处理客户端的请求。

总结：

redis 提供的多种集群模式适用于不同的场景：

• 主从复制：适用于基础的数据冗余和读负载分担。
• redis 集群模式：适用于大规模的数据存储与处理，支持水平扩展。
• 哨兵模式：确保高可用性，并支持自动故障转移。
• redis cluster + sentinel：适用于需要高可靠性和可扩展性的复杂应用。

关于哨兵模式和cluster+哨兵模式区别

关于上面几种模式的区别，可以得出以下的结论：

2. 最小节点配置

在 redis 集群中，为了确保高可用性和故障恢复，建议至少配置以下节点：

如下图所示：

每个 slave 都是对应 master 的备份。当 master 节点发生故障时，对应的 slave 节点会自动升级为新的 master，保持数据的可用性。

2.1、最小节点配置

主节点（master nodes）:

最少需要 3 个主节点。这可以确保在某个主节点失效的情况下，集群仍然能够提供服务。

从节点（replica nodes）:

至少需要 3 个从节点，每个主节点对应一个从节点，用于数据备份和故障转移。

2.2、整体配置

因此，最小的集群配置为 6 个节点：

• 3 个主节点
• 3 个从节点

2.3、理由

• 主节点: 提供读写服务，负责处理客户端请求和数据存储。
• 从节点: 作为主节点的数据备份，提供数据副本和读取负载分担。

2.4、故障恢复

在以上配置中：

• 如果一个主节点失效，集群可以通过从节点的副本自动进行故障转移（即选举一个从节点提升为新的主节点），确保服务的持续可用性。
• 由于至少有 3 个主节点，可以保证在最多 1 个主节点失效的情况下，仍然能够通过剩余的主节点维持集群的正常运行。

如果希望更具恢复能力和负载均衡，可以增加主节点和从节点的数量，常见的做法是保持主从节点的比例为 1:1。

而对于集群为什么要三个master节点原因，并且推荐为奇数？

• 新master的选举需要大于半数的集群master节点同意才能选举成功，如果只有两个master节点，当其中一个挂了，是达不到选举新master的条件的。
• 而奇数的master节点更多的是 从节省机器资源角度出发。

3. 单主多从

整体结构如下图所示：

3.1、优势：

容错:

如果主节点出现故障，redis 可以提升一个从节点为新的主节点。即使有一个主节点出现故障，仍然有多个从节点作为冗余，确保数据的可靠性和业务的持续性。

负载均衡:

在高读负载的应用场景中，可以将读取请求分配到从节点，减轻主节点的压力。这种方式可以提高性能，特别是在读操作远比写操作频繁的情况下。

节省资源:

对于一些小型应用或开发阶段的项目，配置一个主节点和多个从节点可以有效利用资源，而不是部署更多的主节点。

4. 配置实例

4.1、单主双从

非常适合读取较多，但对写入频率要求不高的场景。

例如，很多数据可以读，但修改数据的频率较低。

4.2、3 主 3 从

更适合需要高可用性的系统，能够处理更高的写负载并提供更强的故障恢复能力。

5. 选择配置

在选择主从节点配置时，可以考虑以下因素：

系统负载:

• 写入负载较重的情况下，建议使用多主。
• 若以读取为主，单主多从则较为合适。

冗余需求:

• 对业务连续性要求较高，建议使用多个主节点，在高可用性场景下要确保系统稳定。

成本和资源:

• 根据可用资源和成本预算，可能会选择较少的节点配置，特别是在开发或小型应用中。

总结

3 主节点 + 3 从节点的配置是确保高可用性的最小标准配置。

以上为个人经验，希望能给大家一个参考，也希望大家多多支持代码网。