redis集群和sentinel方案

简单用就sentinel，大规模才cluster

Redis 集群的特点：

1. 数据分片：Redis Cluster 通过分片将数据分布在多个节点上，每个节点负责存储一部分数据（即槽位）。
2. 去中心化：每个节点都管理一部分数据，节点之间相互连接，形成分布式结构。
3. 高可扩展性：容易通过增加节点来扩展系统的容量和处理能力。
4. 自动故障转移：集群能够自动检测节点故障并进行主从角色的切换。
5. 读写分离：可以配置主从复制，实现读写分离，提高性能。

Redis Sentinel 的特点：

1. 监控与故障转移：Sentinel 主要负责监控 Redis 主从复制集群的状态，当主节点发生故障时，Sentinel 会自动将一个从节点提升为新的主节点。
2. 主从复制：Sentinel 基于主从复制模型，适用于单一主节点和多个从节点的架构。
3. 配置简单：相对于集群，Sentinel 的配置和部署过程更简单。
4. 自动通知：Sentinel 可以配置通知机制，在故障转移或其他重要事件发生时通知管理员。
5. 不提供数据分片：Sentinel 不会自动分片数据，所有的写操作都依赖于单个主节点。

适用场景：

• Redis 集群适用于需要处理大量数据和高并发读写的场景，可以提供水平扩展和读写分离。
• Redis Sentinel适用于对数据分片需求不高，但需要高可用性和自动故障恢复的场景，特别是当应用程序主要依赖单主节点进行写操作时。

架构差异：

• Redis 集群是一个去中心化的架构，所有节点都是平等的，并且数据在节点之间自动分片。
• Redis Sentinel是一个中心化的监控系统，Sentinel 节点监控主从复制集群，并在主节点故障时进行故障转移。

配置差异：

• Redis 集群配置相对复杂，需要考虑分片、节点连接和数据迁移等问题。
• Redis Sentinel配置相对简单，主要配置监控的主节点和从节点信息。

Redis Sentinel 选举！

用于在主节点发生故障时自动选举出一个新的主节点，以此来保证 Redis 服务的高可用性。

以下是 Sentinel 选举的主要步骤:

1. 主观下线（SDOWN）：每个 Sentinel 节点会定期对 Redis 集群中的主节点和从节点发送心跳检测（PING 命令）。如果一个节点在配置的 down-after-milliseconds 时间内没有响应，那么该 Sentinel 节点会将该节点标记为主观下线。
2. 客观下线（ODOWN）：当一个 Sentinel 节点将主节点标记为主观下线后，它会询问其他 Sentinel 节点对这个主节点的状态。如果超过 quorum 数量的 Sentinel 节点也认为主节点已经下线（即主观下线），那么这个主节点就会被标记为客观下线，这意味着主节点确实出现了故障。
3. 选举领导者：一旦主节点被确认为客观下线，Sentinel 集群需要选举出一个领导者（Leader）来负责执行故障转移操作。选举过程基于 RAFT 算法，每个 Sentinel 节点都有资格成为领导者，它们会向其他 Sentinel 节点发送请求成为领导者的消息。如果一个 Sentinel 节点收到的投票数达到 max(quorum, num(sentinels)/2+1)，则它成为领导者。
4. 故障转移：领导者 Sentinel 节点负责故障转移的具体操作，它会从现有的从节点中选择一个来作为新的主节点。选择新主节点的规则通常包括：
   • 优先选择 slave-priority 配置最高的从节点。
   • 如果有多个从节点具有相同的 slave-priority，则选择复制偏移量（replication offset）最大的从节点，表示它拥有最新的数据。
   • 如果复制偏移量也相同，则选择 runid 最小的从节点。
5. 更新配置和通知：领导者 Sentinel 节点会向被选中的从节点发送 SLAVEOF NO ONE 命令，使其成为新的主节点。然后，它会向其他从节点发送命令，让它们成为新主节点的从节点。最后，它会更新所有 Sentinel 节点和客户端的配置，以便它们能够连接到新的主节点。
6. 旧主节点恢复：如果原来的主节点重新上线，它会被 Sentinel 集群识别并配置为新主节点的从节点，从而恢复服务。

避免脑裂！！

多个节点认为自己是主节点的情况

1. 使用奇数个节点：在主从复制的集群中，使用奇数个节点可以确保在发生网络分区时，至少有一个节点能够获得多数票，从而避免脑裂。
2. 配置合理的网络分区检测：确保集群能够正确地检测到网络分区，并在检测到分区时采取适当的措施，比如暂停写操作。
3. 设置合理的超时和阈值：合理配置超时参数和阈值，比如 Sentinel 的 down-after-milliseconds 和 quorum 参数，以确保节点在真正下线之前有足够的时间进行检测和确认。
4. 使用强一致性协议：例如 Raft 或 Paxos 协议，这些协议通过选举机制确保在任何时候只有一个主节点。
5. 使用更高级的高可用性解决方案：比如 Redis Cluster，它通过分片和多个主节点来提高系统的可用性和容错能力。
6. 数据复制策略：确保数据复制是同步或准同步的，减少数据在主从节点之间的延迟。
7. 监控和报警：实施有效的监控系统，以便在发生脑裂之前检测到潜在的问题，并及时发出警报。
8. 避免单点故障：设计系统时避免任何单点故障，比如使用多个 Sentinel 节点来避免单个 Sentinel 节点的故障导致的问题。
9. 定期测试和演练：定期对系统进行故障转移测试，确保故障转移机制按预期工作，并根据测试结果调整配置。
10. 使用成熟的高可用性框架：比如使用 Kubernetes 等容器编排工具，它们提供了内置的高可用性机制。
11. 避免过度分区：在设计分布式系统时，避免过度分区，以减少网络分区导致脑裂的风险。
12. 使用数据一致性检查：定期进行数据一致性检查，确保所有节点上的数据保持一致。