持久化选项
-
快照持久化：获得存储在内存里面的数据在某个时间点上的副本。
-
AOF持久化（只追加文件append-only file）：会在执行命令时，将被执行的写命令写到硬盘里。
两种方案既可同时使用，也可单独使用，或都不使用，具体结合数据及应用决定。
# 快照持久化选项
#save 900 1
#save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename "dump.rdb"
dir "/home/ycl/install/redis"
# AOF持久化选项
appendonly no
appendfilename "appendonly.aof"
# appendfsync always
appendfsync everysec
# appendfsync no
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-load-truncated yes
dir "/home/ycl/install/redis" #共享选项：决定快照文件和AOF文件保存位置
快照持久化
在新的快照文件创建完毕之前，Redis、系统或硬件三者之中任意一个崩溃，那么Redis将丢失最近一次快照后的所有数据。
创建快照方法：
-
客户端向Redis发BGSAVE命令（除windows平台）。Redis调用fork创建一个子进程，然后子进程负责将快照写入硬盘，父进程继续处理命令请求。
-
客户端向Redis发SAVE命令。SAVE命令在快照创建完成前不再响应任何其他命令。SAVE命令不常用，除非没有足够内存执行BGSAVE命令。
-
配置SAVE选项。如save 60 10000，从Redis最近一次创建快照之后开始算起，“60s之内有10000次写入”。
-
SHUTDOWN或其它标准TERM信号会使Redis执行一个SAVE命令，阻塞所有客户端，不再执行客户端发送任何命令，SAVE结束关闭服务器。
-
一个Redis向另一个Redis发送SYNC命令进行复制操作，若服务器没执行BGSAVE则主服务器进行BGSAVE。
使用场景
-
个人开发：尽可能降低快照带来的资源消耗。如 save 900 1
-
日志聚合计算：将日志的处理进度记录到Redis里，程序在系统崩溃后根据进度记录继续执行之前未完成工作。
-
大数据：几G的数据量Redis创建子进程将数据保存到硬盘没问题，但Redis所占内存增大时，BGSAVE创建子进程耗时也会增加。若Redis占几十G且剩余内存不多时，或Redis跑在虚拟机上时，BGSAVE将使系统长时间停顿、引发系统大量使用虚拟内存，使Redis性能降低。为此，需关闭自动保存。但手动BGSAVE也会有同样问题，只是人为控制了出现停顿的时间而已。另一方面，SAVE因不用创建子进程，没有进程间争夺资源等创建快照更快一些。
AOF持久化
建议使用appendfsync everysec选项，AOF文件每秒同步一次，可以将丢失数据时间窗口降低至1s，性能和不使用任何持久化性能相差无几。问题是AOF文件体积会不断增大——①占用过多硬盘空间 ②还原数据慢
BGREWRITEAOF
该命令会移除AOF文件中冗余命令来重写AOF文件。
具体过程如下
1、redis 调用 fork ，现在有父子两个进程
2、子进程根据内存中的数据库快照，往临时文件中写入重建数据库状态的命令
3、父进程继续处理 client 请求，除了把写命令写入到原来的 aof 文件中。同时把收到的写命令缓存起来。这样就能保证如果子进程重写失败的话并不会出问题。
4、当子进程把快照内容写入已命令方式写到临时文件中后，子进程发信号通知父进程。然后父进程把缓存的写命令也写入到临时文件。
5、现在父进程可以使用临时文件替换老的 aof 文件，并重命名，后面收到的写命令也开始往新的 aof 文件中追加。
