redsi 的持久化-3
redis的持久化方案
Redis 是一个内存数据库，为了保证数据的持久性，它提供了两种持久化方案：
RDB 方式（默认）快照方式进行备份某时某刻数据的一个完成备份，类似于mysql的Dump
AOF 方式 日志的方式进行备份
1、RDB 方式
介绍：
（1）RDB 是 Redis 默认采用的持久化方式。
（2）RDB 方式是通过快照（snapshotting）完成的，当符合一定条件时 Redis 会自动将内存中的数据进行快照并持久化到硬盘。
（3）Redis会在指定的情况下触发快照
- 符合自定义配置的快照规则
- 执行 save 或者 bgsave 命令
- 执行 flushall 命令
- 执行主从复制操作
- 在 redis.conf 中设置自定义快照规则
RDB 持久化条件：
1.格式：save
save 900 1 #表示15分钟（900秒钟）内至少1个键被更改则进行快照。
save 300 10 #表示5分钟（300秒）内至少10个键被更改则进行快照。
save 60 10000 #表示1分钟内至少10000个键被更改则进行快照。
# 这里就是 Redis 默认配置信息，可以配置多个条件（每行配置一个条件），每个条件之间是“或”的关系。
# 配置 dbfilename 指定 rdb 快照文件的名称，默认文件名为 dump.rdb
特别说明：
- Redi s启动后会读取 RDB 快照文件，将数据从硬盘载入到内存。
- 根据数据量大小与结构和服务器性能不同，这个时间也不同。通常将记录一千万个字符串类型键、大小为 1GB 的快照文件载入到内存中需要花费 20～30 秒钟。
2）快照的实现原理
（1）Redis 使用 fork 函数复制一份当前进程的副本(子进程)
（2）父进程继续接收并处理客户端发来的命令，而子进程开始将内存中的数据写入硬盘中的临时文件。
（3）当子进程写入完所有数据后会用该临时文件替换旧的RDB文件，至此，一次快照操作完成。
注意：
- Redis 在进行快照的过程中不会修改 RDB 文件，只有快照结束后才会将旧的文件替换成新的，也就是说任何时候 RDB 文件都是完整的。
- 这就使得我们可以通过定时备份 RDB 文件来实现 Redis 数据库的备份， RDB 文件是经过压缩的二进制文件，占 用的空间会小于内存中的数据，更加利于传输。
3）RDB 优缺点
（1）缺点：使用 RDB 方式实现持久化，一旦 Redis 异常退出，就会丢失最后一次快照以后更改的所有数据。这个时候我们就需要根据具体的应用场景，通过组合设置自动快照条件的方式来将可能发生的数据损失控制在能够接受范围。如果数据相对来说比较重要，希望将损失降到最小，则可以使用 AOF 方式进行持久化。
（2）优点： RDB 可以最大化 Redis 的性能：父进程在保存 RDB 文件时唯一要做的就是fork 出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无需执行任何磁盘 I/O 操作。同时这个也是一个缺点，如果数据集比较大的时候，fork 可以能比较耗时，造成服务器在一段时间内停止处理客户端的请求。
2、AOF 方式
1）AOF的介绍：
（1）默认情况下 Redis 没有开启 AOF（append only file）方式的持久化
（2）开启 AOF 持久化后每执行一条会更改 Redis 中的数据的命令，Redis 就会将该命令写入硬盘中的 AOF 文件，这一过程显然会降低 Redis 的性能，但大部分情况下这个影响是能够接受的，另外使用较快的硬盘可以提高 AOF 的性能（固态硬盘）。
（3）可以通过修改 redis.conf 配置文件中的 appendonly 参数开启 AOF 方式
（4）AOF 文件的保存位置和 RDB 文件的位置相同，都是通过 dir 参数设置的。
（5）默认的文件名是 appendonly.aof，可以通过 appendfilename 参数修改。
（6）开启后，重启 Redis，然后查看一下 bin 目录，就会发现多了一个 appendonly.aof 文件
2）AOF 重写原理（优化 AOF 文件）
（1）Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF进行重写，重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。
（2）整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。
（3）AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松。
3）参数说明
（1）auto-aof-rewrite-percentage 100 表示当前 aof 文件大小超过上一次 aof 文件大小的百分之多少的时候会进行重写。如果之前没有重写过，以启动时 aof 文件大小为准。
（2）auto-aof-rewrite-min-size 64mb 限制允许重写最小 aof 文件大小，也就是文件大小小于 64mb 的时候，不需要进行优化。
4）同步磁盘数据
Redis 每次更改数据的时候， aof 机制都会将命令记录到 aof 文件，但是实际上由于操作系统的缓存机制，数据并没有实时写入到硬盘，而是进入硬盘缓存。再通过硬盘缓存机制去刷新到保存到文件。
三个配置参数：分不同情况进行使用
（1）appendfsync always #每次执行写入都会进行同步 ， 这个是最安全但是是效率比较低的方式
（2）appendfsync everysec #每一秒执行
（3）appendfsync no #不主动进行同步操作，由操作系统去执行，这个是最快但是最不安全的方式
5）AOF 文件损坏以后如何修复
服务器可能在程序正在对 AOF 文件进行写入时停机， 如果停机造成了 AOF 文件出错（corrupt）， 那么 Redis 在重启时会拒绝载入这个 AOF 文件， 从而确保数据的一致性不会被破坏。
当发生这种情况时， 可以用以下方法来修复出错的 AOF 文件：
（1）为现有的 AOF 文件创建一个备份。
（2）使用 Redis 附带的 redis-check-aof 程序，对原来的 AOF 文件进行修复。
redis-check-aof --fix
(3). 重启 Redis 服务器，等待服务器载入修复后的 AOF 文件，并进行数据恢复
AOF持久化配置最优方案
appendonly yes #将该选项设置为yes，打开
appendfilename "appendonly.aof" #文件保存的名字
appendfsync everysec #采用第二种策略
dir ./data #存放的路径
no-appendfsync-on-rewrite yes #在aof重写的时候，是否要做aof的append操作，因为aof重写消耗性能，磁盘消耗，正常aof写磁盘有一定的冲突，这段期间的数据，允许丢失
6）如何选择 RDB 和 AOF
（1）一般来说,如果对数据的安全性要求非常高的话，应该同时使用两种持久化功能。
如果可以承受数分钟以内的数据丢失，那么可以只使用 RDB 持久化。
（2）有很多用户都只使用 AOF 持久化， 但并不推荐这种方式： 因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快 。
两种持久化策略可以同时使用，也可以使用其中一种。如果同时使用的话， 那么 Redis 重启时，会优先使用AOF文件来还原数据。
