当前位置： 首页 > news >正文

Redis 部署模式详解

news 2025/7/29 13:12:08

Redis 支持多种部署模式，主要包括单机模式（Single）、哨兵模式（Sentinel）、集群模式（Cluster）及增强代理集群，分别适用于不同场景，以下是它们的详细介绍。以下说明仅适用于 Redis 7.0+。

一、单机模式（Single）

1. 简介

（1）最简单的部署方式，仅运行单个 Redis 实例。

（2）无高可用性，如果实例崩溃，服务不可用。

（3）适用场景：开发环境。

2. 配置方法

（1）修改 redis.conf

# 绑定 IP（默认仅本地访问）
bind 0.0.0.0  # 允许远程访问# 设置密码（可选）
requirepass yourpassword# 持久化配置（默认启用 RDB）
save 900 1      # 15 分钟内至少 1 次修改则保存
save 300 10     # 5 分钟内至少 10 次修改则保存
save 60 10000   # 1 分钟内至少 10000 次修改则保存# 启用 AOF（可选）
appendonly yes
appendfilename "appendonly.aof"

（2）启动 Redis

redis-server /path/to/redis.conf

（3）客户端连接

redis-cli -h 127.0.0.1 -p 6379 -a yourpassword

二、哨兵模式（Sentinel）

1. 简介

（1）整体设计：主从架构 + 自动故障转移，提供高可用性（HA）。

（2）部署方式：1 个主节点（Master） + N 个从节点（Replica）+ M 个 Sentinel 节点。

（3）适用场景：需要高可用但不需要数据分片（水平扩展）的场景。

2. 整体架构

20250708_d6255e

组成部分：

（1）1 个主节点（Master）：负责写入和数据存储。

（2）N 个从节点（Replica）：复制主节点数据，提供读能力。

（3）M 个哨兵节点（Sentinel）：监控主从状态，触发故障转移。

执行流程：

（1）监控（Monitoring）

  • 每个 Sentinel 定期检查 Master 和 Replica 是否存活（默认每秒 1 次）。

  • 若 Master 未响应超过 down-after-milliseconds（如 30 秒），Sentinel 标记其为 主观下线（SDOWN）。

（2）选举（Leader Election）

  • 当多数 Sentinel（>= quorum 配置值）确认 Master 下线，标记为 客观下线（ODOWN）。

  • Sentinel 集群通过 Raft 协议选举一个 Leader Sentinel 来执行故障转移。

（3）故障转移（Failover）

  • Leader Sentinel 选择一个最优的 Replica 提升为新的 Master。

  • 通知其他 Replica 复制新 Master。

  • 更新客户端连接信息（通过 +switch-master 事件通知）。

（4）客户端重定向

  • 客户端通过 Sentinel 获取最新的 Master 地址（如 SENTINEL get-master-addr-by-name mymaster）。

交互流程：

20250708_6143eb

3. 配置方法

（1）主节点配置（redis-master.conf）

bind 0.0.0.0
requirepass yourpassword
masterauth yourpassword  # 从节点访问主节点的密码

（2）从节点配置（redis-replica.conf）

bind 0.0.0.0
requirepass yourpassword
replicaof 127.0.0.1 6379  # 指向主节点
masterauth yourpassword   # 主节点密码

（3）哨兵配置（sentinel.conf）

sentinel monitor mymaster 127.0.0.1 6379 2  # 监控主节点，2 表示至少 2 个 Sentinel 同意才触发故障转移
sentinel auth-pass mymaster yourpassword    # 主节点密码
sentinel down-after-milliseconds mymaster 5000  # 5 秒无响应视为下线
sentinel failover-timeout mymaster 60000   # 故障转移超时时间（60 秒）

（4）启动服务

# 启动主节点
redis-server redis-master.conf# 启动从节点
redis-server redis-replica.conf# 启动 Sentinel
redis-sentinel sentinel.conf

（5）验证故障转移

# 查看主从信息
redis-cli -p 6379 INFO replication# 手动关闭主节点，观察 Sentinel 日志
tail -f /var/log/redis/sentinel.log

（6）客户端配置示例

无需配置全部 Sentinel 地址：客户端只需连接任意一个正常工作的 Sentinel 即可获取集群状态（Sentinel 之间通过 Gossip 协议自动同步信息）。

推荐配置多个 Sentinel 地址：仅用于容灾，避免某个 Sentinel 不可用时客户端无法初始化。

Set<String> sentinels = new HashSet<>();
sentinels.add("sentinel1:26379"); // 只需 1 个 Sentinel 即可工作
sentinels.add("sentinel2:26379"); // 额外添加用于容灾
sentinels.add("sentinel3:26379"); // 非必须，但建议JedisSentinelPool pool = new JedisSentinelPool("mymaster", sentinels);

