您的位置:首页 > 数据库 > Redis

Redis 主从复制 原理与用法

2015-12-31 17:31 896 查看
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 :

如果主服务器是 Redis 2.8 或以上版本,那么从服务器使用 PSYNC 命令来进行同步。

如果主服务器是 Redis 2.8 之前的版本,那么从服务器使用 SYNC 命令来进行同步。

Redis 复制机制

首先是slave端,对于slave端来说,主从复制主要经历四个阶段:

第一阶段:与master建立连接

第二阶段:向master发起同步请求(SYNC)

第三阶段:接受master发来的RDB数据

第四阶段:载入RDB文件

下面我们就通过一个图来概述在每一个阶段中,slave究竟做了些什么:



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

Python代码


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

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



看完这个图,你也许会有以下几个疑问:

1. 为什么在master发送完RDB文件后,还要定期的向slave发送PING命令?

2. 在发送完RDB文件之后,master发送的“变更”命令又是什么,有什么用?

在回答问题之前1,我们先回答问题2:

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

Python代码


def processCommand(cmd, argc, argv):
# 处理命令
call(cmd, argc, argv)
# 如果该命令造成数据库键空间变化and当前redis是一个master,则同步变更命令
if redisServer.update_key_space and len(redisServer.slaves) > 0:
replicationFeedSlaves(cmd, argc, argv)

def replicationFeedSlaves(cmd, argc, argv):
# 把变更命令发送给每一个处于:REDIS_REPL_WAIT_BGSAVE_END状态的slave节点
for slave in redisServer.slaves:
if slave.replstate == REDIS_REPL_WAIT_BGSAVE_START:
continue
slave.updateNotify(cmd, argc, argv)

由于在发送完RDB文件之后,master会不定时的给slave发送“变更”命令,可能过1s,也可能过1小时,所以为了防止slave无意义等待(譬如master已经挂掉的情况),master需要定时发送“保活”命令PING,以此告诉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,从设置同步时,会清空所有数据
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: