Redis入门（八）——Redis的主从复制
目录
- Redis主从复制简介
- 如何配置
- 测试复制
- 复制原理
- 哨兵模式
1.Redis主从复制简介
当系统的访问量越来越大，一台redis服务器已经支撑不了如此大的访问量时，为了解决这个问题，通常会采取的一种方式是主从架构Master/Slave，Master 以写为主，Slave 以读为主，Master 主节点更新后根据配置，自动同步到从机Slave 节点。这就是常说的redis的主从复制读写分离。redis的主从架构除了可以实现读写分离，在主机发生故障时还可以实现主从转换，从而保障系统具有一定的容灾能力。
根据系统的需要，主从结构可使用一主一从、一主多从、以及树状结构。具体结构如下图
2.如何配置
配置文件修改：
如何开启多个redis服务：首先将redis.conf 配置文件复制三份，通过修改端口分别模拟三台Redis服务器。
开启守护进程：daemonize yes
Pid文件名字：设置pidfile。例如：/var/run/redis_6379.pid,此时当redis作为守护进程运行的时候，它会把 pid 默认写到 /var/redis/run/redis_6379.pid 文件里面
指定端口号：三个端口号分别为6379、6380、6381。
指定log文件：配置logfile。三个文件中分别配置为，6379.log、,6380.log、6381.log。
指定dump文件名字：配置dbfilename
设置主从关系：
redis的主从关系在从机上配置。在从机上使用如下命令配置主从关系和查看主从关系：
配置主从：slaveof 主库IP 主库端口号
查看主从关系：info replicati
使当前数据库停止与其他数据库的同步，转成主数据库：SLAVEOF no one
从机：
主机：
注意：每次Slave与Master断开后都需要重新连接，除非配置redis.conf文件。
3.测试主从复制
全量复制：
从机执行 SLAVEOF 命令后，会将主节点所有的数据全部复制过来。每次通过SLAVEOF设置主从都会进行一次全量复制，后面就是增量复制。
增量复制：
主机写入新的数据，从机会复制一份。
读写分离：
下面我们在从机写入新的数据
可见，此时从机是只读的。在redis的配置文件中， slave-read-only 的配置可配置从机的猪肚状态。若将该配置项设置为no，从机也可以写入数据。
此时，新写入到从机的数据有复制到主机吗？由图可见，从机的数据并没有复制到主机。
主机宕机：
此时从机的主从状态如何：
由此可见，主机宕机，从机仍为从机。若主机再次正常工作，此时原主机仍恢复主机的角色。若在主机回复之前我们在6380上执行SLAVEOF no one命令设置新的主机。带主机恢复后，此时主机并不会再次成为主机，而此时的主机还是6380。此时原主机仍然为主机，但是不再和其他两个机器有主从关系。
4.复制原理
Redis的复制功能分为同步（sync）和命令传播（command propagate）两个操作。
新版同步（2.8以上）:
当从节点发出 SLAVEOF 命令，要求从服务器复制主服务器数据，建立连接的过程如下：
当slave接收到slaveof后，将masterhost设置主机的节点。
redis在后台建立slave到master的连接，连接建立后，slave调用syncWithMaster与master建立同步。
slave向master异步发送PING，master回复PONG。
从机接收到主服务器返回PONG，确认可以和主机器通信后，向机务器发送”PSYNC ？ -1”命令，申请执行初次的全量同步
收到 SYNC 命令的主机执行 BGSAVE 命令，在后台生成一个 RDB 文件，master在执行 BGSAVE 命令期间会使用一个缓冲区记录这期间所有写命令，以保证主机执行 BGSAVE 命令期间的所有写命令也可以同步给slave。
主机执行 BGSAVE 命令完毕后，主机会将 BGSAVE 命令生成的 RDB 文件发送给从机，从机接收此 RDB 文件并导入该RDB文件。
主机发送RDB 文件完成后，会将缓冲区的所有写命令也发送给从服务器，从服务器执行相应命令。
命令传播:
当同步操作完成之后，主服务器会进行相应的修改命令，这时候从服务器和主服务器状态就会不一致。
为了让主服务器和从服务器保持状态一致，主服务器需要对从服务器执行命令传播操作，主服务器会将自己的写命令发送给从服务器执行。从服务器执行相应的命令之后，主从服务器状态继续保持一致。
注意：
全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。在Redis2.8之后，主从断开重连后会根据断开之前最新的命令偏移量进行增量复制。
增量复制：Master继续将新的所有收集到的修改命令依次传给slave,完成同步。
为何是RDB而不是AOF：
RDB文件中记录的是Redis数据库中所有的key-value对，这种持久方式在任意时刻开启都能保证持久化的数据是主机中完整数据，也就是说该方式可以保证主从机数据一致。与此相对的AOF持久化方式则是将所有写命令计入到文件中，这种文件保留的数据只是从开启AOF的那一刻开始，开启之前的数据是无法保存的，所以复制机制没有使用AOF文件。
5.哨兵模式
在实际应用中若采取一主多从的模式，当主机宕机后，就没有主机的角色发挥作用，此时在主机无法工作的时候，有某个从机转换成主机，承担主机的工作，这就是哨兵模式。哨兵模式就是监控redis是否按照预期良好地运行（至少是保证主节点是存在的），若一台主机出现问题时，哨兵会自动将该主机下的某一个从机设置为新的主机，并让其他从机和新主机建立主从关系。
如何配置：
在配置文件目录下新建 sentinel.conf 文件，名字绝不能错，然后配置相应内容。
sentinel monitor 被监控数据库名字(自己起名字) 127.0.0.1 6379 1
上面最后一个数字1，表示主机挂掉后salve投票看让谁接替成为主机，得票数多少后成为主
启动哨兵模式：
redis-sentinel /myredis/sentinel.conf
上述目录依照各自的实际情况配置，可能目录不同
此时主机宕机，两个从机会进行投票，选出新的主机，（此时可从redis的日志中看到这些操作）。若主机再次恢复，它会成为新主机下的一个从机继续工作。
在我实际工作中接触到的分布式系统，redis的主从选举是由zookeeper来完成。切zookeeper在系统中的数目为单数，保证选举的快速高效。
主从复制的缺点
由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。