JavaWeb - Redis03

最新推荐文章于 2024-01-10 14:20:02 发布

上山打卤面

最新推荐文章于 2024-01-10 14:20:02 发布

阅读量163

点赞数

分类专栏： JavaWeb基础 # 后端（Servlet Cookie Session）文章标签： redis

本文链接：https://blog.csdn.net/qq_41922608/article/details/104596663

版权

JavaWeb基础同时被 2 个专栏收录

40 篇文章 1 订阅

订阅专栏

后端（Servlet Cookie Session）

14 篇文章 0 订阅

订阅专栏

Redis的持久化事务和锁

持久化

持久化简介
- 什么是持久化
  - 利用永久性存储介质将数据进行保存，在特定的时间将保存的数据进行恢复的工作机制称为持久化。
- 为什么要进行持久化
  - 防止数据的意外丢失，确保数据安全性
- Redis中两种持久化的方式：
  - RDB方式：将当前数据状态进行保存，快照形式，存储数据结果，存储格式简单，关注点在数据
  - AOF：将数据的操作过程进行保存，日志形式，存储操作过程，存储格式复杂，关注点在数据的操作过程
RDB启动方式
- RDB启动方式 —— save指令命令手动执行一次保存操作
  - save指令相关配置
    - dbfilename dump.rdb
      - 说明：设置本地数据库文件名，默认值为 dump.rdb
      - 经验：通常设置为dump-端口号.rdb
    - dir
      - 说明：设置存储.rdb文件的路径
      - 经验：通常设置成存储空间较大的目录中，目录名称data
    - rdbcompression yes
      - 说明：设置存储至本地数据库时是否压缩数据，默认为 yes，采用 LZF 压缩
      - 经验：通常默认为开启状态，如果设置为no，可以节省 CPU 运行时间，但会使存储的文件变大（巨大）
    - rdbchecksum yes
      - 说明：设置是否进行RDB文件格式校验，该校验过程在写文件和读文件过程均进行
      - 经验：通常默认为开启状态，如果设置为no，可以节约读写性过程约10%时间消耗，但是存储一定的数据损坏风险
  - save指令执行的原理：
    
    注意：save指令的执行会阻塞当前Redis服务器，直到当前RDB过程完成为止，有可能会造成长时间阻塞，线上环境不建议使用
- RDB启动方式 —— bgsave指令手动启动后台保存操作，但不是立即执行（为了解决上面的阻塞问题）
  - bgsave指令相关配置：
    - stop-writes-on-bgsave-error yes
      - 说明：后台存储过程中如果出现错误现象，是否停止保存操作
      - 经验：通常默认为开启状态
  - bgsave指令工作原理：
    
    注意： bgsave命令是针对save阻塞问题做的优化。Redis内部所有涉及到RDB操作都采用bgsave的方式，save命令可以放弃使用
- RDB启动方式 ——save配置上面的方式已经很香了但是手动的进行bgsave 有点麻烦
  - 配置 save second changes 满足限定时间范围内key的变化数量达到指定数量即进行持久化
  - 参数
    - second：监控时间范围
    - changes：监控key的变化量
  - 位置
    - 在conf文件中进行配置
  - 示例：
    
    save 900 1 900秒钟有1个key发生变化进行bgsave 使用配置的方式也肯定是使用bgsave的形式
    save 300 10 300秒钟有10个key发生变化
    save 60 10000 60秒钟有10000个key发生变化
  - save配置原理
    
    注意：
    - save配置要根据实际业务情况进行设置，频度过高或过低都会出现性能问题，结果可能是灾难性的
    - save配置中对于second与changes设置通常具有互补对应关系，尽量不要设置成包含性关系
    - save配置启动后执行的是bgsave操作
- RDB三种启动方式对比
- rdb特殊启动形式
  - 服务器运行过程中重启 debug reload
  - 关闭服务器时指定保存数据 shutdown save在没有进行AOF的配置默认使用bgsave
- RDB方式的优缺点：
  - RDB优点
    - RDB是一个紧凑压缩的二进制文件，存储效率较高
    - RDB内部存储的是redis在某个时间点的数据快照，非常适合用于数据备份，全量复制等场景
    - RDB恢复数据的速度要比AOF快很多
    - 应用：服务器中每X小时执行bgsave备份，并将RDB文件拷贝到远程机器中，用于灾难恢复。
  - RDB缺点
    - RDB方式无论是执行指令还是利用配置，无法做到实时持久化，具有较大的可能性丢失数据
    - bgsave指令每次运行要执行fork操作创建子进程，要牺牲掉一些性能
    - Redis的众多版本中未进行RDB文件格式的版本统一，有可能出现各版本服务之间数据格式无法兼容现象（但是也是有解决办法的有软件能解决）
AOF
- AOF概念：
  - AOF(append only file)持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令达到恢复数据的目的。与RDB相比可以简单描述记录数据为记录数据产生的过程
  - AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式
