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 的性能瓶颈,但数据同步会占用一定带宽,特别是写操作多时更为明显。因此:

  • 写操作密集型场景:推荐使用集群模式,以实现负载分摊与高可用。
  • 常规场景:大多数情况下,哨兵模式即可满足需求,部署和维护成本也更低。
相关推荐
IvorySQL13 分钟前
聚焦六大功能:PostgreSQL 18 新特性深度解析
数据库·postgresql·开源
饿了我会自己捡代码吃21 分钟前
【MySQL】使用C/C++链接mysql数据库
c语言·数据库·mysql
gb421528737 分钟前
DDD 与传统三层架构的详细对比
数据库·架构
不是三毛没有半1 小时前
Mysql 简单的语句回顾
数据库·mysql·oracle
abcefg_h1 小时前
MySQL查询详细介绍
数据库·mysql
whn19772 小时前
批量获取oracle的AWR报告方法
数据库·oracle
小旺不正经3 小时前
数据库表实现账号池管理
数据库·后端·算法
sanx183 小时前
一站式电竞平台解决方案:数据、直播、源码,助力业务飞速启航
前端·数据库·apache·数据库开发·时序数据库
学IT的周星星3 小时前
《MyBatis变形记:当SQL遇上“智能管家“》
数据库·sql·mybatis