redis的持久化(rdb,aof,混合持久化)
redis的主从架构以及redis的哨兵架构
redis的cluster
redis 是要做持久化的,一般用redis会把数据放到缓存中为了提升系统的性能
如果redis没有持久化,重启的化数据就会丢失,所有的请求数据都会打在db上
这个时候数据库可能就会挂掉,所以一般使用redis的化就要开启redis的持久化
# 在redis的conf文件中
#save 60 1000
这个我们可以配置,意思是60s内至少有1000次数据的改动,就会自动保存一次
我们也可以通过save或者bgsave来手动执行生成这个rdb文件,他写进去的是二进制文件
Redis 后台触发条件 的时候生成快照默认 是通过bgsave (异步持久化文件)
![日常学习记录随笔-redis实战_第1张图片](http://img.e-com-net.com/image/info8/db0315456c834365905309e6f15c962e.jpg)
save 是利用执行命令的主线程在生成rdb 文件
bgsave的话 他不是用你的主线程生成rdb文件 他是用你的另外子进程去生成呢个副本
rdb的问题就是数据会丢失 比方我们设置save 60 1000, 在60s内变动1000次数据就会写进rdb 文件进行持久化
如果不到1000次的时候,此时redis宕机了 数据就会丢失
aof 我们可以通过他的appendOnly yes 开启他的aof 机制
![日常学习记录随笔-redis实战_第2张图片](http://img.e-com-net.com/image/info8/88d2e7ae83374c67b6fa5c3b5dae37fc.jpg)
![在这里插入图片描述](http://img.e-com-net.com/image/info8/543dd230db564dea8f7ccff5b528f085.jpg)
aof的策略
1.每执行一条都会去写进redis的aof文件中
2.我可以设置他1s执行一次 每秒执行一次 平均每过1s中,刷新进aof文件中
![日常学习记录随笔-redis实战_第3张图片](http://img.e-com-net.com/image/info8/decab7f1529f44daa9869f9e42fbddc3.jpg)
我们使用aof持久化的时候,当我们redis重启的时候.他会吧你的每一条数据逐行去执行,aof文件的问题就是比如说我aof文件特别大,呢么 这个时候 你去恢复数据的时候会很长
像rdb aof怎么去选择 你的知道他的优缺点
![日常学习记录随笔-redis实战_第4张图片](http://img.e-com-net.com/image/info8/1837fbe5214b48b88e42d608a710bed9.jpg)
rdb 体积小 因为他是二进制压缩数据
aof 体积大 所以他的恢复数据比较慢 但是他的数据安全性会比我们rdb 好一些
aof 也做了一些优化 aof 重写
基于 redis 的incr 进行重写 针对于这种情况 我aof 提供了一种优化机制
![日常学习记录随笔-redis实战_第5张图片](http://img.e-com-net.com/image/info8/bc64727fcc184c0c9d80af24f4a20a56.jpg)
针对于这种情况 redis 提供一种优化机制 我可以直接使用 set red 9 就可以了
![日常学习记录随笔-redis实战_第6张图片](http://img.e-com-net.com/image/info8/e4c2bdc61c0c4ca19b8c913645b1dddd.jpg)
redis可以配置
aof文件如果超过64兆 就会执行重写操作
对于文件不大的情况 不会做重写
比如说 我aof 之前通过aof文件进行恢复数据的时候 我需要incr 6次 我才可以恢复数据
现在我直接set red 6 就可以了
redis 默认开启rdb,aof需要自己去更改 因为rdb 生成的是二进制文件
不管是rdb和aof他都有自己的优缺点
rdb容易丢数据 但是他恢复数据快
我们aof恢复数据他恢复慢 但是他数据相对来说安全一些
在redis 4.o以后 有一个混和持久化
![日常学习记录随笔-redis实战_第7张图片](http://img.e-com-net.com/image/info8/14a33c8d1aba48aba651a1006c723958.jpg)
集中rdb 和aof的优点
他在执行aof 重写的时候会将aof文件变成二进制,前面的是吧内存数据进行的重写变成rdb压缩
混合持久化aof,只要触发aof重写他会把我们aof 文件变成格式比较紧促的二进制rdb 格式
如果我又有命令来执行 他会以为命令的形式追加到append的文件中
回头我恢复的时候 我前面就可以恢复的很快
![日常学习记录随笔-redis实战_第8张图片](http://img.e-com-net.com/image/info8/d168e2500ce943298909e10acfe9862e.jpg)
![日常学习记录随笔-redis实战_第9张图片](http://img.e-com-net.com/image/info8/9abd2c98407648329e8308c6ba54758d.jpg)
Redis4,0之后就可以使用混合持久化.现在用的是5.0的版本
混合持久化的方式本质上还是aof,用的文件还是aof的文件
只不过他在aof重写的时候,他的文件格式不再是单纯的一条一条命令
而是吧内存数据搞成二进制压缩格式,之后有新的命令的时候 还是会以aof的一条条命令
追加到我文件种
redis的数据备份
![日常学习记录随笔-redis实战_第10张图片](http://img.e-com-net.com/image/info8/c34e2cd3b66c44f584ff001cdcc5bc6c.jpg)
redis的主从架构 主节点去写数据 从节点去备份数,并且提供读操作
从节点只需要在redis.conf中配置 replicaof 就可以了
![在这里插入图片描述](http://img.e-com-net.com/image/info8/6898e7b4f3fc457a849d32cb59a5c508.jpg)
我从节点启动的时候,会从主节点进行全量同步数据,
主节点会生成rdb文件发到slave(全量内存生成)上,之后就是增量同步
主从复制的时候,主节点会生成rdb 快照发送到从节点上
从节点过多,会存在主从复制风暴,因为主节点会给每一个从节点发送个rdb 数据
多个从节点会同时从主节点去复制数据,这就会导致主节点压力过大,一般防止多个节点从主节点全部全量复制的化
![日常学习记录随笔-redis实战_第11张图片](http://img.e-com-net.com/image/info8/b0b510eeb2e5494aaa7ab6fc09a1212c.jpg)
我可以让多个备份节点根我们的某一个从节点相连,搞这种阶梯型架构来备份我们的从节点
有的时候,我可以为了提升性能,比如说我吧10条命令一次性的发送到redis中去执行
我可以批量发到redis 中去执行 让redis批量执行.减少网络传输的开销
redis的管道可以让你一次性的吧多条命令,一次性的发送到redis的service中
![日常学习记录随笔-redis实战_第12张图片](http://img.e-com-net.com/image/info8/25068bdcd16145358952cbd543b28da7.jpg)
哨兵模式 我们的主从架构上master挂了,可能的通过手动的方式把从节点加到主节点上,
对我们哨兵架构来说,哨兵监控redis,哨兵会自动帮你进行选举,选举从节点,
当主节点挂了以后,哨兵集群中至少有一半认为他是挂了此时才会说是挂了(哨兵的个数是基数)
![在这里插入图片描述](http://img.e-com-net.com/image/info8/a1f19e0b1e1449d68ef5b3b302c5ff7c.jpg)
也就是当主节点挂了,此时要开启新的选举 你必须有半数以上的哨兵认可 这个主节点挂了,才可以开启这个选举。当主节点挂了 集群中半数以上哨兵同意你挂了 再开启你的集群选举
![日常学习记录随笔-redis实战_第13张图片](http://img.e-com-net.com/image/info8/f25096645a7048a6831dcee690c868b5.jpg)
我们可以使用Info 命令来查看你redis的命令