企业官网建设流程全解析

一、先搞懂：为什么需要主从复制？

平时我们单机Redis只能扛少量并发，一旦遇到两个致命问题直接崩：

1. 读写压力拉满：商品详情、用户会话这类高频查询疯狂打单机Redis，CPU、内存直接打满，响应超时；
2. 数据丢了无备份：服务器宕机、磁盘损坏，内存数据直接清空，没有备份根本找不回数据。

而主从复制（Master-Slave）就是官方给出的解决方案，核心两大作用：

1. 读写分离，分担压力

写操作全部交给主节点，所有读请求分流到从节点，大幅降低主节点负载，海量查询场景性能直接翻倍。

2. 数据热备份，实现容灾

主节点的数据会自动同步到所有从节点，相当于实时多副本。就算主机彻底挂掉，从机还保留完整数据，不会出现数据全部丢失的惨剧。

补充小知识点：所有从节点默认只读，禁止写入，强行set会直接抛READONLY报错，保证数据只由主节点统一修改，避免多节点数据混乱。

二、手把手实操：搭建一主两从环境

课程里用多配置文件多实例的方式搭建，一台机器跑3个Redis实例（6379主、6380/6381从），步骤超清晰，我全程跟着敲一遍成功了！

1. 拆分多份配置文件

新建myredis文件夹，复制原始redis.conf作为公共模板，再分别创建3个独立配置，区分端口、pid、rdb文件名：

# 1. 创建存放配置的目录mkdirmyredis&&cdmyredis# 复制基础配置cp/opt/redis-6.2.1/redis.conf ./# 创建6379主节点配置vimredis6379.conf# 写入内容include /myredis/redis.conf pidfile /var/run/redis_6379.pid port6379dbfilename dump6379.rdb# 创建6380从节点配置vimredis6380.conf include /myredis/redis.conf pidfile /var/run/redis_6380.pid port6380dbfilename dump6380.rdb slaveof127.0.0.16379# 核心：绑定6379为主机# 创建6381从节点配置vimredis6381.conf include /myredis/redis.conf pidfile /var/run/redis_6381.pid port6381dbfilename dump6381.rdb slaveof127.0.0.16379

2. 启动所有实例并验证

# 依次启动三台redis服务redis-server redis6379.conf redis-server redis6380.conf redis-server redis6381.conf# 查看进程确认启动成功ps-ef|grepredis

登录6379主节点，执行info replication查看主从状态：

redis-cli-p6379127.0.0.1:6379>info replication# Replicationrole:master connected_slaves:2# 成功识别两台从机slave0:ip=127.0.0.1,port=6380,state=online slave1:ip=127.0.0.1,port=6381,state=online

3. 测试数据同步

主机写入一条数据，从机直接读取，完美同步：

# 主机操作127.0.0.1:6379>setstudent zhangsan OK# 从机查询redis-cli-p6380127.0.0.1:6380>get student"zhangsan"# 从机尝试写入，直接报错只读127.0.0.1:6380>settest123(error)READONLY You can'twriteagainst areadonly replica.

三、底层核心：主从同步完整原理

很多同学只会搭建，但一问同步流程就卡壳，这里分全量复制、增量复制两步讲清楚，面试必问！

1. 全量复制（首次连接必走）

1. 从节点启动，执行slaveof绑定主节点后，主动向Master发送SYNC同步命令；
2. Master收到指令，fork一个子进程生成当前全量数据RDB快照文件；
3. Master一边传输RDB给从机，一边缓存同步期间新收到的所有写指令；
4. 从机接收RDB文件，清空自身原有数据，加载快照到内存；
5. Master把缓存的新增写命令全部发给从机，从机逐条执行，完成完整数据同步。

2. 增量复制（日常同步，断开重连优化）

早期老版本Redis只要从机短暂断开，就会重新全量同步，海量数据场景巨耗性能。新版本引入复制缓冲区repl_backlog优化：

• Master持续把所有写操作存入环形缓冲区；
• 从机断线重连后，发送PSYNC携带自身同步偏移量offset；
• Master对比offset，如果缓冲区还存着这段数据，直接补发增量指令，不用全量同步；
• 只有偏移量超出缓冲区范围，才会再次执行全量复制。

补充两个实操现象

