Redis学习笔记(三):Linux环境安装Redis、配置Redis、持久化(RDB、AOF)

基于Linux环境安装Redis

基于Center OS7安装Redis

  • 下载安装包:

    wget http://download.redis.io/releases/redis-?.?.?.tar.gz 
  • 解压

tar –xvf  文件名.tar.gz 
  • 编译

    make 
  • 安装

make install [destdir=/目录] 
  • 创建软链接

    #ln -s 原始目录名 快速访问目录名 
    ln -s /usr/local/redis/src/redis-cli /sbin/redis-cli
    ln -s /usr/local/redis/src/redis-server /sbin/redis-server

也可以使用dockers安装配置redis

Redis服务启动

默认配置启动

redis-server [ –-port 6379 ]

指定配置文件启动

redis-server /usr/local/docker/redis/conf/redis-6379.conf #配置路径

查看服务有启动

ps -ef | grep redis

Redis客户端连接

默认连接

  • redis-cli

连接指定服务器

  • redis-cli -h 127.0.0.1 –port 6379

Redis服务端配置

Redis配置文件主要配置项及相关含义

  • daemonize yes :以守护进程方式启动,使用本启动方式,redis将以服务的形式存在,日志将不再打印到命令窗口中
  • port 6*** : 设定当前服务启动端口号
  • dir /usr/local/docker/redis/data:设定当前服务文件保存位置,包含日志文件、持久化文件(后面详细讲解)等
  • logfile 6***.log:设定日志文件名,便于查阅

Redis 持久化

持久化简介

**什么是持久化 **:利用永久性存储介质将数据进行保存,在特定的时间将保存的数据进行恢复的工作机制称为持久化。

持久化的作用:防止数据的意外丢失,确保数据安全性

持久化过程保存什么

  • 将当前数据状态进行保存,快照形式,存储数据结果,存储格式简单,关注点在数据
  • 将数据的操作过程进行保存,日志形式,存储操作过程,存储格式复杂,关注点在数据的操作过程

在这里插入图片描述

一、RDB

RDB启动方式 —— save指令

命令 :

 save

作用 :手动执行一次保存操作

注意:save指令的执行会阻塞当前Redis服务器,直到当前RDB过程完成为止,有可能会造成长时间阻塞,线上环境不建议使用。

启动:redis-server启动时自动加载RDB文件

save指令相关配置 :

  • dbfilename dump.rdb
    • 说明:设置本地数据库文件名,默认值为 dump.rdb
    • 经验:通常设置为dump-端口号.rdb
  • dir
  • 说明:设置存储.rdb文件的路径
  • 经验:通常设置成存储空间较大的目录中,目录名称data
  • rdbcompression yes
  • 说明:设置存储至本地数据库时是否压缩数据,默认为 yes,采用 LZF 压缩
  • 经验:通常默认为开启状态,如果设置为no,可以节省 CPU 运行时间,但会使存储的文件变大(巨大)
  • rdbchecksum yes
  • 说明:设置是否进行RDB文件格式校验,该校验过程在写文件和读文件过程均进行
  • 经验:通常默认为开启状态,如果设置为no,可以节约读写性过程约10%时间消耗,但是存储一定的数据损坏风险

在这里插入图片描述

RDB启动方式 —— bgsave指令

命令:

bgsave

作用: 手动启动后台保存操作,但不是立即执行

bgsave指令工作原理 :

在这里插入图片描述

注意: bgsave命令是针对save阻塞问题做的优化。Redis内部所有涉及到RDB操作都应该采用bgsave的方式,save命令可以放弃使用。

bgsave指令相关配置 :

  • dbfilename dump.rdb
  • dir
  • rdbcompression yes
  • rdbchecksum yes
  • stop-writes-on-bgsave-error yes
    • 说明:后台存储过程中如果出现错误现象,是否停止保存操作
    • 经验:通常默认为开启状态
