分布式存储-Redis持久化&高可用

分布式存储-Redis持久化&高可用

我们知道Redis很强大的一部分原因是因为它的数据是存储在内存中的,那如果服务器挂了之后,是不是我们的数据会丢失了呢?那我们需要把内存中的数据通过一个机制给它持久化,从而对数据的安全进行保障。本篇会聊到:

  • 两种数据存储机制【RDB】 和【AOF】
  • 哨兵模式

Redis的持久化机制

RDB【快照模式】:在某个时间段把当前的内存中数据进行一个存储【 默认

这种方式适合【灾备】,但是在备份的间隔时间可能造成一部分数据丢失

触发方法->

  • 自定义规则配置。在redis.conf中有一个save的命令行 第一个参数是 【save命令】 第二个参数是 【second】 第三个参数是 【change】。举例而言:如果在900s内有任何一个key发生变化他都会去触发一个快照。分布式存储-Redis持久化&高可用 我们可以尝试修改  分布式存储-Redis持久化&高可用5s中有一个key变化,就生成它的快照文件。当我们修改后就会生成一个dump文件,这个文件的位置我们可以使用redis-config中的dir参数进行指定。我们要保障他是数据的安全性,我们就可以写脚本,不断的把dump进行备份。当出现危险情况,把dump文件还原,就可以恢复数据了。分布式存储-Redis持久化&高可用
  • 可以执行SAVE(同步-阻塞)命令和BGSAVE(异步-非阻塞)命令
  • 执行FLASHALL命令(执行这个命令的时候出发快照)
  • Master-replicate(复制的时候)

AOF【Append Only File】:采用日志的方式来保存每个事务操作,他会把每个操作都写在文件中。

【配置方式(redis config中)】:我们可以把no 改成 yes,然后重启配置文件,我们发现appendonly.aof文件会生成到我们指定的文件路径下面(dir中指定的,和dump文件在同样的目录下)。当我们打开这个文件发现什么都没有  

分布式存储-Redis持久化&高可用

我们插入几个数据到redis中就会在这个文件中生成相关的数据,其实它存储的数据和咱们在手写redis客户端的那里的命令是一样的

分布式存储-Redis持久化&高可用

 分布式存储-Redis持久化&高可用

 那么他是实时同步数据到这个文件中的吗?这点其实我们可以配置,根据我们的cpu和数据数据安全程度进行权衡。

分布式存储-Redis持久化&高可用

  • no:交给操作系统进行同步(默认30s)。
  • everysec:默认/S都进行同步。
  • always:每个命令实时同步

但是这引发了一个弊病:每次事务操作都进行记录,那么这个文件必然是越来越大的,这对于我们后来的解析是很不友好的,这个时候就引出了rewrite

 【rewrite】:把无效的指令全部都进行压缩,本质其实是重新生成当前的AOF文件,这是因为如果去修改这个的AOF文件的话,那样的时间和效率的代价太大,生成文件之后对老的AOF文件进行覆盖

  • 自动触发重写
    • 分布式存储-Redis持久化&高可用 
    • 【rewrite-percentage】:当当前的AOF的文件大小超过上一个AOF文件的百分之多少(我们自己配置的)的时候就会进行重写:
    • 【rewrite-min-size】:不会进行重写的最小大写(当文件小于64mb的时候不会进行重写)
  • 手动触发重写(bgrewriteaof)
    • 分布式存储-Redis持久化&高可用

问题:会不会在写AOF的时候有些数据没有写入?

主进程在进行数据操作的时候,他会把数据保存在一个重写缓存中,换而言之,他会单独开辟一块空间去存储在重写期间接受到的命令,然后在重写完成后把重写的文件再次追加到新的AOF文件中。所以不会的。 

Redis的高可用

主从复制:下面有多种方式可以进行选择,这些不仅可以应用在redis上,其实在很多 情况下都可以使用,比如数据库。

  • 【一主多从】:所有的事务操作全部访问master,slave进行读的操作。这样的好处就是我们可以对slave进行水平扩容,当读多写少的情况下。但是当有多个slave的情况下,master同步数据给slave的压力就变大了,这个时候就可以采用级联复制【由一个slave去同步数据给其他slaves】
  • 【双主复制(双亲热备)】:其实他们有两个角色【master、backup】,并且在同一个时刻只有一个节点在进行工作,但是这两个节点都是输入运行状态。然后在这两个前面假设一个Keepalived,他会不断发送心跳去确定master的状态,如果master挂了他就会把backup作为新的master进行顶替
  • 【多主一从】:把不同master上的数据放在同一个slave上去进行数据统计和汇总

