大家好！在之前的文章中，我们深入探讨了Redis的持久化机制（RDB和AOF），解决了数据"丢不丢"的问题。但随着业务量的增长，我们很快会面临另一个挑战："快不快"。
单台Redis服务器虽然性能强劲，但毕竟受限于CPU和网络带宽，其并发处理能力（QPS）是有上限的（通常在3万-5万左右）。当面对"双11"这种海量读请求时，单节点很容易成为瓶颈。
怎么办？既然"一夫当关"太累，那我们就组建一支"军队"！今天，我们就来学习Redis最基础的集群模式------主从复制，通过"人多力量大"来实现读写分离，大幅提升系统的并发能力。
什么是主从架构？
主从架构的核心思想非常简单：一主多从，读写分离。
- 主节点（Master） ：
- 它是集群的"大脑"，负责处理所有的写操作（如SET、DEL）。
- 它会将接收到的写命令，实时同步给所有的从节点。
- 从节点（Slave/Replica） ：
- 它们是主节点的"分身"，负责处理读操作（如GET）。
- 它们不能直接写入数据（除非特殊配置），只能被动接收主节点的数据同步。
- 注：在Redis 5.0之前，从节点被称为Slave，后来为了消除"主奴"色彩，官方改称为Replica，但两者指代的是同一个东西。
通过这种架构，我们可以将巨大的读压力分散到多个从节点上，而主节点则专注于写操作，从而成倍地提升系统的整体吞吐量。
实战演练：单机模拟三节点集群
在生产环境中，主从节点通常部署在不同的物理机上。但为了学习和测试，我们可以在一台虚拟机上，通过不同端口来模拟三个Redis实例。
环境规划
- IP地址：192.168.80.134（本机，也就是你虚拟机的ip）
- Master节点：端口 7001
- Slave节点1：端口 7002
- Slave节点2：端口 7003
准备工作
- 创建目录 ：在
/tmp下创建7001、7002、7003三个文件夹，作为各自的工作目录。 - 准备配置文件 ：将原始的
redis.conf复制三份，分别放入这三个文件夹中。 - 修改配置 ：
- 修改
port：分别改为7001、7002、7003。 - 修改
dir：指向各自的工作目录（如dir /tmp/7001/）。 - 关闭AOF：为了演示方便，暂时设置
appendonly no（生产环境建议开启）。 - 声明IP：添加
replica-announce-ip 192.168.80.134，确保节点间能正确识别IP。
- 修改
启动实例
分别启动三个Redis实例：
redis-server /tmp/7001/redis.conf
redis-server /tmp/7002/redis.conf
redis-server /tmp/7003/redis.conf
此时，它们是三个互不相关的独立Redis实例。
一件重要的事：防火墙相关端口一定要开放或者直接关闭，主节点中配置bind用
bash
bind 127.0.0.1 192.168.80.134这个很重要，不然后续会失败，因为：（这里博主一开始也没注意到，排了半天错）
虽然从节点和主节点在同一台物理机 上，但网络数据包的走向是：从节点 -> 网卡 -> 回环 -> 主节点。
如果主节点的配置里写着 bind 127.0.0.1，这就相当于主节点对外宣布："我只听 127.0.0.1 的话，别的 IP（包括 192.168.80.134）找我，我一律不理。"
为什么同一个虚拟机也不行？
- 从节点的视角 ：你告诉从节点
replicaof 192.168.80.134 7001。 - 网络包的流向 ：从节点会把数据包发给
192.168.80.134。 - 主节点的视角 ：主节点监听的是
127.0.0.1。 - 结果 ：虽然都在同一台机器里，但入口 IP 不匹配。主节点觉得："我不认识 192.168.80.134 这个地址进来的请求"，于是拒绝连接（或者在防火墙/保护模式下直接丢弃）
建立"血缘"关系
实例启动后，我们需要手动建立主从关系。这可以通过命令临时生效，也可以写入配置文件永久生效。
方式一：命令行临时配置（推荐测试用）
我们登录到从节点，告诉它"谁是你的老大"。
- 连接7002 ：
redis-cli -p 7002 - 执行命令 ：
slaveof 192.168.80.134 7001- 注：Redis 5.0后推荐使用
replicaof 192.168.80.134 7001，效果一样。
- 注：Redis 5.0后推荐使用
- 连接7003 ：
redis-cli -p 7003 - 执行命令 ：
replicaof 192.168.80.134 7001
方式二：配置文件永久生效（推荐生产用）
在从节点的redis.conf中添加一行配置：
replicaof 192.168.80.134 7001
这样重启后，主从关系依然存在。
验证状态
在主节点（7001）上执行info replication，你应该能看到类似这样的输出：
role:master
connected_slaves:2
slave0:ip=192.168.150.101,port=7002...
slave1:ip=192.168.150.101,port=7003...
这说明主从关系搭建成功！
读写分离测试
现在，让我们看看主从架构是如何工作的。
1. 写操作（只能在Master）
我们在主节点（7001）写入数据：
127.0.0.1:7001> set num 300
OK
2. 读操作（可以在Slave）
接着，我们去从节点（7002和7003）读取数据：
127.0.0.1:7003> get num
"123"
数据已经成功同步！
3. 从节点写保护
如果你尝试在从节点写入数据：
127.0.0.1:7002> set number 666
系统会报错：
(error) READONLY You can't write against a read only replica.
这是Redis的保护机制，防止从节点的数据与主节点不一致。
知识小结
为了方便大家复习，我整理了本节的重点速查表：
| 知识点 | 核心内容 | 避坑/考点 |
|---|---|---|
| 架构角色 | Master负责写，Slave负责读 | 实现读写分离，提升读性能 |
| 配置命令 | slaveof <ip> <port> 或 replicaof |
需在从节点上执行 |
| 数据流向 | 单向复制：Master → Slave | 从节点数据是只读的副本 |
| 状态查看 | info replication |
关注 connected_slaves 数量 |
| 术语演变 | Redis 5.0前叫Slave，后叫Replica | 考试或面试时需注意版本差异 |