主从复制
主从复制介绍
分析单个Redis 的问题
在一个项目中读的操作是比写的操作要多的 像京东，淘宝等等同一时刻看的人是远远多于买的人的所有单个redis既要承担写的操作又要承担读的操作效率低在高并发的情况下不稳定
所以引出了主从复制
一图胜千言
Redis 主从复制的示意图
对上图的解读
- 上图描述了主机数据更新后, 自动同步到备机的master/slaver 机制
- Master 以写为主，Slaver 以读为主
- 好处: 读写分离, 提升效率(理解: 读写分离后, 将读和写操作分布到不同的Reids, 减少单个Redis 的压力, 提升效率)
- 好处: 容灾快速恢复(理解: 如果某个slaver , 不能正常工作, 可以切换到另一个slaver)
- 主从复制, 要求是1 主多从, 不能有多个Master( 理解: 如果有多个主服务器Master,那么slaver 不能确定和哪个Master 进行同步, 出现数据紊乱)
- 要解决主服务器的高可用性, 可以使用Redis 集群
搭建一主多从
需求说明
- 搭建主从复制结构
- 这里我们搭建一主二从即可, 其它slaver 可以依此完成
思路分析
开始执行
- 创建目录, 并拷贝redis.conf 到/wyxredis
创建命令是 mkdir /wyxredis
到创建的目录下 cd /wyxredis
然后把redis.conf复制到我们刚刚创建的目录
cp /etc/redis.conf /wyxredis/redis.conf
- vi /wyxredis/redis.conf , 进行如下设置,
- 创建3 个文件/wyxredis/redis6379.conf /wyxredis/redis6380.conf /wyxredis/redis6381.conf并编辑
include /wyxredis/redis.conf
pidfile /var/run/redis_6379.pid
port 6379
dbfilename dump6379.rdb
注意前面3个文件都是这样的操作 只是端口号要发生改变
-
启动三台redis 服务器
-
连接到3 个Redis 服务, info replication 打印主从复制的相关信息, 如图, 这时三台Redis都是Master
connected_slaves代表的是有几个从服务器
- 将6380 和6381 配置成slaver, 6379 作为主机-在slaver 执行如命令, 成为某个实例的从服务器
-指令说明: slaveof <master_ip> <master_port>
解释上图
role:slave代表的是从服务器 Master带表的主服务器
master_host 指的是主服务器的ip
master_port 指的是主服务器的端口
master_link_status_up代表是主服务器是否在线
其它的其实就是根据英语单词来解释的还是很好理解的
- 在主机上写，在从机上可以读取数据, 如果你在从机上写入数据，就报错
- 到此一个基本的主从复制结构就OK 了.
主从复制-原理
原理示意图
解读上图-主从复制流程
- Slave 启动成功连接到master 后会发送一个sync 命令
- Master 接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后, master 将传送整个数据文件到slave,以完成一次完全同步
- slave 服务在接收到数据库文件数据后，将其存盘并加载到内存中, 即全量复制
- Master 数据变化了, 会将新的收集到的修改命令依次传给slave, 完成同步, 即增量复制
- 但是只要是重新连接master,一次完全同步（全量复制)将被自动执行
一主二仆
如果从服务器down 了, 重新启动, 仍然可以获取Master 的最新数据
如果主服务器down 了, 从服务器并不会抢占为主服务器, 当主服务器恢复后, 从服务器仍然指向原来的主服务器.
薪火相传
示意图
解读上图
-
上一个Slave 可以是下一个slave 的Master，Slave 同样可以接收其他slaves 的连接和同步请求，那么该slave 作为了链条中下一个的master, 可以有效减轻master 的写压力,去中心化降低风险
-
用slaveof <master_ip><master_port>
-
风险是一旦某个slave 宕机，后面的slave 都没法同步
-
主机挂了，从机还是从机，无法写数据了
实验
- 将6381 的主机设置为6380, 他的数据同步就是从6380 获取
- 查看6380 和6379
反客为主
1、在薪火相传的结构下, 当一个master 宕机后, 指向Master 的slave 可以升为master, 其后面的slave 不用做任何修改
2、用slaveof no one 将从机变为主机(说明: 后面可以使用哨兵模式, 自动完成切换.)
实验
哨兵模式(sentinel)
工作示意图
2、哨兵模式(如图): 反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库
实验
- 调整为一主二仆模式，6379 带着6380、6381 , 根据前面讲解的调整即可
- 创建/wyxredis/sentinel.conf , 名字不能乱写, 按照指定的来
sentinel monitor redis_master 127.0.0.1 6379 1
说明:
- redis_master 为监控对象起的服务器名称
- 1 表示至少有多少个哨兵同意迁移的数量, 这里我配置1 表示只要有1 个哨兵同意迁移就可以切换
启动哨兵, 注意看哨兵的端口是26379
当主机挂掉，从机选举中产生新的主机
如果原来的主机重启, 会自动成为从机
注意事项和细节
1、在哨兵模式下，主机down 后的执行流程分析
2、解读上图- 哨兵如何在从机中, 推选新的Master 主机, 选择的条件依次为:
- 优先级在redis.conf 中默认：replica-priority 100，值越小优先级越高
- 偏移量是指获得原主机数据的量, 数据量最全的优先级高
- 每个redis 实例启动后都会随机生成一个40 位的runid, 值越小优先级越高