4. 特点

（1）高可用：Sentinel 确保主节点故障时自动切换。

（2）无分片：仅解决 HA 问题，不扩展写性能。

（3）最少 3 节点：建议部署 3 个 Sentinel 以避免脑裂问题。

三、集群模式（Cluster）

1. 简介

（1）整体设计：支持主从实现高可用，将数据分片到 16384 个槽（Slot），每个节点负责部分槽，已实现水平扩展。

（2）适用场景：大数据量、高并发、需要横向扩展的场景。

2. 整体架构

20250708_676ba3

组成部分：

（1）Master 节点（主节点）

  • 负责处理客户端读写请求。

  • 管理分配的哈希槽（Slot）范围（如 Slots 0-5460）。

  • 通过 Gossip 协议 与其他节点交换集群状态信息。

（2）Slave 节点（从节点）

  • 异步复制对应 Master 的数据（通过 -->|Replication| 箭头表示）。

  • 当 Master 故障时，Slave 可自动晋升为新的 Master（故障转移）。

  • 可处理读请求（需客户端配置 READONLY）。

（3）通信协议

  • 节点间通过 Gossip 协议（PING/PONG 消息）交换集群拓扑、槽分配、节点状态等信息。

数据机制：

（1）哈希槽（Slots）分布

  • Redis Cluster 将所有数据划分为 16384 个槽位，每个 Master 负责一部分槽范围（如 0-5460）。

  • 客户端通过 CRC16(key) mod 16384 计算键所属的槽位。

（2）Move 重定向

  • 若客户端访问的键不属于当前连接的节点，节点会返回 MOVED 错误并指引正确节点。

3. 配置方法

（1）修改 redis.conf（每个节点）

bind 0.0.0.0
cluster-enabled yes               # 启用集群模式
cluster-config-file nodes-6379.conf  # 集群节点配置文件
cluster-node-timeout 15000        # 节点超时时间（15 秒）
requirepass yourpassword          # 集群密码
masterauth yourpassword           # 主节点间认证密码

（2）启动所有节点

redis-server /path/to/redis-6379.conf
redis-server /path/to/redis-6380.conf

（3）创建集群

# 6 个节点（3 主 3 从）
redis-cli --cluster create \127.0.0.1:6379 127.0.0.1:6380 127.0.0.1:6381 \127.0.0.1:6382 127.0.0.1:6383 127.0.0.1:6384 \# --cluster-replicas 1 表示每个主节点有 1 个从节点--cluster-replicas 1 -a yourpassword

（4）验证集群状态

redis-cli -c -p 6379 -a yourpassword
127.0.0.1:6379> CLUSTER INFO
127.0.0.1:6379> CLUSTER NODES

（5）客户端配置示例

支持集群协议：客户端需实现 Redis Cluster 的 MOVED/ASK 重定向逻辑（主流客户端库已内置支持）。

种子节点配置：只需配置集群中任意 1-2 个节点地址（客户端会自动发现其他节点）。

认证信息：若集群启用密码，需统一所有节点的密码。

public class RedisClusterExample {public static void main(String[] args) {// 1. 配置至少一个集群节点地址（多个更容错）Set<HostAndPort> nodes = new HashSet<>();nodes.add(new HostAndPort("127.0.0.1", 6379));nodes.add(new HostAndPort("127.0.0.1", 6380));// 2. 创建集群连接（带密码）JedisCluster jedisCluster = new JedisCluster(nodes, 2000, 2000, 5, "yourpassword");// 3. 执行命令（自动处理重定向）jedisCluster.set("foo", "bar");String value = jedisCluster.get("foo");System.out.println(value); // 输出 "bar"// 4. 关闭连接jedisCluster.close();}
}

4. 特点

（1）在 Redis Cluster 中，扩充主节点时，必须重新分配槽（Slots），这是由集群的分布式数据分片机制决定的。

（2）节点故障时，槽是否要重新分配，具体场景如下：

四、增强代理集群模式

上述三种部署模式特点如下：

在实际生产环境中，推荐采用 Redis 集群模式（Cluster）部署，以确保集群高可用（主从）与水平扩展（数据分片），但该模式存在客户端配置繁琐、无法兼容历史配置等问题，所以官方推出了 Redis Cluster Proxy，旨在简化客户端与 Redis Cluster 的交互，它允许客户端像连接单节点 Redis 一样访问 Redis Cluster，无需处理 MOVED/ASK 重定向和集群拓扑变更。

1. Redis Cluster Proxy 核心功能

（1）透明集群访问

  • 客户端无需感知集群拓扑，Proxy 自动处理请求路由和重定向。

  • 兼容标准 Redis 协议，支持所有单节点命令（除部分集群管理命令如 CLUSTER）。

（2）连接池管理

