写点什么

Redis 部署模式详解

  • 2025-07-28
    福建
  • 本文字数:4358 字

    阅读完需:约 14 分钟

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 yesappendfilename "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. 整体架构



组成部分:

(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)。


交互流程:



3. 配置方法


(1)主节点配置(redis-master.conf

bind 0.0.0.0requirepass yourpasswordmasterauth yourpassword  # 从节点访问主节点的密码
复制代码


(2)从节点配置(redis-replica.conf

bind 0.0.0.0requirepass yourpasswordreplicaof 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
# 启动 Sentinelredis-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. 整体架构



组成部分:

(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.0cluster-enabled yes               # 启用集群模式cluster-config-file nodes-6379.conf  # 集群节点配置文件cluster-node-timeout 15000        # 节点超时时间(15 秒)requirepass yourpassword          # 集群密码masterauth yourpassword           # 主节点间认证密码
复制代码


(2)启动所有节点

redis-server /path/to/redis-6379.confredis-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 yourpassword127.0.0.1:6379> CLUSTER INFO127.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.gitcd redis-cluster-proxymake./src/redis-cluster-proxy -c proxy.conf
复制代码


(2) 配置文件 proxy.conf

# 绑定端口bind 0.0.0.0port 7777
# 后端 Redis Cluster 节点cluster-node-timeout 5000cluster 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 的高可用与水平扩展,整体架构如下:



负载均衡层:

(1)作用:

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

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


(2)配置示例(以 HAProxy 为例):

frontend redis-proxy    bind *:6379    mode tcp    default_backend proxy_servers
backend proxy_servers mode tcp balance roundrobin server proxy1 192.168.1.100:7777 check inter 2s server proxy2 192.168.1.101:7777 check inter 2s
复制代码


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



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


五、总结与建议


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


文章转载自:曾左

原文链接:https://www.cnblogs.com/zengzuo613/p/18995048

体验地址:http://www.jnpfsoft.com/?from=001YH

用户头像

还未添加个人签名 2025-04-01 加入

还未添加个人简介

评论

发布
暂无评论
Redis 部署模式详解_redis_电子尖叫食人鱼_InfoQ写作社区