在实际工作中，我们使用的 Redis 高可用模式有两种：Redis Cluster 和 Redis Sentinel，那么，这两种模式有什么区别？我们该如何选择？这篇文章，我们将深入分析。
一、Redis Sentinel模式
1. 什么是Redis Sentinel?
Redis Sentinel是 Redis 官方提供的高可用性解决方案，旨在监控 Redis 主从复制集群，检测故障并执行自动故障转移。Sentinel 主要负责以下几个方面：
- 监控（Monitoring）： 持续监控主节点和从节点的运行状态。
- 通知（Notification）： 在发现问题时，通过 API 或脚本通知管理员或其他系统。
- 自动故障转移（Automatic Failover）： 当主节点发生故障时，自动将一个从节点提升为新的主节点，并重新配置剩余的从节点。
- 配置提供者（Configuration Provider）： 提供客户端获取当前主节点的信息，确保客户端能够连接到正确的主节点。
Redis Sentinel核心结构如下图：
2. Sentinel的工作原理
Sentinel 以分布式的方式运行，通常部署多个 Sentinel 实例（推荐至少三个），以避免单一 Sentinel 实例的故障影响整个系统。Sentinel 通过选举机制选出领导者，负责协调故障检测和故障转移的过程。主要包含以下 5个步骤：
- 监控： Sentinel 实例定期向主节点和从节点发送心跳，检查它们的可达性和健康状态。
- 故障检测： 当 Sentinel 发现某个节点连续多次未响应心跳，就将其标记为疑似故障（S_DOWN，Subjectively Down）。
- 达成共识： 多个 Sentinel 实例需要达成一致，确认该节点确实故障（O_DOWN，Objectively Down）。
- 故障转移： 选举一台从节点作为新的主节点，并将其余从节点指向新的主节点。
- 通知客户端： 更新客户端的连接信息，使其连接到新的主节点。
3. Sentinel的优势
- 简单易用： 配置和部署相对简单，适合中小规模的 Redis 部署。
- 故障转移自动化： 提供自动的主从切换，减少了人工干预的需求。
- 客户端通知支持： 通过 Sentinel APIs，客户端可以动态获取主节点信息，适应故障转移后的变化。
4. Sentinel的限制
- 单一数据存储： Sentinel 并不支持数据的分片和扩展，只能在单一 Redis 实例上进行主从复制。
- 扩展性有限： 随着数据量和请求量的增加，无法通过增加节点来水平扩展系统容量。
- 配置复杂度： 在多种场景下，配置和管理 Sentinel 集群可能较为复杂，尤其是在大规模部署中。
二、Redis Cluster模式
1. 什么是Redis Cluster?
Redis Cluster 也是 Redis 官方提供的分布式数据存储方案，旨在实现数据的自动分片和高可用性。通过将数据分布到多个主节点上，Redis Cluster 提供了线性的扩展能力，并结合了主从复制机制，确保数据的冗余和容错能力。
Redis Cluster核心结构如下图：
2. Cluster的核心特性
- 数据分片（Sharding）： Redis Cluster 将数据按照哈希槽（Hash Slots）分布到多个主节点，每个主节点管理一定范围的槽。
- 高可用性： 每个主节点可以配置多个从节点，确保在主节点故障时能够自动进行故障转移。
- 无中心化管理： Cluster 采用分布式架构，没有单点故障，所有节点在运行时通过 Gossip 协议互相通信和维护状态。
- 动态扩容与收缩： 支持在运行时动态添加或移除节点，自动重新分配哈希槽，实现灵活的资源管理。
3. Cluster的工作原理
Cluster的工作原理主要可以从下面 3个点来进行分析：
(1) 数据分片与哈希槽
Redis Cluster 使用一致性哈希（Consistent Hashing）将数据键映射到 16384 个哈希槽中。每个主节点负责管理一部分哈希槽，通过调整槽的分配，可以实现数据的均衡分布。
(2) 节点通信
Cluster 中的节点通过 Gossip 协议进行通信，定期交换状态信息，包括节点的健康状况、槽的分配情况等。Cluster 节点之间能够快速响应节点的增减和故障事件。
(3) 故障检测与故障转移
当一个主节点出现故障时，Cluster 的从节点会检测到主节点的不可达状态，并通过多数节点的共识决定是否执行故障转移。选举出一个从节点作为新的主节点，并重新配置槽的所有权，确保数据的持续可用。
4. Cluster 的优势
- 高可扩展性： 通过数据分片，实现水平扩展，适应大规模数据和高并发请求。
- 无单点故障： 分布式架构设计，避免了单点故障的风险，提高了系统的可靠性。
- 自动化管理： 支持动态扩容与收缩，简化了运维管理的复杂性。
- 高可用性与数据冗余： 结合主从复制机制，确保数据的高可用性和容错能力。
5. Cluster 的限制
- 操作复杂性： 相比 Sentinel，Cluster 的配置和管理更为复杂，需要更高的维护成本。
- 不支持全局事务： Cluster 不支持跨槽操作的事务，某些复杂的业务场景可能受到限制。
- 客户端支持要求高： 客户端需要支持 Cluster 模式，能够处理命令重定向和哈希槽的分布情况。
- 资源消耗较大： 由于分片和复制的存在，整体资源消耗较单节点部署更高。
三、两者对比
在了解了 Redis Sentinel 和 Redis Cluster 的基本概念后，接下来我们将从多个维度对两者进行详细的比较。
1. 架构设计
Redis Sentinel：
- 主从复制架构： 单一主节点，多个从节点。
- Sentinel 监控： 部署多个 Sentinel 实例，分布在不同的机器上以避免单点故障。
- 客户端连接： 客户端直接连接到主节点和从节点，或者通过 Sentinel API 动态获取主节点信息。
Redis Cluster：
- 分布式架构： 多个主节点组成集群，每个主节点负责管理一定范围的哈希槽。
- 数据分片： 数据自动分布到不同的主节点，实现水平扩展。
- 主从复制： 每个主节点可以配置多个从节点，提供数据的冗余和故障转移能力。
- 无中心化管理： 所有节点通过 Gossip 协议进行通信和状态维护。
2. 数据分片与扩展性
Redis Sentinel：
- 无内建分片： Sentinel 主要关注高可用性，不提供数据分片功能。
- 扩展性限制： 通过增加从节点主要实现读扩展，写扩展受限于主节点的性能。
Redis Cluster：
- 内建分片： 使用哈希槽实现数据的自动分片，支持水平扩展。
- 易于扩展： 添加新节点后，Cluster 自动重新分配哈希槽，平衡数据分布。
3. 故障检测与自动故障转移
Redis Sentinel：
- 集中式故障检测： 通过多个 Sentinel 实例共同监控集群状态，依靠多数 Sentinel 的共识决定故障事件。
- 自动故障转移： 在主节点故障时，自动提升从节点为新的主节点，并重新配置其余从节点。
- 简单的拓扑： 主要针对主从拓扑，故障转移过程相对简单。
Redis Cluster：
- 分布式故障检测： 每个节点通过 Gossip 协议监控集群状态，分布式决策故障事件。
- 自动故障转移： 同时支持主节点和从节点的故障检测与转移，具有更高的容错能力。
- 复杂的拓扑： 支持多主从架构，故障转移过程更为复杂，但提供更高的可用性。
4. 客户端支持与路由机制
Redis Sentinel：
- 客户端要求： 客户端需要支持 Sentinel 协议，能够动态获取主节点信息，适应故障转移后的变化。
- 简单路由： 客户端直接连接到主节点或从节点，不涉及数据分片。
- 适用范围： 适合单实例或简单主从复制的场景。
Redis Cluster：
- 客户端要求： 客户端必须支持 Cluster 协议，能够处理命令重定向，了解哈希槽分布。
- 智能路由： 客户端根据键的哈希槽决定连接到哪个主节点，支持跨主节点的操作。
- 复杂操作支持： 支持部分复杂命令，但跨槽操作存在限制。
3.5 配置与管理复杂度
Redis Sentinel：
- 配置简单： 只需配置主从复制和 Sentinel 监控，无需考虑数据分片。
- 管理相对简单： 增加从节点或进行故障转移较为容易，适合中小规模部署。
- 监控工具支持： 有丰富的监控和管理工具支持 Sentinel 集群。
Redis Cluster：
- 配置复杂： 需要配置多个主节点和从节点，指定哈希槽范围，涉及更多的部署细节。
- 管理复杂： 动态扩展、缩减需要重新分配哈希槽，涉及数据迁移和重新平衡。
- 工具支持： 提供 redis-trib（现已集成到 redis-cli）等工具，但仍需专业运维技能。
6. 数据一致性与持久性
Redis Sentinel：
- 强一致性： 主从复制一般采用异步方式，存在短暂的数据不一致风险。
- 持久化选项： 支持 RDB 和 AOF 持久化，但需手动配置和管理。
- 数据丢失风险： 在主节点故障后，可能会丢失部分未同步到从节点的数据。
Redis Cluster：
- 最终一致性： 数据分片后，各主节点保持独立，主从复制同样采用异步方式。
- 持久化选项： 支持 RDB 和 AOF，同样需要合理配置以保证数据安全。
- 数据丢失风险： 取决于复制延迟和故障转移策略，多从节点配置可以降低数据丢失风险。
7. 性能表现
Redis Sentinel：
- 读性能提升： 通过增加从节点，可以分担读请求，提升整体读性能。
- 写性能受限： 写请求集中在主节点，写性能受限于单节点的处理能力。
- 延迟较低： 单实例或少量从节点时，延迟表现良好。
Redis Cluster：
- 读写性能提升： 通过数据分片，多个主节点可以并行处理读写请求，提升整体性能。
- 网络开销： 数据分片和节点间通信可能增加一定的网络开销。
- 延迟影响： 跨节点操作或重定向可能增加请求延迟，但在大规模部署中仍具有较高性能。
四、适用场景分析
1. Redis Sentinel 适用场景
- 中小规模部署： 适用于数据量和请求量较小，主从复制足以满足需求的场景。
- 单数据中心： 在单一数据中心内实现高可用性，容错能力足够。
- 简化架构需求： 不需要数据分片和水平扩展，架构相对简单。
- 读多写少的应用： 通过增加从节点提升读性能，适合读密集型应用。
2. Redis Cluster 适用场景
- 大规模部署： 需要处理海量数据和高并发请求，通过数据分片实现水平扩展。
- 多数据中心分布： 支持跨数据中心部署，提高全球可用性和容灾能力。
- 高可用与高性能并重： 需要在高可用性和性能之间取得平衡，适用于对可靠性和响应时间要求高的应用。
- 复杂业务场景： 需要支持复杂的数据模型和查询操作，虽有一定限制，但仍适用多数场景。
五、优缺点总结
1. Redis Sentinel
优点：
- 部署简单： 适合快速搭建高可用环境。
- 配置灵活： 可根据需求调整主从节点数量，满足读扩展需求。
- 维护成本低： 简单的架构减少了维护的复杂性。
- 兼容性强： 支持大部分 Redis 命令和功能，不受分片限制。
缺点：
- 扩展性有限： 无法实现数据的水平分片，面对大规模数据时能力受限。
- 单点写入： 写请求集中在主节点，可能成为性能瓶颈。
- 数据一致性风险： 异步复制可能导致数据不一致，存在数据丢失的风险。
2. Redis Cluster
优点：
- 高扩展性： 支持数据的自动分片，适应大规模数据和高并发请求。
- 高可用性： 结合主从复制，实现更高的容错能力和故障转移。
- 去中心化管理： 无单点故障，提升系统整体可靠性。
- 性能优势： 通过并行处理提高读写性能，满足高性能需求。
缺点：
- 配置与管理复杂： 需要合理规划哈希槽分配和节点配置，增加运维难度。
- 客户端要求高： 客户端需支持 Cluster 协议，处理命令重定向和哈希槽路由。
- 数据迁移成本： 动态扩展或缩减时，数据迁移可能涉及较高的资源消耗和延迟。
- 操作限制： 某些 Redis 命令和事务在 Cluster 模式下存在限制，需要调整业务逻辑。
六、总结
Redis Sentinel 和 Redis Cluster 都是 Redis官方提供的高可用性解决方案，但它们在架构设计、功能特性、适用场景等方面存在显著差异。
Redis Sentinel 适用于中小规模、单数据中心、高可用性优先的场景，部署和管理相对简单；而 Redis Cluster 则更适用于需要水平扩展、大规模、分布式高可用的应用，具备更高的灵活性和扩展性，但同时也带来了更高的配置和管理复杂度。
在大厂中，两种高可用方式都会提供，作为一名技术人员，我们不能完全黑盒使用，应该更多地了解它们的工作原理以及优缺点，这样才能更好地帮助我们做好技术选型，出现问题时也能快速地去解决问题。
