1. 复制(replica)介绍
Redis数据库支持主从复制，master以写为主，slave以读为主，当master数据变化的时候，自动将新的数据异步同步到slave数据库。
实现读写分离、容灾恢复、数据备份、水平扩容支撑高并发。
2. 案例演示
2.1 架构说明
一个master，两个slave。
2.2 以配置文件方式启动主从复制
以端口为6379的redis举例修改配置文件并启动主从复制
1. 开启daemonize
2. 注释
3. 关闭protected-mode
4. 指定端口
5. 指定当前工作目录
6. pid文件名
7. log文件名
8. requirepass
9. dump.rdb
10. aof（本步骤可选，非必须）
11. 从机访问主机的访问密码(slave从机需要配置，master主机不用配置)
12. 先启动主机master，再启动从机slave
13. 主从关系查看
-
主机日志
-
从机日志
-
命令
info replication
14. 主从问题小结
从机不可执行写命令
slave是从头开始复制还是从切入点开始复制?
master启动，写到k3
slave1跟着master同时启动，跟着写到k3
slave2写到k3后才启动，那之前的是否也可以复制？
Y，首次一锅端，后续跟随，master写，slave跟
主机shutdown后情况如何？从机是上位还是原地待命
从机不动，原地待命，从机数据可以正常使用；等待主机重启动归来
主机shutdown后重启，主从关系能恢复吗，从机能否顺利复制
主从关系可以恢复，从机可以顺利复制。
某台从机down掉后，主机继续，从机重启后会继续复制吗
手动配置复制关系： 如果在启动过程中没有直接在从机的配置文件中定义主机（Master）信息，而是通过命令行启动并使用类似于 SLAVEOF 127.0.0.1 6379 的命令将从机连接到主机，那么在从机宕机后重新启动时，它将会以自己作为主机的状态启动，并不会自动恢复数据同步。为了使数据同步重新开始，需要再次手动执行 SLAVEOF 127.0.0.1 6379 这样的命令，将其重新设为主机的从机，以实现数据同步。
配置文件定义复制关系： 如果在从机的配置文件中明确指定了主机的信息，那么在从机宕机后重新启动时，它会自动尝试连接到指定的主机并恢复数据同步。这种情况下，从机会重新以从属身份连接到主机，继续同步数据。
2.3 以命令方式启动主从复制
三台机器都是主机状态，在预设的从机上执行命令：slaveof 主机ip 主机端口
1. 从机重启以后的效果
2. 配置VS命令实现的区别
配置方式实现，持久稳定。
命令方式实现，当次生效。
2.4 从机是否可以作为其他从机的主机
上一个从机可以是下一个从机的主机，从机同样可以接受其他从机的连接和同步请求，那么此从机就作为链条中下一个从机的主机，可以有效减轻上一层主机的写压力。
2.5 从机变回主机命令
SLAVEOF NO ONE
对一个从属服务器执行命令 SLAVEOF NO ONE 将使得这个从属服务器关闭复制功能，并从从属服务器转变回主服务器，原来同步所得的数据集不会被丢弃。
利用『 SLAVEOF NO ONE 不会丢弃同步所得数据集』这个特性，可以在主服务器失败的时候，将从属服务器用作新的主服务器，从而实现无间断运行
3. 复制原理和工作流程
3.1 slave启动，同步初请
slave启动成功连接到master后，会发送一个sync命令。
slave首次全新连接master，一次完全同步（全量复制）将被自动执行，slave自身原有数据会被master数据覆盖清楚。
3.2 首次连接，全量复制
master节点收到sync命令后会开始在后台保存快照（即RDB持久化，主从复制会触发RDB），同时收集所有接收到的用于修改数据集的命令缓存起来，master节点执行RDB持久化后，master将RDB快照文件和所有缓存的命令发送到所有slave，以完成一次同步。
slave在接收到文件后，将其存盘并加载到内存中，从而完成复制的初始化。
3.3 心跳持续，保持通讯
master发出PING包的周期，默认是10秒
3.4 进入平稳，增量复制
master继续将新收集到的所有的修改命令，依次传递给slave，完成同步。
3.5 从机下线，重连续传
master会检查backlog里面的offset，master和slave都会保存一个复制的offset还有一个masterID，offset是保存在backlog中的，master只会把已经复制的offset后面的数据复制给slave，类似于断点续传。
4. 复制的缺点
4.1 复制延时，信号衰减
由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。
4.2 master down掉以后无法处理
默认情况下不会在slave中自动选出一个节点当做master。