redis 持久化
Redis 支持两种持久化方式， RDB方式和AOF方式， 前者会根据指定的规则“定时”将内存中的数据存储在硬盘上，后者在每次执行命令后将命令本身记录下来。二者可单独使用一种，但多数情况是二者结合使用
tags: #redis #redis-RDB #redis-AOF
RDB 方式
RDB 方式通过快照所完成，当符合一定条件时， redis 会自动将内存的所有数据生成一份副本并存储在硬盘上，这个过程即为快照
redis 会在以下几种情况进行数据快照：
- 根据配置规则进行自动快照
- 用户执行SAVE或者BGSAVE 命令
- 执行FLASHALL命令
- 执行复制时
根据配置规则进行自动快照
redis 安装目录的配置中预置了3个条件：
save 900 1
save 300 10
save 60 10000
当 redis 符合快照条件时会自动执行快照操作。 快照条件的配置由两个参数构成： 时间M 和改动的键的个数N。每条快照条件占一行且以 save 开头，同时可存在多个条件，条件之间是 ‘或’ 的关系， 就以上的例子而言， save 900 1 意为：在15分钟(即900秒)内有一个或一个以上的键被更改则进行快照，同理， save 300 10 表示在300秒内至少有10个键被修改则进行快照
用户执行SAVE或者BGSAVE 命令
当服务重启、手动迁移及备份时也会需要到手动执行快照操作，redis 提供两个命令来完成这一任务。
SAVE 命令
当执行SAVE命令时，redis 同步的进行快照操作，在快照执行的过程中会阻塞所有来自客户端的请求，当数据库中的数据较多时， 这一过程会导致 redis 较长时间不响应。生产环境尽量避免使用。
BGSAVE 命令
需要手动执行快照时推荐使用BGSAVE命令，其可在后台异步进行快照操作，快照的同时服务器还可继续响应来自客户端的请求，执行完此命令，redis 会返回OK表示开始执行快照操作，若想知道快照是否完成。 可通过 LASTSAVE 命令获取最近一次成功执行快照的时间，返回结果是一个 unix 时间戳。
异步快照的具体过程参考快照原理
执行FLASHALL命令
执行FLASHALL时， redis 会清除数据库中的所有的数据 。 需要注意的是， 不论清空数据库的过程是否触发了自动快照条件，只要自动快照条件不为空， redis 就会执行一次快照操作。
例如： 当定义的快照条件为当1秒内修改10000个键时进行自动快照，而数据库中只有一个键时，执行FLASHALL也会触发快照，即便这一过程只有一个键被修改了。
当没有定义自动快照条件的时候，执行FLASHALL则不会进行快照
执行复制时
当设置了主从模式时，redis 会在复制初始化时，进行自动快照。 使用复制操作时，即便没有定义自动快照条件，且没有手动执行过快照， 也会生成RDB快照文件
快照原理
redis 默认会将快照文件存储在 redis 当前进程的工作目录中的 dump.rdb 文件中。 可以通过配置 dir 和 dbfile 两个参数分别指定快照文件的存储路径和文件名。快照过程如下 ：
- redis 使用 fork 函数复制一份当前进程(父进程)的副本(子进程)
- 父进程继续接受并处理客户端发来的命令， 而子进程开始将内存中的数据写入硬盘中的临时文件
- 当子进程写入完所有数据后会用该临时文件替换旧的RDB文件，至此一次快照操作完成。
在执行 fork 的时候， 操作系统(类 unix 操作系统)会使用写时复制(copy-on-write)策略，即 fork 函数发生的那一刻， 父子进程共享同一内存数据， 当父进程要改某一片数据时(如执行一个写命令)， 操作系统会将该片数据复制一份，以保证子进程数据不受影响，所以新的RDB文件存储的是执行 fork 那一刻的数据。
写时复制策略也保证了在 fork 的时刻虽然看上去生成了两份内存副本，但实际上内存的占用量并不会增加一倍。这就意味着当系统内存只有2GB，而 Redis 数据库 的内存有1.5 GB时，执行fork后内存使用量并不会增加到3 GB (超出物理内存)。为此需要确保Linux系统允许应用程序申请超过可用内存(物理内存和交换分区)的 空间，方法是在 /etc/sysctl.conf 文件加入vm.overcommit_memory = 1，然后重启系统或者执行sysctl vm.overcommit_ memory=1确保设置生效。
另外需要注意的是，当进行快照的过程中，如果写入操作较多，造成fork前后数据差异较大，是会使得内存使用量显著超过实际数据大小的，因为内存中不仅保存了当前的数据库数据，而且还保存着fork时刻的内存数据。进行内存用量估算时很容易忽略这一问题，造成内存用量超限。
通过上述过程可以发现Redis在进行快照的过程中不会修改RDB文件，只有快照结束后才会将旧的文件替换成新的，也就是说任何时候RDB文件都是完整的。这使得我们可 以通过定时备份RDB文件来实现Redis 数据库备份。RDB文件是经过压缩(可以配置rdbcompression参数以禁用压缩节省CPU占用)的二进制格式，所以占用的空间会小于内存中的数据大小，更加利于传输。
Redis启动后会读取RDB快照文件，将数据从硬盘载入到内存。根据数据量大小与结构和服务器性能不同，这个时间也不同。通常将一个记录1000万个字符串类型键、大小为 1 GB的快照文件载入到内存中需要花费20~30秒。
通过RDB方式实现持久化，一旦Redis异常退出，就会丢失最后一次快照以后更改的所有数据。这就需要开发者根据具体的应用场合，通过组合设置自动快照条件的方式来将可能发生的数据损失控制在能够接受的范围。例如，使用Redis存储缓存数据时，丢失最近几秒的数据或者丢失最近更新的几十个键并不会有很大的影响。如果数据相对重要，希望将损失降到最小，则可以使用AOF方式进行持久化。
AOF 方式
当使用 redis 存储非零时数据时， 一般需要打开AOF持久化来降低进程中止导致的数据丢失。 AOF可将 redis 执行的每一条命令追加到硬盘文件中，这一过程显然会降低 redis 到性能，但是大部分情况这个影响是可接受的。 另， 使用较快的硬盘可提升AOF的性能。
开启AOF
默认情况下 redis 没有开启AOF(append only file) 方式的持久化，可以通过 appendonly 参数启用：appendonly yes
开启AOF持久化后每执行一条会更改 redis 中数据的命令， redis 就会将该命令写入磁盘中的AOF文件。 AOF文件保存位置和RDB文件的位置相同， 都是通过 dir 参数设置的， 默认的文件名是 appendonly.aof 可以通过 appendfilename 参数修改：
appendfilename appendonly.aof
在启动 redis 时会逐个执行AOF文件中的命令来将硬盘中的数据载入到内存中，载入的速度相较RDB会慢一些
AOF 的实现
AOF 文件以纯文本的形式记录另 redis 执行的写命令，例如在开启AOF持久化的情况下执行如下4个命令：
set foo 1
set foo 2
set foo 3
get foo
redis 会将前三条命令写入AOF文件。被写入的AOF文件的内容是 redis 客户端向 redis 发送原始通信协议的内容
有一个问题是前两条命令其实是冗余的，因为这两条命令执行结果会被第三条命令覆盖，随着执行命令越来越多，AOF文件的大小也会越来越大，即使内存中的数据可能并没有多少。 redis 可以自动优化AOF文件， 举上个例子来说，就是将前两条命令删掉只保留第三条。 *reids 达到一定条件会自动重写AOF文件，这个条件可在配置文件中设置: *
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
auto-aof-rewrite-percentage 参数的意义是当目前AOF文件大小超过上一次重写时AOF文件大小的百分之多少时会再次重写，若从未重写过，则以启动时的AOF文件大小为依据。
auto-aof-rewrite-min-size 参数限制了允许重写的最小AOF文件大小，通常在AOF文件很小的情况下即使其中有很多冗余的命令我们也并不太关心。 除了让 redis 自动重写之外，我们还可以主动使用·BGREWRITEAOF命令执行AOF重写
同步硬盘数据
虽然每次执行更改数据库内容的操作时，AOF都会将命令记录在AOF文件中， 但事实上，由于操作系统但缓存机制，数据并没有真正写入硬盘，而是进入了系统但硬盘缓存。在默认情况下系统每30秒执行一次同步操作，以便将硬盘缓存中的内容真正的写入硬盘，在这30秒的过程中如果系统异常退出则会导致硬盘缓存中的数据丢失，一般来讲，启用AOF的应用都无法容忍这样的损失， 这就需要 redis 在写入AOF文件后主动要求系统将缓存同步到硬盘中， 在 redis 中我们可以通过 appendfsync 参数设置同步的时机： ```
# appendfsync always 最安全也是最慢的方式
appendfsync everysec # 即兼顾性能又保证了安全
# appendfsync no # 最快但最不安全
默认情况下， redis 采用 everysec 规则，即每秒执行一次同步操作。 always 表示每次执行写入都会执行同步。no 表示不主动进行同步操作，而是完全交由系统来做（即每30秒一次），一般情况下使用默认值 everysec 就够了
redis 允许同时开启AOF 和 RDB 既保证了数据安全又使得备份等操作十分容易。 此时重启 redis 后， redis 会使用 AOF 文件来恢复数据， 因为AOF方式可能丢失的数据更少