Redis复制(replica)
是什么？
就是主从复制，master以写为主，Slave以读为主。当master数据变化的时候，自动将新的数据异步同步到其它slave数据库
读写分离
容灾恢复
数据备份
水平扩容支撑高并发
案例演示
架构说明
一个Master两个Slave，三台虚拟机，每台都安装redis
拷贝多个redis.conf文件
redis6379.conf、redis6380.conf、redis6381.conf
小口诀
三台虚拟机需要能相互ping通且需要注意防火墙配置
三大命令：
主从复制
replicaof 主库IP 主库端口，配从(库)不配主(库)
改换门庭
slaveof 新主库IP 新主库端口
自立为王
slaveof no one
修改配置文件细节操作
redis6379.conf为例，步骤如下：
开启daemonize yes
注释掉bind 127.0.0.1
protected-mode no
指定端口
指定当前工作目录，dir
pid文件名字，pidfile
log文件名字，logfile。如果日志文件和启动文件同级，这里可以配置为./6379.log，否则这里一定要写绝对路径，是个巨坑！！！
requiredpass
dump.rdb名字
aof文件，appendfilename
从机访问主机的通行密码masterauth,必须
从机需要配置，主机不用
一主二仆
方案1：配置文件固定写死主从关系
配置文件执行：replicaof 主库IP 主库端口
配从(库)不配(主)库：配置从机
先master，后两台slave依次启动
主从关系查看
日志
主机日志，vim 6379.log
备机日志 tail -f 6380.log
命令
127.0.0.1:6379> info replication
方案2：命令操作手动主从关系指令
从机停机去掉配置文件中的配置项，3台目前都是主机状态，各不从属
3台master
预设的从机上执行命令
salveof 主库IP 主库端口
配置 VS 命令的区别
配置，持久稳定永久生效；
命令，当成生效
薪火相传
上一个slave可以是下一个slave的master，slave同样可以接收其他slaves的连接和同步请求，那么该slave作为了链条中下一个的master,可以有效减轻主master的写压力
中途变更转向:会清除之前的数据，重新建立主从关系并拷贝最新的
slaveof 新主库IP 新主库端口
反客为主
slaveof no one 使当前数据库停止与其他数据库的同步关系
复制原理和工作流程
slave启动，同步初请
slave启动成功链接到master后会发送一个sync命令
slave首次全新连接master，一次完全同步(全量复制)将被自动执行，slave自身原有数据会被master数据覆盖清除
首次连接，全量复制
master节点收到sync命令后会开始在后台保存快照(即RDB持久化，主从复制时会触发RDB)，同时收集所有接收到的用于修改数据集的命令并缓存起来，master节点执行RDB持久化完后，master将RDB快照文件和所有缓存的命令发送到所有slave，以完成一次完全同步
而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中，从而完成复制初始化
心跳持续，保持通信
repl-ping-replica-period 10
进入平稳，增量复制
master继续将新的所有收集到的修改命令自动依次传送给slave，完成同步
从机下线，重连续传
master会检查backlog里面的offset，master和slave都会保存一个复制的offset还有一个masterId，offset是保存在backlog中的。master只会把已经缓存的offset后面的数据复制给slave，类似断点续传
复制的缺点
复制延时，信号衰减
由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。
master挂了怎么办？
默认情况下，不会在slave节点中自动选一个master
那每次都要人工干预？ -> 无人值守变成刚需