©2020-2024 ioDraw All rights reserved,
Privacy Policy
<>持久化方式
通常数据库存在三种用于持久操作以防止数据损坏的常见策略:
* 1．是数据库不关心故障，而是在数据文件损坏后从数据备份或快照中恢复。RDB就是这种情况
*
2．该数据库使用操作日志记录每个操作的操作行为，以在失败后通过日志恢复一致性。由于操作日志是按顺序追加写入的，因此不会出现无法恢复操作日志的情况。类似于Mysql的重做和撤消日志。
*
3．数据库不修改旧数据，而仅通过追加进行写入，因此数据本身就是日志，因此永远不会出现数据无法恢复的情况。CouchDB是一个很好的例子。AOF类似这种情况
严格上讲Redis为持久化提供了三种方式:
* RDB:在指定的时间间隔能对数据进行快照存储，类似于MysQL的dump备份文件。
* AOF:记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据（MySQL的binlog）
* RDB与AOE混合使用，这是Redis4.0开始的新特性。在混合使用中AOF读取RDB数据重建原始数据集，集二者优势为
一体。
<>操作
[root@localhost ~]# cd /usr/local/redis/ [root@localhost redis]# ll total 0
drwxr-xr-x. 2 root root 152 Dec 12 20:58 bin [root@localhost redis]# mkdir conf
[root@localhost redis]# mkdir data [root@localhost redis]# mkdir log
[root@localhost redis]# vim /usr/local/redis/conf/redis.conf
配置文件
# 放行访问IP限制 bind 0.0.0.0 # 后台启动 daemonize yes # 日志存储目录及日志文件名 logfile
"/usr/local/redis/log/redis.log" # rdb数据文件名 dbfilename dump.rdb #
rdb数据文件和aof数据文件的存储目录 dir /usr/local/redis/data #设置密码 requirepass 123456
[root@localhost redis]# bin/redis-server conf/redis.conf
<>RDB持久化
我们可以配置Redis在n秒内如果超过m个key被修改就自动做快照，下面是默认的快照保存配置(这3个选项都屏蔽，则RDB禁用)∶
# 900秒内如果超过1个key改动，则发起快照保存 save 900 1 # 300秒内如果超过10个key改动，则发起快照保存 save 300 10
# 60秒内如果超过1W个key改动，则发起快照保存 save 60 10000
<>快照
把整个内存数据映射到硬盘中，保存一份到硬盘，因此恢复数据起来比较快，把数据映射回去即可，不像AOF，一条条的执行操作命令。
快照是默认的持久化方式。这种方式是就是将内存中数据以快照的方式写入到二进制文件中，默认的文件名为dump.db。可以通过配置设置自动做快照持久化的方式。
产生快照的情况有以下几种:
* 手动bgsave执行，非阻塞
* 手动save执行，阻塞
* 根据配置文件自动执行(bgsave方式)
* 客户端发送shutdown，系统会先执行save命令阻塞客户端，然后关闭服务器
* 当有主从架构时，从服务器向主服务器发送sync命令来执行复制操作时，主服务器会执行bgsaxe操作
<>RDB工作原理
Redis默认会将快照文件存储在Redis当前进程的工作目录中的dump.rdb文件中，可以通过配置dir和dbfilename两个参数分别指定快照文件的存储路径和文件名。流程过程如下(rdb.c中)。
BGSAVE会fork一个子进程来保存RDB，在这个期间能够正常接受外界命令，这时候如果主进程有修改的语句，就会把需要修改的数据复制出来，给子进程使用，主进程改干嘛干嘛。
保存好的新的RDB后，会将新RDB替换旧的RDB。如果期间还有SAVE,或BGSAVE命令执行，会被拒绝，如果有BGREWRITEAOF命令，会在BGSAVE执行结束后再执行。
<>RBD的优点
* 紧凑压缩的二进制文件
* fork子进程性能最大化
* 启动效率高
<>RDB的缺点
* 生成快照的时机问题
* fork子进程的开销问题
<>AOF持久化
它也是Redis持久化的重要手段之一，AOF (Append Only
File)只追加文件，也就是每次处理完请求命令后都会将此命令追加到aof文件的末尾。而RDB是压缩成二进制等时机开子进程去干这件事。
通过配置进行启动，默认是关闭的。
# 默认appendonly为no appendonly yes appendfilename "appendonly.aof" #
RDB文件和AOF文件所在目录 dir /usr/local/redis/data
<>同步策略
Redis中提供了3种AOF同步策略:
* 每秒同步（默认，每秒调用一次fsync，这种模式性能并不是很糟糕)
* 每修改同步（会极大消弱Redis 的性能，因为这种模式下每次write后都会调用fsync)。
* 不主动同步（由操作系统自动调度刷磁盘，性能是最好的) # 每秒钟同步一次，该策略为AOF的缺省策略 appendfsync everysec #
每次有数据修改发生时都会写入AOF文件 appendfsync always # 从不同步。高效但是数据不会主动被持久化 appendfsync no
<>工作原理
AOF的频率高的话肯定会对Redis带来性能影响，因为每次都是刷盘操作。跟mysql一样了。Redis每次都是先将命令放到缓冲区，然后根据具体策略（每秒/每条指令/缓冲区满）进行刷盘操作。如果配置的always，那么就是典型阻塞，如果是everysec每秒的话，那么会开一个同步线程去每秒进行刷盘操作，对主线程影响稍小。
<>写入文件与恢复
AOF文件是一个只进行append操作的日志文件，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。假如一次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过redis-check-aof工具来帮助我们修复问题。
AOF文件有序地保存了对数据库执行的所有写入操作，这些写入操作以Redis协议的格式保存，因此 AoF文件的内容非常容易被人读懂，对文件进行分析(
parse)也很轻松。
导出(export)AOF文件也非常简单:举个例子，如果你不小心执行了FLUSHALL
命令，但只要AOF文件未被重写，那么只要停止服务器，移除AQEFA文件未尾的
FLUSHALL命令，并重启Redis，就可以将数据集恢复到FLUSHALL执行之前的状态。
<>重写
Redis可以在AOF文件体积变得过大时，自动地在后台对AOF进行rewrite。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。
因为Redis在创建新AOF文件的过程中，会继续将命令追加到现有的AOF文件里面，即使重写过程中发生停机，现有的AOF文件也不会丢失。
而一旦新AOF文件创建完毕，Redis 就会从旧AOF 文件切换到新 AOF文件，并开始对新AOF文件进行追加操作。
<>为什么要重写
比如我有业务很简单，就来回delete set同一个key。就这个业务运行了10年，那么aof文件将记录无数个delete k1， set
k1。其实都是重复的，但是我aof每次都追加，文件变成了1T大小。这时候Redis宕机了，要恢复，你想想1TB大小的aof文件去恢复，累死了。最主要的是1TB大小只记录了两个命令，所以压缩其实就是来处理这件事的。
rewrite触发条件
* 客户端执行bgrewriteaof命令.
* auto-aof-rewrite-min-size 64mb
* auto-aof-rewrite-percentage 100
<>常用配置
# fsync持久化策略 appendfsync everysec #
AOF重写期间是否禁止fsync;如果开启该选项，可以减轻文件重写时CPU和硬盘的负载（尤其是硬盘），但是可能会丢失AOF重写期间的数据;需要在负载和安全性之间进行平衡
no-appendfsync-on-rewrite no # 当前aof文件大于多少字节后才触发重写 auto-aof-rewrite-min-size
64mb # 当前写入日志文件的大小超过上一次rewrite之后的文件大小的百分之100时，也就是2倍时触发Rewrite
auto-aof-rewrite-percentage 100 # 如果AOF文件结尾损坏，Redis启动时是否仍载入AOF文件
aof-load-truncated yes
<>AOF优点
* 数据不易丢失
* 自动重写机制
* 易懂易恢复
<>AOF缺点
* AOF文件恢复数据慢
* AOF持久化效率低
<>如何选择RDB和AOF
<>同时开启
Redis先加载AOF文件来恢复原始数据，因为AOF数据比rdb更完整,但是aof存在潜在的bug，如把错误的操作记录写入了aof，会导出数据恢复失败,所以可以把RDB作为后备数据。
为了考虑性能，可以只在slave上开启RDB，并且15min备份一次，如果为了避免AOF
rewite的IO以及阻塞，可以在Redis集群中不开启AOE，靠集群的备份机制来保证可用性，在启动时选取较新的RDB文件，如果集群全部崩溃，会丢失15min前的数据。
<>混合模式
Redis4.0开始支持该模式。
解决的问题: Redis在重启时通常是加载AOF文件，但加载速度慢。因为RDB数据不完整，所以加载AOF
开启方式: aof-use-rdb-preamble true
开启后，AOF在重写时会直接读取RDB中的内容。
运行过程:通过bgrwriteaof完成，不同的是当开启混合持久化后
* 1.子进程会把内存中的数据以RDB的方式写入aof中
* 2．把重写缓冲区中的增量命令以AOF方式写入到文件
* 3．将含有RDB个数和AOF格数的AOF数据覆盖旧的AOF文件
新的AOF文件中，一部分数据来自RDB文件，一部分来自Redis运行过程时的增量数据
<>数据恢复
当我们开启了混合持久化时，启动Redis依然优先加载aof文件，aof文件加载可能有两种情况如下:
* aof文件开头是rdb的格式,先加载rdb内容再加载剩余的aof
* aof文件开头不是rdb的格式，直接以aof格式加载整个文件
优点:既能快速备份又能避免大量数据丢失
缺点:RDB是压缩格式，AOF在读取它时可读性较差
<>二者动态切换
在Redis 2.2或以上版本，可以在不重启的情况下，从RDB切换到AOF:
* 为最新的 dump.rdb文件创建一个备份
* 将备份放到一个安全的地方 cp dump.rdb dump.rdb.bak
执行以下两条命令:
# 开启aof redis-cli config set appendonly yes # 关闭rdb redis-cli config set save
""
* 确保写命令会被正确地追加到AOF文件的末尾
* 执行的第一条命令开启了AOF功能: Redis会阻塞直到初始AOF文件创建完成为止，之后Redis
会继续处理命令请求，并开始将写入命令追加到AOF文件末尾
<>Redis容灾备份
开启RDB持久化
save 900 1 save 300 10 save 60 10000
开启AOF配置
# 开启aof appendonly yes appendfilename "appendony.aof" # rewrite
auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb # appendfsync
always appendfsync everysec # appendfsync no
RDB日志备份，编写脚本定时备份
vim一个redis-rdb-copy-per-hour.sh
#!bin/bash cur_date=$(date "+%Y%m%d%H%M%S") rm -rf
/usr/local/redis/snapshotting/$cur_date mkdir -p /usr/local/redis/snapshotting/
$cur_date cp /usr/local/redis/data/dump.rdb /usr/local/redis/snapshotting/
$cur_date del_date=$(date -d -48hour "+%Y%m%d%H%M") rm -rf
/usr/local/redis/snapshotting/$del_date
使用crontab定时器执行备份脚本
crontab -e
然后写入生产环境可以调整一下每小时执行一次