Redis Sentinel vs. Cluster：哨兵和集群，到底怎么选？

“哥们，最近在搞 Redis 高可用，有点纠结，不知道该用 Sentinel（哨兵） 还是 Cluster（集群），你能给分析分析不？”

相信不少开发者在搭建 Redis 高可用方案时，都会遇到类似的灵魂拷问。别慌，今天咱们就来好好掰扯掰扯 Sentinel 和 Cluster，让你不再纠结！

先说结论：如果你只是需要主从复制和故障自动转移，Sentinel 就够用了；但如果你需要更高的性能、更大的容量，以及数据的自动分片，那就得上 Cluster 了。

接下来，咱们深入细节，看看它们到底有啥不一样。

一、 哨兵（Sentinel）：站岗放哨，保障主从切换

Sentinel，顾名思义，就是“哨兵”。它的核心职责是：监控 Redis 主从节点的状态，并在主节点挂掉的时候，自动将从节点提升为新的主节点，保证服务的可用性。

1.1 Sentinel 的核心功能

• 监控（Monitoring）： Sentinel 会持续不断地检查你的主节点和从节点是否正常工作。
• 通知（Notification）： 当被监控的 Redis 节点出现问题时，Sentinel 会通过 API 通知系统管理员，或者其他的应用程序。
• 自动故障转移（Automatic failover）： 当主节点挂了，Sentinel 会自动启动故障转移流程，将一个从节点升级为新的主节点，并让其他从节点复制新的主节点。
• 配置提供者（Configuration provider）： Sentinel 可以作为客户端获取 Redis 节点信息的权威来源。客户端连接到 Sentinel，询问当前可用的 Redis 主节点地址。

1.2 Sentinel 的架构

一个典型的 Sentinel 系统，至少包含三个 Sentinel 节点（为了保证 Sentinel 自身的健壮性）。这些 Sentinel 节点会相互监控，并共同决策是否需要进行故障转移。

(请自行替换为有效的图片链接)

Sentinel 节点之间使用 Gossip 协议（流言协议）来交换信息，并使用 Raft 算法来保证决策的一致性。

1.3 Sentinel 的工作流程

1. 发现与监控： Sentinel 节点启动后，会自动发现 Redis 主节点和从节点，并开始监控它们的状态。
2. 主观下线（SDOWN）： 如果一个 Sentinel 节点发现主节点在指定的时间内（down-after-milliseconds）没有响应，就会将主节点标记为“主观下线”（Subjectively Down，简称 SDOWN）。
3. 客观下线（ODOWN）： 当足够多的 Sentinel 节点（quorum）都将主节点标记为 SDOWN，主节点就会被标记为“客观下线”（Objectively Down，简称 ODOWN）。
4. 领导者选举： Sentinel 节点之间会进行选举，选出一个领导者（Leader）来负责故障转移。
5. 故障转移： 领导者会选择一个从节点作为新的主节点，并向其他从节点发送命令，让它们复制新的主节点。同时，领导者还会更新客户端的配置，让它们连接到新的主节点。

1.4 Sentinel 的优缺点

优点：

• 部署简单： 相比 Cluster，Sentinel 的部署和配置相对简单。
• 自动故障转移： 无需人工干预，即可实现主从切换。
• 高可用： 保证了 Redis 服务在主节点故障时的可用性。

缺点：

• 容量有限： Sentinel 本身并不存储数据，它只是监控和管理 Redis 节点。因此，Redis 系统的容量受限于单个主节点的容量。
• 性能瓶颈： 所有的写操作都必须经过主节点，主节点可能会成为性能瓶颈。
• 数据丢失风险： 由于 Redis 的复制是异步的，主从切换时可能会丢失少量数据。

二、 集群（Cluster）：分布式存储，横向扩展

Cluster，顾名思义，就是“集群”。它通过将数据分片（Sharding）存储在多个 Redis 节点上，实现了数据的分布式存储和负载均衡，从而突破了单机 Redis 的容量和性能限制。

