Redis 复制功能详解

Redis 复制功能的几个重要方面：

1. 一个Master可以有多个Slave；
2. Redis使用异步复制。从2.8版本开始，Slave会周期性（每秒一次）发起一个Ack确认复制流（replication stream）被处理进度；
3. 不仅主服务器可以有从服务器， 从服务器也可以有自己的从服务器， 多个从服务器之间可以构成一个图状结构；
4. 复制在Master端是非阻塞模式的，这意味着即便是多个Slave执行首次同步时，Master依然可以提供查询服务；
5. 复制在Slave端也是非阻塞模式的：如果你在redis.conf做了设置，Slave在执行首次同步的时候仍可以使用旧数据集提供查询；你也可以配置为当Master与Slave失去联系时，让Slave返回客户端一个错误提示；
6. 当Slave要删掉旧的数据集，并重新加载新版数据时，Slave会阻塞连接请求（一般发生在与Master断开重连后的恢复阶段）；
7. 复制功能可以单纯地用于数据冗余（data redundancy），也可以通过让多个从服务器处理只读命令请求来提升扩展性（scalability）： 比如说， 繁重的 SORT 命令可以交给附属节点去运行。
8. 可以通过修改Master端的redis.config来避免在Master端执行持久化操作（Save），由Slave端来执行持久化。

Redis复制工作原理：

1. 如果设置了一个Slave，无论是第一次连接还是重连到Master，它都会发出一个SYNC命令；
2. 当Master收到SYNC命令之后，会做两件事：
　a) Master执行BGSAVE，即在后台保存数据到磁盘（rdb快照文件）；
　b) Master同时将新收到的写入和修改数据集的命令存入缓冲区（非查询类）；
3. 当Master在后台把数据保存到快照文件完成之后，Master会把这个快照文件传送给Slave，而Slave则把内存清空后，加载该文件到内存中；
4. 而Master也会把此前收集到缓冲区中的命令，通过Reids命令协议形式转发给Slave，Slave执行这些命令，实现和Master的同步；
5. Master/Slave此后会不断通过异步方式进行命令的同步，达到最终数据的同步一致；
6. 需要注意的是Master和Slave之间一旦发生重连都会引发全量同步操作。但在2.8之后版本，也可能是部分同步操作。
部分复制
2.8版本开始，当Master和Slave之间的连接断开之后，他们之间可以采用持续复制处理方式代替采用全量同步。
Master端为复制流维护一个内存缓冲区（in-memory backlog），记录最近发送的复制流命令；同时，Master和Slave之间都维护一个复制偏移量(replication offset)和当前Master服务器ID（Master run id）。当网络断开，Slave尝试重连时：
　a. 如果MasterID相同（即仍是断网前的Master服务器），并且从断开时到当前时刻的历史命令依然在Master的内存缓冲区中存在，则Master会将缺失的这段时间的所有命令发送给Slave执行，然后复制工作就可以继续执行了；
　b. 否则，依然需要全量复制操作；
Redis 2.8 版本的这个部分重同步特性会用到一个新增的 PSYNC 内部命令， 而 Redis 2.8 以前的旧版本只有 SYNC 命令， 不过， 只要从服务器是 Redis 2.8 或以上的版本， 它就会根据主服务器的版本来决定到底是使用 PSYNC 还是 SYNC ：
　a.如果主服务器是 Redis 2.8 或以上版本，那么从服务器使用 PSYNC 命令来进行同步。
　b.如果主服务器是 Redis 2.8 之前的版本，那么从服务器使用 SYNC 命令来进行同步。

Redis 复制机制(replication )：

首先是slave端，对于slave端来说，主从复制主要经历四个阶段：
第一阶段：与master建立连接
第二阶段：向master发起同步请求（SYNC）
第三阶段：接受master发来的RDB数据
第四阶段：载入RDB文件[快照文件]
下面我们就通过一个图来概述在每一个阶段中，slave究竟做了些什么：

 

关于上图，有一点说明下：redis接收到slaveof master_host master_port命令后并没有马上与master建立连接，而是当执行服务器例行任务serverCron，发现自己正处于REDIS_REPL_CONNECT状态，这时才真正的向maser发起连接，伪代码：

