Redis 主从复制、读写分离、高可用（七）-part 1

Redis主机数据更新后根据配置和策略，自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主，这样就可以减轻服务器的压力了。

redis主从复制之配置介绍

复制的原理介绍

slave启动成功连接到master后会发送一个sync命令，Master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave,以完成一次完全同步

1. 全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
2. 增量复制：Master继续将新的所有收集到的修改命令依次传给slave,完成同步

但是只要是重新连接master,一次完全同步（全量复制)将被自动执行

case 1：一主N从

（在这里我只使用了一台Linux机器，但是通过配置同样可以达到Redis集群的需求，如果有多个服务器，配置是一样的）

首先从拷贝3个redis.conf文件（拷贝两个也是可以的，这里我是为了区分Master/Slave）

那么接下来就是修改配置了

1.主机配置介绍（为了说明在主从复制的时候访问的不是同一个数据库文件，将数据库文件名也相应的修改） 

2.从机配置介绍

OK配置完成了，那么接下来就是启动redis服务并连接，查看配置是否有效

通过info replication命令查看信息

我们可以看到，3台服务器的redis服务成功启动，角色都是master，那么接下来就是要区分主从库了，通过命令slaveof 主机IP 主机redis端口

slaveof 127.0.0.1 6379

这样就可以了，然后再次通过info replication命令查看，发现这个时候端口号为6380,6381的redis从主库变成了从库

那么这个时候在主库中执行写的操作

在set k4之前做了set k1，k2，k3操作，然后6380，6381作为从库连接主库，发现主库中所有的数据在从库中都有，而且每个从库都有数据库文件

那么在这个时候我们在从库执行write操作的时候，发现是无法正确执行的

因为有了从库之后，读写就已经分离了，所以在从库中只能执行读的操作

上面呢我是通过命令的方式实现主从库的分离的，那么大家就会发现，这样子是很麻烦的，万一从库redis服务挂了之后，再次启动redis服务之后还要执行

slaveof 127.0.0.1 6369

这样子是很不人性化的，而且也是非常的麻烦，那么接下来就通过配置文件的方式实现主从库的分离

其他的从库也是这样配置，OK，配置已经好了，那么接下来就是启动redis服务了

我们可以看到，当redis服务启动之后，角色立马变成从库了，而不要向我们之前的需要手动敲命令，这样也是挺方便的

上面的case 1呢讲到了一主N从得模式

那么redis从库是否可以让其他的redis服务连接呢？

case 2：传宗接代

传宗接代的意思呢就是说一个主库下只有一个从库，而这个从库下又有其他的redis从库跟着。一个跟着一个，而不是一个主库下有跟着N个从库，这样子呢就可以去中心化，但是这样子呢会出现数据复制的延时，因为你是一个跟着一个，在主库中有数据的变化，那么下面的从库就会立即复制，但是这个时候只有一个从库，要等当前从库复制完成才可以再次向下复制

配置

将其中一台的配置修改

启动redis服务

服务启动成功，那么中间那一台连着主库的那个redis（也就是直连主库然后下面又跟着从库的那台）是什么角色呢？

可以看到，中间的那个redis从库依然是从库的角色，但是下面又跟着小弟。但是呢这个时候还是无法执行write的操作，因为中间的那个依旧是从库的角色

 

ps:若主宕机了，从会一直等待（后面会用 哨兵解决这个问题）