banner

IT运维工程师学习笔记-Redis笔记(6):redis数据安全-主从复制特性

redis主从复制特性

像MySQL一样,redis是支持主从同步的,而且也支持一主多从以及多级从结构。主从结构,一是为了纯粹的冗余备份,二是为了提升读性能,比如很消耗性能的SORT就可以由从服务器来承担。redis的主从同步是异步进行的,这意味着主从同步不会影响主逻辑,也不会降低redis的处理性能。主从架构中,可以考虑关闭主服务器的数据持久化功能,只让从服务器进行持久化,这样可以提高主服务器的处理性能。

执行复制的从服务器会连接上主服务器,主服务器会执行gbsave操作。然后从服务器接收主服务器发送的整个数据库的初始副本(copy);之后主服务器执行的写命令,都会被发送给所有连接着的从服务器去执行,从而实现更新从服务器的数据集。因为从服务器包含的数据会不断地进行更新,所以客户端可以向任意一个从服务器发送请求,以此来避免对主服务器进行集中式的访问。

   

注:

  

  

从服务器可以使用slaveof no one来让服务器停止复制操作,不再接受主服务器的数据更新,变成主服务器;也可以使用slaveof host port命令来让从服务器开始从一个新主服务器复制。

   

从服务器连接主服务器时的步骤

步骤

主服务器操作

从服务器操作

1

等待命令进入

连接(重新连接)主服务器,发送sync命令

2

开始执行bgsave,并使用缓冲区记录bgsave之后执行的所有写命令

根据配置选项来决定是继续使用现有的数据来处理客户端命令请求,还是向发送请求的客户端返回错误

3

bgsave执行完毕,向从服务器发送快照文件,并在发送期间继续使用缓冲区记录被执行的写命令

丢弃所有旧数据,开始载入主服务器发来的快照文件

4

快照文件发送完毕,开始向从服务器发送存储在缓冲区里面的写命令

完成对快照文件的解释操作,开始接受命令请求

5

缓冲区存储的写命令发送完毕;开始没执行一个写命令,就向从服务器发送相同的写命令。

执行主服务器发来的所有存储在缓冲区里面的写命令;并从现在开始,接收并执行主服务器传来的每个写命令

   

在日常生产中,要保留足够的内存空间给redis使用,剩余30%-45%空间为宜。因为在复制进行期间redis会尽可能的处理接收到的命令。但是,如果主从服务器之间网络带宽不足,或者主服务器没有足够的内存来创建子进程和创建记录写命令的缓冲区,那么redis处理命令请求的效率将会受到影响。

另外,要说的一点是,即使有多个从服务器同时发来SYNC指令,主服务器也只会执行一次BGSAVE,然后把持久化好的RDB文件发给多个下游

从服务器设置很简单,既可以配置选项slaveof host port也可以在执行过程中使用命令slaveof命令来设置为从。如果是配置选项slaveofhost那么redis在启动时会首先载入当前可用的任何快照文件或AOF文件,然后连接主服务器并执行复制过程。如果是使用slaveof命令,那么redis会立即尝试连接主服务器,连接成功后执行复制过程。

在主从架构中,从服务器通常被设置为只读模式,这样可以避免从服务器的数据被误修改。但是从服务器仍然可以接受CONFIG等指令,所以还是不应该将从服务器直接暴露到不安全的网络环境中。如果必须如此,那可以考虑给重要指令进行重命名,来避免命令被外人误执行。

注:

  

  

redis不支持主主复制

因为redis允许用户在服务器启动之后使用slaveof命令来设置从服务器,且会清空自身的所有数据。被互相设置为主服务器的两个redis实例只会持续占用大量处理器资源并且连续不断地尝试与对方进行通信,得到不一致的数据,或完全得不到数据。

主从链

多个从服务器同步主服务器的时候,需要通过互联网或者不同数据中心之间进行时,会造成网络不可用。因为redis的主服务器和从服务器并没有特别不同的地方,所以从服务器也可以拥有自己的从服务器,并由此形成主从链。

在对不同数据中心进行复制的时候,这种从服务器树有时候是必须的;

从服务器对从服务器在复制上唯一的区别在于,如果服务器X拥有从服务器Y,那么当从服务器X在执行从服务器连接主服务器操作步骤时,它将断开与从服务器Y的连接,导致从服务器Y需要重新连接并重新同步。

当读请求的重要性高于写请求的重要性,并且请求的数量远远超出一台redis服务器可以处理的范围时,用户就需要添加新的从服务器来处理读请求。随着负载上升,主服务器可能无法快速的更新所有从服务器,或者因为重新连接和重新同步从服务器而导致系统超载。为了缓解这个问题,用户可以创建一个由redis主从节点组成的中间层来分担主服务器的复制工作。

主从服务器不一定要像上图这样组成树形结构,但该结构对redis复制来说是可行的并且是合理的。

我们通过复制和AOF持久化可以将数据持久化到多台机器上,用户首先需要为主服务器设置多个从服务器,然后对每个从服务器设置appendonly yes选项和appendfsync everysec选项(如有需要也可以将主服务器进行相同的设置),这样,用户就可以让多台服务器以每秒一次的频率将数据同步到硬盘上了。

用户还需要等待主服务器发送的写命令到达从服务器,并且在执行后续操作之前,检查数据是否已经被同步到了硬盘里面。为了验证,是否已经将写输入发送至从服务器,用户需要在向主服务器写入真正的数据之后,再向主服务器写入一个唯一的虚拟值,然后通过检查虚构值是否存在于从服务器来判断写数据是否已经到达从服务器。

对于判断数据是否已经被保存到硬盘则要困难的多。对于每秒同步一次AOF文件的redis服务器来说,用户总是可以通过等待1秒来确保数据已经被保存到硬盘里面;但更节约时间的做法是,检查INFO命令的输出结果中aof_pending_bino_fsync属性的值是否为0,0表示已将将已知的所有数据都保存到硬盘里面了。

注:

  

  

INFO命令中的其他信息

INFO命令提供了大量的与redis服务器当前状态有关的信息,比如内存占用量,客户端连接数、每个数据库包含的键的数量、上一次创建快照文件之后执行的命令数量等。

 

推荐阅读:

/boot分区到底要不要单独划分

个人博客模板自定义修改

情书

阅读: 790
在同意共创许可协议(CC BY-NC-SA-4.0)的前提下,您可以转载本文。
付生保个人博客
https://shengbao.org/714.html

相关阅读

留言评论

暂无留言