是什么
主节点的数据同步到从节点上，主节点负责写，从节点负责读。
能干嘛
- 读写分离
- 容灾恢复
怎么玩
1.配从（库）不配主（库）
2.从库配置：slaveof 主库IP 主库端口 （每次与master断开之后，都需要重新连接，除非配置进redis.conf文件）
3.修改配置文件细节操作
- 拷贝多个redis.conf文件
- 开启 daemonize yes
- Pid文件名字 （如 pidfile "/var/run/redis_6380.pid"）
- 指定端口 （如 port 6380）
- Log 文件名字 （如 logfile "6380.log"）
- Dump.rdb名字 （如 dbfilename "dump6380.rdb"）
常用方法
- 一主二仆 （此时并没有将slaveof写进配置文件）
即一个Master两个Slave，现设定6379的为master，6380、6381为slave。
master所写的内容slave都能读取到（包括6380和6381成为slave之前6379所写的内容）
如果slave对master设置的键值进行修改会发生什么？
这说明slave只负责读取。
如果发生一些故障导致master挂了，那slave如何表现呢？是翻身做master还是继续当slave？
很明显，此时角色还是为slave。
如果master又回来了，那slave是继续跟着master干，还是不再听指挥了呢？
在当前配置下，slave还是会继续跟着master。
如果某个slave挂了（这里假设端口为6380的挂了），当这个slave又启动的时候会发生什么？是继续跟着原来的master还是自己当master？
在这种情况下slave会自己成为master。
- 薪火相传
上一个slave可以是下一个slave的master，slave同样可以接收其他slave的连接和同步请求，那么改slave作为链中下一个的master，可以有效减轻master的写压力。
让6379成为master，6380成为6379的slave，6381成为6380的slave（虽然在逻辑上6380既为master又为slave，但在计算机中显示仍为slave）。
- 反客为主
使用slaveof no one命令：使当前库停止与其他库的同步，转成主库。
复制原理
slave启动成功连接到master后会发送一个sync命令，master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave，以完成一次完全同步。
全量复制：slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
增量复制：master继续将新的所有收集到的修改命令依次传给slave，完成同步。
但是只要是重新连接master，一次完全同步（全量复制）将被自动执行。
复制的缺点
- 复制延时
由于所有的写操作都是先在master上操作，然后同步更新到slave上，所以master同步到slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，slave机器数量的增加也会使这个问题更加严重。
哨兵模式（sentinel）
是什么
反客为主的自动版，能够后台监控主机是否出现故障，如果故障了根据投票数自动将从库转换为主库。
使用步骤
- 调整结构，6379带着6380、6381
- 自定义的目录（我的为 /myredis）下新建 sentinel.conf 文件，名字绝不能错
- 配置哨兵，填写内容（sentinel monitor 被监控数据库名字（自己起名字）127.0.0.1 6379 1 【此处的1表示主机挂掉后slave投票看让谁接替成为主机，得票数多少后成为主机】）
- 启动哨兵（redis-sentinel /myredis/sentinel.conf）
让6379挂掉，则会从6380和6381中投票选出新的master。
问题：如果此时6379回来了，那结果又当如何呢？是否会造成双master冲突？