REDIS复制原理

桃扇骨 2024-02-18 15:04 10阅读 0赞

主从复制简单来说就是把一台redis数据库中的数据同步到另一台redis数据库，并且按照数据流向，数据的发送者我们称作master，数据的接受者我们称作slave（master/slave的划分并不是那么一定的，譬如B可以作为A的slave，但同时也可以作为C的master），下面就从slave和master的角度分别说明主从复制流程。  
  
首先是slave端，对于slave端来说，主从复制主要经历四个阶段：  
  
第一阶段：与master建立连接  
第二阶段：向master发起同步请求（SYNC）  
第三阶段：接受master发来的RDB数据  
第四阶段：载入RDB文件  
  
下面我们就通过一个图来概述在每一个阶段中，slave究竟做了些什么：  
  
![点击查看原始大小图片][0e62936a-b96a-3a35-b69a-1bbde1f54fe5.png]  
  
关于上图，有一点说明下：redis接收到slaveof master\_host master\_port命令后并没有马上与master建立连接，而是当执行服务器例行任务serverCron，发现自己正处于REDIS\_REPL\_CONNECT状态，这时才真正的向maser发起连接，伪代码：

Python代码 ![收藏代码][icon_star.png]

1.  def serverCron():
2.  \# 服务器处于REDIS\_REPL\_CONNECT状态
3.  if redisServer.repl\_state == REDIS\_REPL\_CONNECT:
4.  \# 向master发起连接
5.  connectWithMaster()
6.  \# 其他例行任务（省略）...

接着我们来看下主从复制过程中，master这边的流程是如何，在具体看细节之前，我们先综合来看master这边主要做的几件事情：  
  
![e574f370-3b04-34f1-be52-507783d02c1f.png][]  
  
看完这个图，你也许会有以下几个疑问：  
  
1. 为什么在master发送完RDB文件后，还要定期的向slave发送PING命令？  
2. 在发送完RDB文件之后，master发送的“变更”命令又是什么，有什么用？  
  
在回答问题之前1，我们先回答问题2：  
master保存RDB文件是通过一个子进程进行的，所以master依然可以处理客户端请求而不被阻塞，但这也导致了在保存RDB文件期间，“键空间”可能发生变化（譬如接收到一个客户端请求，执行"set name diaocow"命令），因此为了保证数据同步的一致性，master会在保存RDB文件期间，把接受到的这些可能变更数据库“键空间”的命令保存下来，然后放到每个slave的回复列表中，当RDB文件发送完master会发送这些回复列表中的内容，并且在这之后，如果数据库发生变更，master依然会把变更的命令追加到回复列表发送给slave，这样就可以保证master和slave数据的一致性！相关伪代码：

Python代码 ![收藏代码][icon_star.png]

1.  def processCommand(cmd, argc, argv):
2.  \# 处理命令
3.  call(cmd, argc, argv)
4.  \# 如果该命令造成数据库键空间变化and当前redis是一个master，则同步变更命令
5.  if redisServer.update\_key\_space and len(redisServer.slaves) > 0:
6.  replicationFeedSlaves(cmd, argc, argv)
7.  
8.  def replicationFeedSlaves(cmd, argc, argv):
9.  \# 把变更命令发送给每一个处于：REDIS\_REPL\_WAIT\_BGSAVE\_END状态的slave节点
10. for slave in redisServer.slaves:
11. if slave.replstate == REDIS\_REPL\_WAIT\_BGSAVE\_START:
12. continue
13. slave.updateNotify(cmd, argc, argv)

由于在发送完RDB文件之后，master会不定时的给slave发送“变更”命令，可能过1s，也可能过1小时，所以为了防止slave无意义等待（譬如master已经挂掉的情况），master需要定时发送“保活”命令PING，以此告诉slave：我还活着，不要中断与我的连接  
  
现在我们就看下，当master接受到slave发送的sync同步命令后究竟发生了哪些事：  
  
![点击查看原始大小图片][7955607d-eafd-35d3-9f13-e403260ccfd0.png]  
上图看似分支复杂，但我们抓住以下几点即可：  
  
1.保存RDB文件是在一个子进程中进行的；  
2.如果master已经在保存RDB文件，但是没有客户端正在等待这次BGSAVE，新添加的slave需要等到下次BGSAVE，而不能直接使用这次生成的RDB文件（原因图中已经说明）  
3.master会定期检查RDB文件是否保存完毕（时间事件serverCron）；  
  
接下来我们看下，master是如何给每一个slave发送RDB文件的：  
  
![fb6df892-16ac-3880-ade7-9cb43e2f356a.png][]  
  
好了，至此我们已经分析完在主从复制过程中，master和slave两边分别是怎么一个处理流程;最后，我绘制了一个图，综述了主从复制这一过程（我们可以边看图，边回忆其中的具体细节）：  
  
![点击查看原始大小图片][79f24d66-c2ac-3b2e-8f56-12148f50041d.png]  
  
PS：在主从复制过程中，任何一步发生错误，都会导致整个过程重头开始，所以若RDB文件很大又或是此时正处在业务高峰期，对系统性能将会有非常大的影响！  
  
**总结：**  
1. 了解主从复制master和slave的概念；  
2. 了解主从复制执行过程，特别是其中关键的几步；  
3. 了解目前主从复制过程中尚存的不足之处；

[0e62936a-b96a-3a35-b69a-1bbde1f54fe5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/f4a1f5adfb184ab8a71d284f7dae4503.png
[icon_star.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/7a1984abbaae430b95fc9fbd1b4605f3.png
[e574f370-3b04-34f1-be52-507783d02c1f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/fe4bd0e0a2ad401cab3c3a6b4e3267e4.png
[7955607d-eafd-35d3-9f13-e403260ccfd0.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/c0538cab3df8471bb1c7c94c7da9588b.png
[fb6df892-16ac-3880-ade7-9cb43e2f356a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/226f71f47aa04c8fbe7f4dd7fd89a46b.png
[79f24d66-c2ac-3b2e-8f56-12148f50041d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/29/9ccd5067a3934aeaa9be8e3c20c297d7.png