一. 什么是主从复制

主机数据更新后根据配置和策略，自动同步到备机的master/slaver机制，Master 以写为主， Slave 以读为主*

二. 作用

创建好多台Redis服务器
- 拷贝Redis.conf文件到指定路径下，假设路径为： /myredis/redis.conf
  - 修改文件的一些参数：开启daemonize yes，Appendonly 关掉或者换名字
- 在新建几个不同名字的Redis配置文件
- 分别在各个配置文件中加入以下内容
```
include /myredis/redis.conf     #拷贝的Redis.conf的路径
pidfile /var/run/redis_6379.pid #新的Redis服务器pid文件名（自己指定）
port 6379                       #新的Redis服务器端口号（自己指定）
dbfilename dump6379.rdb         #RDB持久化文件名（自己指定）
```
- 启动三台redis服务器（此处演示一主两从）
- 查看系统进程，看看三台服务器是否启动：ps -ef | grep redis
指定好从库（默认全是主库，所以无需指定主库）
- 在每个从库的Redis服务器上执行命令：slaveof <ip> <port> ip和port为主库ip和端口
查看各个从库的状态：info replication
- 如下就代表配置成功

之后从库中无法进行写操作，只能从主库写，从库读

Slave启动成功连接到master后会发送一个sync命令
Master接到命令启动后台的存盘进程，同时Master服务器的数据立即进行持久化，在后台进程执行完毕之后，master将传送整个数据文件(RDB持久化文件)到slave,以完成一次完全同步
全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
增量复制：Master继续将新的所有收集到的修改命令依次传给slave,完成同步
但是只要是重新连接master,一次完全同步（全量复制)将被自动执行

由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。

说明：重新连接主库之后，会直接进行全量复制，直接完全同步

上一个Slave可以是下一个slave的Master，Slave同样可以接收其他 slaves的连接和同步请求，那么该slave作为了链条中下一个的master, 可以有效减轻master的写压力,去中心化降低风险。

当一个master宕机后，后面的slave可以立刻升为master，其后面的slave不用做任何修改。

反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库

自定义的/myredis目录下新建sentinel.conf文件，名字绝不能错
配置哨兵：sentinel monitor mymaster 127.0.0.1 6379 1
- 其中mymaster为监控对象起的服务器别名， 1 为至少有多少个哨兵同意迁移的数量，127.0.0.1 6379为监控的主机。
启动哨兵
执行redis-sentinel /myredis/sentinel.conf
当主机挂了，哨兵们会按照选举策略切换新的主机（见下）

选择新的主机的条件优先级：
- 选择优先级靠前的：replica-priority 100 可以在redis的配置文件中设置，值越低优先级越高（默认100）
- 选择偏移量最大的：偏移量是指获得原主机数据最全的
- 选择runid最小的从库：每个redis实例启动后都会随机生成一个40位的runid
选出新主机后，哨兵向其他从机发送slaveof <ip><prot>命令，使他们成为新主机的从机
当已下线的原主机重新上线后，哨兵也会发送slaveof <ip><prot>命令，让他成为也新主机的从机