redis 所有队列重置过期时间 redis 队列持久化

文章目录

• 一、Redis持久化
• 二、Redis的持久化方式

• 1）RDB（Redis DB）

• 自动
• 手动

• 1）save指令
• 2）bgsave指令
• 3）SAVE 和 BGSAVE 命令

• RDB的优点和缺点

• 2）AOF（AppendOnlyFile）

• 使用
• 猜想
• 机制
• 策略
• 重写

• 1)自动
• 2)手动

• AOF的优点和缺点

一、Redis持久化

• 缓存：缓存是提高了CPU对内存反复的数据的处理速度.CPU要运算的数据都是从内存取来的
• 内存：速度比缓存慢，比硬盘块，重启后内容会消失
• 硬盘：重启后数据依然存在
• 持久化：将数据从掉电易失的内存存放到能够永久存储的设备上
• redis是基于内存的，提高对重复数据的访问速度，作为缓存服务器时，不需要持久化
• 作为内存数据库和消息队列时，需要持久化，消息对列是在消息的传输过程中保存消息的容器。

二、Redis的持久化方式

1）RDB（Redis DB）

• 在默认情况下，Redis 将数据库快照保存在名字为 dump.rdb的二进制文件中，每次保存的内容

自动

可以打开redis的配置文件，查看，设置自动保存快照

• save 900 1 如果键值更新的时间慢，只有一条，900秒会重新拍摄一个快i照，即900秒内更新的键值达到一个或以上，会保存一次
• save 300 10 如果值更新的达到了10,300秒时会save一次，300秒内更新的键值达到了10个或10个以上，会save一次
• save 60 10000 Redis要满足在60秒内至少有1000个键被改动，会自动保存一次
• 只要上面三个条件满足一个，就自动执行备份。
  创建RDB文件之后，时间计数器和次数计数器会清零。所以多个条件的效果不是叠加的
• 不能save的太快，一秒保存一次，降低了性能

手动

1）save指令

速度快，但会阻塞服务器无法，响应客户端请求，只能存储完成，生成新的rdb二进制备份

更改值后，执行save指令

查看rdb文件是否更新

2）bgsave指令

* 非阻塞，Redis服务正常接收处理客户端请求
* Redis会folk()一个新的子进程来创建RDB文件，子进程处理完后会向父进程* 发送一个信号，通知它处理完毕
* 父进程用新的dump.rdb替代旧文件
* 由于数据量少，看不出和save指令的区别，不在演示，知道在后台运行，速度比save要慢一点，不会影响客户端就行

3）SAVE 和 BGSAVE 命令

* SAVE不用创建新的进程，速度略快
* BGSAVE需要创建子进程，消耗额外的内存
* SAVE适合停机维护，服务低谷时段
* BGSAVE适合线上执行you'd

RDB的优点和缺点

• 优点
  完全备份，不同时间的数据集备份可以做到多版本恢复
  紧凑的单一文件，方便网络传输，适合灾难恢复
  恢复大数据集速度较AOF快
• 缺点
  会丢失最近写入、修改的而未能持久化的数据（当数据更改的数据量达到10000，但为到60秒时，服务器烧了，崩了，这60秒的数据就会丢失）
  folk过程非常耗时，会造成毫秒级不能响应客户端请求

2）AOF（AppendOnlyFile）

• 采用追加的方式保存，默认为不启动
• 记录所有的写操作命令，在服务启动的时候使用这些命令就可以还原数据库
• AOF方式不能保证绝对不丢失数据

由于默认是不启动这种保存方式的，需要把他打开

使用

编辑配置文件

更改默认值

将rdb的自动存储方式注释掉，将aof默认值改为启动

保存退出，停止redis，重启redis

• 重启redis的指令
  1.前台
  redis-server redis.conf
  若想后台启动
  更改配置文件，下次再执行该指令，便可后台启动
  
  2.后台
  nohup redis-server redis.conf &

重启后查看bin目录

