Redis持久化存储
Redis是一种内存型数据库，一旦服务器进程退出，数据库的数据就会丢失，为了解决这个问题，Redis提供了RDB与AOF两种持久化的方案，将内存中的数据保存到磁盘中，避免数据的丢失。
RDB持久化存储
Redis提供了RDB持久化的功能，这个功能可以将Redis在内存中的的状态保存到硬盘中，它可以手动执行。也可以在redis.conf中配置，定期执行。
RDB持久化产生的RDB文件是一个经过压缩的二进制文件，这个文件被保存在硬盘中，Redis可以通过这个文件还原数据库当时的状态。
RDB(持久化)
内存数据保存到磁盘
在指定的时间间隔内生成数据集的时间点快照（point-in-time snapshot）
优点：速度快，适合做备份，主从复制就是基于RDB持久化功能实现
rdb通过再redis中使用save命令触发 rdb
Redis持久化之RDB实践
1.准备一个redis配置文件redis.conf
cp redis.conf /redis/conf/6379.conf
2.配置文件中更改以下内容
vim 6379.conf
daemonize yes #后台运行
redisport 6379 #redis端口
logfile /redis/log/redis_6379.log #redis日志文件位置
dir /redis/data #指定redis数据文件夹放在哪
dbfilename dump_6379.rdb #指定rdb的数据文件
requirepass redis #指定redis的密码
save 900 1 #代表900秒内 有1个修改key的操作，就进行持久化
save 300 10 #300秒内 有10个修改类的操作，就持久化
save 60 10000 #60秒内 有10000个修改类的操作，就持久化
3.创建 /redis/data/文件夹
mkdir /redis/data
4.通过配置文件启动 redis服务端，支持rdb持久化的 服务端
redis-server /redis/conf/6379.conf
5.通过save指令 手动触发持久化数据
如果存在老的RDB文件，新替换老
复杂度 O(N)
阻塞客户端命令
不会消耗额外内存
6.通过bgsave指令 手动触发持久化数据
如果存在老的RDB文件，新替换老
复杂度 O(N)
不阻赛客户端命令
需要fork，消耗内存
7.自动生成RDB，
需要修改redis.conf配置文件
stop-writes-on-bgsave-error yes
dbcompression yes
rdbchecksum yes
dbfilename dump_6379.rdb
dir /redis/data
8.RDB还原
只需要把备份好的RDB文件拷贝至数据目录，并该名成对应的RDB文件名称。
9.触发方式
全量复制
主从复制时，主会自动生成RDB文件。
debug reload
Redis中的debug reload提供debug级别的重启，不清空内存的一种重启，这种方式也会触发RDB文件的生成。
shutdown 或者 shutdown save
会触发RDB文件的生成。
RDB总结
RDB是Redis内存到硬盘的快照，用于持久化
save通常会阻塞Redis
bgsave不会阻塞Redis，但是会fork新进程
save自动配置满足任一条件就会被执行
AOF持久化
不需要你手动的save触发持久化
AOF（append-only log file）
记录服务器执行的所有变更操作命令（例如set del等），并在服务器启动时，通过重新执行这些命令来还原数据集。AOF 文件中的命令全部以redis协议的格式保存，新命令追加到文件末尾。
优点：最大程序保证数据不丢
缺点：日志记录非常大
随着时间的推移，命令的逐步写入。AOF文件也会逐渐变大。当我们用AOF来恢复时会很慢，而且当文件无限增大时，对硬盘的管理，对写入的速度也会有产生影响。Redis当然考虑到这个问题，所以就有了AOF重写。
AOF重写
随着时间的推移，命令的逐步写入。AOF文件也会逐渐变大。当我们用AOF来恢复时会很慢，而且当文件无限增大时，对硬盘的管理，对写入的速度也会有产生影响。Redis当然考虑到这个问题，所以就有了AOF重写。
AOF重写就是把过期的、没用的、重复的以及可优化的命令，进行化简。只取最终有价值的结果。虽然写入操作很频繁，但系统定义的key的量是相对有限的。
AOF重写可以大大压缩最终日志文件的大小。从而减少磁盘占用量，加快数据恢复速度。比如我们有个计数的服务，有很多自增的操作，比如有一个key自增到1个亿，对AOF文件来说就是一亿次incr。AOF重写就只用记1条记录。
AOF重写两种方式
bgrewriteaof命令触发AOF重写
redis客户端向Redis发bgrewriteaof命令，redis服务端fork一个子进程去完成AOF重写。这里的AOF重写，是将Redis内存中的数据进行一次回溯，回溯成AOF文件。而不是重写AOF文件生成新的AOF文件去替换。
AOF重写配置
auto-aof-rewrite-min-size：AOF文件重写需要的尺寸
auto-aof-rewrite-percentage：AOF文件增长率
redis提供了aof_current_size和aof_base_size，分别用来统计AOF当前尺寸（单位：字节）和AOF上次启动和重写的尺寸（单位：字节）。
AOF自动重写的触发时机，同时满足以下两点）：
aof_current_size > auto-aof-rewrite-min-size
aof_current_size - aof_base_size/aof_base_size > auto-aof-rewrite-percentage
AOF持久化的三种策略
1:Always
服务器每写入一个命令,就调用一次fdatasync,将缓冲区里面的命令写入到磁盘里面,在这种模式下,服务器即使遭遇意外停机,也不会丢失任何自己已经成功执行的命令数据
2:Everysec
服务器每一秒重调用一次fdatasync,将缓冲区里面的命令写入到磁盘里面,在这种模式写,服务器即使遭遇意外停机时,最多只丢失一秒钟内执行的命令数据
3:NO
服务器不主动调用fdatasync,由操作系统决定任何将缓冲区里面的命令写入磁盘里面,在这种模式写,服务器遭遇意外停机时,丢失命令的数据是不确定的
4:always
速度慢,everysec和no都很快,默认值:everysec
AOF持久化重写配置
1.编辑redis.conf配置文件，写入如下内容
daemonize yesport 6379
logfile /redis/log/redis_6379.log
dir /redis/data/
# 开启aof持久化的参数
appendonly yes
# AOF文件名称
appendfilename "appendonly.aof"
# 每秒进行一次aof持久化
appendfsync everysec
# AOF重写最小尺寸
auto-aof-rewrite-percentage 100
# AOF重写期间是否暂停append操作。AOF重写非常消耗磁盘性能，而正常的AOF过程中也会往磁盘刷数据。
auto-aof-rewrite-min-size 64mb
# 通常偏向考虑性能，设为yes。万一重写失败了，这期间正常AOF的数据会丢失，因为我们选择了重写期间放弃了正常AOF刷盘。
no-appendfsync-on-rewrite yes
# redis启动时候加载.aof文件如果末尾文件不完整的话，是否截取掉，如果是yes，自动截取正常启动，如果设置为no则会报错
of-load-truncated yes
# 4.0版本的混合持久化默认关闭的，通过aof-use-rdb-preamble配置参数控制，yes则表示开启，no表示禁用，默认是禁用的
aof-use-rdb-preamble yes
2.创建配置文件对应的目录
mkdir /redis/{log,data}
3.启动redis服务（我这边redis配置文件名称为6379.conf）
redis-server /redis/conf/6379.conf
4.验证 aof持久化
写入数据后，杀死进程，
再次启动redis，检查数据
AOF命令重写试验
1.使用redis-cli插入大量数据
2.查看aof文件大小
3.使用flushall清空数据
4.再次查看aof文件，aof文件并没有减少
5.使用bgrewriteaof命令重写aof文件
6.再次查看aof文件（aof文件size减少）
Redis 持久化方式有哪些？有什么区别？
RDB与AOF
| 命令 | RDB | AOF |
|---|---|---|
| 启动优先级 | 低 | 高 |
| 体积 | 小 | 大 |
| 恢复速度 | 快 | 慢 |
| 数据安全性 | 丢数据 | 根据策略决定 |
| 轻重 | 重 | 轻 |
rdb：
基于快照的持久化，速度更快，一般用作备份，主从复制也是依赖于rdb持久化功能
RDB是一个非常紧凑的文件
RDB在保存RDB文件时父进程唯一需要做的就是folk出一个子进程，接下来工作全部交给子进程来做，父进程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能
与AOF相比，在恢复大的数据时候，RDB方式更快一些
数据丢失风险大
RDB需要经常folk子进程来保存数据集到磁盘，当数据集比较大额时候，folk的过程是比较耗时的，可能会导致redis在一些毫秒级不能响应客服端请求
aof：
以追加的方式记录redis操作日志的文件。可以最大程度的保证redis数据安全，类似于mysql的binlog
Redis优缺点(从上述redis持久化试验)
Redis优点
适合大规模的数据恢复
对数据完整性和一致性要求不高
Redis缺点
在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改
fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑
开发运维持久化常见问题
fork操作（在客户端下，使用info命令查看）
1、同步操作
2、与内存量息息相关：内存越大，耗时越长（与机器类型有关）
3、info:latest_fork_usec 查看持久化时间
改善fork
1、优先使用物理机或者高效支持fork操作的虚拟化技术
2、控制Redis实例最大可用内存：maxmemory
3、合理配置Linux内存分配策略：vm.overcommit_memory=1
4、降低fork频率：例如放宽AOF重写自动触发时机，不必要的全量复制
子进程开销和优化
1.CPU
开销：RDB和AOF文件生成，属于CPU密集型
优化：不做CPU绑定，不和CPU密集型部署
2.内存
开销：fork内存开销，copy-on-write
优化：echo never >/sys/kernel/mm/transparent_hugepage/enabled
3.硬盘
开销：AOF和RDB文件写入，可以结合iostat，iotop分析
优化：
1、不要和高硬盘负载服务部署一起：存储服务、消息队列等
2、no-appendfsync-on-rewrite = yes
3、根据写入量决定磁盘类型：例如ssd
4、单机多实例持久化文件目录可以考虑分盘