周传炽搭建Redis主从复制，很多人第一反应是去下载Redis、配redis.conf、再跑两个实例，来回折腾半天。后来我换了思路，所有实例都跑在Docker里，通过docker-compose一次性把三个节点拉起来，配置全部用volume挂进去，改配置、重启、看日志都方便得多，整个过程从零到一主二从跑通，十分钟内搞定。如果你也正在用Docker做本地开发或测试环境，想在Redis主从复制这件事上少踩坑，这篇内容值得你看完。
先简单说下这次要做什么：用docker-compose在本地启动三个Redis实例，一个主节点、两个从节点，通过配置让两个从节点自动同步主节点的数据。搭建完成后，我会演示写入数据后从节点是否同步、模拟主节点挂掉后从节点如何处理，以及一些我实际踩过的问题和排查思路。
1. 方案设计：为什么用Docker而不是直接装多个Redis实例
1.1 Docker在这个场景里的价值
如果不用Docker，想在本地搭一个一主二从的Redis环境，你需要下载Redis源码或安装包，编译安装好三份，或者解压三份目录，然后分别维护三份redis.conf，还要处理端口占用的冲突、数据目录的隔离、进程的管理和日志收集。听起来工作量不大，但每换一台机器、每换一个版本就要重来一遍，尤其当你需要模拟多节点环境来做测试时，这种重复劳动非常消耗耐心。
用Docker之后，情况完全变了。Redis镜像本身就是官方维护好的运行环境，你不需要关心编译参数、依赖库、系统兼容性。三个容器可以通过同一个compose文件声明出来，端口映射、数据卷、网络、启动命令全部在文件里一次性定义清楚。以后想从一主二从扩展到一主三从，或者换一个Redis大版本，改几行配置重新执行一条命令就行，整个环境“可复制、可丢弃、可重建”，这对开发调试和测试验证来说价值非常大.
1.2 主从复制到底解决了什么问题
在拆解具体配置之前，有必要把主从复制的功能边界说清楚，否则很容易对它产生不切实际的期待。
Redis主从复制最核心的能力是数据冗余和多副本读。主节点负责接收写请求，然后把写操作以数据流的形式同步给所有从节点。这样即使主节点所在机器出现磁盘损坏、进程崩溃等极端情况，数据仍然保存在从节点上。而从节点因为拥有完整的数据副本，可以承担读请求，起到读写分离的效果——把读的流量分发到从节点，主节点专注于处理写请求，这在“读多写少”的业务场景下效果非常明显。
但主从复制不等于高可用。默认配置下，主节点宕机后从节点不会自动升级为新的主节点，业务依然会面临写入失败的问题。要实现自动故障转移，需要在主从复制的基础上再引入哨兵机制或Redis Cluster集群模式，这是另一套复杂的架构设计。我在文中后面会专门演示手动模拟故障的过程，帮你看清主从复制的边界到底在哪里。
1.3 一主二从的节点规划
我这次搭建的拓扑是一主二从，具体如下：
| 节点角色 | 容器服务名 | 映射端口 | 容器内部端口 |
|---|---|---|---|
| 主节点 | redis-master | 6379 | 6379 |
| 从节点1 | redis-slave1 | 6380 | 6379 |
| 从节点2 | redis-slave2 | 6381 | 6379 |
选一主二从而不是“一主一从”，主要考虑到两个测试场景：一是验证多个从节点同时同步是否正常；二是演示当其中一个从节点挂掉重启后，能不能自动追上主节点的数据。这些场景在生产环境里很常见，提前在本地把行为摸透，总比在线上慌张排查要好。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 环境准备与镜像选型
2.1 Docker环境检查
开始操作前，先确认Docker已经正确安装并启动。在终端执行：
bash复制docker version
正常情况下，输出中应该同时包含Client和Server两段信息，并且Server段的Status字段为“running”。如果只看到Client信息或者提示无法连接，说明Docker守护进程没有跑起来，需要先处理Docker环境问题。
如果你是Windows用户，启动Docker Desktop时遇到“virtualization support not detected”或“virtualisation support wasn't detected”之类的报错，大概率是BIOS里的虚拟化技术没有开启，或Windows的Hyper-V、WSL2功能未启用。这类环境问题不解决，后面所有容器操作都跑不起来。修好之后再回来，继续本次实践。
这里有个实践中的经验：在本地做Redis主从复制实验时，不需要在Docker里额外配置网络模式，用compose默认创建的bridge网络就够用。默认网络能让同一个compose文件中的容器通过“服务名+内部端口”互相访问，这个特性后面配置主从关系时会频繁用到。
2.2 Redis镜像版本选择
镜像标签直接决定了Redis的行为差异。我这次使用Redis 7.0以上的镜像做验证，配置方式和老版本有细微差别。
yaml复制image: redis:7.2
拉取最新版本的镜像：
bash复制docker pull redis:7.2
镜像本身就包含了一个默认配置的Redis服务端，直接用redis-server启动就能跑。但我们做主从复制需要自定义配置，所以要把自己的redis.conf挂载进容器里，用指定配置文件的方式启动。
bash复制docke