- AOF写数据过程：
- AOF写数据三种策略(appendfsync)
  - always(每次）每次写入操作均同步到AOF文件中，数据零误差，性能较低
  - everysec（每秒）每秒将缓冲区中的指令同步到AOF文件中，数据准确性较高，性能较高在系统突然宕机的情况下丢失1秒内的数据（推荐使用）
  - no（系统控制）由操作系统控制每次同步到AOF文件的周期，整体过程不可控 no的意思是不可控的意思不是不配置AOF
- AOF功能开启的步骤：先开启功能在配置策略
  - 第一步配置 appendonly yes|no 是否开启AOF持久化功能，默认为不开启状态
  - 第二步配置 appendfsync always|everysec|no AOF写数据策略
- AOF相关配置
  - appendfilename filename AOF持久化文件名，默认文件名未appendonly.aof，建议配置为appendonly-端口号.aof
  - dir AOF持久化文件保存路径，与RDB持久化文件保持一致即可
- AOF写数据遇到的问题：
  - 解决方式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 到达指定的百分比就重写
  - AOF手动重写 —— bgrewriteaof指令工作原理
  - AOF重写的流程：
  - RDB与AOF对比：
  - RDB与AOF的选择问题：
    - 对数据非常敏感，建议使用默认的AOF持久化方案
      - AOF持久化策略使用everysecond，每秒钟fsync一次。该策略redis仍可以保持很好的处理性能，当出现问题时，最多丢失0-1秒内的数据。
      - 注意：由于AOF文件存储体积较大，且恢复速度较慢
    - 数据呈现阶段有效性，建议使用RDB持久化方案
      - 数据可以良好的做到阶段内无丢失（该阶段是开发者或运维人员手工维护的），且恢复速度较快，阶段点数据恢复通常采用RDB方案
      - 注意：利用RDB实现紧凑的数据持久化会使Redis降的很低
    - 综合比对
      - RDB与AOF的选择实际上是在做一种权衡，每种都有利有弊
      - 如不能承受数分钟以内的数据丢失，对业务数据非常敏感，选用AOF
      - 如能承受数分钟以内的数据丢失，且追求大数据集的恢复速度，选用RDB
      - 灾难恢复选用RDB
      - 双保险策略，同时开启 RDB 和 AOF，重启后，Redis优先使用 AOF 来恢复数据，降低丢失数据的量

事务

什么是事务：redis事务就是一个命令执行的队列，将一系列预定义命令包装成一个整体（一个队列）。当执行时，一次性
按照添加顺序依次执行，中间不会被打断或者干扰（学过数据库方面的知识事务不会陌生这里就不详述）
事务的基本操作
- 开启事务multi 设定事务的开启位置，此指令执行后，后续的所有指令均加入到事务中
- 执行事务 exec 设定事务的结束位置，同时执行事务。与multi成对出现，成对使用
- 注意：加入事务的命令暂时进入到任务队列中，并没有立即执行，只有执行exec命令才开始执行
- 取消事务 discard 终止当前事务的定义，发生在multi之后，exec之前 redis 中没有事务回滚的操作需要手动的进行回滚 这个也是Redis中事务所被诟病的所以不常用
事务的工作流程：

锁

锁的基本操作：
- 对 key 添加监视锁，在执行exec前如果key发生了变化，终止事务执行 watch key1 [key2……]
- 取消对所有 key 的监视 unwatch
分布式锁：使用 setnx 设置一个公共锁 setnx lock-key value 利用setnx命令的返回值特征，有值则返回设置失败，无值则返回设置成功
- 对于返回设置成功的，拥有控制权，进行下一步的具体业务操作
- 对于返回设置失败的，不具有控制权，排队或等待
- 操作完毕通过del操作释放锁非常重要但是要是忘了进行锁的释放怎么办：就是给锁进行时效性的设置超时了自动放弃锁
- 使用 expire 为锁key添加时间限定，到时不释放，放弃锁
  - expire lock-key second
  - pexpire lock-key milliseconds 这种方式比较的常用一般都是微妙或者是毫秒级的
- 由于操作通常都是微秒或毫秒级，因此该锁定时间不宜设置过大。具体时间需要业务测试后确认
  - 例如：
    - 测试百万次最长执行时间对应命令的最大耗时，测试百万次网络延迟平均耗时
    - 锁时间设定推荐：最大耗时120%+平均网络延迟110%
    - 如果业务最大耗时<<网络平均延迟，通常为2个数量级，取其中单个耗时较长即可
- 但是上面两个命令导致不是原子操作解决方式：1 就是天机事务2 就是使用set命令因为 SET 命令可以通过参数来实现和 SETNX 、 SETEX 和 PSETEX 三个命令的效果，所以将来的 Redis 版本可能会废弃并最终移除 SETNX 、 SETEX 和 PSETEX 这三个命令：
  - 参数：
    - EX second ：设置键的过期时间为 second 秒。 SET key value EX second 效果等同于 SETEX key second value
    - PX millisecond ：设置键的过期时间为 millisecond 毫秒。 SET key value PX millisecond 效果等同于 PSETEX key millisecond value 。
    - NX ：只在键不存在时，才对键进行设置操作。 SET key value NX 效果等同于 SETNX key value 。
    - XX ：只在键已经存在时，才对键进行设置操作

上山打卤面

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
打赏
0
评论
JavaWeb - Redis03

Redis的持久化事务持久化简介什么是持久化利用永久性存储介质将数据进行保存，在特定的时间将保存的数据进行恢复的工作机制称为持久化。为什么要进行持久化防止数据的意外丢失，确保数据安全性Redis中两种持久化的方式：RDB方式：将当前数据状态进行保存，快照形式，存储数据结果，存储格式简单，关注点在数据AOF：将数据的操作过程进行保存，日志形式，存储操作过程，存...
复制链接

扫一扫