Redis主从复制

文章目录一、先搞懂为什么需要主从复制1. 读写分离分担压力2. 数据热备份实现容灾二、手把手实操搭建一主两从环境1. 拆分多份配置文件2. 启动所有实例并验证3. 测试数据同步三、底层核心主从同步完整原理1. 全量复制首次连接必走2. 增量复制日常同步断开重连优化补充两个实操现象四、两种拓展主从架构薪火相传 手动切换主机1. 薪火相传链式主从2. 反客为主手动故障切换五、哨兵模式主从自动故障切换1. 哨兵是什么2. 哨兵极简搭建3. 哨兵选举新主的优先级规则六、主从复制常见面试考点汇总基础问答哨兵相关易踩坑细节七、学习小结一、先搞懂为什么需要主从复制平时我们单机Redis只能扛少量并发一旦遇到两个致命问题直接崩读写压力拉满商品详情、用户会话这类高频查询疯狂打单机RedisCPU、内存直接打满响应超时数据丢了无备份服务器宕机、磁盘损坏内存数据直接清空没有备份根本找不回数据。而主从复制Master-Slave就是官方给出的解决方案核心两大作用1. 读写分离分担压力写操作全部交给主节点所有读请求分流到从节点大幅降低主节点负载海量查询场景性能直接翻倍。2. 数据热备份实现容灾主节点的数据会自动同步到所有从节点相当于实时多副本。就算主机彻底挂掉从机还保留完整数据不会出现数据全部丢失的惨剧。补充小知识点所有从节点默认只读禁止写入强行set会直接抛READONLY报错保证数据只由主节点统一修改避免多节点数据混乱。二、手把手实操搭建一主两从环境课程里用多配置文件多实例的方式搭建一台机器跑3个Redis实例6379主、6380/6381从步骤超清晰我全程跟着敲一遍成功了1. 拆分多份配置文件新建myredis文件夹复制原始redis.conf作为公共模板再分别创建3个独立配置区分端口、pid、rdb文件名# 1. 创建存放配置的目录mkdirmyrediscdmyredis# 复制基础配置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.163792. 启动所有实例并验证# 依次启动三台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:6379info replication# Replicationrole:master connected_slaves:2# 成功识别两台从机slave0:ip127.0.0.1,port6380,stateonline slave1:ip127.0.0.1,port6381,stateonline3. 测试数据同步主机写入一条数据从机直接读取完美同步# 主机操作127.0.0.1:6379setstudent zhangsan OK# 从机查询redis-cli-p6380127.0.0.1:6380get studentzhangsan# 从机尝试写入直接报错只读127.0.0.1:6380settest123(error)READONLY You cantwriteagainst areadonly replica.三、底层核心主从同步完整原理很多同学只会搭建但一问同步流程就卡壳这里分全量复制、增量复制两步讲清楚面试必问1. 全量复制首次连接必走从节点启动执行slaveof绑定主节点后主动向Master发送SYNC同步命令Master收到指令fork一个子进程生成当前全量数据RDB快照文件Master一边传输RDB给从机一边缓存同步期间新收到的所有写指令从机接收RDB文件清空自身原有数据加载快照到内存Master把缓存的新增写命令全部发给从机从机逐条执行完成完整数据同步。2. 增量复制日常同步断开重连优化早期老版本Redis只要从机短暂断开就会重新全量同步海量数据场景巨耗性能。新版本引入复制缓冲区repl_backlog优化Master持续把所有写操作存入环形缓冲区从机断线重连后发送PSYNC携带自身同步偏移量offsetMaster对比offset如果缓冲区还存着这段数据直接补发增量指令不用全量同步只有偏移量超出缓冲区范围才会再次执行全量复制。补充两个实操现象从节点重启后自动同步从机宕机再启动slaveof配置永久生效重启后自动连接主机拉取数据主机宕机从机不会自动上位单纯主从模式没有自动故障转移主机挂掉后从机永远是slave角色只能手动执行slaveof no one手动升级为主也就是课程里说的「反客为主」。四、两种拓展主从架构薪火相传 手动切换主机1. 薪火相传链式主从架构6379(主) → 6380(从中间主) → 6382(从)简单说从节点也可以挂载自己的从节点好处是分摊主节点同步压力所有同步流量不用全部压在6379。缺点也很明显中间节点宕机下游所有从节点全部断连数据同步中断生产环境很少用。搭建只需要给6382配置slaveof 127.0.0.1 6380即可实操很简单。2. 反客为主手动故障切换主机6379宕机业务无法写入手动把从机升级为主机# 登录6380从机解除从属关系变成新主127.0.0.1:6380slaveof no one OK# 此时6380可以正常写数据127.0.0.1:6380setnewdata999OK# 剩下的从机重新绑定新主机redis-cli-p6381127.0.0.1:6381slaveof127.0.0.16380但手动切换有致命缺陷故障需要人工发现、人工操作线上突发宕机来不及处理于是就有了哨兵Sentinel。五、哨兵模式主从自动故障切换1. 哨兵是什么哨兵就是运行在独立进程里的监控程序相当于Redis的「运维管理员」后台持续监控所有主、从节点主机宕机自动投票选出新主全程无需人工干预是生产标准搭配。哨兵三大核心功能监控持续ping主从节点检测节点是否下线通知节点异常时把故障消息推送给客户端自动故障转移主机故障通过投票机制选出最优从机升级新主其余从机自动挂载新主机。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. 哨兵选举新主的优先级规则主机宕机后哨兵会按三层规则筛选最优从节点依次判断副本优先级replica-priorityredis.conf中replica-priority数值越小优先级越高设置0永远不能当选主机复制偏移量offsetoffset越大说明同步的数据越完整优先选运行id最小前两项相同随机生成的40位runid更小的从机上位。六、主从复制常见面试考点汇总基础问答主从复制作用读写分离、数据备份、故障容灾从节点能否写入默认只读禁止写操作全量复制和增量复制区别首次同步全量RDB断线重连优先增量补发缓冲区指令单纯主从模式缺点主机宕机无法自动切换需要人工操作。哨兵相关哨兵作用监控、消息通知、自动故障转移哨兵判断主机下线逻辑主观下线单个哨兵认为故障→客观下线达到配置票数新主选举三条优先级优先级数值、复制偏移量、runid。易踩坑细节链式主从会有单点故障风险生产优先一主多从搭配哨兵哨兵不能和Redis集群混淆哨兵解决单套主从高可用Redis集群解决数据分片扩容主从同步全程操作原子性指令不会出现半截同步的脏数据。七、学习小结最开始看课程文档的时候分不清主从、哨兵、集群三者的定位实操一遍才理清逻辑主从复制基础解决备份、读写分离哨兵Sentinel主从的配套工具解决主机宕机自动切换Redis Cluster集群数据分片海量数据水平扩容最少3主节点。