标签：文件 存储 同步 slave redis Redis master 快照 分布式
分布式存储-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
标签：文件,存储,同步,slave,redis,Redis,master,快照,分布式 来源： https://www.cnblogs.com/UpGx/p/15439143.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。