使用Bitnami镜像部署Redis哨兵模式：高可用架构实战

1. 为什么用 Bitnami 镜像部署 Redis 哨兵模式先说结论如果你需要在 Docker 或 Kubernetes 里快速搭一套高可用的 Redis用 Bitnami 的 redis-sentinel 镜像可能是目前最省事的方案。我前后踩过不少坑从裸装 Redis 到自写哨兵配置再到后来切到 Bitnami 镜像对比下来这个镜像把哨兵模式的复杂度基本封装掉了你只需要关心几个环境变量剩下的主从切换、哨兵选举、配置同步它都帮你处理了。哨兵模式解决的是什么问题Redis 单机部署一旦宕机缓存全部失效轻则接口变慢重则直接把数据库打挂。主从复制能解决读压力但主节点挂了从节点不会自动顶上需要人工干预。哨兵Sentinel就是干这个事的监控主节点健康状态发现主节点挂了自动从从节点里选一个提升为新主节点再把其他从节点的复制目标切过去整个过程应用无感知。这就是 Redis 高可用的基础形态。Bitnami 提供的 redis-sentinel 镜像跟官方 redis 镜像不一样官方镜像只给了 Redis 本体哨兵要自己配 sentinel.conf还得管理一堆配置文件。Bitnami 镜像把 Redis 和 Sentinel 拆成两个独立组件用环境变量控制镜像内部有脚本自动生成配置。最直观的好处标准化的环境变量、内置健康检查、支持 Kubernetes 的 statefulset 部署模式。我第一次用的时候照着文档配了一遍主从加哨兵三节点前后不到半小时就跑起来了。这个镜像适合谁适合已经在用 Docker Compose 或 Kubernetes 的人想快速搭建开发或测试环境的 Redis 高可用集群不想花太多时间在配置文件上。如果你有自定义哨兵参数、特殊 ACL 需求Bitnami 也提供对应的环境变量不至于锁死。但如果你需要深度定制 Redis 内核或哨兵行为那还是老老实实用官方镜像自己写配置更灵活。2. 部署前的准备工作与镜像选型2.1 环境要求与镜像版本选择先看环境我这里以 Docker Compose 为例Kubernetes 的部署思路类似后面会提。需要 Docker 和 Docker Compose版本不要太老Compose 至少要支持环境变量插值。我用的 Docker 版本是 24.xCompose 是 2.20没遇到兼容问题。如果你用的是 Podman 或者其他容器运行时Bitnami 镜像本身是标准 OCI 镜像理论上也能跑但文档和脚本主要针对 Docker 生态不建议在非 Docker 环境里折腾。镜像选择上Bitnami 的仓库名是bitnami/redis-sentinel但要注意它和bitnami/redis是配套的。不建议混用官方 redis 镜像和 bitnami 哨兵镜像因为 Bitnami 的哨兵会自动发现同网络下的 Redis 节点它依赖 Bitnami Redis 镜像自带的一些标签和网络别名。混用会导致哨兵无法正确识别主从关系排查起来很头疼。我见过有人用redis:7.0做数据节点哨兵用 Bitnami结果哨兵一直报-NOMASTERLINK最后老老实实全换成 Bitnami 了。版本方面建议直接用7.2或者7.4的 tag比如bitnami/redis-sentinel:7.2和bitnami/redis:7.2保持大版本一致。Redis 7.x 在稳定性、性能、ACL 方面都有明显提升现在没必要用 6.x。最新版本可以上 Docker Hub 看但别用latest生产环境一定要锁定精确版本号。2.2 网络拓扑设计一主两从三哨兵哨兵模式的典型拓扑是一个主节点至少两个从节点至少三个哨兵实例。为什么从节点要至少两个因为哨兵判断主节点宕机需要多数派同意三个哨兵里两个以上达成一致才能触发故障转移。如果只有一个从节点主节点挂了从节点提升后没有其他从节点可切新主一旦再挂整个集群就彻底不可用了。两个从节点还能分担读压力也能在故障转移后保持集群的冗余性。三个哨兵是最低要求原因是哨兵自身的可用性。哨兵之间也要互相通信选举 leader 需要多数派三个哨兵允许挂一个两个哨兵挂一个就只剩一个无法形成多数派故障转移就无法自动执行。生产环境建议三节点起步如果资源充裕可以五节点但多数场景三个够了。网络层面我会单独创建一个 Docker 网络让数据节点和哨兵节点都在同一个网络里这样容器之间通过服务名就能互相访问。为什么不直接用默认 bridge因为默认网络下容器名解析有时候不稳定而且 Compose 项目之间隔离性差。用自定义网络更干净也方便以后扩展。下面是一个我常用的网络规划表格角色服务名容器端口用途主节点redis-master6379写请求入口从节点1redis-slave-06379读请求、故障转移候选从节点2redis-slave-16379读请求、故障转移候选哨兵1redis-sentinel-026379监控、选举哨兵2redis-sentinel-126379监控、选举哨兵3redis-sentinel-226379监控、选举注意数据节点和哨兵节点的容器端口都是 6379 和 26379不同容器之间通过服务名访问不需要对外暴露太多端口。如果你要在宿主机上调试可以映射出来但生产环境建议只暴露一个入口比如通过负载均衡指向哨兵或主节点。3. 编写 Docker Compose 配置文件详解3.1 主从节点配置环境变量的核心逻辑这一节是重点中的重点。Bitnami 镜像的配置逻辑几乎全部通过环境变量控制我们需要理解几个关键变量否则写出来的配置会各种报错。先看数据节点的 Compose 配置我直接贴出可用的版本然后逐个解释services: redis-master: image: bitnami/redis:7.2 container_name: redis-master environment: - REDIS_REPLICATION_MODEmaster - REDIS_PASSWORD${REDIS_PASSWORD} - REDIS_MASTER_HOSTredis-master - REDIS_MASTER_PORT_NUMBER6379 - ALLOW_EMPTY_PASSWORDno - REDIS_AOF_ENABLEDyes volumes: - redis-master-data:/bitnami/redis/data networks: - redis-sentinel-net ports: - 6379:6379 restart: unless-stopped核心变量就是REDIS_REPLICATION_MODE这个值只能是master或slave。Bitnami 会根据这个变量决定容器启动时是初始化为主节点还是从节点并自动生成对应的redis.conf。如果你不设置这个变量默认是master但从节点必须显式设成slave否则启动后会以独立主节点身份运行无法跟主节点建立复制关系。REDIS_PASSWORD是必须的。生产环境别用空密码虽然 Bitnami 支持ALLOW_EMPTY_PASSWORDyes但那样哨兵连接主节点也需要密码空密码会导致认证混乱。注意 Bitnami 的密码变量名是REDIS_PASSWORD不是REQUIREPASS别写错。REDIS_MASTER_HOST和REDIS_MASTER_PORT_NUMBER在从节点上需要设置用于告诉从节点连接谁。在主节点上其实不需要设置但为了统一配置我习惯写上不影响。REDIS_AOF_ENABLEDyes开启 AOF 持久化。哨兵模式讲究的是数据安全主节点挂了切换后新主节点最好能恢复尽量多的数据AOF 比 RDB 丢失的数据更少。当然 AOF 有性能开销纯缓存场景可以关掉但真要部署高可用建议开启。从节点的配置跟主节点类似只是复制模式不同redis-slave-0: image: bitnami/redis:7.2 container_name: redis-slave-0 depends_on: - redis-master environment: - REDIS_REPLICATION_MODEslave - REDIS_PASSWORD${REDIS_PASSWORD} - REDIS_MASTER_HOSTredis-master - REDIS_MASTER_PORT_NUMBER6379 - REDIS_MASTER_PASSWORD${REDIS_PASSWORD} - ALLOW_EMPTY_PASSWORDno - REDIS_AOF_ENABLEDyes volumes: - redis-slave-0-data:/bitnami/redis/data networks: - redis-sentinel-net restart: unless-stopped这里多了一个REDIS_MASTER_PASSWORD它的值其实就是主节点的密码。从节点向主节点发起复制时主节点需要验证从节点身份所以从节点必须知道自己要连接的主节点的密码。Bitnami 镜像里如果你不设置这个变量从节点会尝试用REDIS_PASSWORD作为主节点密码大部分情况下没问题但显式写出来更清晰。有一个容易踩的坑如果主节点设置了密码而从节点的REDIS_MASTER_PASSWORD跟主节点密码不一致日志里会看到MASTER - REPLICA sync started但紧接着报NOAUTH Authentication required然后一直重试。排查的时候先确认两个变量值一致。3.2 哨兵节点配置自动发现与参数调优哨兵节点的镜像用bitnami/redis-sentinel它本身也包含 Redis 二进制但启动的是redis-sentinel进程。关键是它如何知道监控哪些节点Bitnami 的做法是依然通过环境变量指定主节点地址哨兵启动后会自动发现主节点下的所有从节点。哨兵的 Compose 配置如下redis-sentinel-0: image: bitnami/redis-sentinel:7.2 container_name: redis-sentinel-0 depends_on: - redis-master - redis-slave-0 - redis-slave-1 environment: - REDIS_MASTER_HOSTredis-master - REDIS_MASTER_PORT_NUMBER6379 - REDIS_MASTER_SETredis-master - REDIS_SENTINEL_QUORUM2 - REDIS_PASSWORD${REDIS_PASSWORD} - REDIS_SENTINEL_PASSWORD${REDIS_PASSWORD} - ALLOW_EMPTY_PASSWORDno networks: - redis-sentinel-net ports: - 26379:26379 restart: unless-stopped关键变量解释REDIS_MASTER_HOST和REDIS_MASTER_PORT_NUMBER指定哨兵要监控的主节点。注意这里不是哨兵自己成为从节点而是告诉哨兵“去监控这个主节点”。REDIS_MASTER_SET这个值是一个自定义的集群名称你可以理解为哨兵监控的“逻辑组名”。多个哨兵监控同一组主从REDIS_MASTER_SET必须一致否则哨兵之间会认为各自监控的主节点不同无法协同。REDIS_SENTINEL_QUORUM这是哨兵判断主节点客观下线所需的最小同意数。三个哨兵设 2表示至少两个哨兵认为主节点不可达才触发故障转移。如果设 1则一个哨兵就能触发安全性降低但故障转移更快。生产环境建议 2。REDIS_SENTINEL_PASSWORD哨兵之间通信的密码。Bitnami 要求哨兵之间也需要认证如果你不设置默认允许空密码但配合数据节点的密码建议统一设置。注意这里不是数据节点密码是哨兵集群自己的密码但为了管理方便我通常会设置成跟数据节点密码一样也可以不同只要所有哨兵一致就行。哨兵还有一个重要参数是REDIS_SENTINEL_FAILURE_TIMEOUT默认 20000 毫秒即主节点 20 秒内无响应才可能触发转移。如果业务对可用性要求高可以调小到 5000 毫秒但要注意网络抖动也可能导致误判。我一般保持默认除非网络环境很稳定。REDIS_SENTINEL_PORT_NUMBER默认为 26379一般不用改。如果要暴露到宿主机注意三台哨兵的宿主机端口不能冲突比如分别映射 26380、26381、26382但容器内仍然 26379。我上面的配置只展示了一个哨兵节点另外两个结构类似只是容器名和端口映射不同。后面给完整配置文件。3.3 完整 Compose 文件与启动步骤把主节点、两个从节点、三个哨兵全部写在一个 Compose 文件里用环境变量文件管理密码。目录结构如下redis-sentinel/ ├── docker-compose.yml ├── .env.env文件内容REDIS_PASSWORDyour_strong_password注意.env文件里不要加引号密码不要包含空格和#这类特殊字符否则 YAML 解析会出问题。我踩过坑密码里有$符号Compose 在解析时把它当作变量插值了导致密码错误。建议密码只用字母数字和下划线比如Redis2024这种带的没问题但$一定避开。下面是完整的docker-compose.ymlservices: redis-master: image: bitnami/redis:7.2 container_name: redis-master environment: - REDIS_REPLICATION_MODEmaster - REDIS_PASSWORD${REDIS_PASSWORD} - REDIS_MASTER_HOSTredis-master - REDIS_MASTER_PORT_NUMBER6379 - ALLOW_EMPTY_PASSWORDno - REDIS_AOF_ENABLEDyes volumes: - redis-master-data:/bitnami/redis/data networks: - redis-sentinel-net ports: - 6379:6379 restart: unless-stopped redis-slave-0: image: bitnami/redis:7.2 container_name: redis-slave-0 depends_on: - redis-master environment: - REDIS_REPLICATION_MODEslave - REDIS_PASSWORD${REDIS_PASSWORD} - REDIS_MASTER_HOSTredis-master - REDIS_MASTER_PORT_NUMBER6379 - REDIS_MASTER_PASSWORD${REDIS_PASSWORD} - ALLOW_EMPTY_PASSWORDno - REDIS_AOF_ENABLEDyes volumes: - redis-slave-0-data:/bitnami/redis/data networks: - redis-sentinel-net restart: unless-stopped redis-slave-1: image: bitnami/redis:7.2 container_name: redis-slave-1 depends_on: - redis-master environment: - REDIS_REPLICATION_MODEslave - REDIS_PASSWORD${REDIS_PASSWORD} - REDIS_MASTER_HOSTredis-master - REDIS_MASTER_PORT_NUMBER6379 - REDIS_MASTER_PASSWORD${REDIS_PASSWORD} - ALLOW_EMPTY_PASSWORDno - REDIS_AOF_ENABLEDyes volumes: - redis-slave-1-data:/bitnami/redis/data networks: - redis-sentinel-net restart: unless-stopped redis-sentinel-0: image: bitnami/redis-sentinel:7.2 container_name: redis-sentinel-0 depends_on: - redis-master - redis-slave-0 - redis-slave-1 environment: - REDIS_MASTER_HOSTredis-master - REDIS_MASTER_PORT_NUMBER6379 - REDIS_MASTER_SETredis-master - REDIS_SENTINEL_QUORUM2 - REDIS_PASSWORD${REDIS_PASSWORD} - REDIS_SENTINEL_PASSWORD${REDIS_PASSWORD} - ALLOW_EMPTY_PASSWORDno networks: - redis-sentinel-net ports: - 26379:26379 restart: unless-stopped redis-sentinel-1: image: bitnami/redis-sentinel:7.2 container_name: redis-sentinel-1 depends_on: - redis-master - redis-slave-0 - redis-slave-1 environment: - REDIS_MASTER_HOSTredis-master - REDIS_MASTER_PORT_NUMBER6379 - REDIS_MASTER_SETredis-master - REDIS_SENTINEL_QUORUM2 - REDIS_PASSWORD${REDIS_PASSWORD} - REDIS_SENTINEL_PASSWORD${REDIS_PASSWORD} - ALLOW_EMPTY_PASSWORDno networks: - redis-sentinel-net ports: - 26380:26379 restart: unless-stopped redis-sentinel-2: image: bitnami/redis-sentinel:7.2 container_name: redis-sentinel-2 depends_on: - redis-master - redis-slave-0 - redis-slave-1 environment: - REDIS_MASTER_HOSTredis-master - REDIS_MASTER_PORT_NUMBER6379 - REDIS_MASTER_SETredis-master - REDIS_SENTINEL_QUORUM2 - REDIS_PASSWORD${REDIS_PASSWORD} - REDIS_SENTINEL_PASSWORD${REDIS_PASSWORD} - ALLOW_EMPTY_PASSWORDno networks: - redis-sentinel-net ports: - 26381:26379 restart: unless-stopped networks: redis-sentinel-net: driver: bridge volumes: redis-master-data: driver: local redis-slave-0-data: driver: local redis-slave-1-data: driver: local启动的命令很简单cd redis-sentinel docker compose up -d第一次启动会拉取镜像网络好的话几分钟。启动完成后查看状态docker compose ps所有服务都应该显示Up。如果有容器反复重启先看日志docker compose logs redis-master这个阶段最常见的错误就是密码不一致或者从节点REDIS_MASTER_HOST写错日志里会给出明确提示。耐心看日志能解决 90% 的问题。3.4 验证主从复制与哨兵状态启动后不能只看容器状态要验证数据链路。我先在主节点写入数据然后到从节点读取确认复制正常。用redis-cli进入容器docker exec -it redis-master redis-cli -a ${REDIS_PASSWORD} set greeting hello sentinel注意-a后面直接跟密码会显示在进程列表里只是测试环境无所谓生产环境建议用REDISCLI_AUTH环境变量。然后到从节点上读取docker exec -it redis-slave-0 redis-cli -a ${REDIS_PASSWORD} get greeting如果能返回hello sentinel主从复制正常。再看从节点状态docker exec -it redis-slave-0 redis-cli -a ${REDIS_PASSWORD} info replication关注master_link_status:up和slave_repl_offset如果 offset 在增长说明数据在同步。从节点如果显示master_link_down多半是REDIS_MASTER_PASSWORD不对或网络不通。哨兵状态用redis-cli连接哨兵端口docker exec -it redis-sentinel-0 redis-cli -p 26379 -a ${REDIS_SENTINEL_PASSWORD} sentinel masters注意哨兵的端口是 26379用-a传的是REDIS_SENTINEL_PASSWORD不是数据节点密码别搞混。输出里应该能看到一个 masterflags为masternum-slaves为 2。如果num-slaves是 0说明哨兵没有发现从节点检查从节点是否设置了REDIS_REPLICATION_MODEslave以及主节点密码是否正确。再查看哨兵是否发现了所有哨兵节点docker exec -it redis-sentinel-0 redis-cli -p 26379 -a ${REDIS_SENTINEL_PASSWORD} sentinel sentinels redis-master应该能看到另外两个哨兵的信息。如果只有自己说明哨兵之间网络不通或REDIS_SENTINEL_PASSWORD不一致。注意这里sentinel sentinels命令的参数是redis-master也就是REDIS_MASTER_SET的那个值。4. 故障转移实测模拟主节点宕机4.1 手动 Kill 主节点观察哨兵行为部署完成只是第一步不测试故障转移等于白干。我习惯直接在容器层面模拟主节点挂掉docker stop redis-master正常情况下哨兵会在REDIS_SENTINEL_FAILURE_TIMEOUT默认的 20 秒内检测到主节点不可达然后进入客观下线流程。三个哨兵中至少两个同意接着选出 leader从两个从节点里挑一个提升为新主节点。等待大约 30 秒然后查看哨兵状态docker exec -it redis-sentinel-0 redis-cli -p 26379 -a ${REDIS_SENTINEL_PASSWORD} sentinel masters这时候输出中的flags应变为master但Name或ip可能指向了其中一个从节点比如redis-slave-0。再用同样的命令看sentinel slaves redis-master你会发现原来的主节点和剩下的从节点中一个成为新主另一个变成它的从节点。验证新主节点是否可写docker exec -it redis-slave-0 redis-cli -a ${REDIS_PASSWORD} set after_failover ok如果成功说明这个节点确实已经被提升为主节点了。如果报READONLY You cant write against a read only replica说明提升还没完成或选错了节点再等几秒。有人会问我停的是redis-master容器怎么新主节点可能是redis-slave-0或redis-slave-1这是哨兵正常的行为。它不会重启旧主节点而是直接角色切换。旧主节点容器虽然被停了但它的数据和配置还在卷里。等旧主节点重新启动后哨兵会发现这个节点已经变成从节点并自动让新主节点为它同步数据。这就是高可用的意义整个过程不需要人工干预。4.2 恢复旧主节点后的角色变化旧的redis-master容器被docker stop后由于 Compose 配置了restart: unless-stopped容器不会自动重启因为你是手动 stop 的。如果你想让它重新加入集群手动启动docker start redis-master容器启动后会以什么角色运行关键看它的环境变量REDIS_REPLICATION_MODEmaster。如果哨兵没有修改它的配置它会认为自己还是主节点这就会产生两个主节点导致脑裂。但 Bitnami 镜像做了处理。哨兵在故障转移后会记录旧主节点的地址当旧主节点重新上线时哨兵会通过SENTINEL RESET机制重新配置它。更严谨地说Bitnami 镜像中的哨兵脚本会自动向旧主节点发送REPLICAOF NO ONE或切换到新的主节点。实测下来旧主节点启动后大约几秒钟内会被哨兵降级为从节点。查看状态docker exec -it redis-sentinel-0 redis-cli -p 26379 -a ${REDIS_SENTINEL_PASSWORD} sentinel slaves redis-master输出中会看到旧主节点的flags标记为slave说明它已经被正确纳入新主节点的复制链路。这里有个细节哨兵对节点的重配置依赖sentinel-monitor配置中记录的地址和端口。由于我们全部使用容器服务名比如redis-master作为主机名哨兵和节点之间的通信都是通过 Docker 内部 DNS 解析。只要网络没问题就能正常重配置。如果旧主节点启动后数据落后很多它需要从新主节点全量同步。数据量大的时候可能有短暂的延迟这取决于网络和磁盘速度一般几秒到几十秒不等。我的建议是别急着把旧主节点的端口映射暴露到外面等它完成同步角色稳定后再配置外部访问。4.3 脑裂问题的边界条件刚才说到脑裂这里展开一下。哨兵模式不是绝对可靠在极端网络分区情况下可能出现多个主节点。比如原来的主节点和两个从节点之间网络断开但主节点还在运行从节点和哨兵之间互相能通信。哨兵判定主节点宕机提升了一个从节点为新主。此时旧主节点还在接受写入但它无法同步到新主这就产生了脑裂数据可能出现不一致。Redis 官方没有完全避免脑裂的方案但可以通过配置降低风险。比如min-replicas-to-write和min-replicas-max-lag让主节点在从节点数量不足或复制延迟过大时拒绝写入。在 Bitnami 镜像里可以用环境变量REDIS_MIN_REPLICAS_TO_WRITE和REDIS_MIN_REPLICAS_MAX_LAG设置。我一般设REDIS_MIN_REPLICAS_TO_WRITE1和REDIS_MIN_REPLICAS_MAX_LAG10意思是主节点至少要有一个健康从节点且复制延迟不超过 10 秒才允许写入。这样即使发生脑裂旧主节点也会因为从节点断开而拒绝新写入减少数据不一致窗口。但也别把值调太高否则从节点临时抖动时主节点直接拒绝写入影响可用性。哨兵模式的脑裂问题需要结合业务权衡。如果缓存数据允许一定时间的不一致那么保持默认配置问题不大。如果是关键业务数据建议考虑使用 Redis Cluster 或引入外部一致性机制但这就超出本文范围了。5. 客户端连接配置应用如何感知故障转移5.1 通过哨兵获取主节点地址应用连接 Redis 时不能直接写死一个主节点地址否则主节点切换后应用就找不到新主节点了。正确的做法是连接哨兵由哨兵返回当前主节点的地址和端口。支持哨兵的客户端库会做这件事比如 Java 的 Lettuce、Python 的 redis-py、Go 的 go-redis 都支持sentinel模式。以 Java Spring Boot 为例配置application.yml里的 Lettuce 连接参数spring: data: redis: password: ${REDIS_PASSWORD} sentinel: master: redis-master nodes: - redis-sentinel-0:26379 - redis-sentinel-1:26379 - redis-sentinel-2:26379注意这里master对应的是REDIS_MASTER_SET的值不是主节点的 host。nodes列的是哨兵节点的地址和端口只要你的应用能访问到至少一个哨兵客户端就能获得当前主节点信息。客户端连接到哨兵后会先向哨兵发送SENTINEL get-master-addr-by-name获取当前主节点地址然后建立连接。如果主节点发生切换客户端库会监听哨兵的switch-master事件自动断开旧连接建立到新主节点的连接。这个机制是哨兵模式的核心价值也是客户端必须支持哨兵协议的原因。很多人在这一步踩坑明明哨兵部署好了用redis-cli直接连主节点没问题但应用连不上。检查点有两个一是应用的网络能否到达哨兵节点的 26379 端口二是master名称是否跟REDIS_MASTER_SET一致。名称不一致会导致客户端拿不到地址。5.2 常见客户端配置示例Java与PythonPython 使用redis库的哨兵模式from redis.sentinel import Sentinel sentinel Sentinel([(redis-sentinel-0, 26379), (redis-sentinel-1, 26379), (redis-sentinel-2, 26379)], passwordyour_password, sentinel_kwargs{password: your_sentinel_password}) master sentinel.master_for(redis-master, passwordyour_password) slave sentinel.slave_for(redis-master, passwordyour_password)注意sentinel_kwargs里的 password 是哨兵密码而master_for的 password 是数据节点密码。如果密码设错连接会报认证错误。redis-py的哨兵客户端在故障转移后会自动更新主从节点地址这也是推荐用客户端哨兵模式而不是自己解析地址的原因。Go 语言使用go-redisimport github.com/redis/go-redis/v9 rdb : redis.NewFailoverClient(redis.FailoverOptions{ MasterName: redis-master, SentinelAddrs: []string{redis-sentinel-0:26379, redis-sentinel-1:26379, redis-sentinel-2:26379}, Password: your_password, SentinelPassword: your_sentinel_password, })NewFailoverClient会自动处理哨兵发现和主从切换写业务代码时就像连接单机 Redis 一样不用关心底层发生了切换。5.3 Spring Boot 集成中的一个常见坑Spring Boot 2.x 默认使用 Lettuce 作为 Redis 客户端。配置哨兵模式后如果遇到RedisCommandTimeoutException: Command timed out很可能不是网络问题而是主节点切换时连接池中的旧连接没有及时失效。Lettuce 在某些版本里对哨兵切换的处理不是默认开启的需要在配置中增加超时和重试参数spring: data: redis: timeout: 5000ms lettuce: pool: max-active: 8 max-idle: 8 min-idle: 0 shutdown-timeout: 200ms更关键的是Spring Boot 3.x 中spring.redis前缀变成了spring.data.redis如果还在用旧前缀配置不生效应用会连本地默认端口导致大量超时。这个问题我见过很多次升级 Spring Boot 后记得检查配置前缀。另外生产环境建议应用连接哨兵时不要把哨兵的 host 写死成容器名因为应用可能不在 Docker 网络里。要么通过宿主机映射端口要么在应用所在的环境里配置 DNS 解析。如果应用也在同一个 Docker 网络里直接使用服务名没问题如果应用跑在宿主机上就要映射哨兵的端口到宿主机比如把哨兵的 26379 映射到宿主机不同端口然后配置nodes为localhost:26380等。6. 常见问题与排查技巧实录6.1 故障排查速查表我在实际部署和运行期间遇到不少问题整理成一张速查表按现象、可能原因、解决思路列出来方便快速定位现象可能原因排查与解决从节点一直down日志报NOAUTH从节点REDIS_MASTER_PASSWORD与主节点密码不一致统一密码重启从节点容器哨兵sentinel masters显示master-link-down主节点地址不可达或主从复制链路断开检查网络确认主节点容器存在docker exec到哨兵容器里 ping 主节点容器名哨兵只发现一个哨兵看不到其他REDIS_SENTINEL_PASSWORD不一致或网络隔离确保所有哨兵的密码、网络相同查看哨兵日志确认哪个节点连接失败故障转移后应用仍然写旧主节点客户端没有使用哨兵模式检查客户端配置是否使用sentinel模式不要直接连主节点 IP容器反复重启环境变量拼写错误或密码包含特殊字符查看容器日志检查.env文件密码改用字母数字主节点切换后旧主节点成master与当前主节点作对旧主节点容器手动启动后未及时被哨兵重置等待几秒后执行SENTINEL RESET *观察输出必要时重启旧的 Redis 容器哨兵日志报Cant resolve instance hostname容器间 DNS 解析失败确保所有容器在同一个自定义网络里检查 Compose 服务名是否拼写正确排查问题的第一要务是看日志。docker compose logs service可以看到容器启动和运行中的输出。Bitnami 镜像镜像的日志写得很清晰基本会直接告诉你缺什么环境变量、连接失败的原因。不要凭感觉去改配置看日志能省一半时间。6.2 密码与安全配置经验最后说点安全相关的实操经验。哨兵模式的密码分为数据节点密码和哨兵密码两层。数据节点密码就是 Redis 的requirepass主从复制时从节点需要提供这个密码。哨兵密码是哨兵之间互相通信和客户端查询哨兵时的认证密码通过REDIS_SENTINEL_PASSWORD设置。在 Bitnami 镜像中如果你设置了REDIS_PASSWORD建议同时设置REDIS_SENTINEL_PASSWORD否则哨兵可能因为无法向主节点认证而无法正常监控。我之前试过只设数据密码不设哨兵密码结果故障转移是正常的但某些哨兵命令返回NOAUTH排查了半天。还有一点Bitnami 镜像默认情况下会开启 protected mode 吗实际上容器内 Redis 绑定的地址是0.0.0.0但因为有密码保护问题不大。如果你把端口映射到宿主机确保防火墙只允许内网访问不要让 6379 暴露到公网。Redis 未授权访问漏洞在安全漏洞排行里常年排前几别拿生产环境开玩笑。Kubernetes 部署时注意不要用密码明文写在 Deployment 里用 Secret 挂载为环境变量。Bitnami 的 Helm chart 已经集成了 Secret如果你手动写 YAML也要绑 Secret。我这里主要讲 Docker Compose但原理一致。7. 扩展Kubernetes 部署思路与资源推荐如果你打算在 Kubernetes 里用哨兵模式Bitnami 的 Helm chart 是现成的方案。不过这里提一句Kubernetes 环境下很多团队更倾向于使用 Redis Operator比如 KubeDB、Spotahome Redis Operator来管理哨兵集群因为它们更贴合 K8s 的 StatefulSet 和 PVC 模型。Bitnami 也有自己的 Helm chartbitnami/redis但要注意它默认部署的是主从加哨兵不是 Redis Cluster。chart 支持的参数跟 Docker 镜像里的环境变量基本一致但通过 Helm values 文件来配置。我自己在 K8s 里部署时会参考 Bitnami chart 的 values 配置主要调整以下参数master: persistence: enabled: true size: 8Gi resources: requests: memory: 256Mi limits: memory: 512Mi replica: replicaCount: 2 persistence: enabled: true size: 8Gi sentinel: enabled: true quorum: 2在 K8s 里哨兵通过 Service 暴露主从节点虽然角色会变化但 Service name 不变客户端连接哨兵的 Service比如redis-sentinel即可。需要注意的是K8s 的 Pod IP 是动态的哨兵内部需要记录节点 IP当 Pod 重建后 IP 变了哨兵需要重新发现。Bitnami 的 chart 通过 headless service 解决了这个问题所以用现成 chart 比自己拼 YAML 靠谱。如果你有更复杂的需求比如多集群、多区域部署哨兵模式就不太合适了可以考虑 Redis Cluster 或者云厂商托管的 Redis。但对大多数内部系统来说一主两从三哨兵的性价比和运维复杂度很平衡。8. 写在最后的实操总结整个部署过程走下来我个人最大的体会是Bitnami 镜像把配置过程黑盒化极大降低了上手门槛但你必须理解环境变量的语义否则出了问题连合理猜测都做不到。我建议在使用之前先手动用官方 Redis 搭一次纯手写的哨兵模式了解 sentinel.conf 里每个参数的含义再来接触 Bitnami 封装好的变量你会更容易理解它在背后帮你做了什么。一个小技巧调试阶段把所有节点日志都打开用docker compose logs -f --tail50同时跟踪多个容器。当主节点被停掉时你能从哨兵日志里看到完整的状态流转比如sdown主观下线、odown客观下线、switch-master切换主节点。熟悉这套流程后你在排查客户端连接问题时脑子会清晰很多。另外关于持久化建议同时开启 RDB 和 AOF。Bitnami 默认开启 RDBREDIS_AOF_ENABLED设为 yes 开启 AOF。两种持久化同时开启不会冲突Redis 重启时优先加载 AOFAOF 数据更完整。但要注意磁盘占用卷大小至少预留两倍数据量否则磁盘写满后 Redis 会进入只读模式那算是另一个事故了。最后再补充一个小坑如果你在 Compose 里用了depends_on它只能保证容器启动顺序不能保证服务就绪。比如从节点启动时主节点可能还没初始化好但 Bitnami 镜像内部有重试机制会自动等待主节点可用。所以不要因为容器启动顺序的问题去加 sleep 之类的 hack镜像已经处理了。这套方案我用了近两年期间经历过多次主节点切换除了网络分区这种极端情况还没出现过数据严重不一致的问题。哨兵模式作为 Redis 高可用的入门方案够用、稳定、可运维配合 Bitnami 镜像的封装确实是性价比很高的选择。希望这篇总结能帮你少踩一些坑有问题的话评论区继续聊。