更改键值

查看bin目录

可知采用的是aof记录，原rdb文件没有更新

查看aof文件

可以看到更改指令的记录

再执行其他命令，看看是否记录

结果：关于查询的get指令，没有对键进行修改，不会记录，只有对键进行更改的指令，才会被记录。

猜想

执行flushall指令，在aof文件中把指令flushall删去,看键值是否存在

测试

对键值进行了更改，查看aof文件

有flushall的记录=》将该条记录删除=》保存退出

重启redis，查看key值是否还在

结果：依然存在

机制

• 目前常见的操作系统中，执行系统调用write函数，将一些内容写入到某个文件里面时，为了提高效率，系统通常不会直接将内容写入硬盘里面，而是先将内容放入一个内存缓冲区（buffer）里面，等到缓冲区被填满，或者用户执行fsync调用和fdatasync调用时才将储存在缓冲区里的内容真正的写入到硬盘里，未写入磁盘之前，数据可能会丢失
• AOF方式不能保证绝对不丢失数据

策略

• appendfsync选项，这个选项的值可以是always、everysec或者no

默认是Everysec，可以通过redis.conf更改查看

• Always：服务器每写入一个命令，就调用一次fdatasync，将缓冲区里面的命令写入到硬盘。这种模式下，服务器出现故障，也不会丢失任何已经成功执行的命令数据
• Everysec（默认）：服务器每一秒重调用一次fdatasync，将缓冲区里面的命令写入到硬盘。这种模式下，服务器出现故障，最多只丢失一秒钟内的执行的命令数据
• No：服务器不主动调用fdatasync，由操作系统决定何时将缓冲区里面的命令写入到硬盘。这种模式下，服务器遭遇意外停机时，丢失命令的数量是不确定的
• 运行速度：always的速度慢，everysec和no都很快
• 可以根据情况调整策略

重写

• 重写的原因：AOF文件过大
  合并重复的操作，AOF会使用尽可能少的命令来记录
• 重写过程

• folk一个子进程负责重写AOF文件
• 子进程会创建一个临时文件写入AOF信息
• 父进程会开辟一个内存缓冲区接收新的写命令
• 子进程重写完成后，父进程会获得一个信号，将父进程接收到的新的写操作
• 由子进程写入到临时文件中
• 新文件替代旧文件

注：如果写入操作的时候出现故障导致命令写半截，可以使用redis-check-aof工具修复

1)自动

• 配置文件中的选项，自动执行BGREWRITEAOF命令
• auto-aof-rewrite-min-size ，触发AOF重写所需的最小体积：只要在AOF文件的体积大于等于size时，才会考虑是否需要进行AOF重写，这个选项用于避免对体积过小的AOF文件进行重写
• auto-aof-rewrite-percentage ，指定触发重写所需的AOF文件体积百分比：当AOF文件的体积大于auto-aof-rewrite-min-size指定的体积，并且超过上一次重写之后的AOF文件体积的percent %时，就会触发AOF重写。（如果服务器刚刚启动不久，还没有进行过AOF重写，那么使用服务器启动时载入的AOF文件的体积来作为基准值）。将这个值设置为0表示关闭自动AOF重写

2)手动

• 客户端向服务器发送BGREWRITEAOF命令
  演示
  增加键值
  
  查看aof
  
  执行重写
  
  再次查看
  
  发现里面的内容会简化，文件体积也有所减少

AOF的优点和缺点

• 优点

• 写入机制，默认fysnc每秒执行，性能很好不阻塞服务，最多丢失一秒的数据
• 重写机制，优化AOF文件
• 如果误操作了（FLUSHALL等），只要AOF未被重写，停止服务移除AOF文件尾部FLUSHALL命令，重启Redis，可以将数据集恢复到 FLUSHALL 执行之前的状态

• 缺点

• 相同数据集，AOF文件体积较RDB大了很多
• 恢复数据库速度叫RDB慢（文本，命令重演）

java