Redis 集群模式与高可用机制

最近在准备面试,正把平时积累的笔记、项目中遇到的问题与解决方案、对核心原理的理解,以及高频业务场景的应对策略系统梳理一遍,既能加深记忆,也能让知识体系更扎实,供大家参考,欢迎讨论。

在分布式环境下,为了避免单一节点负载过高导致的不稳定,Redis 提供了 集群模式(Cluster) ,哨兵模式的升级版,Master 节点支持水平扩容。

在集群模式中,通过计算 Key 的哈希值,把它映射到哈希槽中的一个,再由槽映射到具体的 Master 节点。 将 Key 分布到多个节点上,每个 Master 节点后会配置若干 Slave 节点,用于在故障时进行主备切换。客户端可以连接任意 Master 节点,集群内部会根据 Key 自动将请求转发到正确的 Master 节点

节点类型

Master 节点 :负责存储和写操作,是集群的核心。

Slave 节点 :作为备份,支持故障切换,通过调整配置可承担读请求。

数据分片(Sharding)

  • 使用 哈希槽 (Hash Slot) 方式分片。

    • 一共 16384 个槽,分配到不同 Master 节点(集群最多 16384 个 Master 节点,不建议设置过多个,因为每个节点之间都要互相发送心跳包,节点越多,开销越大(近似 O(N²) 复杂度))。

    • 客户端根据 Key 的 CRC16 哈希值定位到具体槽,再找到对应 Master 节点。

  • 奇数投票机制

    • 建议 Master 数量为奇数,集群内部需要多数投票才能判定某个 Master 下线。如果是偶数个 Master,容易出现"脑裂"或无法形成多数投票,奇数更稳
  • 工作中常见 Master 数量

    • Redis单节点 QPS 大约在 10 万 ~ 20 万 ops/s(纯内存读写,开启持久化、网络延迟、复杂命令会降低)。
    • 30 万并发场景,Redis Cluster 建议配置3 个或 5 个 Master 节点;前期业务上线时,建议预留空间,避免因集群规模过小导致性能瓶颈或高可用风险,影响生产环境稳定性。

高可用的实现

集群模式的高可用机制与哨兵模式类似:

  1. 集群内节点之间会定期进行心跳检测;
  2. 如果多数节点判定某个 Master 节点失效,就会将其踢出集群;
  3. 随后从该 Master 的 Slave 节点中选举出一个新的 Master,继续提供服务。

这样,即使某个节点宕机,集群也能保持可用性,保证系统的稳定。

使用场景

虽然集群模式能够避免单 Master 的性能瓶颈,但数据同步会占用一定带宽,特别是写操作多时更为明显。因此:

  • 写操作密集型场景:推荐使用集群模式,以实现负载分摊与高可用。
  • 常规场景:大多数情况下,哨兵模式即可满足需求,部署和维护成本也更低。
相关推荐
海梨花4 小时前
字节跳动后端 一面凉经
java·redis·学习·leetcode·面经
GBASE5 小时前
GBASE南大通用政企行业案例-国家电网公司“网上国网”项目
数据库
GBASE5 小时前
DB-Engines数据库排行榜9月榜单速递
数据库
IvorySQL5 小时前
PostgreSQL 中唯一索引的工作原理
数据库·postgresql
爱隐身的官人5 小时前
新后端漏洞(上)- Redis 4.x5.x 未授权访问漏洞
redis·未授权访问漏洞
king_harry5 小时前
Postgresql客户端psql提示符(Prompt)配置
数据库·postgresql·prompt
Kookoos5 小时前
多租户配额与预算:限额、配额周期与突发桶的结算模型(Final)
redis·令牌桶·abp vnext·配额·突发桶·账期结算
DemonAvenger5 小时前
大数据量下的MySQL优化策略:从理论到实战,助你游刃有余
数据库·mysql·性能优化
代码的余温6 小时前
SQL Server核心架构深度解析
数据库·sqlserver·架构