定义：主机数据更新后根据配置策略，自动同步到备的Master/slave机制，Master以写为主，Slave以读为主。
Tip：配从(从库)不配主(主库)
1.从库配置：
slave of 主库IP 主库端口
每次与master断开连接后，都需要重新连接，除非配置到redis.conf文件中
2.修改配置文件的操作细节：
一.修改进程管道文件：pidfile
二.修改端口：port
三.修改log文件名称
四.修改dump.rdb名称
五.开启daemonize yes
3.常用3招(三个窗口端口分别为：6379、6380、6381，后面内容均已此三个端口描述）：
一. 一主二仆（6379为主，6380、6381为仆） :
分别启动三个redis配置，在6380、6381上执行：slaveof 主机的IP 主机端口(例：slaveof 127.0.0.7 6379),使用命令 info replication 查看主备详情
笔记：1.从机不能进行写操作（只能读）
2.主机(6379)存储数据后，从机(6380、6381)执行slaveof命令，会将主机所有数据备份到从机上来
3.主机宕掉，从机还是slave角色，并不会上位成为master,链接状态变为down
4.主机从新启动后，还是master角色，从机的连接状态变为up
5.从机宕了，恢复后不再与之前的主机有关联，角色变为master,想要变为从机，需要再次执行命令slaveof
这种一主二仆的模式过于中心化，全部围绕一个主机来做数据备份，下面介绍薪火相传(一个节点接一个节点)的模式
二. 薪火相传 :
在6381上执行slaveof 127.0.0.1 6380，我们发现，6380既是6379的从机又是6381的主机
在6379上执行写的命令，在6381上同样能拿到
三. 反客为主 （主机宕掉，从 从机重新选举一个作为新的主机）:
命令：slaveof no one (使当前数据库停止与其他数据库同步，转成主数据库)
操作步骤：
1. 将三台redis还原回一主二仆的环境(6379为主机，6380与6381作为6379的从机)
2. 将6379关掉(模拟线上宕机情况),
3. 在6380中执行命令slaveof no one
4. 将6381改成6380的从机
5. 重新将6379启动
我们发现，6380变成了主机，底下连了一台6381从机，当6379重新连接后，底下没有挂任何从机（区别于一主二仆）
4.复制原理：
1. Slave连接到Master后发送一个sync命令，Master接到命令启动后台的存盘进程(同时收集所有接收到的修改数据的命令集[主库写操作]），后台进程完成后，Master将传送整个数据文件到slave来完成一次同步
2. 全量复制：第一次slaveof到主库的时候（接收到数据文件后，将其存盘并加载到内存中）
3. 增量复制：除第一次slaveof外，从库以后都是增量存储数据（接收主库传来的修改命令）
5.哨兵模式（类似反客为主的自动版）：
举例：生产环境，如果凌晨主机宕了，从机通过投票自动选举新的主机
操作步骤：
1. 调整环境现在主机是6379，从机为6380与6381
2. # cd /usr/local/bin (redis的启动目录)
3. # touch sentinel.conf (配置哨兵监控哪台主机，如果主机挂了，从机如何进行投票选举新的主机，名字绝对不能错)
4. # vim sentinel.conf，在sentinel.conf加入如下内容： sentinel monitor host6379 127.0.0.1 6380 1
host6379：被监控的主机名称(自己取)
1代表主机宕掉后，剩余的从机如果谁的票数多余1票，就将作为新的主机
5. 启动哨兵模式，执行命令：redis-sentinel sentinel.conf，你会看到如下图案：
从图中发现，哨兵开始巡逻6380与6381，只要6379挂掉，那么这两台从机就开始投票，谁票数多谁上位。
5. 将主机6379 shutdown，我们看到terminal窗口中出现如下信息：
结论：
6381变成了新的主机，
6380变成了6381的从机
重新将关闭后的6379启动，6379变成了6381的slave
6.复制的缺点：
由于所有的写操作都在Master上，然后同步到Slave,所以Master同步到Slave上有一定的延迟，当系统繁忙的时候，延迟问题会加重，Slave机器数量的增加也会导致问题更加严重
总结：
工作中一般都是哨兵模式