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

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

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

Redis的持久化机制

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

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

触发方法->

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

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

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

、

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

 

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

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

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

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

• 自动触发重写
  •  
  • 【rewrite-percentage】:当当前的AOF的文件大小超过上一个AOF文件的百分之多少（我们自己配置的）的时候就会进行重写：
  • 【rewrite-min-size】：不会进行重写的最小大写（当文件小于64mb的时候不会进行重写）
• 手动触发重写（bgrewriteaof）
  • 

问题：会不会在写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>

• 启动子节点，这个时候我们发现，其实启动的时候，master的数据就自动同步到slave中了，并且我们可以使用 【info  replication】查看他的角色 
• 
•  

同步原理(RDB模式)：

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

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

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

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

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

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

哨兵模式：

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

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

在sentinel.confi配置监听的master

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

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

 

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

 

【 启动sentinel】

【 查看 日志 】

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

 这个时候我们的架构就是

 

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

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

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