Redis主从复制(新)

        像一些大型的项目，为了保证系统的稳定性，会有一台Redis服务器专门作为主机(master)，还会有多台服务器作为从机(slave)，主机可专门用作写数据，然后根据配置和策略，自动将数据同步到从机，而从机专门用来读数据，从而实现了读写分离，也叫主从复制。

主从复制的作用有：

• 读写分离，这样性能得到扩展。

• 数据备份。

• 容灾处理，恢复快速。

1.一主二仆

1.首先启动三台redis服务器：

 2.分别进入到客户端，可以通过info replication命令打印信息：

3.发现服务启动后，3台服务均默认为主机，我们要将6380和6381配置为从机，成为6379的从服务器。

4.在6380服务和6381服务上执行slaveof 127.0.0.1 6379命令即可，此时主机可以进行读写操作，而从机只能进行读操作。

注意：

• 如果主机6379挂掉，从机依然是从机，不会上位为主机，没有主机只是没有写操作。等到主机重启后，一切恢复如初。

• 从机挂掉重启后又会成为一台"空"主机，就需要重新设置slaveof 127.0.0.1 6379。

主机的数据是怎么同步到从机的？

一阶段——>如果现有一个从机突然连接到主机上时：

• slaveof命令成功后证明从机连接成功，从机会向master主机发送一个同步命令。

• master接收到同步命令之后，主机会自动触发进行数据持久化操作，同时将所有接收到的用于修改数据集命令缓存起来，持久化后主机将磁盘中的rdb文件发送到各从服务器，从服务器拿到rdb文件后本地磁盘保存并读取加载数据，此操作也称为全量复制。

二阶段——>平常主机上的数据怎么同步到从机上：

• 主机持续将新的所有收集到的修改命令自动依次传给从机，完成同步，此操作也称为增量复制。

2.薪火相传

        上面的一主二仆主机需要挨个传送数据给从机，这样主机压力有点大，能不能使从机之间进行数据的传输呢？

        上一个slave1其实也可以是下一个slave2的Master，slave1同样可以接收其他slave的连接和同步请求，那么该slave1作为了链条中下一个的"master"(实际还是6379的从机)，可以有效减轻6379master的传输压力,去中心化降低风险。

        用salveof ip port命令进行操作。风险就是这个salve1宕机了，后面连接的salve1的从机就没法同步备份了。如果6379主机master挂了，那么从机还是从机，只是无法写数据了。

3.反客为主

        反客为主就是当6379master主机宕机后，可以有一个从机slave可以升级为master主机，其它后面的slave不用做任何修改。需要手动用 slaveof no one 将从机变为主机。但是缺点是我们要手动设置，可以采用哨兵模式来自动完成。

4.哨兵机制

 

        Redis的哨兵机制是一套独立的模式，哨兵可看作是一个独立的进程，用来监视主机，我们需要单独启动，该进程发送命令，等待主机的响应，达到监控主机Redis服务的作用。

        如果在规定的时间内，接收不到主机的响应，那就说明主机挂掉了，则会通过一套选举机制，从众多的从机当中选取一台当作Redis服务的主机，原主机的直系小弟从机配置会自动变换，变为选举的主机的从机。就算挂掉的主机重新上线，还是会成为刚被选举的主机的从机。

4.1从机之间是怎么推选的？

1.选择配置文件中优先级靠前的，值越小，优先级越高，默认为100。

2.选择和原主机数据同步最全的从机。

3.选择runid最小的从机，启动时，会自动生成一个40位的runid。

5.主从复制的问题

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