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案例故障重启后从磁盘读取的快照文件用于恢复数据默认是保存在当前目录

save 使用主进程执行RDBbgsave是使用子线程执行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太多可以采用链式的方法来降低各个主节点的压力

Redis常用进阶存储原理和主从思路

Redis常用进阶存储原理和主从思路

简介