Docker 搭建 Redis 主从哨兵集群：高可用架构实战

Redis 这玩意儿，单机跑起来确实爽，一条docker run就完事。但真到了线上环境，单点故障就是悬在头顶的刀——主节点一挂，整个缓存层直接雪崩，数据库瞬间被流量打穿。我见过太多团队在这个问题上栽跟头，平时不觉得，出事就是 P0 级事故。所以今天聊的这套Docker 搭建 Redis 主从加哨兵集群的方案，本质上解决的就是三个问题：数据热备份、读流量分摊、故障自动切换。适合谁看？手里有台 4G 内存以上的开发机或测试服务器，想在生产环境之前把高可用架构跑通的后端开发、运维同学。如果你还在用单机 Redis 扛线上流量，这篇文章建议逐字看完。

1. 为什么单机 Redis 不够用

1.1 单点故障的真实代价

先算一笔账。假设你的服务 QPS 是 5000，其中 80% 的请求要查 Redis，也就是每秒 4000 次缓存读取。Redis 单机撑这个量级毫无压力，但问题是——它挂了怎么办？所有请求瞬间穿透到 MySQL，数据库连接池在几秒内被打满，然后整个服务不可用。从 Redis 进程崩溃到业务全面瘫痪，中间可能只有 10 到 30 秒的窗口期。

有人会说，那我加个重启脚本不就行了？docker restart确实能拉起来，但重启期间的数据丢失呢？如果没开 AOF 持久化，内存里的数据全没了，缓存击穿带来的连锁反应比 Redis 本身挂掉更可怕。而且重启需要时间，冷启动加载 RDB 文件，几个 G 的数据可能要几十秒，这段时间业务就是裸奔状态。

所以单机 Redis 的问题不是"会不会挂"，而是"挂了之后怎么办"。主从复制解决数据备份问题，哨兵解决自动切换问题，两者结合才是完整的高可用方案。

1.2 主从复制到底复制了什么

Redis 的主从复制不是简单的文件拷贝，它有一套完整的同步机制。当你在一台从节点上执行REPLICAOF命令后，会发生这么几件事：

从节点先和主节点建立连接，发送PSYNC命令。如果是第一次同步，主节点会执行BGSAVE生成 RDB 快照文件，同时把生成期间的新写命令缓存到缓冲区。RDB 文件传输完毕后，从节点加载快照，然后主节点把缓冲区里的命令补发给从节点。这之后，主节点每执行一条写命令，都会异步传播给所有从节点。

这个过程有个关键点：主从复制是异步的。也就是说，主节点写入成功返回给客户端时，从节点可能还没收到这条命令。如果主节点在这瞬间挂了，这条数据就丢了。这不是 bug，是设计取舍——Redis 优先保证性能和可用性，不保证强一致。理解这一点，后面配置哨兵的时候才知道为什么会有数据丢失窗口。

1.3 哨兵的核心职责

哨兵（Sentinel）本身也是一个 Redis 进程，但它不存储数据，只做三件事：监控、通知、自动故障转移。

监控是指哨兵持续向主节点和从节点发送PING命令，如果在down-after-milliseconds时间内没收到有效回复，就主观认为这个节点挂了（主观下线）。但一个哨兵说挂了不算数，需要多个哨兵都认为它挂了，才判定为客观下线。这个"多个"的数量由quorum参数决定。

确认主节点客观下线后，哨兵们会选举出一个领导者哨兵，由它来执行故障转移：从所有从节点中挑一个最合适的升级为主节点，然后让其他从节点指向新主节点，最后通知客户端新的主节点地址。整个过程自动完成，不需要人工干预。

注意：哨兵集群本身也建议部署奇数个节点，最少 3 个。2 个哨兵的话，挂一个就剩一个，无法形成多数派，故障转移就失效了。

2. 集群架构设计与目录规划

2.1 节点角色分配

这套方案我建议用 6 个容器来跑：1 个主节点、2 个从节点、3 个哨兵节点。为什么从节点要 2 个？因为哨兵选举新主节点时，需要从节点有足够的"资历"——数据越新、优先级越高的从节点越容易被选中。2 个从节点既保证了冗余，又不会浪费太多资源。

哨兵 3 个是为了满足多数派原则。如果只部署 2 个哨兵，当其中一个网络抖动时，剩下的 1 个无法独立完成客观下线判定（quorum 通常设为 2），故障转移就会卡住。3 个哨兵允许挂掉 1 个，系统仍能正常工作。

