Redis的复制(Master/Slave)

 主从策略：

　　也就是我们所说的主从复制，主机数据更新后根据配置和策略，自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主。

 作用：

　　1、读写分离

　　2、容灾恢复

 配置操作：

　　配置从库通过slaveof host port 关联主库

 修改配置文件详细：

pidfile -> /var/run/redis_6379.pid 、 /var/run/redis_6380.pid 、 /var/run/redis_6381.pid
port    -> 6379 、 6380 、 6381
logfile -> /var/log/redis_6379.log 、 /var/log/redis_6380.log  /var/log/redis_6381.log 
dbfilename      -> dump_6379.rdb 、 dump_6380.rdb 、 dump_6381.rdb
appendfilename  -> "appendonly_6379.aof" 、 "appendonly_6380.aof" 、 "appendonly_6381.aof"

 常用方法：

　　1、一龙双凤：一个Master两个Slave

 

　　2、薪火相传：

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

　　　　b.中途变更转向:会清除之前的数据，重新建立拷贝最新的。

　　　　c.  

　　3、反客为主

 一龙双凤：

分别运行三个配置文件,指定三个不同的Port连接-> 6379、6380、6381
通过info replication 查看主从关系

现在都是master，相互之间没有关联
建立关系之前，在6379中设置k1、k2、k3、k4的值

 在6380、6381中运行slaveof 127.0.0.1 6379 同时关联6379，通过info replication查看关系

 在6380中进行通过k1 k2...获取关联之前6379设置的值

 关联之后，6380和6381通过不同的key可以获取6379以前设置的值，并且关联之后的6379创建的值也可以获取.

 但是需要注意的是当6380和6381通过slaveof关联6379之后，就组成了主从关系，此时的6380和6381是不可以进行写的

 问题1：主从关系的话，如果“主”挂了，那么从会顶上去变成主吗？

显然，这种关联状态下，如果“主”宕机，那么两个“从”不会编程“主”，咸鱼翻身还是咸鱼。
问题2：如果“主”又复活了，那么还会恢复主从关系吗

如图所示，6380和6381的连接状态由down变up了，所以恢复了主从关联。

问题3：如果“从机”挂了，然后重启的，还会自动链接到“主机”上吗？

如果“从机”中途挂了，再次启动会失去主从联系，需要重新slaveof才能关联“主机”，除非配置进redis.conf文件。

 薪火相传：

1、 分别运行三个配置文件,指定三个不同的Port连接-> 6379、6380、6381，此时三者没有任何关联，从机[ 6380 ]通过slaveof 127.0.0.1 6379 链接主机，从机[ 6381 ]通过slaveof 127.0.0.1 6380 链接从机[ 6380 ],分别通过info replication查看关联：

这种方法是去中心化，减少了Master的压力，但是如果中途6380变更的话，数据将会重新拷贝，6381的数据也会跟着变化。

 反客为主：

 　　在一龙双凤的情况下，假如主机宕机了，那么从机的任意一台可以通过slaveof no one来成为主机，剩下那个有两个选择：1、等待原主机(6379)重新上线；2、成为新主机(6380)的从机。

　　 在薪火相传的情况下，假如主机宕机了，那么紧跟着主机的Slave通过slavof no one 来成为新主机。

分别运行三个配置文件,指定三个不同的Port连接-> 6379、6380、6381，[6380]和[6381]分别运行SLAVEOF 127.0.0.1 6379关联主机[6379]:

此时，主机[6379]挂了，我们通过slace no one 让[6380]成为新的主机，将[6381]重新关联到[6380]上：

 复制过程：

1、Master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令；
2、在后台进程执行完毕之后，master将传送整个数据文件到slave,以完成一次完全同步；
3、全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中；
4、增量复制：Master继续将新的所有收集到的修改命令依次传给slave,完成同步；
5、但是只要是重新连接master,一次完全同步（全量复制)将被自动执行；

 哨兵模式：

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

 详细操作：

1、创建哨兵配置文件，必须以sentinel.conf为文件名。

2、编辑配置文件sentinel.conf：

　　内容： sentinel monitor 被监控数据库名字(自己起名字) 127.0.0.1 6379 1

　　上面最后一个数字1，表示主机挂掉后salve投票看让谁接替成为主机，得票数多少后成为主机。

3、设置主从：

 

4、启动哨兵：

　　redis-sentinel sentinel.conf  

 

5、当作为Master的 [ 6379 ]出现故障关闭的时候，哨兵系统就会进行对[ 6379 ]关联的“从机”进行投票选举，票数高的就会自动变为Master，剩下的“从机”自动变成“新主机”的从机。

选举后的关系：[ 6380 ] :主机  、[ 6380 ] :从机  

6、此时 [ 6380 ]为主机、[ 6381 ]为从机，如果[ 6379 ]此时回来会是以什么状态回归呢？

 

如图所示，以前的 [ 6379 ]主机宕机后重启，会变成[ 6380 ]的Slave(从机)。

7、一组sentinel能同时监控多个Master，只需要写进sentinel.conf配置。  

 主从优缺点：

优点：

　　　1、在一个Redis集群中，master负责写请求，slave负责读请求，这么做一方面通过将读请求分散到其他机器从而大大减少了master服务器的压力，另一方面slave专注于提供读服务从而提高了响应和读取速度。
　　　2、在一个Redis集群中，如果master宕机，slave可以介入并取代master的位置，因此对于整个Redis服务来说不至于提供不了服务，这样使得整个Redis服务足够安全。
　　　3、水平增加Slave机器可以提高性能

缺点：

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