RDB启动方式 ——save配置原理

配置 :

 save second changes

作用: 满足限定时间范围内key的变化数量达到指定数量即进行持久化

参数 :

  • second:监控时间范围
  • changes:监控key的变化量

位置: 在conf文件中进行配置

范例 :

 save 900 1 
 save 300 10 
 save 60 10000 

save配置原理 :

在这里插入图片描述

注意

  • save配置要根据实际业务情况进行设置,频度过高或过低都会出现性能问题,结果可能是灾难性的
  • save配置中对于second与changes设置通常具有互补对应关系,尽量不要设置成包含性关系
  • save配置启动后执行的是bgsave操作
Save VS bgsave

在这里插入图片描述

rdb特殊启动形式
  • 全量复制
  • 服务器运行过程中重启
 debug reload
  • 关闭服务器时指定保存数据
shutdown save

默认情况下执行shutdown命令时,自动执行 bgsave(如果没有开启AOF持久化功能)

RDB优缺点

RDB优点 :

  • RDB是一个紧凑压缩的二进制文件,存储效率较高
  • RDB内部存储的是redis在某个时间点的数据快照,非常适合用于数据备份,全量复制等场景
  • RDB恢复数据的速度要比AOF快很多
  • 应用:服务器中每X小时执行bgsave备份,并将RDB文件拷贝到远程机器中,用于灾难恢复。

RDB缺点

  • RDB方式无论是执行指令还是利用配置,无法做到实时持久化,具有较大的可能性丢失数据
  • bgsave指令每次运行要执行fork操作创建子进程,要牺牲掉一些性能
  • Redis的众多版本中未进行RDB文件格式的版本统一,有可能出现各版本服务之间数据格式无法兼容现象

二、AOF

AOF简介

RDB的弊端:

  • 存储数据量较大,效率较低 基于快照思想,每次读写都是全部数据,当数据量巨大时,效率非常低
  • 大数据量下的IO性能较低
  • 基于fork创建子进程,内存产生额外消耗
  • 宕机带来的数据丢失风险

解决思路 :

  • 不写全数据,仅记录部分数据
  • 降低区分数据是否改变的难度,改记录数据为记录操作过程
  • 对所有操作均进行记录,排除丢失数据的风险

AOF概念 :

  • AOF(append only file)持久化:以独立日志的方式记录每次写命令,重启时再重新执行AOF文件中命令 达到恢复数据的目的。与RDB相比可以简单描述为改记录数据为记录数据产生的过程
  • AOF的主要作用是解决了数据持久化的实时性,目前已经是Redis持久化的主流方式

AOF写数据过程 :

在这里插入图片描述

AOF写数据三种策略(appendfsync)

三种策略:

  • always(每次):每次写入操作均同步到AOF文件中,数据零误差,性能较低,不建议使用。
  • everysec(每秒): 每秒将缓冲区中的指令同步到AOF文件中,数据准确性较高,性能较高,建议使用,也是默认配置 。在系统突然宕机的情况下丢失1秒内的数据
  • no(系统控制): 由操作系统控制每次同步到AOF文件的周期,整体过程不可控

AOF功能开启 :

  • 配置
 appendonly yes|no #是否开启AOF持久化功能,默认为不开启状态 
  • 配置

    appendfsync always|everysec|no  #AOF写数据策略 
AOF相关配置
  • 配置 :AOF持久化文件名,默认文件名未appendonly.aof,建议配置为appendonly-端口号.aof
 appendfilename filename 
  • 配置 :AOF持久化文件保存路径,与RDB持久化文件保持一致即可
dir 
AOF重写

随着命令不断写入AOF,文件会越来越大,为了解决这个问题,Redis引入了AOF重写机制压缩文件体积。AOF文件重 写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程。

简单说就是将对同一个数据的若干个条命令执行结 果转化成最终结果数据对应的指令进行记录。

在这里插入图片描述

