今天继续来看看有关 Redis 的一个问题,主从复制。通常,对于大多数的场景来说,读比写更多,于是对于缓存的水平扩展,其中的一个方式 “主从复制” 就是一个常见的思路。有了主从复制,那么可以扩展出很多从节点来应对大量的读请求。那么问题来了 Redis 的主从复制是如何实现的呢?
PS:本文仅关心复制的机制,不关心主节点下线重新选等等异常情况
题目本身不复杂,提问者问这个问题的想法可能会有下面几个方面
假设你完全没有看过 Redis 源码来思考这个问题,可以从下面几个角度去尝试分析,并猜测答案。
有了上面的思考,其实实际也就有思路的。首先主从复制肯定有两种情况,一种就是第一次复制,也就是要执行一次全量复制,将主节点的所有数据到复制到从节点上去;另一种就是增量复制,在数据同步之后后续的增量数据保持同步。
因为需要全量同步所有数据,我们知道 Redis 数据在内存里面,既然要发送,那势必需要先持久化一次。也就是先 SYNC 一遍,通过方法 startBgsaveForReplication
来完成的
代码位置在:https://github.com/redis/redis/blob/14f802b360ef52141c83d477ac626cc6622e4eda/src/replication.c#L855
这个问题不大, 就是保存一个 RDB 文件。
这个也很不难,就是将数据直接扔过去就好了。 代码位置在:https://github.com/redis/redis/blob/14f802b360ef52141c83d477ac626cc6622e4eda/src/replication.c#L1402
后续的任务就是增量同步后续产生的数据了。在猜测时我们想到有两种复制方式,一种是直接复制数据,这种方式复制 RDB 是可行,在全量同步的时候用这个肯定更好,如果同步命令那么从节点还需再执行一次过于复杂和麻烦,还耗时。而对于后续的增量同步来说,肯定是同步命令来的更高效(不过还是得看实际)。
下面就是传播命令的方法:
/* Propagate the specified command (in the context of the specified database id)
* to AOF and Slaves.
*
* flags are an xor between:
* + PROPAGATE_NONE (no propagation of command at all)
* + PROPAGATE_AOF (propagate into the AOF file if is enabled)
* + PROPAGATE_REPL (propagate into the replication link)
*
* This is an internal low-level function and should not be called!
*
* The API for propagating commands is alsoPropagate().
*
* dbid value of -1 is saved to indicate that the called do not want
* to replicate SELECT for this command (used for database neutral commands).
*/
static void propagateNow(int dbid, robj **argv, int argc, int target) {
if (!shouldPropagate(target))
return;
/* This needs to be unreachable since the dataset should be fixed during
* replica pause (otherwise data may be lost during a failover) */
serverAssert(!(isPausedActions(PAUSE_ACTION_REPLICA) &&
(!server.client_pause_in_transaction)));
if (server.aof_state != AOF_OFF && target & PROPAGATE_AOF)
feedAppendOnlyFile(dbid,argv,argc);
if (target & PROPAGATE_REPL)
replicationFeedSlaves(server.slaves,dbid,argv,argc);
}
这个方法就是将增量命令传播给 AOF 和 Slaves,AOF 就是持久化的另一种方式,而 Slaves 就是我们需要同步的从节点了。具体 replicationFeedSlaves
方法就不具体看了。
这个其实是我们在猜测的时候漏掉的,想来也是,master 肯定需要知道 slave 的状态,如果连不上了,肯定要处理,在 replication.c 中有这样一个方法
/* Replication cron function, called 1 time per second. */
void replicationCron(void) {
看名字和注释就秒懂了,每秒执行一次的同步定时任务。
而其中调用了 replicationFeedSlaves
方法,也就是 PING 一下,看看活着没
replicationFeedSlaves(server.slaves, -1, ping_argv, 1);
如果我们 redis 存放的数据很多,第一次同步会有两个时间,一个是 bgsave 的时间,这个时间其实还好,毕竟平时就是要执行的,而第二个时间就是传输数据的时间,这个时间就取决于带宽了。
不过首先这个操作时,主节点依旧可以被读写,只不过操作均被缓存了,所以倒是不必担心这段时间无法被使用。难就在如果数据过多可能真的会导致一个问题就是,同步->超时->重试,然后不断循环,所以为了避免这样的情况出现,建议 Redis 前往别直接把主机全部内存吃完。通常 maxmemory 设置为 75% 就相对不会出现问题,也不容易 OOM。
当然,有人肯定会问,能不能直接先手动拷贝 RDB 文件来减少同步时间,实际操作过我告诉你,不要手动操作,容易出现意想不到的问题,当出现问题之后,数据还是会不同步,还是会执行重新同步,还不如第一次就手动让程序自己来。
命令在传播的阶段设置了主从同步发送的缓冲区,通过维护一个缓冲区来保证当主节点无需等待,从节点自己凭实力拿就好了,即使有一段时间突然抖动了一下,也没事,缓冲区里面还有,继续同步就行嘞。但当完全超过缓冲区的承受范围,那么还是需要执行一次全量同步来保证数据一致。
之前看代码的时候就注意到了一个参数 repl_diskless_sync
翻译过来就是无盘同步,显然这个优化是 Redis 注意到第一次同步的时候,如果马上写入 RDB 显然是有点慢了,直接 dump 内存肯定会来的更快,所以这就是无盘,也就是不先落盘。
最后用一张图来总结整个过程
我们看着这个图我们也可以想到,其实这样复制的策略在绝大多数复制的场景中都是适用的,如果实际没有命令这个说法,那就将数据拆分成小块(chunk)来同步。需要注意点和优化点可能 Redis 都帮你想好了,对着抄就可以了。所以,我称为一种设计为 ”单向同步“,那么如果什么是多向同步呢?也就是多个人同时编辑或操作数据,互相同步的策略,此时就需要一些 diff 算法和策略了,你也可以考虑设计看看,看具体会遇到什么问题。