  • 复用后端连接，减少客户端与多个节点直接建连的开销。

（3）协议兼容性

  • 支持旧版 Redis 客户端（如仅支持单节点模式的 SDK）。

（4）性能较好

  • 基于 C 开发，性能损耗低（官方测试延迟增加约 10%）。

2. Redis Cluster Proxy 配置方法

(1) 安装 Redis Cluster Proxy

# 从官方仓库编译安装
git clone https://github.com/RedisLabs/redis-cluster-proxy.git
cd redis-cluster-proxy
make
./src/redis-cluster-proxy -c proxy.conf

(2) 配置文件 proxy.conf

# 绑定端口
bind 0.0.0.0
port 7777# 后端 Redis Cluster 节点
cluster-node-timeout 5000
cluster 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003

(3) 启动 Proxy

./src/redis-cluster-proxy -c proxy.conf

3. Redis Cluster Proxy 部署增强

实际部署 Proxy 时，为确保整个系统高可用，应部署多个 Proxy 实例，通过 HAProxy（或 LVS、Envoy）实现 Proxy 的高可用与水平扩展，整体架构如下：

20250709_e99ed5

负载均衡层：

（1）作用：

  • 将请求分发到多个 Proxy 实例（轮询/最小连接数）。

  • 健康检查自动剔除故障 Proxy。

（2）配置示例（以 HAProxy 为例）：

frontend redis-proxybind *:6379mode tcpdefault_backend proxy_serversbackend proxy_serversmode tcpbalance roundrobinserver proxy1 192.168.1.100:7777 check inter 2sserver proxy2 192.168.1.101:7777 check inter 2s

为保证 HAProxy 的高可用，我们一般会部署两套 HAProxy，通过 Keepalived 互为主备，即增强代理集群，整体架构如下：

20250708_d6255e

该集群具备 Redis Cluster 的高可用与水平扩展能力，以及 Redis Cluster Proxy 的透明访问特性（兼容历史配置，简化客户端调用）。此外，借助 Keepalived 和 HAProxy（或 LVS、Envoy），实现 Redis Cluster Proxy 节点及集群的高可用，同时简化了集群调用代码的配置复杂度。

五、总结与建议

哨兵模式不支持水平扩展，且与集群模式一样，存在与客户端配置代码强耦合，难以兼容历史配置，无法实现透明访问等问题。因此在实际使用中，推荐采用 Keepalived + HAProxy（LVS 或 Envoy） + Redis Cluster Proxy + Redis Cluster 增强代理集群模式部署，以实现集群高可用、水平扩展、透明访问及兼容历史配置等必要功能。

文章转载自：曾左

原文链接：Redis 部署模式详解 - 曾左 - 博客园

体验地址：JNPF快速开发平台

http://www.lryc.cn/news/602879.html

相关文章：

  • NBIOT模块 BC28通过MQTT协议连接到电信云
  • 【大模型LLM】梯度累积（Gradient Accumulation）原理详解
  • 微服务架构中 gRPC 的应用
  • Rust 最短路径、Tide、Partial、Yew、Leptos、数独实践案例
  • Hugging Face-环境配置
  • 洛谷 P10448 组合型枚举-普及-
  • HTML响应式SEO公司网站源码
  • 归雁思维：解锁自然规律与人类智慧的桥梁
  • 疯狂星期四文案网第22天运营日记
  • CFIHL: 水培生菜的多种叶绿素 a 荧光瞬态图像数据集
  • 递归算法的一些具体应用
  • TDSQL 技术详解
  • go‑cdc‑chunkers：用 CDC 实现智能分块 强力去重
  • Apache Ignite 的 JDBC Client Driver（JDBC 客户端驱动）
  • 利用frp实现内网穿透功能（服务器）Linux、（内网）Windows
  • OpenGL进阶系列22 - OpenGL SuperBible - bumpmapping 例子学习
  • 短剧系统开发上线全流程攻略：从架构设计到性能优化
  • 页面性能优化
  • Go性能优化深度指南：从原理到实战
  • C++-关于协程的一些思考
  • Linux 远程连接与文件传输：从基础到高级配置
  • 多系统集成前端困境：老旧工控设备与新型Web应用的兼容性突围方案
  • Docker笔记（基本命令、挂载本地gpu、Dockerfile文件配置、数据挂载、docker换源）
  • 3Dmax模型位置归零
  • [机缘参悟-237]：AI人工神经网络与人类的神经网络工作原理的相似性
  • Java项目：基于SSM框架实现的进销存管理系统【ssm+B/S架构+源码+数据库+毕业论文+远程部署】
  • Java Collections工具类
  • Mac查看本机ip地址
  • 【密码学】3. 流密码
  • 互信息：理论框架、跨学科应用与前沿进展