04-Redis 数据持久化实践

https://redis.io/topics/config/

第二步:停止redis并删除挂载目录下(/usr/local/docker/redis01/conf)的redis.conf配置文件.

第三步:将下载的redis.conf文件拷贝到redis挂载目录(/usr/local/docker/redis01/conf)

第四步:基于vim打开redis.conf文件,然后注释 bind 127.0.0.1这一行,并修改protected-mode的值修改为no.(java连接redis需要改这两项目)

第五步:重启redis服务,并检查启动日志(docker logs 容器id)

Rdb方式持久化

==================================================================

概述

---

Rdb方式是通过手动(save-阻塞式，bgsave-异步)或周期性方式保存redis中key/value的一种机制,Rdb方式一般为redis的默认数据持久化方式.系统启动时会自动开启这种方式的持久化机制。

RDB方式配置

---

RDB方式的持久化是默认开启的，也可按规则自己配置，例如，打开redis.conf文件，例如

这里表示每隔60s，如果有超过1000个key发生了变更，那么就生成一个新的dump.rdb文件，就是当前redis内存中完整的数据快照，这个操作也被称之为snapshotting(快照)。

save 60 1000

持久化 rdb文件遇到问题时，主进程是否接受写入，yes 表示停止写入，如果是no 表示redis继续提供服务。

stop-writes-on-bgsave-error yes

在进行快照镜像时,是否进行压缩。yes:压缩，但是需要一些cpu的消耗。no:不压缩，需要更多的磁盘空间。

rdbcompression yes

一个CRC64的校验就被放在了文件末尾，当存储或者加载rbd文件的时候会有一个10%左右的性能下降，为了达到性能的最大化，你可以关掉这个配置项。

rdbchecksum yes

快照的文件名

dbfilename dump.rdb

存放快照的目录

dir /var/lib/redis

Rdb方式持久化实践

---

试验一

在redis中保存几条数据，然后执行shutdown关闭redis,然后再重启redis，看看刚才插入的数据是否还在？假如数据还在，为什么？

因为,通过redis-cli shutdown这种方式去停掉redis，其实是一种安全退出的模式，redis在退出的时候会将内存中的数据立即生成一份完整的rdb快照,例如

127.0.0.1:6379> set phone 11111111

OK

127.0.0.1:6379> shutdown #默认也会进行持久化

[root@centos7964 ~]# docker start redis01

[root@centos7964 ~]# docker exec -it redis01 redis-cli

127.0.0.1:6379> keys *

1. “pone”

试验二

在redis中再保存几条新的数据，用kill -9粗暴杀死redis进程，模拟redis故障异常退出，导致内存数据丢失的场景？

这次就发现，redis进程异常被杀掉，几条最新的数据就丢失了。例如:

首先,打开第一个客户端,先清除redis内存和磁盘对应的数据

[root@centos7964 data]# docker exec -it redis01 redis-cli

127.0.0.1:6379> flushall

OK

127.0.0.1:6379> exit

[root@centos7964 data]# ls

dump.rdb

[root@centos7964 data]# rm –f dump.rdb

[root@centos7964 data]# ls

然后,打开并登录第二个客户端,并向redis存储一些数据,例如

[root@centos7964 ~]# docker exec -it redis01 redis-cli

127.0.0.1:6379> set one mybatis

OK

127.0.0.1:6379> set two spring

OK

127.0.0.1:6379> keys *

1. “one”

2. “two”

接下来,再次回到第一个客户端,杀掉redis进程,例如

[root@centos7964 data]# ps -ef | grep redis

polkitd 6995 6974 0 14:44 ? 00:00:00 redis-server *:6379

root 7064 6974 0 14:44 pts/0 00:00:00 redis-cli

root 7111 6467 0 14:47 pts/1 00:00:00 docker exec -it redis01 redis-cli

root 7130 6974 0 14:47 pts/1 00:00:00 redis-cli

root 7278 7180 0 14:51 pts/0 00:00:00 grep --color=auto redis

[root@centos7964 data]# kill -9 6995

[root@centos7964 data]# docker start redis01

最后,打开第一个客户端,登录redis,检查key是否还存在.

[root@centos7964 ~]# docker exec -it redis01 redis-cli

127.0.0.1:6379> keys *

(empty array)

127.0.0.1:6379>

[root@centos7964 ~]#

试验三

手动调用save(同步保存)或者bgsave(异步保存)执行rdb快照生成.然后杀掉redis进程,再重启检测是否还有刚刚保存的数据.

127.0.0.1:6379> set id 100

OK

127.0.0.1:6379> set name jack

OK

127.0.0.1:6379> save #阻塞式持久化

OK

127.0.0.1:6379> set address beijing

OK

127.0.0.1:6379> bgsave #异步方式持久化

Background saving started

小节面试分析

---

Redis中的save和bgsave有什么不同？

• Redis Save 命令执行一个同步保存操作，将当前 Redis 实例的所有数据快照(snapshot)以 RDB 文件的形式保存到硬盘。

• BGSAVE 命令执行之后立即返回 OK ，然后 Redis fork 出一个新子进程，原来的 Redis 进程(父进程)继续处理客户端请求，而子进程则负责将数据保存到磁盘，然后退出。

RDB持久化机制有哪些优点？

第一：RDB会生成多个数据文件，每个数据文件都代表了某一个时刻中redis的数据，这种多个数据文件的方式，非常适合做冷备，可以将这种完整的数据文件发送到一些远程云服务上去，在国内可以是阿里云的ODPS分布式存储上，以预定好的备份策略来定期备份redis中的数据.

第二：RDB对redis对外提供的读写服务，影响非常小，可以让redis保持高性能，因为redis主进程只需要fork一个子进程，让子进程执行磁盘IO操作来进行RDB持久化即可。

第三：相对于AOF持久化机制来说，直接基于RDB数据文件来重启和恢复redis进程，更加快速。

RDB持久化机制有哪些缺点？