从零开始的 Redis 主从架构搭建与实战验证。
文章目录
- [一、 引言](#一、 引言)
- [二、 环境准备与拓扑结构](#二、 环境准备与拓扑结构)
- [三、 核心搭建步骤](#三、 核心搭建步骤)
-
- [1、复制 Redis 配置文件](#1、复制 Redis 配置文件)
- 2、修改三个配置文件
- 3、配置从节点
- [4、启动三个 Redis](#4、启动三个 Redis)
- 5、查看是否启动成功
- 四、主从功能验证
- 总结：为什么要主从部署
一、 引言
主从部署（Master-Slave Deployment），本质上就是：
一台服务器负责"写"，另一台或多台服务器负责"复制和读"。
假设你有个校园二手平台：
- 用户发商品
- 用户下单
- 用户搜索商品
- 用户看详情
其中：
- "发商品、下单"属于写操作
- "搜索、查看"属于读操作
如果全压在一个数据库：
一个数据库：
又读又写又计算
CPU：我要报警了
于是：
主库（Master）
负责：
insert
update
delete
从库（Slave）负责：
select 查询
结构如下：
用户请求
写操作
读操作
主库
从库
数据同步
从库
二、 环境准备与拓扑结构
你需要：
1个主节点（Master）
2个从节点（Replica/Slave）
| 角色 | 端口 |
|---|---|
| 主节点 | 6379 |
| 从节点1 | 6380 |
| 从节点2 | 6381 |
三、 核心搭建步骤
1、复制 Redis 配置文件
先找到你的 redis.conf。
我的redis.conf文件路径如下：
bash
/usr/local/bin/redis.conf然后创建三个配置文件：
bash
cp redis.conf redis6379.conf
cp redis.conf redis6380.conf
cp redis.conf redis6381.conf2、修改三个配置文件
- 主节点配置（6379）
编辑：
bash
vi redis6379.conf修改如下地方：
bash
port 6379 # 139行
daemonize yes # 327行
pidfile /var/run/redis6379.pid # 359行，指定 Redis 进程号（PID）的保存文件路径
logfile "6379.log" # 373行，指定 Redis 的日志文件名叫 6379.log
dir ./data6379 # 533行，指定 Redis 的工作目录 = 当前目录下的 data6379 文件夹一定一定一定要创建目录
bash
mkdir data63793、配置从节点
因为我设置了两个从节点，下面只演示一个节点的配置，port 6381重复步骤即可。
依旧编辑：
bash
vi redis6380.conf修改：
bash
port 6380
daemonize yes
pidfile /var/run/redis6380.pid
logfile "6380.log"
dir ./data6380
replicaof 127.0.0.1 6379 # 556行，把当前 Redis 设成【本机 6379 端口】的从库依旧创建目录，不要忘记！！！
bash
mkdir data63804、启动三个 Redis
启动！
bash
redis-server redis6379.conf
redis-server redis6380.conf
redis-server redis6381.conf5、查看是否启动成功
查看进程：
bash
ps -ef | grep redis若是启动成功则应该显示如图所示：
带有 redis-server 关键字的进程就是成功启动的进程。
四、主从功能验证
a、连接主节点
第一步连接主节点：
bash
redis-cli -p 6379写入：
bash
set name ytxb、连接从节点
新开终端：
bash
redis-cli -p 6380查询：
bash
get name如果步骤正确你将会看见以下截图所示：
c、查看主从信息
主节点：
bash
info replication你会看到主节点显示：
bash
role:master
connected_slaves:2从节点显示：
bash
role:slave
master_host:127.0.0.1还有一个重点体现，当你在从节点输入：
bash
set age 18
这是因为：从节点默认只读
上面这个小例子很好的说明了
Redis 读写分离
总结：为什么要主从部署
1、读写分离
在实际业务中，数据库通常是"读多写少"。主从架构让主节点（6379）专注于处理写请求，从节点（6380/6381）专注于处理读请求。各司其职，大幅优化了服务器的资源利用率。
2、提高并发
随着访问量激增，单台 Redis 的网络 IO 和 CPU 往往会成为瓶颈。通过引入多个从节点共同分担读流量，集群的并发读能力得到了成倍的提升，轻松应对高并发场景。
3、数据备份
主从复制实现了数据的多机热备份。当主节点不幸宕机或发生硬件故障时，从节点上依然保存着完整的数据，为系统的容灾恢复和后续的故障转移（如哨兵模式）提供了坚实的基础。
搭建好主从架构，只是我们迈向 Redis 高可用架构的第一步。虽然它实现了读写分离和数据备份，但如果主节点挂了，目前还需要我们手动去执行 REPLICAOF NO ONE 来切换主节点。在下一篇文章中，我将带大家继续进阶，解锁能实现自动故障转移的------Redis Sentinel（哨兵模式）！