关于redis的安装和基本使用，参考本人博客：
Redis数据库的学习与实践—Redis的常用命令及高级应用
1 redis持久化（persistence）
1.1 Redis 提供了多种不同级别的持久化方式
- RDB 持久化可以在指定的时间间隔内生成数据集的时间点快照（point-in-time snapshot）。
- AOF 持久化记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。 AOF 文件中的命令全部以 Redis 协议的格式来保存，新命令会被追加到文件的末尾。 Redis 还可以在后台对 AOF 文件进行重写（rewrite），使得 AOF 文件的体积不会超出保存数据集状态所需的实际大小。
Redis 还可以同时使用 AOF 持久化和 RDB 持久化。 在这种情况下， 当 Redis 重启时， 它会优先使用 AOF 文件来还原数据集， 因为 AOF 文件保存的数据集通常比 RDB 文件所保存的数据集更完整。
也可以关闭持久化功能，让数据只在服务器运行时存在。
1.2 RDB 模式
1.2.1 配置方式
RDB 复制模式也称作快照模式，在指定时间间隔中保存数据快照。
save <seconds> <changes>
在 seconds 时间间隔中发生changes次数的变化，就触发一次快照保存。可以配置多条规则。
除了在redis的配置文件中配置快照的规则外，还可以手动直接触发一次快照。直接调用SAVE 或者 BGSAVE命令。
1.2.2 工作原理
当 Redis 需要保存 dump.rdb 文件时， 服务器执行以下操作：
- Redis 调用 fork() ，同时拥有父进程和子进程。
- 子进程将数据集写入到一个临时 RDB 文件中。
- 当子进程完成对新 RDB 文件的写入时，Redis 用新 RDB 文件替换原来的 RDB 文件，并删除旧的 RDB 文件。
这种工作方式使得 Redis 可以从写时复制（copy-on-write）机制中获益
1.2.3 优缺点
优点：
- RDB 是一个非常紧凑（compact）的文件，它保存了 Redis 在某个时间点上的数据集。 这种文件非常适合用于进行备份： 比如说，你可以在最近的 24 小时内，每小时备份一次 RDB 文件，并且在每个月的每一天，也备份一个 RDB 文件。 这样的话，即使遇上问题，也可以随时将数据集还原到不同的版本。
- RDB 非常适用于灾难恢复（disaster recovery）：它只有一个文件，并且内容都非常紧凑，可以（在加密后）将它传送到别的数据中心。
- RDB 可以最大化 Redis 的性能：父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘 I/O 操作。
- RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
缺点：
- rdb模式按照指定时间发生几次变化来持久化数据，这就有可能在数据没有发生持久化的时候就宕机，导致当前时间段内的数据丢失
- 每次rdb回fork子进程进行，当数据量比较大的时候fork很耗时间，CPU紧张的时候更容易出现卡顿。
1.3 AOF(AppendOnly File) 模式
在服务器突然断电，死机，或者调用kill -9 命令杀死redis的时候，使用rdb的方式持久化是不够，这个时候最新的操作是没有被持久化。因此redis提供另外的一种持久化方式，append-only file 。
1.3.1 AOF 配置方式
要启动AOF的方式，需要在配置文件中设置
appendonly yes
配置时候，redis没产生一条指令都会被追加到AOF文件中，当服务器重启的时候，redis就从这个文件中重新执行指令来回复数据到内存中。
aof重写
通过上面不难发现，如果每次执行指令被保存，aof文件会越来远大。例如，一个increment 100次，就有100条指令，但是实际可以在回复数据的时候调用一句set 指令回复到最后的数据就可以了。所以redis也内置了重写机制。在不中断对客户端的服务器的情况下，在后台对aof文件重写。reids 2.2之前。需要是不是的调用BGREWRIETAOF指令，redis 2.4之后都是自动触发此指令。
同步频率配置 (how durable)
多久把数据同步(fsync)一次到文件的策略有三种：
- fsync always 每次新的指令，每条指令都加到aof。此方法非常非常的慢，但是非常安全。
- fsync everysec每个一秒钟同步一次。这种方法速度很快，最坏情况是损失1s内的数据
- never no 不同步，而是交给操作系统去处理。非常快，但是不安全。
redis默认和推荐的方法是每秒同步方式。
配置方式：
# appendfsync always
appendfsync everysec
# appendfsync no
AOF文件损坏怎么处理
当AOF文件损坏的时候，redis不能再从AOF中恢复数据，可按找下面的步骤处理：
- 备份当前AOF文件
- 使用redis-check-aof工具修复原AOF文件，执行命令
redis-check-aof --fix - 选择性的使用
diff -u检测两个文件的不同 - 用修改后的文件重启服务
1.3.2 AOF 工作原理（rewrite）
- redis forks 一个子进程
- 子进程开始把AOF写到一个临时文件
- 父进程计算所有的新变化并放在一个内存缓冲区（同时他还把这些变化写进老的AOF文件，所以重写失败，也是安全的）
- 最后。redis自动用新文件替换老文件。开始往新文件添加数据
1.3.3 AOF 优缺点
AOF 优点：
- 数据安全性更高，从同步机制上看。always方式满，但每条指令都存储。
- aof是一个追加文件，出现问题可以使用redis-check-aof工具修复
- 文件过大的时候会使用重写方式，只要文件存在，数据有可以恢复
- 文件内容以redis的协议存储，方便解读。能偶方便导出和解析。
AOF 缺点：
- 数据量过大的时候，redis的aof体积会比rdb文件大
- 根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。 在一般情况下， 每秒 fsync 的性能依然非常高， 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快， 即使在高负荷之下也是如此。 不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间（latency）
1.4 数据容灾
需要经常对数据数据（rdb文件）进行备份
- 使用corn job方式，定去备份rdb文件到某个文件夹
- 备份时间打上时间标签，使用find找到很早期的备份删除
- 定期把备份放到当前物理机之外的机器备份一份。
