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 从节点的配置是确保高可用性的最小标准配置。
以上为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。