Redis - 主从复制
主从复制，主机数据更新后根据配置和策略，自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主。
利用 Redis 可以做到 读写分离、容灾恢复 等
怎么玩？
1. 配从(库)不配主(库)
2. 从库配置：slaveof 主库IP 主库端口，每次与master断开之后，都需要重新连接，除非你配置进redis.conf文件，Info replication命令查看该 redis 库的角色。
3. 修改配置文件细节操作
1. 拷贝多个 redis.conf文件
2. 开启 daemon yes
3. pid 文件名字
4. 指定端口
5. log 文件名字
6. dump.rdb文件
4. 常用三招
1. 一主二仆
启动三个客户端
日志文件
查看每个 redis 数据库的角色：info replication，三个全是 master
以 6379 为 master，6380、6381作为 slave，在选中作为从库的服务器上执行 SLAVEOF 127.0.0.1 6379（小弟拜老大）
此时在master（6379）上执行set k4 v4 ,问题是：两个slave（6380、6381上面可以get k4 吗？）验证如下：有
再问：k1\k2\k3在两个从库上有吗？也即可以get到吗？验证如下：有
再看每个库的角色，一主二仆
再问：在三台机器上同时执行相同的命令set k6 v6？1. 先到先得？2. 后者覆盖？3. 主机执行后，从机执行报错，无法执行？
1. 主机抢先执行：结果如3（主机可写，从机只读）
再问：如果主机挂了，从机如何变化？1. 趁机上位？2. 原地待命？验证如2，连接状态是 down
再问：主机又连上了？1. 照旧？2. 主从体系乱掉？验证如下1，照旧，忠心耿耿
再问：从机死了？只要跟master断开了，就需要重新连接，除非你配置到了文件里面
6380 重新拜老大
2. 薪火相传
上一个 Slave 可以是下一个 slave的 Master，Slave同样可以接收其他 slaves 的连接和同步请求，那么该 slave 作为了链条中下一个的 master ,可以有效减轻master的写压力，这个类似于一个链条的结构。中途变更转向:会清除之前的数据，重新建立拷贝最新的，Slaveof 新主库IP 新主库端口
3. 反客为主（纯手动）
SLAVEOF no one命令，使当前数据库停止与其他数据库的同步，转成主数据库
复制原理：
- Slave启动成功连接到master后会发送一个sync命令
- Master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，maste 将传送整个数据文件到slave,以完成一次完全同步
- 全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
- 增量复制：Master继续将新的所有收集到的修改命令依次传给slave,完成同步
- 但是只要是重新连接master,一次完全同步（全量复制)将被自动执行
哨兵模式（sentinel）：
是什么？
反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库
怎么玩(使用步骤)？
调整结构，6379 老大 带着 6380、6381 两位小弟
自定义的/myredis目录下新建 sentinel.conf 文件，名字绝不能错
配置哨兵,填写内容：
1. sentinel monitor 被监控数据库名字(自己起名字) 127.0.0.1 6379 1；
2. 上面最后一个数字1，表示主机挂掉后salve投票看让谁接替成为主机，得票数多少后成为主机
启动哨兵：
1. redis-sentinel /myredis/sentinel.conf ；
2. 上述目录依照各自的实际情况配置，可能目录不同
正常主从演示：
原有的master挂了：哨兵后台动作
投票新选：重新选出来的老大
重新主从继续开工,info replication查查看
问题：如果之前的master重启回来，会不会双master冲突？
不会，他会变成一个从库。
一组sentinel能同时监控多个Master
复制的缺点：复制延时， 由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。