def serverCron():    
# 服务器处于REDIS_REPL_CONNECT状态
if redisServer.repl_state == REDIS_REPL_CONNECT:      
# 向master发起连接
connectWithMaster()
 # 其他例行任务（省略）...  

接着我们来看下主从复制过程中，master这边的流程是如何，在具体看细节之前，我们先综合来看master这边主要做的几件事情：

看完这个图，你也许会有以下几个疑问：

1. 为什么在master发送完RDB文件后，还要定期的向slave回应PONG命令？
2. 在发送完RDB文件之后，master发送的“变更”命令又是什么，有什么用？

在回答问题之前1，我们先回答问题2：
master保存RDB文件是通过一个子进程进行的，所以master依然可以处理客户端请求而不被阻塞，但这也导致了在保存RDB文件期间，“键空间”可能发生变化（譬如接收到一个客户端请求，执行"set name diaocow"命令），因此为了保证数据同步的一致性，master会在保存RDB文件期间，把接受到的这些可能变更数据库“键空间”的命令保存下来，然后放到每个slave的回复列表中，当RDB文件发送完master会发送这些回复列表中的内容，并且在这之后，如果数据库发生变更，master依然会把变更的命令追加到回复列表发送给slave，这样就可以保证master和slave数据的一致性！相关伪代码：

def processCommand(cmd, argc, argv):
# 处理命令
call(cmd, argc, argv)
# 如果该命令造成数据库键空间变化and当前redis是一个master，则同步变更命令
if redisServer.update_ey_space and len(redisServer.slaves) > 0:
 replicationFeedSlaves(cmd, argc, argv)
def replicationFeedSlaves(cmd, argc,www.baidu620.com/ argv):
# 把变更命令发送给每一个处于：
REDIS_REPL_WAIT_BGSAVE_END状态的slave节点
for slave in redisServer.slaves:
 if slave.replstate www.dongfan178.com== REDIS_REPL_WAIT_BGSAVE_START:
　　continue 
 www.dashuju178.com  slave.updateNotify(cmd, argc, argv) 

由于在发送完RDB文件之后，master会不定时的给slave发送“变更”命令，可能过1s，也可能过1小时，所以为了防止slave无意义等待（譬如master已经挂掉的情况），master需要定时回应“保活”命令PONG，以此告诉slave：我还活着，不要中断与我的连接
现在我们就看下，当master接受到slave发送的sync同步命令后究竟发生了哪些事：

上图看似分支复杂，但我们抓住以下几点即可：
1.保存RDB文件是在一个子进程中进行的；
2.如果master已经在保存RDB文件，但是没有客户端正在等待这次BGSAVE，新添加的slave需要等到下次BGSAVE，而不能直接使用这次生成的RDB文件（原因图中已经说明）
3.master会定期检查RDB文件是否保存完毕（时间事件serverCron）；
接下来我们看下，master是如何给每一个slave发送RDB文件的：

好了，至此我们已经分析完在主从复制过程中，master和slave两边分别是怎么一个处理流程;最后，我绘制了一个图，综述了主从复制这一过程（我们可以边看图，边回忆其中的具体细节）：

PS：在主从复制过程中，任何一步发生错误，都会导致整个过程重头开始，所以若RDB文件很大又或是此时正处在业务高峰期，对系统性能将会有非常大的影响！

Redis 复制操作：

一、Redis实现复制很简单，主要有下面两个方法：

1、从机器的redis.conf添加slaveof 主IP 端口，然后带上配置文件启动server

# src/redis-server redis.conf

2、从机器启动后在命令里打入slaveof 主IP 端口，这里是全局命令

127.0.0.1 6379> salveof 192.168.10.10 6379

二、关闭同步（从机器）

# src/redis-server no one

注意：
1、Redis不支持主主复制，任意两台机器间不能互相slaveof
2、从设置同步时，会清空所有数据

原文链接：https://blog.csdn.net/java_green_hand0909/article/details/82385569