前面的2篇文章分别介绍了Redis主从同步源码浅析-Master端 以及 Redis主从同步源码浅析-Slave端 相关的代码实现，从中我们可以看出redis主从同步的一个最大的缺点，也是阻碍大数据应用的地方便是其每次连接端开都需要重连master进行全量数据的重新同步，这个代价是可想而知的。
长连接断开在线上环境中出现得很频繁，如果需要重新同步所有RDB文件，几十G的文件，从建立RDB快照，发送文件内容到slave，然后slave执行命令一一加载进内存中，这个时间开销估计也得好几个小时，更别说树形结构的master->slave->slave， 对网卡的压力，对服务器的压力都是很恐怖的。从这方面来说，动辄几个小时甚至一天的修复时间，没人敢用Redis主从同步在生产环境中使用。
但是福音来了：即将（2013年第三季度）发布的2.8版本会解决这个问题，通过：Replication partial resynchronization 的方式，也就是部分重新同步，这里就说部分同步吧，注意不是常规情况下的新写入指令同步。 阅读全文...
前一篇文章写了下redis主从同步的server端代码，这里补一下slave端的。
简单来讲，看了master端就知道slave端的代码大概流程了：
- 中断跟本slave的下一级slave的连接，强迫其重连SYNC；
- 给master发送PING确认其状态是否OK；
- 发送SYNC要求master做RDB快照（2.8版本以上会有PSYNC的指令，也就是部分同步，下回介绍。）；
- 接收RDB文件大小；
- 接收RDB文件；
- emptyDb()清空当前数据库，rdbLoad()重新加载新的RDB文件；
- 按需startAppendOnly，然后接收master过来的累积和实时更新数据；
下面分别介绍这些步骤。 阅读全文...
关于Redis的主从同步的基本介绍这里有:Replication, 不多介绍了。本文只涉及到主库的代码，从库的相关代码改天补上。
这里主要介绍redis 2.6.13版本代码，目前2.8新增了一些功能，比如增量同步功能等，不过到目前2013-10-05还没有正式上线。总结一下几点跟下面相关的：
- 同步采用类似mysql的操作日志重放方式，将写操作分发到从库重放。
- 每次从库启动必须从主库重新同步一份全量RDB数据文件，因此不能随便停止从库；
- 数据同步采用异步将写操作指令发送给从库的方式进行。
总体来说，redis的同步原理是：slave启动时下载所有数据快照，下载快照过程中产生的新写操作日志会不断累积记录起来，发送完快照后就发送这部分增量日志，日志在slave端进行重放。下面分步讲。 阅读全文...
近期评论