两种持久化方式
RDB方式：在指定时间将内存中数据写入磁盘
AOF方式 ：将以日志的方式记录服务器所处理的每一个操作
无持久化
同时使用RDB和AOF
RDB方式
- 优势：
只包含一个文件，对于文件备份而言是完美的，容易恢复；
可以将单独文件压缩转移到其他存储介质；
通过子进程进行持久化，节约资源 - 劣势：
系统在定时前出故障，数据没来得及持久化。
数据集非常大，令服务器停止几秒。
配置：
redis.conf
100多行：
save 900 1 // 每900s，有1个key发生变化，往硬盘写一次key
save 300 10//每300s，有10个key发生变化，往硬盘写一次key
save 60 10000//每60s，有10000个key发生变化，往硬盘写一次key
194行：
\# The filename where to dump the DB
dbfilename dump.rdb
\# The working directory.
#
\# The DB will be written inside this directory, with the filename specified
\# above using the 'dbfilename' configuration directive.
#
\# The Append Only File will also be created inside this directory.
#
\# Note that you must specify a directory here, not a file name.
dir /var/lib/redis
AOF方式：
- 优势：更高的数据安全性，提供了三种同步策略：
每秒同步：异步完成，效率高，差的是，一旦系统出现宕机的现象，1s内的修改的数据就会丢失。
每修改同步；可视为同步持久化，效率最低，最安全
不同步:你懂的
对于日志的写入模式是追加的模式 ，即使写入的过程中出现宕机的情况也不会影响日志文件中已经存在的数据。
日志文件太大，就启动了日志重写数据。
AOF包含一个格式非常清晰，易于理解的日志文件用于记录所有的修改操作。可以通过这个文件完成数据的重建。 - 劣势：
相同的数据集， AOF文件较大。
策略不同，效率较低。 - 配置：
redis.conf
499行：
\# Please check http://redis.io/topics/persistence for more information.
appendonly no//默认使用RDB,如果要使用AOF，将no改成yes
\# The name of the append only file (default: "appendonly.aof")
appendfilename "appendonly.aof"//AOF文件
556行：同步策略
\# If unsure, use "everysec".
\# appendfsync always//每修改就同步（更安全）
appendfsync everysec//每秒同步
\# appendfsync no//不同步