一主多从配置&准备

  • 准备三个节点,并且都安装好redis
  • 关闭防火墙   systemctl stop firewalld /  fifirewall-cmd --zone=public --add-port=6379/tcp --permanent
  • 配置slave 在config中加上 replicaof  <masterip > <masterport>

分布式存储-Redis持久化&高可用

  • 启动子节点,这个时候我们发现,其实启动的时候,master的数据就自动同步到slave中了,并且我们可以使用 【info  replication】查看他的角色 
  • 分布式存储-Redis持久化&高可用
  •  分布式存储-Redis持久化&高可用

同步原理(RDB模式):

  • slave连接到master服务器发送一个sync指令
  • master接受到指令后执行一个bgsave指令生成快照,并且发送快照给slave服务器
  • slave接受到快照后覆盖自己的快照文件
  • 如果在生成快照的时候有新的命令执行master会把新的命令放在缓存中,当我们slave收到了快照文件后,再把新增的增量的指令同步到slave节点

slave告诉master自己的端口,然后手动发送一个sync命令给master,这个时候就是【全量同步

分布式存储-Redis持久化&高可用

 这个时候在别的节点上执行一个set指令

分布式存储-Redis持久化&高可用

 我们发现他的指令就自动同步到其他的节点,这个叫做【增量同步

分布式存储-Redis持久化&高可用

默认情况下是异步进行同步的,意味着master只要完成客户端请求后,立刻返回给客户端,不管是否同步给slave,当然我们可以修改这个机制。

分布式存储-Redis持久化&高可用

  • master可以写的前提是,他的数据是已经同步给了3个节点
  • 允许slave最长失去联系的时间是10s

哨兵模式:

使用上面的一主多从进行主从复制的问题是,如果master节点挂了怎么办?所以这就引出了哨兵模式。其实他就是监控redis中的所有节点的一个进程,当然他也可以做集群。当master挂了之后他就可以从其他的slave中重新选举出一个master.在这种哨兵机制下,客户端连接的就是哨兵的地址,而不是master的地址。

【哨兵配置】:sentinel是redis自带的,这个文件本身就有,一般和redis,conf在一个文件下

分布式存储-Redis持久化&高可用

在sentinel.confi配置监听的master

分布式存储-Redis持久化&高可用

  • mymaster:自己起的一个哨兵的名字
  • 192.168.221.128: master的ip
  • 6379:mater的端口
  • 2:最低的投票通过次数(至少两个哨兵认为master挂了,才算真的挂了 哨兵可以做集群)

配置心跳超时时间:这里的意思是5s后,master没有响应,那哨兵就认为master挂了

 分布式存储-Redis持久化&高可用

配置容错机制 一定时间master还没有活过来就启动 failover【进行选举】

分布式存储-Redis持久化&高可用 

【 启动sentinel

分布式存储-Redis持久化&高可用

 查看 日志 

分布式存储-Redis持久化&高可用

 这个时候启动其他两个slave的sentinel按照同样的方式,我们发现在master的sentinel的日志中打印了他们的日志

分布式存储-Redis持久化&高可用

 这个时候我们的架构就是

分布式存储-Redis持久化&高可用

 

 模拟master宕机,看看是否会进行选举。查看哨兵的日志发现:

  • sdown指的是当前的哨兵的主观认为
  • vote-for-leader:指的是进行投票
  • odown:指的是三分之二的哨兵都认为maser宕机了
  • next failover delay:在咱们配置中指定的时间【容错机制的时候讲到了这个】内如果master没有启动那就证明要进行重新选举
  • switch master:这个时候就选举一个新的master

分布式存储-Redis持久化&高可用

 这个时候发现原来的slave变成了master

分布式存储-Redis持久化&高可用

 分布式存储-Redis持久化&高可用

 

上一篇:只读实例(slave主从)延迟排查


下一篇:LNMP和Redis、Redis主从复制