端口映射到宿主机时，我习惯用 6379/6380/6381 对应三个 Redis 实例，哨兵用 26379/26380/26381。这样从端口号就能一眼看出角色，排查问题时不用翻文档。

2.2 网络模式选择

Docker 网络这块有两种玩法：bridge 模式和host 模式。

bridge 模式是默认选项，每个容器有独立 IP，通过端口映射对外暴露。好处是隔离性好，坏处是哨兵返回给客户端的主节点地址是容器内网 IP，外部客户端拿到这个 IP 根本连不上。这个问题在跨主机部署时更明显。

host 模式让容器直接使用宿主机网络，没有 NAT 转换，哨兵返回的地址就是宿主机真实 IP，客户端可以直接连接。缺点是端口不能冲突，一台机器上只能跑一套。对于开发和测试环境，我强烈建议用 host 模式，省去大量网络排查的麻烦。

如果你非要用 bridge 模式，也不是不行，但需要额外配置announce-ip和announce-port，让哨兵对外通告宿主机 IP 而不是容器 IP。这个配置后面会详细说。

2.3 目录结构规划

在宿主机上建一个统一的工作目录，比如/opt/redis-cluster，下面按节点分目录：

/opt/redis-cluster/ ├── master/ │ ├── conf/ │ │ └── redis.conf │ └── data/ ├── slave1/ │ ├── conf/ │ │ └── redis.conf │ └── data/ ├── slave2/ │ ├── conf/ │ │ └── redis.conf │ └── data/ ├── sentinel1/ │ ├── conf/ │ │ └── sentinel.conf │ └── data/ ├── sentinel2/ │ ├── conf/ │ │ └── sentinel.conf │ └── data/ └── sentinel3/ ├── conf/ │ └── sentinel.conf └── data/

每个节点独立目录的好处是数据隔离，删掉某个节点的 data 目录就能重置它的状态，不影响其他节点。配置文件也分开管理，改哪个节点的参数一目了然。

3. 主从节点配置与启动

3.1 主节点配置文件详解

先写主节点的redis.conf，放在/opt/redis-cluster/master/conf/下：

# 网络配置 bind 0.0.0.0 port 6379 protected-mode no # 通用配置 daemonize no pidfile /var/run/redis_6379.pid logfile "" loglevel notice databases 16 # 持久化配置 save 900 1 save 300 10 save 60 10000 appendonly yes appendfilename "appendonly.aof" appendfsync everysec # 主从配置 replica-read-only yes repl-diskless-sync yes repl-diskless-sync-delay 5 # 安全配置 requirepass "Redis@2024Master" masterauth "Redis@2024Master" # 客户端配置 timeout 0 tcp-keepalive 300 maxclients 10000

逐条解释几个关键参数。bind 0.0.0.0是让 Redis 监听所有网卡，容器内必须这么设，否则外部连不上。protected-mode no关闭保护模式，配合密码使用。appendonly yes开启 AOF 持久化，这是主从复制之外的第二层数据保障。

repl-diskless-sync yes是个重要优化。传统的主从同步是主节点先把 RDB 写到磁盘，再读出来发给从节点。磁盘 IO 慢的时候，这个步骤可能耗时几秒甚至十几秒。无盘同步直接把 RDB 通过网络发给从节点，省掉磁盘读写，同步速度提升明显。repl-diskless-sync-delay 5是等待 5 秒再开始同步，目的是让多个从节点尽量在同一批次完成，避免重复生成 RDB。

masterauth这个参数容易被忽略。当主节点设置了密码，从节点连接主节点时必须提供密码，否则同步会失败。很多人配了requirepass却忘了masterauth，结果从节点一直连不上主节点，日志里报NOAUTH Authentication required。

3.2 从节点配置差异

从节点的配置和主节点基本一致，只需要改端口和加一行replicaof：

# 从节点1的配置差异部分 port 6380 replicaof redis-master 6379 masterauth "Redis@2024Master"

replicaof指定主节点的地址和端口。在 Docker 自定义网络中，可以直接用容器名redis-master作为主机名，Docker 内置的 DNS 会解析到对应容器 IP。如果用 host 网络模式，这里要写宿主机的真实 IP。

从节点的replica-read-only yes表示从节点只接受读请求，写请求会返回错误。这是默认行为，不建议改成 no，否则主从数据可能不一致。

3.3 启动脚本与容器编排

