浅谈Redis主从复制工商资讯

作者：京东云平台资深研发工程师-张成远Redis是一个开源的，遵守BSD许可协议的key/value缓存系统，并由其高效的响应速度以及丰富的数据结构而闻名。Redis在京东的使用也是非常普遍的，包括很多关键业务上的使用，由于Redis官方集群还未发布，在使用Redis的过程中需要面对Redis的单点问题，京东采用的是一种比较通用的解决方案即由主从备份再加相应的主从切换（在一些场景下可能进行读写分离），使主Redis出现失效的时候可以快速的切换到从Redis上。但Redis目前存在的一个问题是主从复制在遇到网络不稳定的情况下，Slave和Master断开（包括闪断）会导致Master需要将内存中的数据全部重新生成rdb文件（快照文件），然后传输给Slave。Slave接收完Master传递过来的rdb文件以后会将自身的内存清空，把rdb文件重新加载到内存中。这种方式效率比较低下，尤其是在数据量大的情况下，毕竟网络闪断未必丢数据或者说丢的数据只是少部分，但却要为此付出将整个内存数据都重新传输一次的代价。如果能够将闪断过程的更新数据传递给Slave，那么就不需要将Master内存中的所有数据都传递给Slave了。Redis作者在2.8的候选版（以下简称Redis2.8）中已经将这个部分复制的思路实现了。那么Redis2.4.16的全量复制与Redis2.8的部分复制是如何实现的呢?如下图所示,这5个状态是Slave在主从复制过程涉及到的几个状态，其中REDIS_REPL_NONE是Redis启动时候默认的状态。图1-2所示的四个状态表示站在Master的角度来看，Slave所处于的状态，因为Slave在Master端看来就是一个特殊的client（同理Master在Slave端看来也是一个特殊的client）。图1-1 Slave自身的状态图1-2 Master端的Slave状态Redis在接收到“slaveof ip port”命令以后，首先会将自身的状态置为REDIS_REPL_CONNECT，表示需要与自己的Master连接，此时Slave并没有与Master做连接。Redis每隔100ms会调用serverCron()函数一次，每10次serverCron()的调用会调用replicationCron()一次，即每1s会调用一次replication()函数。在replication()函数中，会检查Slave的状态，如果是处于REDIS_REPL_CONNECT状态，就会建立syncWithMaster()的事件处理函数，并将Slave的状态改成REDIS_REPL_CONNECTING。syncWithMaster()函数主要是向Master发送sync命令，当该事件处理函数被触发以后会将Slave的状态改成REDIS_REPL_TRANSFER，表示Slave已经准备就绪要接收Master生成的rdb文件。回到Master的角色，Master发现有一个Slave连接上来，如果此时的Master一个Slave都没有且没有后台快照进程，则启动一个后台进程将当前内存中的数据生成一个rdb文件，同时将Slave的状态置为REDIS_REPL_WAIT_BGSAVE_END状态，表示该Slave等待Master的快照进程结束。在后台进行生成rdb文件的时候，如果有对redis的更新命令，Master会将这些更新命令存到该Slave的buffer中，如果buffer满了会另外开辟list来存储这些更新命令。当后台快照进程结束，Master会将该Slave的状态改为REDIS_REPL_SEND_BULK，同时注册sendBulkToSlave()事件处理函数用于将生成的rdb文件传输给Slave。等rdb传输结束以后，sendBulkToSlave()事件函数会被删除，Slave的状态会被更改为REDIS_REPL_ONLINE，另外再注册sendReplyToClient()事件函数，将Master在快照内过程中的所有更新操作（Slave的buffer里存的命令）发给Slave。再回到Slave的角色，当Master向Slave传输完rdb文件以后，Slave自身会将状态改为REDIS_REPL_CONNECTED，表示复制已完成，处于与Master保持实时同步的状态。上述描述的状态转换如图1-3所示，由图中可知，站在Slave角色看，当出现网络中断的时候不管Slave本身是处于REDIS_REPL_CONNECTING、REDIS_REPL_REPL_TRANSFER还是REDIS_REPL_CONNECTED，都会调用相应的处理函数使Slave进入REDIS_REPL_CONNECT状态，这就意味着Slave需要重新向Master发送sync命令，重新进行一次全量同步过程。图中的REDIS_REPL_WAIT_BGSAVE_START状态是在Slave连接上Master的时候（站在Master的角色看），当时Master刚好后台有快照进程且该快照进程生成的rdb不适合直接传给该Slave时出现的状态，则将Slave的状态置为REDIS_REPL_WAIT_BGSAVE_START。如果此时有快照进程且找到了另外的发起快照进程的Slave，只需要将另外的Slave的buffer内容拷贝到该Slave的buffer中，然后直接进入REDIS_REPL_WAIT_BGSAVE_END状态。如果此时没有后台快照进程，Slave直接进入REDIS_REPL_WAIT_BGSAVE_END状态，同时启动一个后台快照进程。图1-3 Redis-2.4.16主从复制状态转换图在上述状态转图中存在的最大问题在于任何网络闪断都会导致Slave与Master重连，然后重新进入快照过程，需要花费较长的时间重新传输rdb文件，而Slave在接收完rdb文件以后试图将rdb文件恢复到内存的过程中是不能服务的（除info命令外）。所以提供部分复制至少可以做到在网络闪断且更新命令不太多的情景下能够尽量的避免全量复制的方案就显得尤为重要。