Redis常用进阶 存储原理和主从思路
简介
此篇用于需要时随时查阅的知识. 由于不断的学习总是会忘记一些 所以用于记录
笔记对应视频为黑马redis
https://www.bilibili.com/video/BV1Pu411Y7bq
单点redis的问题 :
- 数据丢失问题 持久化
- 并发能力弱 主从集群
- 存储能力问题 ES
- 故障恢复问题 哨兵 健康监测 恢复 (此类不做了解)
所有例子采用的是win10的redis linux其实同理 环境搭建比较费事主要用于记录解决方案
使用的redis版本 Redis-6.0.17-Windows-x64
存储机制
RDB
RDB 全程为redis database backupfile 就是使用线程将内存中的数据记录到磁盘中 当做redis案例故障重启后 从磁盘读取的快照文件 用于恢复数据 默认是保存在当前目录
shell
save 使用主进程执行RDB
bgsave是使用子线程执行rdb当redis主线程停止的时候 会默认的执行一次RDB
默认情况下 redis只有在结束主线程之前才会执行一次rdb 但是如果出现宕机数据就会出现丢失
配置定时RDB
我们可以通过配置文件的配置项 来设置多少时间内有多少数据变动来触发rdb
这是redis的默认出发设置
我们也可以通过 dir来设置文件存储的位置 不推荐开启压缩 因为cpu资源更加宝贵
bgsave
开始的时候会fork主进程到子进程 子进程共享内存数据 完成之后读取内存数据到RDB文件
RDB缺点
- RDB执行时间长 可能存在数据丢失风险
- 子进程压缩和写出比较耗时
AOF
Append Only File Redis处理的每一个写命令都会记录在AOF文件中 可以当做命令日志文件,如果redis出现了故障 恢复的时候就读取日志文件恢复
AOF默认是关闭的 我们需要去配置打开
aof 有三种频率 自上向下
- 每执行一次就存
- 写命令执行完先放入缓冲区 一秒一秒的写入 最多丢失1秒的数据
- 执行完命令直接放入缓冲区 由系统决定什么时候写到磁盘
性能对比:
使用
AOF文件的缺点
AOF占用的硬盘体积会比RDB大很多很多 因为AOF记录的是写命令 如果修改的key重复那么会多出很多无意义的记录
可以通过 执行 bgrewriteaof命令来让AOF执行重写功能 用最少的命令达到相同的记录效果
虽然变成了乱码 但是可以从一些片面的信息看到我们的key和一些值
redis给我们提供了配置 可以设置 AOF文件大于一定体积的时候就执行一次bgrewriteaof命令来最大限度的提升使用效率 分别是
- 根据上次文件的体积
- 根据固定的大小
对比
主从架构
主从架构是用来提升redis的并发上限的 主从之间会同步数据来达到承载更多数据压力的效果, 主节点来执行写操作 从节点来执行读操作就可以提升上限
这次根据教程的例子 我们搭建一主二从
- 7001 master
- 7002 slave
- 7003 slave
架构搭建
恢复配置 关闭 aof 开启 rdb 创建三个文件夹 每一个redis实例都需要自己的配置文件
创建完毕后将 redis.conf复制到每一个目录 然后修改端口号
我们配置主从可以使用 replicaof或者slaveof命令 来使用
也可以使用配置文件的方式来完成主从绑定
启动所有实例
配置主从的命令如下:
SLAVEOF 主节点的ip 主节点的端口
这样主从的配置就配置好了 , 我们可以使用 INFO REPLICATION命令来查看主从信息
我们在主节点写入 所有的从节点都可以查询到数据
数据同步原理
主从数据的第一次同步 是全量的同步 ,交流信息校验过程如下:
而主从之间的同步需要使用 RDB 文件这也是为什么配置架构的时候我们需要打开RDB
master持有数据集id这个id具有唯一性 对应着一个数据集 所有slave都回去继承这个repid,
主机通过偏移量来确认主从同步的数据是否一致 ,所以slave同步时需要将repid和偏移量体提交给master来判断数据的同步容量,
主从之间的增量同步 : 如果主从之间的断开时间太多 slave和master差距太大 就只能全量同步了,如果没有超出设定的范围则根据偏移量来完成增量同步
数据同步优化原理
- 在主节点中配置启用无磁盘复制
REPL-DISKLESS-SYNC避免全量同步时磁盘io的占用 尽可能减少全量同步 - 我们可以适当的提高 repl-baklog的大小 增加缓冲区 及时的恢复宕机的slave
- 如果主节点压力太大 slave太多 可以采用链式的方法来降低各个主节点的压力