redis数据持久化篇

为什么需要持久化

Redis是个基于内存的数据库。

那服务一旦宕机，内存中的数据将全部丢失。

通常的解决方案是从后端数据库恢复这些数据，但后端数据库有性能瓶颈

如果是大数据量的恢复，1、会对数据库带来巨大的压力，2、数据库的性能不如Redis。

导致程序响应慢。

所以对Redis来说，实现数据的持久化，避免从后端数据库中恢复数据，是至关重要的。

Redis持久化有哪些方式呢？为什么我们需要重点学RDB和AOF？
从严格意义上说，Redis服务提供四种持久化存储方案：RDB、AOF、虚拟内存（VM）和　DISKSTORE。

最关键的是目前官方文档上能够看到的Redis对持久化存储的支持明确的就只有两种方案（https://redis.io/topics/persistence）：RDB和AOF。

所以本文也只会具体介绍这两种持久化存储方案的工作特定和配置要点。

RDB 持久化

RDB 就是 Redis DataBase 的缩写，中文名为快照/内存快照

RDB持久化是把当前进程数据生成快照保存到磁盘上的过程

由于是某一时刻的快照，那么快照中的值要早于或者等于内存中的值。

优点：数据压缩、恢复速度快
缺点：非实时备份，可能导致数据丢失

AOF 持久化

Redis是“写后”日志，Redis先执行命令，把数据写入内存，然后才记录日志。

日志里记录的是Redis收到的每一条命令，这些命令是以文本形式保存。

PS: 大多数的数据库采用的是写前日志（WAL），例如MySQL，通过写前日志和两阶段提交，实现数据和逻辑的一致性。

AOF类似于mysql的binlog，可以设置为每秒/每次操作，都以追加的形式，记录到日志里。

优点：非常安全，撑死丢失1s的数据，并且日志有可读性
缺点：文件较大，恢复较慢

1.RDB持久化实战

触发方式

触发rdb持久化的方式有2种，分别是手动触发和自动触发

手动触发

手动触发分别对应save和bgsave命令

save命令：阻塞当前Redis服务器，直到RDB过程完成为止，对于内存 比较大的实例会造成长时间阻塞，线上环境不建议使用
bgsave命令：Redis进程执行fork操作创建子进程，RDB持久化过程由子 进程负责，完成后自动结束。
阻塞只发生在fork阶段，一般时间很短

bgsave流程图如下所示

具体流程如下：
1.redis客户端执行bgsave命令或者自动触发bgsave命令； 

2.主进程判断当前是否已经存在正在执行的子进程，如果存在，那么主进程直接返回； 

3.如果不存在正在执行的子进程，那么就fork一个新的子进程进行持久化数据，fork过程是阻塞的，fork操作完成后主进程即可执行其他操作；

4.子进程先将数据写入到临时的rdb文件中，待快照数据写入完成后再原子替换旧的rdb文件；

5.同时发送信号给主进程，通知主进程rdb持久化完成，主进程更新相关的统计信息（info Persitence下的rdb_*相关选项）。

自动触发

在以下4种情况时会自动触发
redis.conf中配置save m n，即在m秒内有n次修改时，自动触发bgsave生成rdb文件；
主从复制时，从节点要从主节点进行全量复制时也会触发bgsave操作，生成当时的快照发送到从节点；
执行debug reload命令重新加载redis时也会触发bgsave操作；
默认情况下执行shutdown命令时，如果没有开启aof持久化，那么也会触发bgsave操作；

RDB配置参数解释

快照周期：内存快照虽然可以通过技术人员手动执行SAVE或BGSAVE命令来进行，但生产环境下多数情况都会设置其周期性执行条件。

Redis中默认的周期新设置

# 周期性执行条件的设置格式为
save <seconds> <changes>

# 默认的设置为：
save 900 1
# 900秒（15分钟）内至少1个key值改变（则进行数据库保存--持久化）
save 300 10
# 300秒（5分钟）内至少10个key值改变（则进行数据库保存--持久化）
save 60 10000
# 60秒（1分钟）内至少10000个key值改变（则进行数据库保存--持久化） 

# 以下设置方式为关闭RDB快照功能
save ""

以上三项默认信息设置代表的意义是：

如果900秒内有1条Key信息发生变化，则进行快照；
如果300秒内有10条Key信息发生变化，则进行快照；
如果60秒内有10000条Key信息发生变化，则进行快照。
可以按照这个规则，根据自己的实际请求压力进行设置调整，也就是你判断下，你们的redis读写频率大约是多少，是否高频，还是低频触发RDB。
其它相关配置

# 文件名称
dbfilename www.yuchaoit.cn_redis_dump.rdb

# 文件保存路径
dir /www.yuchaoit.cn/redis/data/

# 如果持久化出错，主进程是否停止写入
stop-writes-on-bgsave-error yes

# 是否压缩
rdbcompression yes

# 导入时是否检查
rdbchecksum yes

参数详解

dbfilename：RDB文件在磁盘上的名称。

dir：RDB文件的存储路径。默认设置为“./”，也就是Redis服务的主目录。

stop-writes-on-bgsave-error：上文提到的在快照进行过程中，主进程照样可以接受客户端的任何写操作的特性，是指在快照操作正常的情况下。如果快照操作出现异常（例如操作系统用户权限不够、磁盘空间写满等等）时，Redis就会禁止写操作。这个特性的主要目的是使运维人员在第一时间就发现Redis的运行错误，并进行解决。一些特定的场景下，您可能需要对这个特性进行配置，这时就可以调整这个参数项。该参数项默认情况下值为yes，如果要关闭这个特性，指定即使出现快照错误Redis一样允许写操作，则可以将该值更改为no。

rdbcompression：该属性将在字符串类型的数据被快照到磁盘文件时，启用LZF压缩算法。Redis官方的建议是请保持该选项设置为yes，因为“it’s almost always a win”。

rdbchecksum：从RDB快照功能的version 5 版本开始，一个64位的CRC冗余校验编码会被放置在RDB文件的末尾，以便对整个RDB文件的完整性进行验证。
这个功能大概会多损失10%左右的性能，但获得了更高的数据可靠性。

所以如果您的Redis服务需要追求极致的性能，就可以将这个选项设置为no。

操作部分（RDB）⭐️

[root@db-51 /opt/redis]#cat /opt/redis_6379/conf/redis_6379.conf 
daemonize yes
bind 127.0.0.1 10.0.0.51
port 6379
pidfile /opt/redis_6379/pid/redis_6379.pid
logfile /opt/redis_6379/logs/redis_6379.log

save 900 1
save 300 10
save 60 10000
dbfilename www.yuchaoit.cn_redis_dump.rdb
dir /www.yuchaoit.cn/redis/data/
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes

[root@db-51 /opt/redis]#mkdir -p /www.yuchaoit.cn/redis/data

[root@db-51 ~]$ls /www.yuchaoit.cn/redis/data/
[root@db-51 ~]$

#重启
[root@db-51 /opt/redis]#redis-server /opt/redis_6379/conf/redis_6379.conf 
[root@db-51 /opt/redis]#ls /www.yuchaoit.cn/redis/dat

#测试数据
[root@db-51 ~]$redis-cli set name chaoge
OK
[root@db-51 ~]$redis-cli dbsize
(integer) 1

#更改权限
[root@db-51 ~]$chown -R redis.redis /www.yuchaoit.cn/redis/data
# 达到自动RDB条件写入数据
for((i=1;i<=10086;i++));do
echo $i
redis-cli -h 10.0.0.51 -p 6379  set  这是第$i条数据 这条数据的内容为$i 
done;