一篇文章让你明白复述,主从同步

  

今天想和大家分享有关复述,主从同步(也称“复制”)的内容。

  

我们知道,当有多台复述,服务器时,肯定就有一台主服务器和多台从服务器。一般来说,主服务器进行写操作,从服务器进行读操作。

  

那么这里有存在一个问题:从服务器如何和主服务器进行数据同步的呢?

  

这个问题,就是通过今天的内容:主从同步来解决的。

  

文章内容依旧比较干,建议大家静下心来专心看,文末会给大家做个简单总结归纳。

  

<强> 1。如何进行主从同步

  

假如,现在有2台复述,服务器,地址分别是127.0.0.1:6379和127.0.0.1:12345

  

我们在127.0.0.1:12345的客户端输入命令:

        127.0.0.1:12345>SLAVEOF 127.0.0.6379      

如此127.0.0.1:12345服务器就会去复制127.0.0.1:6379的数据,即前者是从服务器,后者为主服务器。

  

除了以上方式进行复制之外,还可以通过配置文件中的slaveof选项进行设置。

  

可能,求知欲爆棚的你会想知道,复述是怎么进行主从同步的?

  

好的,下面我们继续了解一下。

  

<强> 2。主从同步的实现过程

  

主从同步分为2个步骤:同步和命令传播

  
      <李>同步:将从服务器的数据库状态更新成主服务器当前的数据库状态。(数据库状态在这篇文章开头有提到是什么意思,不清楚的小伙伴可以先看下:《持久化》)   <李>命令传播:当主服务器数据库状态被修改后,导致主从服务器数据库状态不一致,此时需要让主从数据同步到一致的过程。   
  

上面就是主从同步2个步骤的作用,下面我打算稍微细说这两个步骤的实现过程。

  

这里需要提前说明一下:在复述,2.8版本之前,进行主从复制时一定会顺序执行上述两个步骤,而从2.8开始则可能只需要执行命令传播即可。在下文也会解释为什么会这样?

  

<强> 2.1同步

  

从服务器对主服务的同步操作,需要通过同步命令来实现,以下是同步命令的执行步骤:

  
      <李>从服务器向主服务器发送同步命令李   <李>收到同步命令后,主服务器执行bgsave命令,用来生成rdb文件,并在一个缓冲区中记录从现在开始执行的写命令。   <李> bgsave执行完成后,将生成的rdb文件发送给从服务器,用来给从服务器更新数据李   <李>主服务器再将缓冲区记录的写命令发送给从服务器,从服务器执行完这些写命令后,此时的数据库状态便和主服务器一致了。   
  

用图表示就是这样的:

  

一篇文章让你明白复述,主从同步

  

<强> 2.2命令传播

  

经过同步操作,此时主从的数据库状态其实已经一致了,但这种一致的状态的并不是一成不变的。

  

在完成同步之后,也许主服务器马上就接受到了新的写命令,执行完该命令后,主从的数据库状态又不一致。

  

为了再次让主从数据库状态一致,主服务器就需要向从服务器执行命令传播操作,即把刚才造成不一致的写命令,发送给从服务器去执行。从服务器执行完成之后,主从数据库状态就又恢复一致了。

  

这里插播一个疑问:

  

不知道有没有的读者觉得,当发生上述不一致的情况后,复述,再执行同步操作不就好了吗?

  

从效果上来说,的确是可以恢复同步,但其实没有必要的。原因是实现同步的同步命令是一个非常消耗资源的操作,看完下图的说明,相信你肯定理解的。

  

一篇文章让你明白复述,主从同步

  

既然同步是一个非常消耗资源的操作,那复述,有没有什么优化方法呢?答案当然是有的。

  

<强> 2.3优化版同步操作

  

还记得上面说的内容吗——2.8版本开始,进行主从同步可能只需要执行命令传播即可。这个也是因为同步比较耗资源,从而采取的优化。

  

那什么时候可以这么做呢?我们先看下前提条件:

  

主从同步实际分2种情况:

  
      <李>初次复制:从服务器第一次复制当前主服务器(PS:主服务器是有可能更换的)   <李>断线后重复制:处于命令传播阶段的主从服务器,因为网络问题而中断复制,从服务器通过自动重连,重新连接上主服务器并继续复制。

    一篇文章让你明白复述,主从同步