2.1 Cluster 的核心功能

• 数据分片（Sharding）： Cluster 将数据分散存储在多个 Redis 节点上，每个节点负责一部分数据。
• 自动故障转移（Automatic failover）： 与 Sentinel 类似，当主节点挂掉时，Cluster 会自动将从节点提升为新的主节点。
• 负载均衡（Load balancing）： 客户端可以连接到集群中的任意一个节点，Cluster 会自动将请求转发到正确的节点。
• 在线扩容/缩容（Online resizing）： 可以在不停止服务的情况下，动态地添加或删除节点。

2.2 Cluster 的架构

一个典型的 Redis Cluster，至少包含三个主节点（每个主节点至少有一个从节点）。这些节点通过 Gossip 协议相互通信，并使用 CRC16 算法将数据分配到不同的槽（Slot）中。

(请自行替换为有效的图片链接)

Redis Cluster 一共包含 16384 个槽，每个键（Key）都会根据 CRC16 算法计算出一个槽编号，然后根据槽编号找到对应的节点。

2.3 Cluster 的工作流程

1. 节点发现： Cluster 节点启动后，会自动发现其他节点，并建立连接。
2. 槽分配： 集群中的每个节点都会负责一部分槽，并将槽的信息广播给其他节点。
3. 客户端路由： 客户端连接到集群中的任意一个节点，发送命令。如果该节点负责命令对应的槽，就直接执行命令；否则，节点会返回一个 MOVED 错误，告诉客户端应该连接到哪个节点。
4. 故障转移： 当主节点挂掉时，它的从节点会进行选举，选出一个新的主节点，并接管原来主节点的槽。
5. 数据迁移： 当添加或删除节点时，Cluster 会自动进行数据迁移，将槽和数据从一个节点移动到另一个节点。

2.4 Cluster 的优缺点

优点：

• 高性能： 数据分片存储，读写操作可以并行处理，提高了整体性能。
• 高可用： 自动故障转移，保证了服务的高可用性。
• 可扩展性： 可以通过添加节点来线性扩展集群的容量和性能。

缺点：

• 部署复杂： 相比 Sentinel，Cluster 的部署和配置更加复杂。
• 客户端支持： 需要客户端支持 Cluster 协议，才能正确地路由请求。
• 事务限制： Cluster 模式下，不支持跨节点的事务操作。
• 批量操作限制: Cluster模式下, 不支持同时处理多个keys的命令, 比如mget, mset, 因为keys可能分布在不同的实例上.

三、 总结：如何选择？

说了这么多，到底该怎么选呢？其实，选择 Sentinel 还是 Cluster，主要取决于你的业务需求：

• 如果你只需要主从复制和故障自动转移，对性能和容量要求不高，Sentinel 就足够了。
• 如果你需要更高的性能、更大的容量，以及数据的自动分片，那就得上 Cluster 了。

再给你提供几个具体的场景参考：

• 场景一： 你的 Redis 主要用于缓存，数据量不大，对性能要求也不高，但是希望在主节点挂掉的时候，服务不要中断。方案： Sentinel。
• 场景二： 你的 Redis 主要用于存储大量的用户数据，需要支持高并发的读写操作，并且希望能够随着业务的发展，动态地扩展 Redis 的容量。方案： Cluster。
• 场景三： 你的 Redis 既要存储缓存数据，又要存储一些重要的业务数据，希望既有高可用性，又有高性能和可扩展性。方案： 可以考虑将缓存数据和业务数据分开存储，缓存数据使用 Sentinel，业务数据使用 Cluster。

最后，再强调一点：没有最好的方案，只有最适合的方案。 在选择 Redis 高可用方案时，一定要结合自己的业务需求，综合考虑各种因素，做出最合理的选择。

希望这篇文章能帮你理清 Sentinel 和 Cluster 的区别，让你在搭建 Redis 高可用方案时不再迷茫！如果你还有其他问题，欢迎留言讨论！