随笔分类
对 Redis主从复制的些许思考:
# *Redis主从复制中,在经过第一次的全量复制后,主从库之间是基于长连接的命令传播实现写操作的同步的,在此期间对于主从库网络断连也是通过一个缓冲区 repl_backlog_buffer来实现主从库数据同步的,对于 repl_backlog_buffer本身是一个环形缓冲区,使用它会存在什么问题吗?
- *repl_backlog_buffer本身是一个环形缓冲区,因此在缓冲区写满后,主库还是会继续进行写入,此时便会去覆盖之前的写入的操作;
- 如果从库读取数据速度比较慢,那么就可能会出现未读取的数据就被主库新写的操作覆盖了,这边可能会主从库数据的不一致
# 解决:通过调整 repl_backlog_size这个参数来去设置 repl_backlog_buffer缓存区的大小,具体调整需要根据主库写与从库读二者速度之间的差距来进行调整;以及实际上当出现数据覆盖时,主库这边会根据写偏移量和读偏移量判断出来的,此时便能够决定从库究竟是来进行增量复制,还是全量复制;可以说,合理地来去调整 repl_backlo_buffer参数可以避免从库重连转换后进行基于 RDB的全量复制.
# *主从库进行全量复制时使用的是 RDB文件,而我们知道,AOF记录的操作命令更全,相比于 RDB丢失的数据更少,那为什么不去使用 AOF文件呢?
- *首先,RDB文件存储的是数据本身,并且是压缩后的二进制数据,而 AOF文件存储的是写操作命令,而且不是直接命令本身,还需要基于某种协议进行解析才能获取真正的命令,且可能存在冗余的命令(AOF未重写之前),因此,AOF日志文件通常会比 RDB快照文件要大得多;
- 其次,文件传输本身是要占用主库这边的网络带宽了,为了避免主库这边性能不受到太大影响,我们希望文件传输时间尽可能短些,对应传输文件尽可能小些
- 且基于从库初始化速度考虑,基于 RDB快照的恢复肯定是要比基于 AOF日志恢复的(逐条执行日志中命令)
- 基于上述,Redis选择了基于 RDB快照来去做全量复制,这也是我的想法