用docker run逐个启动容器太繁琐，我习惯写一个docker-compose.yml统一管理：

version: '3.8' services: redis-master: image: redis:7.2-alpine container_name: redis-master network_mode: host volumes: - ./master/conf/redis.conf:/usr/local/etc/redis/redis.conf - ./master/data:/data command: redis-server /usr/local/etc/redis/redis.conf restart: always redis-slave1: image: redis:7.2-alpine container_name: redis-slave1 network_mode: host volumes: - ./slave1/conf/redis.conf:/usr/local/etc/redis/redis.conf - ./slave1/data:/data command: redis-server /usr/local/etc/redis/redis.conf depends_on: - redis-master restart: always redis-slave2: image: redis:7.2-alpine container_name: redis-slave2 network_mode: host volumes: - ./slave2/conf/redis.conf:/usr/local/etc/redis/redis.conf - ./slave2/data:/data command: redis-server /usr/local/etc/redis/redis.conf depends_on: - redis-master restart: always

选redis:7.2-alpine这个镜像有两个原因：7.2 版本对哨兵和集群的支持更成熟，alpine 基础镜像体积小，启动快。restart: always保证容器异常退出后自动重启，配合哨兵的故障转移形成双重保障。

启动命令：

cd /opt/redis-cluster docker-compose up -d redis-master redis-slave1 redis-slave2

启动后验证主从状态：

# 在主节点上查看复制信息 docker exec -it redis-master redis-cli -a Redis@2024Master info replication

输出中应该看到role:master和connected_slaves:2。如果connected_slaves是 0，说明从节点没连上，去从节点日志里找原因。

4. 哨兵集群配置与故障转移验证

4.1 哨兵配置文件编写

哨兵的配置文件比 Redis 简单得多，但有几个参数必须配对。以 sentinel1 为例：

port 26379 daemonize no protected-mode no logfile "" dir /data sentinel monitor mymaster 127.0.0.1 6379 2 sentinel auth-pass mymaster Redis@2024Master sentinel down-after-milliseconds mymaster 5000 sentinel failover-timeout mymaster 60000 sentinel parallel-syncs mymaster 1

sentinel monitor mymaster 127.0.0.1 6379 2这行是核心。mymaster是集群名称，可以自定义，但所有哨兵必须用同一个名字。127.0.0.1 6379是主节点地址，host 网络模式下写本地回环地址即可。最后的2是 quorum 值，表示至少 2 个哨兵认为主节点下线，才触发客观下线判定。

sentinel auth-pass是哨兵连接 Redis 节点的密码。如果主节点有密码而从节点没有，这里配的密码会同时用于连接主从节点。所以建议主从节点用同一个密码，省去额外配置。

down-after-milliseconds 5000表示 5 秒内没收到 PING 回复就判定主观下线。这个值不能太小，网络抖动可能导致误判；也不能太大，否则故障发现太慢。5 秒是个比较平衡的选择。

failover-timeout 60000是故障转移的超时时间。如果一次故障转移在 60 秒内没完成，哨兵会认为这次转移失败，重新发起。这个值要大于down-after-milliseconds，否则还没判定下线就超时了。

4.2 哨兵启动与集群发现

哨兵的 docker-compose 配置：

redis-sentinel1: image: redis:7.2-alpine container_name: redis-sentinel1 network_mode: host volumes: - ./sentinel1/conf/sentinel.conf:/usr/local/etc/redis/sentinel.conf - ./sentinel1/data:/data command: redis-sentinel /usr/local/etc/redis/sentinel.conf depends_on: - redis-master - redis-slave1 - redis-slave2 restart: always

注意启动命令是redis-sentinel而不是redis-server。虽然哨兵本质上也是 Redis 进程，但用redis-sentinel启动会自动加载哨兵模式。

三个哨兵启动后，它们会自动发现彼此。原理是哨兵会向主节点的__sentinel__:hello频道发布自己的信息，其他哨兵订阅这个频道后就能感知到新哨兵的存在。所以只要三个哨兵都监控同一个主节点，它们最终会组成一个集群。

验证哨兵集群状态：

docker exec -it redis-sentinel1 redis-cli -p 26379 sentinel master mymaster

输出中关注这几个字段：num-other-sentinels应该是 2，表示发现了另外两个哨兵；flags应该是master，表示主节点正常；num-slaves应该是 2。

4.3 手动触发故障转移

