步骤如下:
1,A为主节点 与 B从节点都处于存活状态,C节点关闭。
2,向redis中写入10W条数据,在写入过程中 ,关闭 A, 启动C
3,随后关闭 B,启动A,
4,最后,会发现10W条数据 可能丢失的只剩了5W,或者更少。
哨兵模式这个问题大家遇到过没有,又是怎么样解决的?
步骤如下:
1,A为主节点 与 B从节点都处于存活状态,C节点关闭。
2,向redis中写入10W条数据,在写入过程中 ,关闭 A, 启动C
3,随后关闭 B,启动A,
4,最后,会发现10W条数据 可能丢失的只剩了5W,或者更少。
哨兵模式这个问题大家遇到过没有,又是怎么样解决的?
到此,Redis的主从同步具体执行流程,我们已经比较清楚了。
值得注意的是:主从复制的过程中,Redis会 fork 子进程生成 RDB 文件,这个 fork 子进程的操作会阻塞 Redis 主线程。假如从节点非常多的时候,会导致主节点忙于 fork 子进程,进而导致主节点阻塞,这时候该怎么办呢?咱们且接着往下看:
这时候,我们可以通过“主-从-从”的模式
,将主节点生成和发送 RDB 文件的压力以级联的方式分散到从节点
。
说简单点就是:可以选择一个配置相对较高的从节点,作为其他从节点的主节点,如下图所示:
可以看到,从节点2和从节点3的主节点就不再设置成主节点了,而是设置成从节点1。这样便可以有效缓解主节点的多从复制压力了。
那么,除了上述问题之外,还存在其他问题吗?答案是肯定的。
主从节点建立连接之后,他们之间会一直维护着一个长连接,避免频繁建立连接的开销。但是,假如这个连接断开了会怎么样呢?
Redis2.8之前,主从节点断开重连之后会执行全量复制,显然全量复制开销过大,所以在Redis2.8之后就被淘汰了,升级成了增量复制。那么,什么是增量复制呢?