php使用redis持久化,Redis持久化完整版本

持久化的简介

RDB

AOF

RDB与AOF的区别

持久化应用场景

对于持久化这个功能点,其实很简单没有那么复杂

演示环境

centos7.0

redis4.0

redis存放目录:/usr/local/redis

redis.conf存放目录:/usr/local/redis/data

1. 持久化简介

redis的所有数据都是保存在内存中,redis崩掉数据会丢失。redis持久化就是把数据保存在磁盘上。利用永久性存储介质将数据进程保存,在特定的时间将保存的数据进行恢复的工作机制称为持久化。

持久化过程保存的是什么呢?

第一种快照形式,存储数据结果,关注点在数据,也就是下文会讲到的RDB

第二种操作过程,存储操作过程,关注点在数据的操作过程,也就是下文会讲到的AOF

2. RDB

2-1 RDB启动方式 -- save命令

下图是redis.conf的配置信息,在执行完save后会生成一个dump.rdb的文件

95a9d33fc44634efe59c0f8477539c78.png

现在我们设置一个值,然后save一下,在/usr/local/redis/data下就会有一个dump6379.rdb的一个文件

d99402ee16df6642e23fccecbdb8d6c3.png

2-2 RDB使用方式之save

dbfilename dump6379.rdb :设置RDB文件名,默认值为dump.rdb

dir:存储rdb或者aof文件的路径

rdbcompression yes :设置存储时是否压缩数据,默认为yes,采用lzf压缩

rdbchecksum yes:设置是否进行RDB文件格式校验,该校验过程在写文件和读文件过程均进行

2-3 RDB数据恢复

其实这个数据恢复相对于其他关系型数据库恢复基本就不用操作什么。只需要重新在启动就好了

2-4 RDB -- save指令工作原理

当你执行save时,其他客户端请求redis的指令都会等待,直到save指令执行完成。因为save指令是单线程执行,一旦执行时间过长会直接导致其他用户端无法正常存储数据。所以这个指令我们默认被废弃。会使用下文介绍的bgsave来代替

2-5 RDB -- bgsave指令工作原理

a80721fb7ec17b597aebeac2a0011648.png

当在redis执行了bgsave后会直接返回一个Background saving started

这个时候我们在看一下日志文件,bgsave命令是针对save阻塞问题做的优化

4f308aee99140b8437a1565287453075.png

2-5 RDB -- 配置文件自启动

以下配置是默认配置

save 900 1

save 300 10

save 60 10000

stop-writes-on-bgsave-error yes

c61d0755f48be7430e582befc1bf872b.png

save 【时间】 【key改变数量】

也就是说在300秒有10个key值发生变化了,就会在后台执行bgsave

3. AOF

3-1 AOF概念

AOF文件存储的是执行命令操作过程,恢复数据也是使用操作过程来恢复。

3-2 AOF写数据过程

81de97954f34e4bab6a58f0e69fbf2de.png

执行一条redis命令

redis的AOF会把命令刷新缓冲区

然后根据一定的方式同步的到redis.conf配置的.aof文件中

3-3 AOF写数据的三种策略

always:执行的命令都会存储到AOF文件中,数据零误差,性能较低,不建议使用

everysec:每秒将缓冲区中的指令同步到AOF文件中,数据准确性较高,性能较高,建议使用,也是默认配置。但是在系统突然宕机的情况下回丢失1秒内的数据

no:由操作系统控制每次同步到AOF文件的周期,整体过程不可控

3-4 AOF功能开启

配置:appendonly yes|no

作用:是否开启AOF持久化功能,默认为不开启状态

配置:appendfsync always| everysec | no

作用:AOF写数据策略

配置:appenfilename filename

作用:AOF持久化文件名,默认名为appendonly.aof

68e57385e4b4a2a018242eb753b8776e.png

然后使用重启redis服务,就可以在usr/local/redis/data目录下可以看到appendonly.aof文件了

75ed7cc86ce810d3ee060818d5c5a21a.png

然后我们在redis客户端执行一条命令,在来查看一下。可以看到数据都会存入appendonly.aof这个文件中。

dce5cdb803f45a76ee3340b2758fbdba.png

3-5 AOF写数据出现的问题

我们先看一个案例,我们重复设置了name这个key后,打开appendonly.aof文件查看,可以看到有三个操作,但是这三个操作我们都是修改的一个key啊!我们只保存最后一个key不行吗?带着这个疑问,我们在继续往下看

476343d0ad689679a951d80ddfed6697.png

3-6 AOF重写

如在上边我们执行了三次 set name 指令,但是我们最终就只需要最后一次执行的记录。也就是我们只需要最后一次执行记录即可。其他的记录就不需要了,然后会把压缩后的数据重写到aof文件中。

重写后我们的磁盘利用率就提高了

还有就是我们恢复数据的速度也会变快

同时也会提高持久化的效率

3-7 AOF重写规则

进程内已超时的数据不再写入文件

忽略删除指令,如del,hdel,srem。 还有就是3-5说的问题,连续对一个key进行操作

对同一数据的多条写入记录合并为一条记录:如lpush list a lpush lsit b lpush list c可以转化为lpush list a b c。

3-8 AOF手动重写

指令:bgrewriteaof

接着我们3-5的问题,我们在命令行执行bgrewriteaof指令然后查看appendonly.aof文件

当执行完后会发现文件变小了,文件里也就只有一条指令了

7aa4743a5e736b8b7bd492b7d81869fa.png

3-9 AOF手动重写工作原理

bcb1bdc2b3979823a6bb6221377795d6.png

3-10 AOF自动重写

配置:auto-aof-rewrite-percentage 100 | auto-aof-rewrite-min-size 64mb

触发对比参数:aof_current_size | aof_base_size

当aof_current_size > auto-aof-rewrite-min-size 64mb 会启动重写

此图来源于网络

563e1fa8906634f9dd798d7e38662063.png

3-11 AOF工作流程和重写流=流程

1544a2b49f4b4583587830b6c857a18f.png

29ba83f192cb0d7feb5a011a28a76342.png

4. 总结

以上就是redis持久化的所有内容。

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值