本篇内容介绍了“复述分布式基础的主从同步”的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够学有所成!
在使用复述的时候首先开始是从单台复述,服务器开始,随着业务和用户量的增长,单机会暴漏一些问题,比如单台服务器的响应达到了上限,复述,服务器宕机所有请求全部越过缓存等等一系列问题。
那么我们最简单的就是有一个备用的复述,服务器,当主服务器挂了从服务器就顶替主服务器继续服务,提高可用性。
我们拥有了主从两台复述,服务器之后,当主服务器挂掉之后从服务器就替换上去继续为我们服务,原来的主服务器恢复正常后我们两台服务器的数据又不一样了,那么我们如何保证这两台服务器的数据一致性问题呢呢?前面我们提到过帽定理和基础理论,我们知道在分布式,集群环境中我们需要保证数据一致性,所以我们这里得使用主从同步,或者是如果我们服务器数量特别多,我们可以减轻主服务器的同步压力,可以使用从从同步。下面我们来介绍复述,支持的几种同步方式。
我们知道复述,增量备份是通过保存执行指令来备份的,那么同步的时候我们也可以如此。主节点会将那些对自己的状态产生修改性影响的指令记录在本地的内存缓冲区中,然后异步将缓冲区中的指令同步到从节点,从节点一边执
行同步的指令流来达到和主节点一样的状态,一边向主节点反馈自己同步到哪里了(偏移量)。
但是内存的缓冲区是有限的,所以复述,主节点不能将所有的指令都记录在内存缓冲区中,复述的复制内存缓冲区是一个定长的环形数组,如果数组内容满了,就会从头开始覆盖前面的内容,如果因为网络状况不好,从节点在短时间内无法和主节点进行同步,那么当网络状况恢复肘,复述的主节点中那些没有同步的指令在缓冲区中有可能已经被后续的指令覆盖掉了。
从节点将无法直接通过指令流来进行同步,这个时候就需要用到更加复杂的同步机制一一快照同步。
<节> <强>快照同步快照同步既全量同步,就是把整个复述,数据库快照发送给从节点进行同步,成功后接下来的动作就是增量同步了,所以快照同步是一个非常耗资源的同步方式,这里注意的是新增加从节点是需要先进行快照同步的。
过程:
先将主节点的数据先bgsave
将这个快照保存在磁盘上,重写开启一个套接字线程
<李>通过插座线程可以发送快照给子节点,此时的快照是所有子节点共享的
<李>子节点同步
这里注意一个问题:当我们进行快照同步的时候,增量同步也在进行,当增量同步的数据被覆盖后还会进行快照同步,如此反复形成一个<强>死循环。
我们上面提到了在快照同步的时候会执行增量同步,这里还有一个没关注的就是复述的AOF增量同步问题。
当主节点进行快照同步时是先把这个快照保存到磁盘中,然后通过子线程共享文件到从节点,这里会进行文件的IO操作,这个操作是非常耗时的,在非SSD磁盘中存储时快照同步会对系统产生较大的负载,此时刚好主节点到了执行AOF备份操作,但是这两者并不能同时进行,所以AOF操作是会被延迟执行的,这样会严重影响主节点的执行效率,所以在Redis2.8版本之后支持无盘复制。
无盘复制是指主服务器直接通过套接字将快照内容发送到从节点,生成快照是一个遍历的过程,主节点会一边遍历内存,一边将序列化的内容发送到从节点,从节点先将接收到的内容存储到磁盘文件中,再进行一次性加载。
<节> <强>同步复制无盘复制属于一种异步的方式,Redis3.0提供了一种同步复制的指令,等等,确保系统强一致性.wait提供两个参数,第一个参数是从节点的数量,第二个参数是时间,<强>以毫秒为单位。
等待等待指令之前的所有写操作同步到N个从节点最多等待T毫秒时间。如果时间=0,表示无限等待直至N个从节点同步完成。
注意:如果时间等于0,刚好有个节点掉线了,那么这里会一直等待,阻塞服务器。
<节>祝辞,set key valueOK>, wait 1, 0(整数),1
<强>总结一下
