1. 为什么要用Docker搭Redis集群从单节点到主从哨兵的演进逻辑先说一个很多人问我的问题单机Redis用得好好的为什么要费劲搭集群这个问题其实分两层。第一层如果你的业务量还没到单节点扛不住的程度那确实不用折腾集群带来的复杂度可能比收益还大。但第二层一旦你开始遇到这些信号——CPU持续打满、内存快不够用、写并发上不去、或者最怕的Redis宕机导致缓存雪崩那集群就不仅仅是进阶玩法而是必须做的功课了。我在实际项目里见过不少类似的情况某公司起初单节点Redis扛着全部缓存数据某天凌晨主节点突然宕机整个订单列表都查不到缓存数据库压力瞬间拉满差点出事故。当时的第一反应就是赶紧弄个高可用方案。而Docker恰好能把这个过程大幅简化——你不需要准备多台物理机或虚拟机在一台机器上就能模拟出完整的集群拓扑开发环境验证通了再平滑迁移到多机生产环境。用Docker搭Redis集群常见的方案有三种方案核心机制适用场景复杂度主从复制Replication主节点写从节点同步备份读写分离、数据备份低哨兵模式Sentinel在主从基础上增加监控和自动故障转移高可用自动切换中Redis Cluster多主多从数据分片存储海量数据、高并发写入高很多人把这三者搞混以为集群就是Redis Cluster。实际上广义的Redis集群方案包含了上面的全部形态。本文会按照从易到难的顺序完整走一遍Docker下的三种搭建方式并重点讲讲我在每一步踩过的坑。这也是我认为一篇实操文章最应该有的内容——不是给你一堆命令复制粘贴而是让你知道每条命令为什么这么写、出了问题怎么排查。适合读者已经了解Docker基本命令run、exec、network和Redis基本概念的人。如果你连docker ps都还没跑过建议先花半小时熟悉Docker基础再回来。2. 环境准备网络、镜像和目录规划少一个后面都难受开始动手前先做三件事。很多人省略了这一步结果搭到一半才发现网络不通、目录权限不对、版本不兼容来回折腾的时间比重新搭一遍还长。2.1 创建Docker网络为什么不能用默认bridgeRedis集群节点之间需要互相通信而且后续扩容、重启容器时IP可能变化所以最稳妥的方式是创建一个自定义网络。默认的bridge网络虽然也能用但容器间通过容器名互相访问的能力受限DNS解析不稳定。docker network create redis-net加个--subnet参数会更可控比如docker network create --subnet172.20.0.0/16 redis-net这个子网段可以自己定只要和宿主机现有网段不冲突即可。指定了子网后后续给容器分配固定IP就方便了哨兵模式下尤其有用。2.2 Redis镜像版本选择别盲目latest我见过太多人直接docker pull redis:latest结果某次升级后配置项变了排查半天才发现是镜像版本问题。这里我建议明确指定版本。docker pull redis:7.0目前Redis 7.x是主流稳定版本7.0、7.2都在维护周期内。Redis 6.x也还能用但新特性如Function、Acl改进缺失没必要。用固定版本号有两个好处其一是保证本地和线上环境一致其二是你百度搜到的问题解决方案跟你的版本对得上不至于被版本差异误导。2.3 目录规划配置文件持久化Docker容器的文件系统是临时的容器删了数据就没了。Redis虽然主要做缓存但开启AOF持久化后数据文件必须放在宿主机上否则容器重建等于丢数据。我的习惯是每个节点一个目录mkdir -p /opt/redis/{6379,6380,6381}以三节点哨兵模式为例6379、6380、6381分别对应三个Redis实例。生产环境多机部署时这个目录结构可以原样拷贝到其他机器上路径一致还能减少配置差异导致的低级错误。此外还需要准备Redis配置文件。下面这三个文件的细节我会在对应的章节逐步展开这里先把最小的骨架立起来touch /opt/redis/6379/redis.conf注意挂载配置文件时容器内的路径和宿主机路径要一一对应。我用/opt/redis/6379/redis.conf宿主机文件挂载到容器内/etc/redis/redis.conf这样改配置文件只需要动宿主机文件不用进容器操作。提示如果你用的是SELinux强制模式的Linux发行版挂载文件前可能要执行chcon -Rt svirt_sandbox_file_t /opt/redis否则容器可能因为权限问题启动失败。这个坑比较隐蔽启动报错时优先检查。3. 主从复制搭建最小可用集群的一小步主从复制是理解后面所有方案的基础。它做的事情一句话概括一个主节点master接收写请求一个或多个从节点slave实时同步主节点的数据读请求可以打到从节点上分担压力。3.1 启动主节点先写主节点的配置文件/opt/redis/6379/redis.confport 6379 daemonize no appendonly yes appendfilename appendonly.aof这里daemonize no是因为容器里应该让Redis以前台方式运行如果设成yesRedis进程会后台化容器会因为没有前台进程而退出。这是Docker运行Redis的第一个经典坑。然后启动容器docker run -d \ --name redis-master \ --network redis-net \ -p 6379:6379 \ -v /opt/redis/6379:/data \ -v /opt/redis/6379/redis.conf:/etc/redis/redis.conf \ redis:7.0 \ redis-server /etc/redis/redis.conf启动后验证一下docker exec -it redis-master redis-cli ping如果返回PONG说明主节点正常。3.2 启动从节点并指定主节点从节点的配置和主节点几乎一样区别在于多了replicaof指令。Redis 5.0之前这个指令叫slaveof5.0之后改名为replicaof更准确的语义老版本命令依然兼容。新项目一律用replicaof。/opt/redis/6380/redis.confport 6380 daemonize no appendonly yes appendfilename appendonly.aof replicaof redis-master 6379注意replicaof后面的主机名我直接用了容器名redis-master。在自定义网络里容器名就是独立的DNS名称容器间可以互相ping通。这也是我之前强调要先建自定义网络的原因。启动从节点docker run -d \ --name redis-slave-1 \ --network redis-net \ -p 6380:6380 \ -v /opt/redis/6380:/data \ -v /opt/redis/6380/redis.conf:/etc/redis/redis.conf \ redis:7.0 \ redis-server /etc/redis/redis.conf验证主从是否连通docker exec -it redis-slave-1 redis-cli info replication重点看这几行输出role:slave master_host:redis-master master_link_status:upmaster_link_status:up表示主从连接正常。如果显示down大概率是网络不通或replicaof配置写错。我遇到过一种情况是容器启动时主节点还没准备好从节点重试几次后自然恢复等1-2分钟再看就up了不用急着改配置。3.3 主从复制的数据验证和误区纠正写几个key验证一下docker exec -it redis-master redis-cli set name hello docker exec -it redis-slave-1 redis-cli get name如果在从节点能读到hello说明复制链路通了。这里必须特别提醒一个误区从节点默认是只读的。从节点上执行写命令会报错READONLY You cant write against a read only replica。这不是故障是设计如此。从节点只负责同步主节点数据和分担读请求写请求永远走主节点。另外主从复制是异步的。异步意味着极端情况下主节点刚收到写请求还没来得及同步给从节点就宕机了这部分数据会丢失。对缓存场景通常可以接受但对数据一致性要求极高的业务需要借助Wait命令或者直接换更严格的中间件Redis本身并不是强一致性的数据库。提示如果主节点开启了密码验证从节点的配置里要加masterauth 密码否则复制会不断报错。这个坑在主从模式下不常见本地测试通常不设密码但一上生产环境很多人就在这里卡住。同样从节点自己的requirepass也要根据情况加上。3.4 主从模式的实际局限主从复制解决了数据备份和读写分离但解决不了自动故障转移。主节点宕机后从节点虽然握着最新数据却不会自动升级为主节点。该怎么办人工干预——登录服务器手动执行replicaof no one让某个从节点转正。人力操作必然存在延迟业务中断时间不可控。于是有了哨兵Sentinel机制。4. 哨兵模式让主从复制具备故障自愈能力哨兵的本质是一个独立运行的Redis实例它不存数据只负责监控主从节点的健康状况并在主节点故障时自动把一个从节点提升为新的主节点。哨兵通常也是集群部署的至少3个避免单点故障——哨兵自己挂了就没人监控了。4.1 为什么至少要3个哨兵这里有个概念叫法定人数quorum。当某个哨兵认为主节点不可达时它不会立刻执行故障转移而是和其他哨兵协商。只有当认为主节点故障的哨兵数达到quorum值才会真正触发切换。quorum常见配置是2共3个哨兵时这么设计是为了避免网络分区导致的误判——万一主节点其实活着只是某个哨兵到它的网络断了单个哨兵的判断并不可靠。如果你只部署1个哨兵它把主节点误判为宕机然后执行切换可能造成脑裂旧主节点还活着但哨兵又提拔了一个新主节点两个主节点同时接受写请求数据就乱了。所以生产环境至少3个哨兵。4.2 哨兵配置与容器启动哨兵有自己的配置文件。/opt/redis/26379/sentinel.confport 26379 daemonize no sentinel monitor mymaster redis-master 6379 2 sentinel down-after-milliseconds mymaster 5000 sentinel failover-timeout mymaster 60000 sentinel parallel-syncs mymaster 1逐行解释sentinel monitor监控名为mymaster的主节点地址是redis-master:6379最后的2就是quorum值表示至少2个哨兵同意才执行故障转移。down-after-milliseconds连续5秒联系不上主节点就判定为主观下线。这个值不要设太小否则网络抖动会导致频繁误判。failover-timeout故障转移超时时间60秒内没完成切换就重试。parallel-syncs新主节点确定后同时允许多少个从节点同步数据。设1表示逐个同步避免网络瞬间压力过大。启动哨兵容器docker run -d \ --name redis-sentinel-1 \ --network redis-net \ -p 26379:26379 \ -v /opt/redis/26379:/data \ -v /opt/redis/26379/sentinel.conf:/etc/redis/sentinel.conf \ redis:7.0 \ redis-sentinel /etc/redis/sentinel.conf同样的方式再启动两个哨兵节点端口26380、26381注意配置文件里的端口要各自改好。3个哨兵都启动后通过日志可以确认它们彼此发现了对方docker logs redis-sentinel-1正常会看到类似sentinel sentinel的日志表示哨兵之间已经建立了互相通信。4.3 故障转移实测手动杀掉主节点看效果很多人搭完哨兵就在那干看着压根不知道好不好用。我建议直接做一次混沌测试——手动杀掉主节点容器看哨兵能不能自动切换。docker stop redis-master等待10-15秒超过down-after-milliseconds阈值然后观察哨兵日志docker logs redis-sentinel-1 --tail 50会看到类似switch-master mymaster 172.20.0.2 6379 172.20.0.3 6380的日志表示已经把6380节点提升为新的主节点。然后检查从节点docker exec -it redis-master redis-cli info replication注意这里旧主节点的容器虽然停了但重新启动后它会发现集群里已经有了新主节点自动降级为从节点并开始同步新主节点数据。这是哨兵模式非常体贴的一个设计——故障恢复后旧主节点不会抢回主位置。4.4 哨兵模式的坑客户端感知与密码问题哨兵模式的第一个潜在坑在客户端。客户端连接Redis的URL需要从redis://...改为sentinel://...并且要指定哨兵地址和主节点名称例如sentinel://172.20.0.10:26379,172.20.0.11:26379,172.20.0.12:26379/mymaster如果你把客户端还配置成直连某个Redis节点的IP那么主节点切换后客户端依然连着旧主节点的IP自然就不可用了。这也是哨兵模式部署完以后必须重点测试客户端是否具备故障转移感知能力的原因。另一个老生常谈的坑是密码。哨兵模式涉及三类密码Redis节点的requirepass从节点同步用的masterauth哨兵集群间通信的sentinel auth-pass任何一个没配好都会导致哨兵无法监控主节点或执行切换。调试时多用docker logs redis-sentinel-1看日志错误信息里通常会直接写明认证失败还是连接超时。提示本地测试时可以先不设密码把整个机制跑通后再逐步加上密码。这样即使出错也容易定位是密码配置的问题还是机制本身的问题。5. Redis Cluster真正的数据分片集群如果你要处理的数据量太大单节点内存装不下或者写并发超过单节点能承受的上限那么哨兵模式也不够用了。哨兵模式的所有节点存的数据是一样的数据量受限于单节点内存。这时候需要Redis Cluster——它将数据按照哈希槽hash slot分布到多个主节点上每个主节点只存一部分数据整体容量和性能可以水平扩展。5.1 哈希槽数据是如何分布的Redis Cluster固定有16384个哈希槽。每个key通过CRC16算法计算出一个值然后对16384取模得到所属的槽位。集群的主节点各自负责一部分槽位。例如3主3从的集群中主节点A负责0-5460槽主节点B负责5461-10922槽主节点C负责10923-16383槽。当你get一个key时客户端根据同样的算法算出槽位然后直接找到对应的节点读取数据。这个设计是Redis Cluster的灵魂也是它和哨兵模式最大的区别。理解了这个后面踩到MOVED重定向或者集群槽位不覆盖这些错误时你就能秒懂原因。5.2 三个主节点的生产级配置文件Redis Cluster对配置文件有额外要求。以下是主节点1的配置/opt/redis/6379/redis.confport 6379 daemonize no appendonly yes appendfilename appendonly.aof cluster-enabled yes cluster-config-file nodes-6379.conf cluster-node-timeout 15000关键参数cluster-enabled yes开启集群模式cluster-config-file集群节点信息文件Redis会自动维护你不用手动编辑cluster-node-timeout节点间通信超时时间超过后会被判定为疑似下线主节点2和主节点3的配置只需改port和cluster-config-file对应值即可。我这里为了演示方便把三个主节点都放在一台机器上通过不同端口区分。生产环境建议每台物理机部署一个节点避免宿主机宕机导致多个副本同时挂掉。启动3个主节点容器以6379为例6380、6381同理docker run -d \ --name redis-cluster-master-1 \ --network redis-net \ -p 6379:6379 \ -v /opt/redis/6379:/data \ -v /opt/redis/6379/redis.conf:/etc/redis/redis.conf \ redis:7.0 \ redis-server /etc/redis/redis.conf5.3 初始化集群与自动分配槽位3个主节点都启动后执行集群初始化命令docker exec -it redis-cluster-master-1 \ redis-cli --cluster create \ 172.20.0.2:6379 172.20.0.3:6379 172.20.0.4:6379 \ --cluster-replicas 0注意这里的IP不是容器名。大多数情况下--cluster create命令不接受Docker容器名它需要的是从集群外部可访问的IP。Docker容器之间可以通过容器名通信但Redis Cluster在启动时会把这些IP记录到集群拓扑里后续客户端连接、节点间重定向都需要这些IP可被访问。所以第一次搭建时IP规划就非常重要。执行后Redis会自动计算并分配16384个哈希槽给你指定的3个节点并输出分配计划。确认无误后输入yes集群开始初始化。初始化完成后检查集群状态docker exec -it redis-cluster-master-1 redis-cli --cluster info 172.20.0.2:6379看到cluster_state:ok并且所有槽位都已分配说明集群主节点部分已经就绪。5.4 添加从节点集群的高可用闭环Redis Cluster光有主节点是不行的因为主节点挂了它负责的槽位就全不可用了。所以生产环境必须为每个主节点配置至少一个从节点。从节点的作用是实时同步对应的主节点数据并在主节点故障时自动提升替代。启动3个从节点配置里同样开启cluster-enabled yes端口分别用6382、6383、6384。然后执行添加命令docker exec -it redis-cluster-master-1 \ redis-cli --cluster add-node \ 172.20.0.5:6382 \ 172.20.0.2:6379 \ --cluster-slave \ --cluster-master-id 主节点ID主节点ID可以通过redis-cli --cluster info查到。如果不想手动指定主节点ID也可以让Redis自己分配从节点给负载最低的主节点。不过我一般倾向于手动指定控制性更强。添加完成后再次查看集群状态确保每个主节点都有对应的从节点。5.5 Cluster实操中的三个经典坑第一个坑MOVED重定向。如果你不是用redis-cli -ccluster模式连接而是直接连某个节点并执行set而这个key的槽位不归该节点管客户端会收到一个MOVED错误提示你应该去另一个IP读取数据。很多新手看到MOVED就以为集群坏了其实恰恰相反它在正常工作——只需要客户端支持自动重定向就行。redis-cli -c就是集群感知模式docker exec -it redis-cluster-master-1 redis-cli -c第二个坑槽位分配不均。默认的--cluster create会平均分配槽位但如果你后续手动添加节点、删除节点槽位可能不均匀导致部分节点负载过高。可以用redis-cli --cluster rebalance 任意节点IP:端口让Redis自动重新平衡。第三个坑Docker端口映射与Cluster总线端口。Redis Cluster每个节点悄悄多了一个集群总线端口默认是Redis端口10000。比如6379对应16379。集群节点间的主从检测、故障转移选举都走这个端口。使用Docker-p映射端口时从节点、外部客户端通常只需要映射Redis端口即可但如果你需要让外部工具如可视化面板接入就要把总线端口也映射出来。否则在你本机通过工具连接集群时节点返回的集群信息里包含16379地址外部网络根本访问不到工具会一直报错。6. 从主从到Cluster的选型建议与生产环境注意点很多文章只会教你怎么搭却很少告诉你什么时候该用哪个方案。我在下面按业务需求做个对照方便你直接抄作业。6.1 主从、哨兵、Cluster怎么选业务诉求推荐方案原因缓存数据量单机内存读写并发一般单节点或主从架构最简单运维成本最低需要高可用主节点宕机自动切换哨兵模式故障转移自动化客户端可感知数据量超过单机内存天花板Redis Cluster数据分片水平扩展写入并发极高单节点CPU成为瓶颈Redis Cluster多主节点分摊写负载要注意的是一旦选择了Cluster你就得接受一些限制。比如多key操作如MGET、事务、Lua脚本要求所有key必须在同一个哈希槽内。如果key的槽位不同操作会直接报错CROSSSLOT。你需要使用哈希标签hash tag来强制某些key进入同一个槽位例如{user:1001}:name和{user:1001}:age会计算同一个槽位因为Redis只对{}内的部分计算哈希。这是一把双刃剑它能帮你实现批量操作但代价是需要自己管理key的分布提升了一些心智负担。6.2 生产环境容器化部署的几个细节Docker容器在开发环境跑通后生产环境部署时至少要检查下面几个点容器重启策略加上--restartalways避免机器重启后Redis容器没有自动拉起。否则一次宿主机维护你的Redis就再也回不来了。资源限制给Redis容器设置内存上限。推荐--memory4g这类参数否则Redis吃满宿主机内存触发OOM时整个宿主机的其他容器都会遭殃。持久化策略生产环境建议开启AOF和RDB双持久化。RDB做快照恢复快AOF记录增量操作更安全。两者配合使用既能快速恢复又能减少数据丢失窗口。不使用--network host的注意事项有些教程推荐用host网络模式好处是没有端口映射的端口丢失问题Cluster总线端口天然可见。但host模式在非Linux环境Docker Desktop下不可用且多实例部署时端口管理困难。我建议使用自定义bridge网络映射方式的常规做法生产环境用编排工具如容器编排平台管理时也更符合习惯。6.3 故障演练是必修课最后必须强调的是搭好不等于能抗故障要真正验证高可用需要主动制造故障。无论是哨兵模式还是Cluster模式我都建议定期做一次故障演练随机选择一个主节点停止它的容器观察从节点是否自动提升观察业务系统是否有感知、恢复时间是多少恢复旧主节点检查数据能否重新同步。这份演练记录比什么配置文档都珍贵。尤其在声明确保业务稳定的前提下生产环境不做一次演练等于把高可用三个字停留在口号阶段。我自己经手的集群项目上线前至少演练三轮每一次都会发现预料之外的问题——第一次是Webhook通知没配好第二次是从节点数据同步延迟比预期大导致部分读请求失败第三次才真正实现了秒级切换。别嫌麻烦越早发现问题损失越小。再分享一个小技巧做故障演练别挑业务高峰时段尽量在凌晨流量低峰期进行。演练前通知所有相关的开发运维同事准备好回滚方案确保万一自动切换失败时能人工介入。这既是技术操作更是工程习惯。7. 总结一下我的实操体会回到开头的问题Docker搭建Redis集群本质上是用容器技术降低分布式系统实验门槛。你不需要堆一柜子的服务器一台笔记本就能把主从、哨兵、Cluster全部跑通。我在这个过程中最大的感受是——三种方案演进的内在逻辑清晰而规整主从方案解决数据备份哨兵方案解决高可用Cluster方案解决容量和并发。每一层都是在补上一层方案的短板。如果你刚开始接触我建议你老老实实按主从→哨兵→Cluster的顺序推进不要跳级。每一步都亲自动手搭建、故意破坏、再恢复这个过程中的Debug经验比最终的集群本身值钱得多。等到某一天你在生产环境中遇到Redis集群告警能依据日志和info输出快速定位而不是手忙脚乱翻文档那就说明这套东西真正长在你身上了。最后补充一个我自己踩过很多次的坑命令敲得再完美配置文件的细节忘了就是会出问题。我后来习惯用docker exec进入容器内检查实际生效的配置而不是只信宿主机上的文件。毕竟容器里走的是镜像自带的默认配置加你挂载的配置两者叠加后最终生效值是什么redis-cli CONFIG GET *一看便知。这个习惯帮我省下了大量排查时间分享给你希望你也能少走弯路。 
长河君 · 2026/10/11 2:12:34 · 阅读 1.2k Docker搭建Redis集群实战：从主从复制到哨兵模式与Cluster分片
1. 为什么要用Docker搭Redis集群从单节点到主从哨兵的演进逻辑先说一个很多人问我的问题单机Redis用得好好的为什么要费劲搭集群这个问题其实分两层。第一层如果你的业务量还没到单节点扛不住的程度那确实不用折腾集群带来的复杂度可能比收益还大。但第二层一旦你开始遇到这些信号——CPU持续打满、内存快不够用、写并发上不去、或者最怕的Redis宕机导致缓存雪崩那集群就不仅仅是进阶玩法而是必须做的功课了。我在实际项目里见过不少类似的情况某公司起初单节点Redis扛着全部缓存数据某天凌晨主节点突然宕机整个订单列表都查不到缓存数据库压力瞬间拉满差点出事故。当时的第一反应就是赶紧弄个高可用方案。而Docker恰好能把这个过程大幅简化——你不需要准备多台物理机或虚拟机在一台机器上就能模拟出完整的集群拓扑开发环境验证通了再平滑迁移到多机生产环境。用Docker搭Redis集群常见的方案有三种方案核心机制适用场景复杂度主从复制Replication主节点写从节点同步备份读写分离、数据备份低哨兵模式Sentinel在主从基础上增加监控和自动故障转移高可用自动切换中Redis Cluster多主多从数据分片存储海量数据、高并发写入高很多人把这三者搞混以为集群就是Redis Cluster。实际上广义的Redis集群方案包含了上面的全部形态。本文会按照从易到难的顺序完整走一遍Docker下的三种搭建方式并重点讲讲我在每一步踩过的坑。这也是我认为一篇实操文章最应该有的内容——不是给你一堆命令复制粘贴而是让你知道每条命令为什么这么写、出了问题怎么排查。适合读者已经了解Docker基本命令run、exec、network和Redis基本概念的人。如果你连docker ps都还没跑过建议先花半小时熟悉Docker基础再回来。2. 环境准备网络、镜像和目录规划少一个后面都难受开始动手前先做三件事。很多人省略了这一步结果搭到一半才发现网络不通、目录权限不对、版本不兼容来回折腾的时间比重新搭一遍还长。2.1 创建Docker网络为什么不能用默认bridgeRedis集群节点之间需要互相通信而且后续扩容、重启容器时IP可能变化所以最稳妥的方式是创建一个自定义网络。默认的bridge网络虽然也能用但容器间通过容器名互相访问的能力受限DNS解析不稳定。docker network create redis-net加个--subnet参数会更可控比如docker network create --subnet172.20.0.0/16 redis-net这个子网段可以自己定只要和宿主机现有网段不冲突即可。指定了子网后后续给容器分配固定IP就方便了哨兵模式下尤其有用。2.2 Redis镜像版本选择别盲目latest我见过太多人直接docker pull redis:latest结果某次升级后配置项变了排查半天才发现是镜像版本问题。这里我建议明确指定版本。docker pull redis:7.0目前Redis 7.x是主流稳定版本7.0、7.2都在维护周期内。Redis 6.x也还能用但新特性如Function、Acl改进缺失没必要。用固定版本号有两个好处其一是保证本地和线上环境一致其二是你百度搜到的问题解决方案跟你的版本对得上不至于被版本差异误导。2.3 目录规划配置文件持久化Docker容器的文件系统是临时的容器删了数据就没了。Redis虽然主要做缓存但开启AOF持久化后数据文件必须放在宿主机上否则容器重建等于丢数据。我的习惯是每个节点一个目录mkdir -p /opt/redis/{6379,6380,6381}以三节点哨兵模式为例6379、6380、6381分别对应三个Redis实例。生产环境多机部署时这个目录结构可以原样拷贝到其他机器上路径一致还能减少配置差异导致的低级错误。此外还需要准备Redis配置文件。下面这三个文件的细节我会在对应的章节逐步展开这里先把最小的骨架立起来touch /opt/redis/6379/redis.conf注意挂载配置文件时容器内的路径和宿主机路径要一一对应。我用/opt/redis/6379/redis.conf宿主机文件挂载到容器内/etc/redis/redis.conf这样改配置文件只需要动宿主机文件不用进容器操作。提示如果你用的是SELinux强制模式的Linux发行版挂载文件前可能要执行chcon -Rt svirt_sandbox_file_t /opt/redis否则容器可能因为权限问题启动失败。这个坑比较隐蔽启动报错时优先检查。3. 主从复制搭建最小可用集群的一小步主从复制是理解后面所有方案的基础。它做的事情一句话概括一个主节点master接收写请求一个或多个从节点slave实时同步主节点的数据读请求可以打到从节点上分担压力。3.1 启动主节点先写主节点的配置文件/opt/redis/6379/redis.confport 6379 daemonize no appendonly yes appendfilename appendonly.aof这里daemonize no是因为容器里应该让Redis以前台方式运行如果设成yesRedis进程会后台化容器会因为没有前台进程而退出。这是Docker运行Redis的第一个经典坑。然后启动容器docker run -d \ --name redis-master \ --network redis-net \ -p 6379:6379 \ -v /opt/redis/6379:/data \ -v /opt/redis/6379/redis.conf:/etc/redis/redis.conf \ redis:7.0 \ redis-server /etc/redis/redis.conf启动后验证一下docker exec -it redis-master redis-cli ping如果返回PONG说明主节点正常。3.2 启动从节点并指定主节点从节点的配置和主节点几乎一样区别在于多了replicaof指令。Redis 5.0之前这个指令叫slaveof5.0之后改名为replicaof更准确的语义老版本命令依然兼容。新项目一律用replicaof。/opt/redis/6380/redis.confport 6380 daemonize no appendonly yes appendfilename appendonly.aof replicaof redis-master 6379注意replicaof后面的主机名我直接用了容器名redis-master。在自定义网络里容器名就是独立的DNS名称容器间可以互相ping通。这也是我之前强调要先建自定义网络的原因。启动从节点docker run -d \ --name redis-slave-1 \ --network redis-net \ -p 6380:6380 \ -v /opt/redis/6380:/data \ -v /opt/redis/6380/redis.conf:/etc/redis/redis.conf \ redis:7.0 \ redis-server /etc/redis/redis.conf验证主从是否连通docker exec -it redis-slave-1 redis-cli info replication重点看这几行输出role:slave master_host:redis-master master_link_status:upmaster_link_status:up表示主从连接正常。如果显示down大概率是网络不通或replicaof配置写错。我遇到过一种情况是容器启动时主节点还没准备好从节点重试几次后自然恢复等1-2分钟再看就up了不用急着改配置。3.3 主从复制的数据验证和误区纠正写几个key验证一下docker exec -it redis-master redis-cli set name hello docker exec -it redis-slave-1 redis-cli get name如果在从节点能读到hello说明复制链路通了。这里必须特别提醒一个误区从节点默认是只读的。从节点上执行写命令会报错READONLY You cant write against a read only replica。这不是故障是设计如此。从节点只负责同步主节点数据和分担读请求写请求永远走主节点。另外主从复制是异步的。异步意味着极端情况下主节点刚收到写请求还没来得及同步给从节点就宕机了这部分数据会丢失。对缓存场景通常可以接受但对数据一致性要求极高的业务需要借助Wait命令或者直接换更严格的中间件Redis本身并不是强一致性的数据库。提示如果主节点开启了密码验证从节点的配置里要加masterauth 密码否则复制会不断报错。这个坑在主从模式下不常见本地测试通常不设密码但一上生产环境很多人就在这里卡住。同样从节点自己的requirepass也要根据情况加上。3.4 主从模式的实际局限主从复制解决了数据备份和读写分离但解决不了自动故障转移。主节点宕机后从节点虽然握着最新数据却不会自动升级为主节点。该怎么办人工干预——登录服务器手动执行replicaof no one让某个从节点转正。人力操作必然存在延迟业务中断时间不可控。于是有了哨兵Sentinel机制。4. 哨兵模式让主从复制具备故障自愈能力哨兵的本质是一个独立运行的Redis实例它不存数据只负责监控主从节点的健康状况并在主节点故障时自动把一个从节点提升为新的主节点。哨兵通常也是集群部署的至少3个避免单点故障——哨兵自己挂了就没人监控了。4.1 为什么至少要3个哨兵这里有个概念叫法定人数quorum。当某个哨兵认为主节点不可达时它不会立刻执行故障转移而是和其他哨兵协商。只有当认为主节点故障的哨兵数达到quorum值才会真正触发切换。quorum常见配置是2共3个哨兵时这么设计是为了避免网络分区导致的误判——万一主节点其实活着只是某个哨兵到它的网络断了单个哨兵的判断并不可靠。如果你只部署1个哨兵它把主节点误判为宕机然后执行切换可能造成脑裂旧主节点还活着但哨兵又提拔了一个新主节点两个主节点同时接受写请求数据就乱了。所以生产环境至少3个哨兵。4.2 哨兵配置与容器启动哨兵有自己的配置文件。/opt/redis/26379/sentinel.confport 26379 daemonize no sentinel monitor mymaster redis-master 6379 2 sentinel down-after-milliseconds mymaster 5000 sentinel failover-timeout mymaster 60000 sentinel parallel-syncs mymaster 1逐行解释sentinel monitor监控名为mymaster的主节点地址是redis-master:6379最后的2就是quorum值表示至少2个哨兵同意才执行故障转移。down-after-milliseconds连续5秒联系不上主节点就判定为主观下线。这个值不要设太小否则网络抖动会导致频繁误判。failover-timeout故障转移超时时间60秒内没完成切换就重试。parallel-syncs新主节点确定后同时允许多少个从节点同步数据。设1表示逐个同步避免网络瞬间压力过大。启动哨兵容器docker run -d \ --name redis-sentinel-1 \ --network redis-net \ -p 26379:26379 \ -v /opt/redis/26379:/data \ -v /opt/redis/26379/sentinel.conf:/etc/redis/sentinel.conf \ redis:7.0 \ redis-sentinel /etc/redis/sentinel.conf同样的方式再启动两个哨兵节点端口26380、26381注意配置文件里的端口要各自改好。3个哨兵都启动后通过日志可以确认它们彼此发现了对方docker logs redis-sentinel-1正常会看到类似sentinel sentinel的日志表示哨兵之间已经建立了互相通信。4.3 故障转移实测手动杀掉主节点看效果很多人搭完哨兵就在那干看着压根不知道好不好用。我建议直接做一次混沌测试——手动杀掉主节点容器看哨兵能不能自动切换。docker stop redis-master等待10-15秒超过down-after-milliseconds阈值然后观察哨兵日志docker logs redis-sentinel-1 --tail 50会看到类似switch-master mymaster 172.20.0.2 6379 172.20.0.3 6380的日志表示已经把6380节点提升为新的主节点。然后检查从节点docker exec -it redis-master redis-cli info replication注意这里旧主节点的容器虽然停了但重新启动后它会发现集群里已经有了新主节点自动降级为从节点并开始同步新主节点数据。这是哨兵模式非常体贴的一个设计——故障恢复后旧主节点不会抢回主位置。4.4 哨兵模式的坑客户端感知与密码问题哨兵模式的第一个潜在坑在客户端。客户端连接Redis的URL需要从redis://...改为sentinel://...并且要指定哨兵地址和主节点名称例如sentinel://172.20.0.10:26379,172.20.0.11:26379,172.20.0.12:26379/mymaster如果你把客户端还配置成直连某个Redis节点的IP那么主节点切换后客户端依然连着旧主节点的IP自然就不可用了。这也是哨兵模式部署完以后必须重点测试客户端是否具备故障转移感知能力的原因。另一个老生常谈的坑是密码。哨兵模式涉及三类密码Redis节点的requirepass从节点同步用的masterauth哨兵集群间通信的sentinel auth-pass任何一个没配好都会导致哨兵无法监控主节点或执行切换。调试时多用docker logs redis-sentinel-1看日志错误信息里通常会直接写明认证失败还是连接超时。提示本地测试时可以先不设密码把整个机制跑通后再逐步加上密码。这样即使出错也容易定位是密码配置的问题还是机制本身的问题。5. Redis Cluster真正的数据分片集群如果你要处理的数据量太大单节点内存装不下或者写并发超过单节点能承受的上限那么哨兵模式也不够用了。哨兵模式的所有节点存的数据是一样的数据量受限于单节点内存。这时候需要Redis Cluster——它将数据按照哈希槽hash slot分布到多个主节点上每个主节点只存一部分数据整体容量和性能可以水平扩展。5.1 哈希槽数据是如何分布的Redis Cluster固定有16384个哈希槽。每个key通过CRC16算法计算出一个值然后对16384取模得到所属的槽位。集群的主节点各自负责一部分槽位。例如3主3从的集群中主节点A负责0-5460槽主节点B负责5461-10922槽主节点C负责10923-16383槽。当你get一个key时客户端根据同样的算法算出槽位然后直接找到对应的节点读取数据。这个设计是Redis Cluster的灵魂也是它和哨兵模式最大的区别。理解了这个后面踩到MOVED重定向或者集群槽位不覆盖这些错误时你就能秒懂原因。5.2 三个主节点的生产级配置文件Redis Cluster对配置文件有额外要求。以下是主节点1的配置/opt/redis/6379/redis.confport 6379 daemonize no appendonly yes appendfilename appendonly.aof cluster-enabled yes cluster-config-file nodes-6379.conf cluster-node-timeout 15000关键参数cluster-enabled yes开启集群模式cluster-config-file集群节点信息文件Redis会自动维护你不用手动编辑cluster-node-timeout节点间通信超时时间超过后会被判定为疑似下线主节点2和主节点3的配置只需改port和cluster-config-file对应值即可。我这里为了演示方便把三个主节点都放在一台机器上通过不同端口区分。生产环境建议每台物理机部署一个节点避免宿主机宕机导致多个副本同时挂掉。启动3个主节点容器以6379为例6380、6381同理docker run -d \ --name redis-cluster-master-1 \ --network redis-net \ -p 6379:6379 \ -v /opt/redis/6379:/data \ -v /opt/redis/6379/redis.conf:/etc/redis/redis.conf \ redis:7.0 \ redis-server /etc/redis/redis.conf5.3 初始化集群与自动分配槽位3个主节点都启动后执行集群初始化命令docker exec -it redis-cluster-master-1 \ redis-cli --cluster create \ 172.20.0.2:6379 172.20.0.3:6379 172.20.0.4:6379 \ --cluster-replicas 0注意这里的IP不是容器名。大多数情况下--cluster create命令不接受Docker容器名它需要的是从集群外部可访问的IP。Docker容器之间可以通过容器名通信但Redis Cluster在启动时会把这些IP记录到集群拓扑里后续客户端连接、节点间重定向都需要这些IP可被访问。所以第一次搭建时IP规划就非常重要。执行后Redis会自动计算并分配16384个哈希槽给你指定的3个节点并输出分配计划。确认无误后输入yes集群开始初始化。初始化完成后检查集群状态docker exec -it redis-cluster-master-1 redis-cli --cluster info 172.20.0.2:6379看到cluster_state:ok并且所有槽位都已分配说明集群主节点部分已经就绪。5.4 添加从节点集群的高可用闭环Redis Cluster光有主节点是不行的因为主节点挂了它负责的槽位就全不可用了。所以生产环境必须为每个主节点配置至少一个从节点。从节点的作用是实时同步对应的主节点数据并在主节点故障时自动提升替代。启动3个从节点配置里同样开启cluster-enabled yes端口分别用6382、6383、6384。然后执行添加命令docker exec -it redis-cluster-master-1 \ redis-cli --cluster add-node \ 172.20.0.5:6382 \ 172.20.0.2:6379 \ --cluster-slave \ --cluster-master-id 主节点ID主节点ID可以通过redis-cli --cluster info查到。如果不想手动指定主节点ID也可以让Redis自己分配从节点给负载最低的主节点。不过我一般倾向于手动指定控制性更强。添加完成后再次查看集群状态确保每个主节点都有对应的从节点。5.5 Cluster实操中的三个经典坑第一个坑MOVED重定向。如果你不是用redis-cli -ccluster模式连接而是直接连某个节点并执行set而这个key的槽位不归该节点管客户端会收到一个MOVED错误提示你应该去另一个IP读取数据。很多新手看到MOVED就以为集群坏了其实恰恰相反它在正常工作——只需要客户端支持自动重定向就行。redis-cli -c就是集群感知模式docker exec -it redis-cluster-master-1 redis-cli -c第二个坑槽位分配不均。默认的--cluster create会平均分配槽位但如果你后续手动添加节点、删除节点槽位可能不均匀导致部分节点负载过高。可以用redis-cli --cluster rebalance 任意节点IP:端口让Redis自动重新平衡。第三个坑Docker端口映射与Cluster总线端口。Redis Cluster每个节点悄悄多了一个集群总线端口默认是Redis端口10000。比如6379对应16379。集群节点间的主从检测、故障转移选举都走这个端口。使用Docker-p映射端口时从节点、外部客户端通常只需要映射Redis端口即可但如果你需要让外部工具如可视化面板接入就要把总线端口也映射出来。否则在你本机通过工具连接集群时节点返回的集群信息里包含16379地址外部网络根本访问不到工具会一直报错。6. 从主从到Cluster的选型建议与生产环境注意点很多文章只会教你怎么搭却很少告诉你什么时候该用哪个方案。我在下面按业务需求做个对照方便你直接抄作业。6.1 主从、哨兵、Cluster怎么选业务诉求推荐方案原因缓存数据量单机内存读写并发一般单节点或主从架构最简单运维成本最低需要高可用主节点宕机自动切换哨兵模式故障转移自动化客户端可感知数据量超过单机内存天花板Redis Cluster数据分片水平扩展写入并发极高单节点CPU成为瓶颈Redis Cluster多主节点分摊写负载要注意的是一旦选择了Cluster你就得接受一些限制。比如多key操作如MGET、事务、Lua脚本要求所有key必须在同一个哈希槽内。如果key的槽位不同操作会直接报错CROSSSLOT。你需要使用哈希标签hash tag来强制某些key进入同一个槽位例如{user:1001}:name和{user:1001}:age会计算同一个槽位因为Redis只对{}内的部分计算哈希。这是一把双刃剑它能帮你实现批量操作但代价是需要自己管理key的分布提升了一些心智负担。6.2 生产环境容器化部署的几个细节Docker容器在开发环境跑通后生产环境部署时至少要检查下面几个点容器重启策略加上--restartalways避免机器重启后Redis容器没有自动拉起。否则一次宿主机维护你的Redis就再也回不来了。资源限制给Redis容器设置内存上限。推荐--memory4g这类参数否则Redis吃满宿主机内存触发OOM时整个宿主机的其他容器都会遭殃。持久化策略生产环境建议开启AOF和RDB双持久化。RDB做快照恢复快AOF记录增量操作更安全。两者配合使用既能快速恢复又能减少数据丢失窗口。不使用--network host的注意事项有些教程推荐用host网络模式好处是没有端口映射的端口丢失问题Cluster总线端口天然可见。但host模式在非Linux环境Docker Desktop下不可用且多实例部署时端口管理困难。我建议使用自定义bridge网络映射方式的常规做法生产环境用编排工具如容器编排平台管理时也更符合习惯。6.3 故障演练是必修课最后必须强调的是搭好不等于能抗故障要真正验证高可用需要主动制造故障。无论是哨兵模式还是Cluster模式我都建议定期做一次故障演练随机选择一个主节点停止它的容器观察从节点是否自动提升观察业务系统是否有感知、恢复时间是多少恢复旧主节点检查数据能否重新同步。这份演练记录比什么配置文档都珍贵。尤其在声明确保业务稳定的前提下生产环境不做一次演练等于把高可用三个字停留在口号阶段。我自己经手的集群项目上线前至少演练三轮每一次都会发现预料之外的问题——第一次是Webhook通知没配好第二次是从节点数据同步延迟比预期大导致部分读请求失败第三次才真正实现了秒级切换。别嫌麻烦越早发现问题损失越小。再分享一个小技巧做故障演练别挑业务高峰时段尽量在凌晨流量低峰期进行。演练前通知所有相关的开发运维同事准备好回滚方案确保万一自动切换失败时能人工介入。这既是技术操作更是工程习惯。7. 总结一下我的实操体会回到开头的问题Docker搭建Redis集群本质上是用容器技术降低分布式系统实验门槛。你不需要堆一柜子的服务器一台笔记本就能把主从、哨兵、Cluster全部跑通。我在这个过程中最大的感受是——三种方案演进的内在逻辑清晰而规整主从方案解决数据备份哨兵方案解决高可用Cluster方案解决容量和并发。每一层都是在补上一层方案的短板。如果你刚开始接触我建议你老老实实按主从→哨兵→Cluster的顺序推进不要跳级。每一步都亲自动手搭建、故意破坏、再恢复这个过程中的Debug经验比最终的集群本身值钱得多。等到某一天你在生产环境中遇到Redis集群告警能依据日志和info输出快速定位而不是手忙脚乱翻文档那就说明这套东西真正长在你身上了。最后补充一个我自己踩过很多次的坑命令敲得再完美配置文件的细节忘了就是会出问题。我后来习惯用docker exec进入容器内检查实际生效的配置而不是只信宿主机上的文件。毕竟容器里走的是镜像自带的默认配置加你挂载的配置两者叠加后最终生效值是什么redis-cli CONFIG GET *一看便知。这个习惯帮我省下了大量排查时间分享给你希望你也能少走弯路。