一、数据持久化之RDB
1、RDB介绍
Redis 数据库文件，全称 Redis DataBase，数据持久化方式之一，数据持久化默认方式，按照指定时间间隔，将内存中的数据及快照写入硬盘
定义RDB文件名
dbfilename "dump.rdb"
RDB指dump.rdb文件; redis数据每次存盘，如果不指定持久化的方式，数据就会默认存入dump.rdb文件中
2、相关配置
数据从内存保存到硬盘的频率
save 900 1 # 900秒 (15分钟) 且有1个key改变即存盘
save 300 10 # 300秒 (5分钟) 且有10个key改变即存盘
save 60 10000 # 60秒 (1分钟) 且有10000个key改变即存盘手动存盘
save # 阻塞写存盘
bgsave # 不阻塞写存盘阻塞写存盘：即当内存中有1G大小的数据，执行了save命令，要写入硬盘，这个过程需要1分钟，则在这一分钟的时间内，不允许向内存中存入数据
不阻塞写存盘：即当内存中有1G大小的数据，执行了bgsave命令，要写入硬盘，这个过程需要1分钟，则在这一分钟的时间内，是允许向内存中继续存入数据的
save 将内存中的数据写入到硬盘
# 删除原有的持久化文件
[root@template ~]# rm /var/lib/redis/6379/*
[root@template redis-4.0.8]# redis-cli
127.0.0.1:6379> ping
PONG
# 添加数据
127.0.0.1:6379> mset v1 2 v2 4 v3 xx v4 66
OK
# 将内存中的数据马上写入到硬盘中(自动存盘的规则，需要满足条件)
127.0.0.1:6379> SAVE
OK
127.0.0.1:6379> exit
# 采用默认持久化方式，数据存到dump.rdb中
[root@template ~]# ll /var/lib/redis/6379/
total 4
-rw-r--r--. 1 root root 231 Apr 17 20:02 dump.rd重启redis服务以后，数据依然存在
[root@template redis-4.0.8]# redis-cli shutdown
[root@template redis-4.0.8]# ps -ef | grep redis.conf
root 121839 1221 0 20:05 pts/0 00:00:00 grep --color=auto redis.conf重新开启redis服务
[root@template redis-4.0.8]# /etc/init.d/redis_6379 start
Starting Redis server...查看当前库下所有的数据，依然存在，数据永久存储
[root@template redis-4.0.8]# redis-cli
127.0.0.1:6379> ping
PONG
127.0.0.1:6379> KEYS *
1) "site"
2) "student"
3) "v1"
4) "v4"
5) "v2"
6) "v3"3、 数据备份与恢复
备份数据：备份dump.rdb 文件到其他位置
恢复数据：拷贝备份文件到数据库目录，启动 redis 服务
redis服务器数据备份，备份dump.rdb文件，到/opt目录下
[root@template ~]# cp /var/lib/redis/6379/dump.rdb /opt/将备份的数据拷贝给template,让template拥有相同的数据
[root@template~]# scp /opt/dump.rdb [email protected]:/root/进行redis的数据恢复，停止redis服务
[root@template~]# /etc/init.d/redis_6379 stop
# 删除template，redis持久化数据文件
[root@template~]# rm -rf /var/lib/redis/6379/dump.rdb
# 将从template主机备份的文件，拷贝到redis的数据目录下
[root@template~]# cp /root/dump.rdb /var/lib/redis/6379/
# 重启服务，会重新加载dump.rdb
[root@template~]# /etc/init.d/redis_6379 start
[root@template~]# redis-cli
127.0.0.1:6379> keys *
127.0.0.1:6379> exit4、验证redis自动存盘
实验环境准备，停止redis服务
[root@template~]# redis-cli -h 192.168.11.10 -p 6350 -a 123456 shutdown进入到redis默认路径下，删除rdb数据文件
[root@template~]# cd /var/lib/redis/6379/
[root@template~]# rm -rf dump.rdb配置文件中修改存盘时间
[root@template ~]# vim /etc/redis/6379.conf
.......
219 save 900 1 #900秒 (15分钟) 且有1个key改变即存盘，不修改
220 save 120 10 #120秒 (2分钟) 且有10个key改变即存盘, 修改修改修改！！！！！
221 save 60 10000 #60秒(1分钟)且有10000个key改变即存盘，不修改启动redis服务
[root@template ~]# /etc/init.d/redis_6379 start连接redis,存入变量
[root@template ~]# redis-cli向reids中连续存入10个以上的变量
127.0.0.1:6379> mset v1 1 v2 1 v3 1 v4 1 v5 1 v6 1 v8 1 v9 1 v10 1 v11 1
127.0.0.1:6379> keys *
127.0.0.1:6379> exit在redis的数据目录下，两分钟dump.rdb出现，验证redis自动持久化成功
[root@template ~]# ls /var/lib/redis/63795、优点与缺点
RDB优点：
高性能的持久化实现 ——》 创建一个子进程来执行持久化，先将数据写入临时文件，持久化过程结束后，再用这个临时文件替换上次持久化好的文件；过程中主进程不做任何IO操作
1》持久化的效率高，因为是由一个单独的子进程来负责将内存中的数据写入到硬盘；
2》持久化过程：将当前进程中的数据生成快照文件，替换上次的持久化文件
PS：进程中的数据，指redis的所有数据，比较适合大规模数据恢复，且对数据完整性要求不是非常高的场合
恢复数据简单，拷贝备份数据，重启服务即可，因为RDB方式，有可能会丢失最后一次的持久化数据，使用时需要对数据完整性要求不高
RDB的缺点:
意外宕机时，丢失最后一次持久化的所有数据
1》redis 是每隔900秒(15分钟)，或者300秒(5分钟)，或者一分钟变量改变10000次，会进行一次持久化(将内存数据写入到硬盘)；
2》如果在还没有到达临界点时(例如：一分钟变量改变 9999次)，硬盘损坏，会导致这9999次的数据丢失。
二、数据持久化之AOF
1、AOF介绍
Append Only File
追加方式记录写操作的文件，记录 redis 服务所有写操作，不断的将新的写操作，追加到文件的末尾，默认没有启用，使用cat命令可以查看文件内容
2、开启AOF持久化功能，在template 上操作
[root@template ~]# redis-cli
127.0.0.1:6379> keys *
127.0.0.1:6379> config set appendonly yes #开启AOF持久化功能
127.0.0.1:6379> config rewrite #将临时配置写到配置文件中
127.0.0.1:6379> exit
[root@template ~]# ls /var/lib/redis/6379/
appendonly.aof dump.rdb3、查看AOF相关配置，在template上操作
[root@template ~]# vim /etc/redis/6379.conf
673:appendonly yes # aof持久化已经启用
677:appendfilename "appendonly.aof" # aof持久化存放数据的文件名4、AOF文件记录写操作的方式
[root@template ~]# vim /etc/redis/6379.conf
702 # appendfsync always #always 在redis中每进行一次写操作, 都会将记录存入appendonly.aof中，并将数据持久化到 dump.rdb文件中
703 appendfsync everysec #everysec 将写操作记录到appendonly.aof中，每秒执行一次，并将数据持久化到 dump.rdb文件中
704 # appendfsync no # no 只把写操作记录到appendonly.aof中，不会进行RDB持久化(节省系统资源)5、备份与恢复
备份数据：备份 appendonly.aof 文件到其他位置
redis服务器数据备份，在template 上操作
[root@template ~]# cp /var/lib/redis/6379/appendonly.aof /opt/将备份的aof数据文件拷贝给node01,让node01拥有相同的数据
[root@template ~]# scp /opt/appendonly.aof [email protected]:/root/恢复数据：拷贝备份文件到数据库目录，启动 redis 服务
[root@node01~]# /etc/init.d/redis_6379 stop
[root@node01~]# rm -rf /var/lib/redis/6379/dump.rdb
[root@node01~]# cp appendonly.aof /var/lib/redis/6379/开启本机的AOF持久化功能
[root@node01~]# vim /etc/redis/6379.conf
673 appendonly yes #no 修改为yes,启动AOF功能
[root@node01~]# /etc/init.d/redis_6379 start
[root@node01~]# redis-cli
127.0.0.1:6379> keys *
127.0.0.1:6379> exit6、优化配置
日志文件会不断增大，何时触发日志重写？
auto-aof-rewrite-min-size 64mb //首次重写触发值
auto-aof-rewrite-percentage 100 //到达增长百分比，再次执行重写查看redis的日志优化配置，在template上操作
#当日志的数据第一次达到64mb时，会触发重写，重写后文件大小为50Mb
#继续向日志中存入数据，日志大小为100Mb时，会触发重写，重写后文件大小为80Mb
#继续向日志中存入数据，日志大小为160Mb时，会触发重写，重写后文件大小为140Mb
#继续向日志中存入数据，日志大小为280Mb时，会触发重写，重写后文件大小为260Mb
[root@template~]# vim /etc/redis/6379.conf
744 auto-aof-rewrite-percentage 100
745 auto-aof-rewrite-min-size 64mb7、AOF优点与缺点
AOF优点
可以灵活设置持久化方式，出现意外宕机时，仅可能丢失1秒的数据
AOF缺点
持久化文件的体积通常会大于 RDB 方式，执行 fsync 策略时的速度可能会比 RDB 方式慢，验证AOF存储数据占用更多空间，在template上操作，统计appendonly.aof的行数
[root@node01 6379]# wc -l appendonly.aof
82 appendonly.aof
[root@node01 6379]# redis-cli
127.0.0.1:6379> set test 22
127.0.0.1:6379> exit #断开redis连接
[root@node01 6379]# wc -l appendonly.aof #再次统计appendonly.aof的行数
94 appendonly.aof8、生产环境的使用：
RDB和AOF持久化 需要同时开启，RDB做持久化，AOF记录redis执行命令