1. 从节点重启后自动同步：从机宕机再启动，slaveof配置永久生效，重启后自动连接主机拉取数据；
2. 主机宕机，从机不会自动上位：单纯主从模式没有自动故障转移，主机挂掉后从机永远是slave角色，只能手动执行slaveof no one手动升级为主，也就是课程里说的「反客为主」。

四、两种拓展主从架构：薪火相传 & 手动切换主机

1. 薪火相传（链式主从）

架构：6379(主) → 6380(从+中间主) → 6382(从)
简单说从节点也可以挂载自己的从节点，好处是分摊主节点同步压力，所有同步流量不用全部压在6379。
缺点也很明显：中间节点宕机，下游所有从节点全部断连，数据同步中断，生产环境很少用。

搭建只需要给6382配置slaveof 127.0.0.1 6380即可，实操很简单。

2. 反客为主（手动故障切换）

主机6379宕机，业务无法写入，手动把从机升级为主机：

# 登录6380从机，解除从属关系，变成新主127.0.0.1:6380>slaveof no one OK# 此时6380可以正常写数据127.0.0.1:6380>setnewdata999OK# 剩下的从机重新绑定新主机redis-cli-p6381127.0.0.1:6381>slaveof127.0.0.16380

但手动切换有致命缺陷：故障需要人工发现、人工操作，线上突发宕机来不及处理，于是就有了哨兵Sentinel。

五、哨兵模式：主从自动故障切换

1. 哨兵是什么？

哨兵就是运行在独立进程里的监控程序，相当于Redis的「运维管理员」，后台持续监控所有主、从节点，主机宕机自动投票选出新主，全程无需人工干预，是生产标准搭配。

哨兵三大核心功能：

1. 监控：持续ping主从节点，检测节点是否下线；
2. 通知：节点异常时把故障消息推送给客户端；
3. 自动故障转移：主机故障，通过投票机制选出最优从机升级新主，其余从机自动挂载新主机。

2. 哨兵极简搭建

在myredis目录创建sentinel.conf配置文件（文件名固定不能改）：

# 格式：sentinel 监控名 主机ip 端口 投票票数 sentinel monitor mymaster 127.0.0.1 6379 1 # 数字1代表：至少1个哨兵认定主机故障，才判定客观下线

启动哨兵进程：

redis-sentinel sentinel.conf

测试故障：关闭6379主节点，等待一小段时间，哨兵自动完成切换，6380/6381其中一台升级为主；
如果重启原来故障的6379，它不会变回主机，只会自动成为新主的从节点。

3. 哨兵选举新主的优先级规则

主机宕机后，哨兵会按三层规则筛选最优从节点，依次判断：

1. 副本优先级replica-priority：redis.conf中replica-priority数值越小，优先级越高；设置0永远不能当选主机；
2. 复制偏移量offset：offset越大，说明同步的数据越完整，优先选；
3. 运行id最小：前两项相同，随机生成的40位runid更小的从机上位。

六、主从复制常见面试考点汇总

基础问答

1. 主从复制作用？读写分离、数据备份、故障容灾；
2. 从节点能否写入？默认只读，禁止写操作；
3. 全量复制和增量复制区别？首次同步全量RDB，断线重连优先增量补发缓冲区指令；
4. 单纯主从模式缺点？主机宕机无法自动切换，需要人工操作。

哨兵相关

1. 哨兵作用：监控、消息通知、自动故障转移；
2. 哨兵判断主机下线逻辑：主观下线（单个哨兵认为故障）→客观下线（达到配置票数）；
3. 新主选举三条优先级：优先级数值、复制偏移量、runid。

易踩坑细节

1. 链式主从会有单点故障风险，生产优先一主多从搭配哨兵；
2. 哨兵不能和Redis集群混淆：哨兵解决单套主从高可用，Redis集群解决数据分片扩容；
3. 主从同步全程操作原子性，指令不会出现半截同步的脏数据。

七、学习小结

最开始看课程文档的时候，分不清主从、哨兵、集群三者的定位，实操一遍才理清逻辑：

1. 主从复制：基础，解决备份、读写分离；
2. 哨兵Sentinel：主从的配套工具，解决主机宕机自动切换；
3. Redis Cluster集群：数据分片，海量数据水平扩容，最少3主节点。