Redis 主从复制
1, 首先Redis主从复制是异步的, 如何理解这的异步呢。
1) 客户端发送写请求给redis 主服务器
2) redis主服务器 把更新内存数据集
3) redis主服务器 返回结果给客户端
4) redis主服务器 把写命令请求以 redis protocol格式传播给redis从服务器
这里redis主服务器,在根据写请求更新完内存数据集之后,就返回给客户端了。如果返回结果给客户端
之后发现主从服务器连接断开,那么内容在下次重新完成同步之前是不一致的,所以说redis的主从复制
不是同步的,而是异步的。
如果这样考虑, redis主服务器先把数据发送给从服务,得到从服务器的应答后,主服务器才更新内存数据集。
那么这样redis的复制就是同步的,如果从服务器不能更新,那么主服务器也不会单独更新。
任何的同步都是相对的,首先找出两个主体,比如redis客户端 和 redis主服务器之间就肯定是同步的,
因为redis只有更新内存数据集之后,才应答客户端。redis主服务器和从服务器之间就不是同步的,
同理redis客户端和从服务器之间也不是同步的。
在redis中,用户可以通过执行SLAVEOF 命令或者通过配置文件设置slaveof选项, 让一个服务器去复制另外一个服务器,
被复制的服务器为主服务器,而对主服务器进行复制的服务器称之为从服务器。Redis的复制功能的实现,是把从服务器
当成一个client来处理的,所以redis里的数据结构client是复用的, 它可以代表一个发送命令请求的客户端,同时也代表
一个从服务器。可以参考 redis/src/server.h中client的定义。
假如现在有两台服务器
A: 127.0.0.1:6379
B:127.0.0.1:6380
我们登录到6380, 敲入如下命令, slaveof 127.0.0.1 6379
那么服务器6380就成为服务器6379的从服务器,反之,服务器6379成为6380的主服务器。
一 旧版复制功能的实现(全量复制)
在Redis中,从服务器对主服务器的复制可以分为以下两种情况:
初次复制:从服务器以前没有复制过任何主服务器,或者从服务器当前要复制的主服务器和上一次复制的主服务器不同;
断线后重复制:处于命令传播阶段的主从服务器因为网络原因而中断了复制,但从服务器通过自动重连接重新连上了主服务器,并继续复制主服务器。
对于初次复制来说,旧版复制功能能够很好地完成任务,但对于断线后重复制来说,旧版复制功能虽然也能让主从服务器重新回到一致状态,但效率却非常低。
1)同步
当客户端向从服务器发送SLAVEOF命令,要求从服务器复制主服务器时,从服务器首先需要执行同步操作,也即是,将从服务器的数据库状态更新至主服务器当前所处的数据库状态。
从服务器对主服务器的同步操作需要通过向主服务器发送SYNC命令来完成,以下是SYNC命令的执行步骤:
从服务器向主服务器发送SYNC命令;
收到SYNC命令的主服务器执行BGSAVE命令,在后台生成一个RDB文件,并使用一个缓冲区记录从现在开始执行的所有写命令;
当主服务器的BGSAVE命令执行完毕时,主服务器会将BGSAVE命令生成的RDB文件发送给从服务器,从服务器接收并载入这个RDB文件,将自己的数据库状态更新至主服务器执行BGSAVE命令时的数据库状态。
主服务器将记录在缓冲区里面的所有写命令发送给从服务器,从服务器执行这些写命令,将自己的数据库状态更新至主服务器数据库当前所处的状态。
注:用来记录生成RDB文件生成这段时间的写命令的缓冲区,是每个客户端独立的,在数据结构client中的定以的一个16k的输出缓冲区。
#define PROTO_REPLY_CHUNK_BYTES (16*1024) /* 16k output buffer */
/* With multiplexing we need to take per-client state.
* Clients are taken in a linked list. */
typedef struct client {
uint64_t id; /* Client incremental unique ID. */
int fd; /* Client socket. */
redisDb *db; /* Pointer to currently SELECTed DB. */
robj *name; /* As set by CLIENT SETNAME. */
sds querybuf; /* Buffer we use to accumulate client queries. */
sds pending_querybuf; /* If this client is flagged as master, this buffer
represents the yet not applied portion of the
replication stream that we are receiving from
the master. */
................................
int authenticated; /* When requirepass is non-NULL. */
int replstate; /* Replication state if this is a slave. */
int repl_put_online_on_ack; /* Install slave write handler on ACK. */
int repldbfd; /* Replication DB file descriptor. */
off_t repldboff; /* Replication DB file offset. */
off_t repldbsize; /* Replication DB file size. */
sds replpreamble; /* Replication DB preamble. */
long long read_reploff; /* Read replication offset if this is a master. */
long long reploff; /* Applied replication offset if this is a master. */
long long repl_ack_off; /* Replication ack offset, if this is a slave. */
long long repl_ack_time;/* Replication ack time, if this is a slave. */
long long psync_initial_offset; /* FULLRESYNC reply offset other slaves
copying this slave output buffer
should use. */
.................................
/* Response buffer */
int bufpos;
char buf[PROTO_REPLY_CHUNK_BYTES];
} client;
/* Copy 'src' client output buffers into 'dst' client output buffers.
* The function takes care of freeing the old output buffers of the
* destination client. */
void copyClientOutputBuffer(client *dst, client *src) {
listRelease(dst->reply);
dst->reply = listDup(src->reply);
memcpy(dst->buf,src->buf,src->bufpos);
dst->bufpos = src->bufpos;
dst->reply_bytes = src->reply_bytes;
}
/* -----------------------------------------------------------------------------
* Low level functions to add more data to output buffers.
* -------------------------------------------------------------------------- */
int _addReplyToBuffer(client *c, const char *s, size_t len) {
size_t available = sizeof(c->buf)-c->bufpos;
if (c->flags & CLIENT_CLOSE_AFTER_REPLY) return C_OK;
/* If there already are entries in the reply list, we cannot
* add anything more to the static buffer. */
if (listLength(c->reply) > 0) return C_ERR;
/* Check that the buffer has enough space available for this string. */
if (len > available) return C_ERR;
memcpy(c->buf+c->bufpos,s,len);
c->bufpos+=len;
return C_OK;
}
/* This function puts a slave in the online state, and should be called just
* after a slave received the RDB file for the initial synchronization, and
* we are finally ready to send the incremental stream of commands.
*
* It does a few things:
*
* 1) Put the slave in ONLINE state (useless when the function is called
* because state is already ONLINE but repl_put_online_on_ack is true).
* 2) Make sure the writable event is re-installed, since calling the SYNC
* command disables it, so that we can accumulate output buffer without
* sending it to the slave.
* 3) Update the count of good slaves. */
void putSlaveOnline(client *slave) {
slave->replstate = SLAVE_STATE_ONLINE;
slave->repl_put_online_on_ack = 0;
slave->repl_ack_time = server.unixtime; /* Prevent false timeout. */
if (aeCreateFileEvent(server.el, slave->fd, AE_WRITABLE,
sendReplyToClient, slave) == AE_ERR) {
serverLog(LL_WARNING,"Unable to register writable event for slave bulk transfer: %s", strerror(errno));
freeClient(slave);
return;
}
refreshGoodSlavesCount();
serverLog(LL_NOTICE,"Synchronization with slave %s succeeded",
replicationGetSlaveName(slave));
}
/* This function is called just before entering the event loop, in the hope
* we can just write the replies to the client output buffer without any
* need to use a syscall in order to install the writable event handler,
* get it called, and so forth. */
int handleClientsWithPendingWrites(void) {
listIter li;
listNode *ln;
int processed = listLength(server.clients_pending_write);
listRewind(server.clients_pending_write,&li);
while((ln = listNext(&li))) {
client *c = listNodeValue(ln);
c->flags &= ~CLIENT_PENDING_WRITE;
listDelNode(server.clients_pending_write,ln);
/* Try to write buffers to the client socket. */
if (writeToClient(c->fd,c,0) == C_ERR) continue;
/* If after the synchronous writes above we still have data to
* output to the client, we need to install the writable handler. */
if (clientHasPendingReplies(c)) {
int ae_flags = AE_WRITABLE;
/* For the fsync=always policy, we wa
2)命令传播
在执行完同步操作之后,主从服务器之间数据库状态已经相同了。但这个状态并非一成不变,如果主服务器执行了写操作,那么主服务器的数据库状态就会修改,并导致主从服务器状态不再一致。
所以为了让主从服务器再次回到一致状态,主服务器需要对从服务器执行命令传播操作:主服务器会将自己执行的写命令,也即是造成主从服务器不一致的那条写命令,发送给从服务器执行,当从服务器执行了相同的写命令之后,主从服务器将再次回到一致状态。
旧版复制功能的缺陷
在Redis中,从服务器对主服务器的复制可以分为以下两种情况:
初次复制:从服务器以前没有复制过任何主服务器,或者从服务器当前要复制的主服务器和上一次复制的主服务器不同;
断线后重复制:处于命令传播阶段的主从服务器因为网络原因而中断了复制,但从服务器通过自动重连接重新连上了主服务器,并继续复制主服务器。
对于初次复制来说,旧版复制功能能够很好地完成任务,但对于断线后重复制来说,旧版复制功能虽然也能让主从服务器重新回到一致状态,但效率却非常低。
SYNC命令是一个非常耗费资源的操作
SYNC命令是非常消耗资源的,因为每次执行SYNC命令,主从服务器需要执行一下操作:
主服务器需要执行BGSAVE命令来生成RDB文件,这个生成操作会耗费主服务器大量的CPU、内存和磁盘I/O资源;
主服务器需要将自己生成的RDB文件发送给从服务器,这个发送操作会耗费主从服务器大量的网络资源(带宽和流量),并对主服务器响应命令请求的时间产生影响;
接收到RDB文件的从服务器需要载入主服务器发来的RDB文件,并且在载入期间,从服务器会因为阻塞而没办法处理命令请求。
SYNC是一个如此消耗资源的命令,所以Redis最好在真需要的时候才需要执行SYNC命令。
新版复制功能的实现
为了解决旧版复制功能在处理断线重复制情况时的低效问题,Redis从2.8版本开始,使用PSYNC命令代替SYNC命令来执行复制时的同步操作。
PSYNC命令具有完整重同步(full resynchronization)和部分重同步(partial resynchronization)两种模式:
其中完整重同步用于处理初次复制情况:完整重同步的执行步骤和SYNC命令的执行步骤基本一样,它们都是通过让主服务器创建并发送RDB文件,以及向从服务器发送保存在缓冲区里面的写命令来进行同步;
而部分重同步则用于处理断线后重复制情况:当从服务器在断线后重新连接主服务器时,如果条件允许,主服务器可以将主从服务器连接断开期间执行的写命令发送给从服务器,从服务器只要接收并执行这些写命令,就可以将数据库更新至主服务器当前所处的状态。
我们现在试举一例来看看使用PSYNC处理断线后情况:
主服务器 从服务器
1, PSYNC
-------->
2, +CONTINUE
<-----------
3, 主服务器发送主从
断线期间发送的写命令
--------------->
部分重同步的实现
部分重同步功能由以下三个部分构成:
主服务器的复制偏移量(replication offset)和从服务器的复制偏移量;
主服务器的复制积压缓冲区(replication backlog);
服务器的运行ID(run ID)。
复制偏移量
执行复制的双方——主服务器和从服务器会分别维护一个复制偏移量:
主服务器每次向从服务器传播N个字节的数据时,就将自己的复制偏移量的值加上N;
从服务器每次收到主服务器传播来的N个字节的数据时,就将自己的复制偏移量的值加上N;
(我靠!!难道从服务器没有反馈吗?丢包了怎么办?难道是用TCP?大家继续看,我只是想穿插一些我的思路)
通过对比主从服务器的复制偏移量,程序可以很容易地知道主从服务器是否处于一致状态:
如果主从服务器处于一致状态,那么主从服务器两者的偏移量总是相同的;
相反,如果主从服务器两者的偏移量并不相同,那么说明主从服务器并未处于一致状态。
如下面的情况:
--------------- 断线 ---------------
| 主服务器 |------------------> | 从服务器A |
| offset=11010 | | offset=11080 |
-------------- --------------
\
\ 传输30个字节
\
\---------------
| 从服务器B |
| offset=11110 |
--------------
制偏移量为10080,那么这时,主服务器应该对从服务器执行完整重同步还是部分重同步呢?如果执行部分重同步的话,主服务器又如何补偿从服务器A在断线期间丢失的那部分数据呢?以上问题的答案都和复制积压缓冲区有关。
复制积压缓冲区
复制积压缓冲区是由主服务器维护的一个固定长度(fixed-size)先进先出(FIFO)队列,默认大小为1MB。实现方式为环形循环队列
和普通先进先出队列随着元素的增加和减少而动态调整长度不同,固定长度先进先出队列的长度是固定的,当入队元素的数量大于队列长度时,最先入队的元素会被弹出,而新元素会被放入队列。
当主服务器进行命令传播时,它不仅会将写命令发送给所有从服务器,还会将写命令入队到复制积压缓冲区里面,如图所示。
因此,主服务器的复制积压缓冲区里面会保存着一部分最近传播的写命令,并且复制积压缓冲区会为队列中的每个字节记录相应的复制偏移量,就像下表所示的那样。
当从服务器重新连上主服务器时,从服务器会通过PSYNC命令将自己的复制偏移量offset发送给主服务器,主服务器会根据这个复制偏移量来决定对从服务器执行何种同步操作:
如果offset偏移量之后的数据(也即是偏移量offset+1开始的数据)仍然存在于复制积压缓冲区里面,那么主服务器将对从服务器执行部分重同步操作;
相反,如果offset偏移量之后的数据已经不存在于复制积压缓冲区,那么主服务器将对从服务器执行完整重同步操作。
根据需要调整复制积压缓冲区的大小
Redis为复制积压缓冲区设置的默认大小为1MB,如果主服务器需要执行大量写命令,又或者主从服务器断线后重连接所需的时间比较长,那么这个大小也许并不合适。如果复制积压缓冲区的大小设置得不恰当,那么PSYNC命令的复制重同步模式就不能正常发挥作用,因此,正确估算和设置复制积压缓冲区的大小非常重要。
复制积压缓冲区的最小大小可以根据公式second*write_size_per_second来估算:
其中second为从服务器断线后重新连接上主服务器所需的平均时间(以秒计算);
而write_size_per_second则是主服务器平均每秒产生的写命令数据量(协议格式的写命令的长度总和);
例如,如果主服务器平均每秒产生1 MB的写数据,而从服务器断线之后平均要5秒才能重新连接上主服务器,那么复制积压缓冲区的大小就不能低于5MB。
为了安全起见,可以将复制积压缓冲区的大小设为2*second*write_size_per_second,这样可以保证绝大部分断线情况都能用部分重同步来处理。
至于复制积压缓冲区大小的修改方法,可以参考配置文件中关于repl-backlog-size选项的说明。
服务器运行ID
除了复制偏移量和复制积压缓冲区之外,实现部分重同步还需要用到服务器运行ID(run ID):
每个Redis服务器,不论主服务器还是从服务,都会有自己的运行ID;
运行ID在服务器启动时自动生成,由40个随机的十六进制字符组成,例如53b9b28df8042fdc9ab5e3fcbbbabff1d5dce2b3;
当从服务器对主服务器进行初次复制时,主服务器会将自己的运行ID传送给从服务器,而从服务器则会将这个运行ID保存起来(注意哦,是从服务器保存了主服务器的ID)。
当从服务器断线并重新连上一个主服务器时,从服务器将向当前连接的主服务器发送之前保存的运行ID:
如果从服务器保存的运行ID和当前连接的主服务器的运行ID相同,那么说明从服务器断线之前复制的就是当前连接的这个主服务器,主服务器可以继续尝试执行部分重同步操作;
相反地,如果从服务器保存的运行ID和当前连接的主服务器的运行ID并不相同,那么说明从服务器断线之前复制的主服务器并不是当前连接的这个主服务器,主服务器将对从服务器执行完整重同步操作。
PSYNC命令的实现
PSYNC命令的调用方法有两种:
如果从服务器以前没有复制过任何主服务器,或者之前执行过SLAVEOF no one命令,那么从服务器在开始一次新的复制时将向主服务器发送PSYNC ? -1命令,主动请求主服务器进行完整重同步(因为这时不可能执行部分重同步);
相反地,如果从服务器已经复制过某个主服务器,那么从服务器在开始一次新的复制时将向主服务器发送PSYNC <runid> <offset>命令:其中runid是上一次复制的主服务器的运行ID,而offset则是从服务器当前的复制偏移量,接收到这个命令的主服务器会通过这两个参数来判断应该对从服务器执行哪种同步操作。
根据情况,接收到PSYNC命令的主服务器会向从服务器返回以下三种回复的其中一种:
如果主服务器返回+FULLRESYNC <runid> <offset>回复,那么表示主服务器将与从服务器执行完整重同步操作:其中runid是这个主服务器的运行ID,从服务器会将这个ID保存起来,在下一次发送PSYNC命令时使用;而offset则是主服务器当前的复制偏移量,从服务器会将这个值作为自己的初始化偏移量;
如果主服务器返回+CONTINUE回复,那么表示主服务器将与从服务器执行部分重同步操作,从服务器只要等着主服务器将自己缺少的那部分数据发送过来就可以了;
如果主服务器返回-ERR回复,那么表示主服务器的版本低于Redis 2.8,它识别不了PSYNC命令,从服务器将向主服务器发送SYNC命令,并与主服务器执行完整同步操作。
复制的实现
步骤1:设置主服务器的地址和端口
当客户端向从服务器发送以下命令时:
127.0.0.1:12345> SLAVEOF 127.0.0.1 6379
OK
从服务器首先要做的就是将客户端给定的主服务器IP地址127.0.0.1以及端口6379保存到服务器状态的masterhost属性和masterport属性里面:
struct redisServer {
// ...
// 主服务器的地址
char *masterhost;
// 主服务器的端口
int masterport;
// ...
};
SLAVEOF命令是一个异步命令,在完成masterhost属性和masterport属性的设置工作之后,从服务器将向发送SLAVEOF命令的客户端返回OK,表示复制指令已经被接收,而实际的复制工作将在OK返回之后才真正开始执行。
步骤2:建立套接字连接
在SLAVEOF命令执行之后,从服务器将根据命令所设置的IP地址和端口,创建连向主服务器的套接字连接,如图15-14所示。
如果从服务器创建的套接字能成功连接(connect)到主服务器,那么从服务器将为这个套接字关联一个专门用于处理复制工作的文件事件处理器,这个处理器将负责执行后续的复制工作,比如接收RDB文件,以及接收主服务器传播来的写命令,诸如此类。
而主服务器在接受(accept)从服务器的套接字连接之后,将为该套接字创建相应的客户端状态,并将从服务器看作是一个连接到主服务器的客户端来对待,这时从服务器将同时具有服务器(server)和客户端(client)两个身份:从服务器可以向主服务器发送命令请求,而主服务器则会向从服务器返回命令回复。
步骤3:发送PING命令
从服务器成为主服务器的客户端之后,做的第一件事就是向主服务器发送一个PING命令。
这个PING命令主要是为了:
通过发送PING命令检查套接字的读写状态;
通过PING命令可以检查主服务器能否正常处理命令。
从服务器在发送PING命令之后可能遇到以下三种情况:
主服务器向从服务器返回了一个命令回复,但从服务器却不能在规定的时限内读取命令回复的内容(timeout),说明网络连接状态不佳,从服务器将断开并重新创建连向主服务器的套接字;
如果主服务器返回一个错误,那么表示主服务器暂时没有办法处理从服务器的命令请求,,从服务器也将断开并重新创建连向主服务器的套接字;
如果从服务器读取到"PONG"回复,那么表示主从服务器之间的网络连接状态正常,那就继续执行下面的复制步骤。
步骤4:身份验证
从服务器在收到主服务器返回的"PONG"回复之后,下一步要做的就是决定是否进行身份验证:
如果从服务器设置了masterauth选项,那么进行身份验证。否则不进行身份认证;
在需要进行身份验证的情况下,从服务器将向主服务器发送一条AUTH命令,命令的参数为从服务器masterauth选项的值。
从服务器在身份验证阶段可能遇到的情况有以下几种:
主服务器没有设置requirepass选项,从服务器没有设置masterauth,那么就继续后面的复制工作;
如果从服务器的通过AUTH命令发送的密码和主服务器requirepass选项所设置的密码相同,那么也继续后面的工作,否则返回错误invaild password;
如果主服务器设置了requireoass选项,但从服务器没有设置masterauth选项,那么服务器将返回NOAUTH错误。反过来如果主服务器没有设置requirepass选项,但是从服务器却设置了materauth选项,那么主服务器返回no password is set错误;
所有错误到只有一个结果:中止目前的复制工作,并从创建套接字开始重新执行复制,直到身份验证通过,或者从服务器放弃执行复制为止。
步骤5:发送端口信息
身份验证步骤之后,从服务器将执行命令REPLCONF listening-port <port-number>,向主服务器发送从服务器的监听端口号。
主服务器在接收到这个命令之后,会将端口号记录在从服务器所对应的客户端状态的slave_listening_port属性中:
typedef struct redisClient {
// ...
// 从服务器的监听端口号
int slave_listening_port;
// ...
}redisClient;
slave_listening_port属性目前唯一的作用就是在主服务器执行INFO replication命令时打印出从服务器的端口号。
步骤6:同步
在这一步,从服务器将向主服务器发送PSYNC命令,执行同步操作,并将自己的数据库更新至主服务器数据库当前所处的状态。
需要注意的是在执行同步操作前,只有从服务器是主服务器的客户端。但是执行从不操作之后,主服务器也会称为从服务器的客户端:
如果PSYNC命令执行的是完整同步操作,那么主服务器只有成为了从服务器的客户端才能将保存在缓冲区中的写命令发送给从服务器执行;
如果PSYNC命令执行的是部分同步操作,那么主服务器只有成为了从服务器的客户端才能将保存在复制积压缓冲区中的写命令发送给从服务器执行;
步骤7:命令传播
当完成了同步之后,主从服务器就会进入命令传播阶段,这时主服务器只要一直将自己执行的写命令发送给从服务器,而从服务器只要一直接收并执行主服务器发来的写命令,就可以保证主从服务器一直保持一致了。
心跳检测
在命令传播阶段,从服务器默认会以每秒一次的频率,向主服务器发送命令:REPLCONF ACK <replication_offset>
其中replication_offset是从服务器当前的复制偏移量。
发送REPLCONF ACK命令对于主从服务器有三个作用:
检测主从服务器的网络连接状态;
辅助实现min-slaves选项;
检测命令丢失。
检测主从服务器的网络连接状态
如果主服务器超过一秒钟没有收到从服务器发来的REPLCONF ACK命令,那么主服务器就知道主从服务器之间的连接出现问题了。
通过向主服务器发送INFO replication命令,在列出的从服务器列表的lag一栏中,我们可以看到相应从服务器最后一次向主服务器发送REPLCONF ACK命令距离现在过了多少秒:
127.0.0.1:6379> INFO replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=12345,state=online,offset=211,lag=0
#刚刚发送过 REPLCONF ACK命令
slave1:ip=127.0.0.1,port=56789,state=online,offset=197,lag=15
#15秒之前发送过REPLCONF ACK命令
master_repl_offset:211
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:210
在一般情况下,lag的值应该在0秒或者1秒之间跳动,如果超过1秒的话,那么说明主从服务器之间的连接出现了故障。
辅助实现min-slaves配置选项
Redis的min-slaves-to-write和min-slaves-max-lag两个选项可以防止主服务器在不安全的情况下执行写命令。
举个例子,如果我们向主服务器提供以下设置:
min-slaves-to-write 3
min-slaves-max-lag 10
那么在从服务器的数量少于3个,或者三个从服务器的延迟(lag)值都大于或等于10秒时,主服务器将拒绝执行写命令,这里的延迟值就是上面提到的INFO replication命令的lag值。
检测命令丢失
我们从命令:REPLCONF ACK <replication_offset>就可以知道,每发送一次这个命令从服务器都会向主服务器报告一次自己的复制偏移量。那此时尽管主服务器发送给从服务器的SET key value丢失了。也无所谓,主服务器马上就知道了。