配置完成后必须做一次故障转移测试，否则真出事的时候你都不知道这套机制能不能用。测试方法很简单：把主节点容器停掉。

docker stop redis-master

然后观察哨兵日志：

docker logs -f redis-sentinel1

正常情况下，5 秒后哨兵会输出+sdown master mymaster（主观下线），接着另外两个哨兵也确认后输出+odown master mymaster（客观下线）。然后进入选举流程，选出领导者哨兵后开始故障转移，日志会显示+failover-state-select-slave、+selected-slave、+failover-state-send-slaveof-noone等状态变化。

最终看到+switch-master mymaster 127.0.0.1 6379 127.0.0.1 6380，表示主节点从 6379 切换到了 6380。这时候用客户端连接哨兵查询新主节点：

docker exec -it redis-sentinel1 redis-cli -p 26379 sentinel get-master-addr-by-name mymaster

返回的应该是127.0.0.1和6380。

注意：故障转移完成后，原来的主节点如果重新启动，它会自动变成新主节点的从节点。这是哨兵的自动重配置机制，不需要手动干预。但前提是原主节点的配置里没有写死replicaof，否则会形成双主。

4.4 客户端如何连接哨兵集群

Java 应用用 Jedis 连接哨兵集群的代码大概长这样：

Set<String> sentinels = new HashSet<>(); sentinels.add("127.0.0.1:26379"); sentinels.add("127.0.0.1:26380"); sentinels.add("127.0.0.1:26381"); JedisSentinelPool pool = new JedisSentinelPool("mymaster", sentinels, "Redis@2024Master"); Jedis jedis = pool.getResource(); jedis.set("key", "value");

关键点是客户端要配置所有哨兵地址，而不是只配一个。这样即使某个哨兵挂了，客户端仍能通过其他哨兵获取最新的主节点信息。Jedis 内部会监听哨兵的切换事件，主节点变更后自动更新连接池。

Python 的 redis-py 类似：

from redis.sentinel import Sentinel sentinel = Sentinel([ ('127.0.0.1', 26379), ('127.0.0.1', 26380), ('127.0.0.1', 26381) ], socket_timeout=0.5) master = sentinel.master_for('mymaster', password='Redis@2024Master') master.set('key', 'value')

5. 踩坑记录与排查手册

5.1 从节点一直连不上主节点

这是最常见的问题，日志里通常报Unable to connect to MASTER或NOAUTH。排查顺序如下：

先确认主节点密码和从节点的masterauth是否一致。很多人主节点设了密码，从节点忘了配masterauth，或者密码里有特殊字符导致解析错误。建议密码用字母数字加简单符号，避免#、空格这类容易出问题的字符。

再确认网络连通性。host 模式下，从节点配置里的replicaof地址如果是127.0.0.1，那主从必须在同一台机器上。跨机器部署要写真实 IP。用docker exec redis-slave1 ping redis-master测试容器间连通性，ping 不通就是网络问题。

最后看主节点是否开启了protected-mode。如果主节点是protected-mode yes且没有密码，从节点从外部连接会被拒绝。要么关保护模式，要么设密码，二选一。

5.2 哨兵无法完成故障转移

哨兵日志显示+odown但迟迟不切换，通常是这几个原因：

quorum 值设置不合理。如果只有 2 个哨兵，quorum 设成 2，那挂掉一个哨兵后就永远无法达到 quorum，故障转移卡死。哨兵数量建议 3 个，quorum 设 2，允许挂 1 个。

failover-timeout太短。故障转移涉及选举、选从节点、重配置等多个步骤，如果超时时间设成 10 秒，可能刚选完领导者就超时了。建议至少 60 秒。

从节点数据太旧。哨兵选新主节点时会优先选数据最新的从节点。如果所有从节点都落后主节点太多，哨兵可能认为没有合适的候选者。检查从节点的master_link_status是否为up，master_last_io_seconds_ago是否在合理范围内。

5.3 故障转移后客户端连不上新主节点

这个问题几乎都是网络模式导致的。bridge 模式下，哨兵返回的新主节点地址是容器内网 IP（比如 172.17.0.5），客户端在宿主机或外部网络根本访问不到这个 IP。

解决方案有两个：一是改用 host 网络模式，哨兵返回的就是宿主机 IP；二是配置sentinel announce-ip和sentinel announce-port，强制哨兵对外通告指定地址。

sentinel announce-ip 192.168.1.100 sentinel announce-port 6379

这样哨兵在通知客户端时，会用192.168.1.100:6379而不是容器内网地址。但注意，如果主节点切换到了另一个容器，端口可能变化，announce-port需要动态调整，比较麻烦。所以还是推荐 host 模式。

5.4 数据丢失窗口有多大

前面说过主从复制是异步的，故障转移时必然有数据丢失。丢失的量取决于两个因素：主从延迟和故障检测时间。

假设主从延迟是 10ms，故障检测时间是 5 秒，那最坏情况下丢失 5 秒内写入的数据。如果业务对数据一致性要求极高，可以考虑WAIT命令，强制等待至少 N 个从节点确认后才返回。但这会显著增加写入延迟，一般缓存场景不建议用。

5.5 哨兵配置文件被自动重写

哨兵在运行过程中会动态修改自己的配置文件，比如发现新哨兵、切换主节点后，都会把最新状态写回sentinel.conf。如果你把配置文件挂载为只读，哨兵会报错退出。

所以挂载哨兵配置时不要加:ro，让容器有写权限。另外，哨兵重写配置后，你手动改的内容可能被覆盖。建议初始配置只写必要参数，后续调整通过sentinel set命令动态修改。

6. 生产环境加固建议

6.1 资源限制与监控

Docker 容器默认不限制资源，Redis 可能吃光宿主机内存导致 OOM。建议在 docker-compose 里加上限制：

deploy: resources: limits: memory: 2G reservations: memory: 512M

同时配置 Redis 的maxmemory和maxmemory-policy。缓存场景建议用allkeys-lru，让 Redis 在内存满时淘汰最久未使用的键，而不是直接报错。

监控方面，哨兵的INFO命令输出包含大量有用信息。重点看sentinel_masters、sentinel_tilt、sentinel_running_scripts这几个指标。sentinel_tilt为 1 表示哨兵进入了 TILT 模式，此时它的判断可能不准确，需要排查原因（通常是系统负载过高或时间跳变）。

6.2 密码管理与安全加固

配置文件里明文写密码不是好习惯。生产环境建议用环境变量注入，或者用 Docker secret 管理。至少要把配置文件权限设为 600，避免其他用户读取。

chmod 600 /opt/redis-cluster/*/conf/*.conf

另外，Redis 的rename-command可以重命名危险命令，比如FLUSHALL、CONFIG、KEYS。虽然有点掩耳盗铃，但能挡住大部分误操作和低级攻击。

rename-command FLUSHALL "" rename-command CONFIG "CONFIG_9f8a7b6c"

空字符串表示禁用该命令。CONFIG重命名后，客户端需要用新名字调用，记得同步更新运维脚本。

6.3 定期演练与配置备份

故障转移机制最怕的是"配了但没测过"。建议每月至少做一次演练：随机停掉一个节点，观察哨兵是否正常切换，客户端是否自动重连。演练记录要存档，包括切换耗时、数据丢失量、异常日志。

配置文件也要定期备份。哨兵会动态重写配置，如果某次重写出了问题（比如磁盘满导致写入失败），配置文件可能损坏。备份时把三个哨兵的配置一起打包，恢复时整体还原。

我在实际运维中养成了一个习惯：每次变更配置前，先docker cp把当前配置拷出来存一份，变更后对比差异。这个习惯帮我定位过好几次"配置漂移"问题——某个节点的配置被手动改过，和版本库里的不一致，导致行为异常。

6.4 扩展方向

这套主从加哨兵的架构撑个几万 QPS 没问题，但如果数据量继续增长，单主节点的写入能力会成为瓶颈。下一步可以考虑 Redis Cluster 分片集群，把数据分散到多个主节点上。不过 Cluster 的运维复杂度比哨兵高不少，槽位迁移、节点扩缩容都需要专门工具，建议先把哨兵这套跑稳了再考虑。

另一个方向是读写分离的精细化。目前从节点默认只读，但客户端需要自己决定哪些请求走主节点、哪些走从节点。可以在客户端 SDK 层面封装，写操作走主节点，读操作按权重轮询从节点。这样能进一步分摊主节点压力。

最后再分享一个小技巧：哨兵的sentinel parallel-syncs参数控制故障转移后同时向新主节点发起同步的从节点数量。设成 1 表示逐个同步，避免新主节点被多个从节点的全量同步请求打垮。如果从节点数据量很大，这个值千万别设大，否则新主节点刚上任就被同步流量压死，引发二次故障。