

首页  思维导图  详情



Redis高可用架构演进

2026-03-03 15:53:42   0  举报





AI智能生成

Redis高可用架构演进，从单点模式到哨兵模式演进，包含部署脚本、经验总结等

redis

redis集群

redis部署

java

后端

模版推荐

作者其他创作

大纲/内容

1. 核心问题与演进目标

1.1 单点Redis的局限性 (起点)

不稳定性：服务宕机后无可用服务。

性能瓶颈：单节点读写能力有限。

1.2 演进目标：强化Redis的读写能力与高可用性。

2. 基础架构：主从复制模式 (Master-Slave Replication)

2.1 核心概念与角色

主节点 (Master)：有且仅有一个，可读可写。

从节点 (Slave)：可以有多个，只读 (read-only)。

数据同步：Master持续将数据更新异步/同步给所有Slaves。

2.2 核心价值与解决的问题

读写分离：读请求分发到多个Slave，大幅提升读吞吐量。

数据冗余：提供数据热备份，增强数据安全性。

缓解写压力：将读操作从Master剥离，间接优化Master的写性能。

2.3 部署配置详细步骤 (以端口6380/6381/6382为例)

步骤1：准备目录

mkdir -p /usr/local/redis/master-slave

cd /usr/local/redis/master-slave && mkdir 6380 6381 6382

步骤2：拷贝配置文件

cp /path/to/redis-3.2.9/redis.conf ./6380/

cp /path/to/redis-3.2.9/redis.conf ./6381/

cp /path/to/redis-3.2.9/redis.conf ./6382/

步骤3：修改配置文件

Master (6380)：编辑 6380/redis.conf，主要修改 port 6380。

Slave (6381)：编辑 6381/redis.conf，修改：

port 6381

slaveof 127.0.0.1 6380 (或 replicaof)

Slave (6382)：编辑 6382/redis.conf，修改：

port 6382

slaveof 127.0.0.1 6380 (或 replicaof)

步骤4：启动服务

打开三个终端，分别执行：

cd 6380 && redis-server ./redis.conf

cd 6381 && redis-server ./redis.conf

cd 6382 && redis-server ./redis.conf

步骤5：功能验证

连接Master写读：redis-cli -p 6380 -> set key value -> get key (成功)。

连接Slave读：redis-cli -p 6381 -> get key (成功，数据已同步)。

连接Slave写：redis-cli -p 6381 -> set key2 value2 (失败，返回 READONLY 错误)。

2.4 遗留缺陷

主节点单点故障：Master宕机后，集群失去写能力，需要人工干预切换。

3. 高可用演进：Sentinel哨兵模式 (解决高可用)

3.1 核心角色：Sentinel哨兵

独立进程：不存储数据，专门用于监控和管理Redis实例。

三大任务：

监控 (Monitoring)：持续检查Master和Slave的健康状态。

提醒 (Notification)：通过API向管理员发送故障告警。

自动故障迁移 (Automatic Failover)：核心功能，自动完成主从切换。

3.2 Sentinel网络 (高可用保障)

自动组网：监控同一Master的多个Sentinel实例会自动发现并组成分布式网络。

优势：避免Sentinel自身单点故障。只要网络中有至少一个Sentinel存活，就能触发故障转移。

部署建议：Sentinel节点数量应为奇数个 (如3或5)，以满足投票的半数以上原则。

3.3 自动故障转移 (Failover) 详细流程

主观下线 (Subjectively Down)：某个Sentinel发现Master在配置时间内 (down-after-milliseconds) 无响应。

客观下线 (Objectively Down)：

该Sentinel向网络中的其他Sentinel发送命令，请求投票判定Master为下线。

当同意的Sentinel数量达到法定人数 (quorum，配置值) 时，Master被判定为客观下线。

Sentinel领导者选举 (Raft算法)：Sentinel网络内部通过选举产生一个领导者，由它来执行本次故障转移。

新Master选举：领导者根据规则（如Slave优先级、复制偏移量、运行ID）从存活的Slave中选出一个最优者。

故障转移执行：

向选出的Slave发送 SLAVEOF NO ONE 命令，将其提升为新的Master。

向其他Slave发送 SLAVEOF 命令，使其复制新的Master。

Sentinel更新自身配置，将监控的主节点指向新的Master。

客户端重定向：当客户端连接旧Master时，会收到一个 -MOVED 或 -ASK 重定向错误，引导其连接新Master。

旧主恢复：原Master恢复上线后，Sentinel会将其自动配置为新Master的Slave。

3.4 Sentinel部署配置详细步骤 (以三个Sentinel为例)

前提：已有一个正常运行的主从集群 (Master:6380, Slaves:6381, 6382)。

步骤1：准备目录

mkdir -p /usr/local/redis/sentinels

cd /usr/local/redis/sentinels && mkdir s1 s2 s3

步骤2：拷贝配置文件

cp /path/to/redis-3.2.9/sentinel.conf ./s1/

cp /path/to/redis-3.2.9/sentinel.conf ./s2/

cp /path/to/redis-3.2.9/sentinel.conf ./s3/

步骤3：修改配置文件 (关键项)

S1 (s1/sentinel.conf):

port 26379

sentinel monitor mymaster 127.0.0.1 6380 2

sentinel down-after-milliseconds mymaster 5000

sentinel failover-timeout mymaster 60000

S2 (s2/sentinel.conf):

port 26380

sentinel monitor mymaster 127.0.0.1 6380 2

... (其他配置同S1)

S3 (s3/sentinel.conf):

port 26381

sentinel monitor mymaster 127.0.0.1 6380 2

... (其他配置同S1)

步骤4：启动Sentinel

打开三个终端，分别执行：

redis-sentinel ./s1/sentinel.conf

redis-sentinel ./s2/sentinel.conf

redis-sentinel ./s3/sentinel.conf

步骤5：测试验证

观察日志：启动后，Sentinel会输出识别到的Master和Slaves信息。

模拟故障：手动停止Master (6380) 进程。

验证切换：观察Sentinel日志，确认其完成了“客观下线”、“选举”、“故障转移”等步骤。使用 redis-cli -p 6381 执行 INFO replication，确认其角色已变为 master。

验证恢复：重新启动原Master (6380)，观察其是否自动变为新Master (6381) 的Slave。

4. 架构总结与最佳实践

4.1 完整演进路径：单点 -> 主从复制 (读写分离/数据备份) -> + Sentinel哨兵 (自动故障转移/高可用)。

4.2 模式对比与定位

主从复制：侧重性能扩展和数据备份。

Sentinel哨兵：侧重高可用和自动故障恢复。

两者结合，构成Redis高可用标准方案。

4.3 生产环境建议

Sentinel部署：应与Redis数据节点部署在不同物理机，避免硬件故障导致同时失效。

数量与配置：Sentinel节点至少3个且为奇数。合理配置 quorum、down-after-milliseconds 和 failover-timeout 参数。

客户端支持：确保应用程序使用的Redis客户端库支持Sentinel协议，能够自动发现和故障切换。

监控告警：对Sentinel和Redis节点的运行状态、日志进行监控，并设置告警。

 Collect

Get Started

高可用技术架构图

 Collect

Get Started

redis高可用

 Collect

Get Started

高可用架构

 Collect

Get Started

Redis哨兵高可用架构





0 条评论

下一页