AOF重写作用 :

  • 降低磁盘占用量,提高磁盘利用率
  • 提高持久化效率,降低持久化写时间,提高IO性能
  • 降低数据恢复用时,提高数据恢复效率

AOF重写规则 :

  • 进程内已超时的数据不再写入文件
  • 忽略无效指令,重写时使用进程内数据直接生成,这样新的AOF文件只保留最终数据的写入命令
  • 如del key1、 hdel key2、srem key3、set key4 111、set key4 222等
  • 对同一数据的多条写命令合并为一条命令
    • 如lpush list1 a、lpush list1 b、 lpush list1 c 可以转化为:lpush list1 a b c。
    • 为防止数据量过大造成客户端缓冲区溢出,对list、set、hash、zset等类型,每条指令最多写入64个元素

AOF重写方式 :

  • 手动重写

     bgrewriteaof 
  • 自动重写

     auto-aof-rewrite-min-size size 
     auto-aof-rewrite-percentage percentage 

bgrewriteaof指令工作原理 :
在这里插入图片描述

AOF自动重写方式
  • 自动重写触发条件设置配置文件

     auto-aof-rewrite-min-size size 
     auto-aof-rewrite-percentage percent 
  • 自动重写触发比对参数( 运行指令info Persistence获取具体信息 )

     aof_current_size 
     aof_base_size 
  • 自动重写触发条件

在这里插入图片描述

AOF工作流程和重写流程

在这里插入图片描述
在这里插入图片描述

三、RDB与AOF区别

RDB VS AOF :
在这里插入图片描述
RDB与AOF的选择之惑 :

  • 对数据非常敏感,建议使用默认的AOF持久化方案
    • AOF持久化策略使用everysecond,每秒钟fsync一次。该策略redis仍可以保持很好的处理性能,当出 现问题时,最多丢失0-1秒内的数据。
    • 注意:由于AOF文件存储体积较大,且恢复速度较慢
  • 数据呈现阶段有效性,建议使用RDB持久化方案
    • 数据可以良好的做到阶段内无丢失(该阶段是开发者或运维人员手工维护的),且恢复速度较快,阶段 点数据恢复通常采用RDB方案
    • 注意:利用RDB实现紧凑的数据持久化会使Redis性能降的很低
  • 综合比对
    • RDB与AOF的选择实际上是在做一种权衡,每种都有利有弊
    • 如不能承受数分钟以内的数据丢失,对业务数据非常敏感,选用AOF
    • 如能承受数分钟以内的数据丢失,且追求大数据集的恢复速度,选用RDB
    • 灾难恢复选用RDB
    • 双保险策略,同时开启 RDB 和 AOF,重启后,Redis优先使用 AOF 来恢复数据,降低丢失数据的量

四、持久化应用场景

0-1秒内的数据。

  • 注意:由于AOF文件存储体积较大,且恢复速度较慢
  • 数据呈现阶段有效性,建议使用RDB持久化方案
    • 数据可以良好的做到阶段内无丢失(该阶段是开发者或运维人员手工维护的),且恢复速度较快,阶段 点数据恢复通常采用RDB方案
    • 注意:利用RDB实现紧凑的数据持久化会使Redis性能降的很低
  • 综合比对
    • RDB与AOF的选择实际上是在做一种权衡,每种都有利有弊
    • 如不能承受数分钟以内的数据丢失,对业务数据非常敏感,选用AOF
    • 如能承受数分钟以内的数据丢失,且追求大数据集的恢复速度,选用RDB
    • 灾难恢复选用RDB
    • 双保险策略,同时开启 RDB 和 AOF,重启后,Redis优先使用 AOF 来恢复数据,降低丢失数据的量

四、持久化应用场景

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-sEomgQMi-1588930603730)(C:\Users\韩壮\AppData\Roaming\Typora\typora-user-images\image-20200508173452213.png)]

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值