Redis&持久化存储

• RDB 是一个非常紧凑（compact）的文件，它保存了 Redis 在某个时间点上的数据集。 这种文件非常适合用于进行备份： 比如说，你可以在最近的 24 小时内，每小时备份一次 RDB 文件，并且在每个月的每一天，也备份一个 RDB 文件。 这样的话，即使遇上问题，也可以随时将数据集还原到不同的版本。
• 生成的文件是一种压缩的二进制文件，方便于在网络中传输。
• RDB 非常适用于灾难恢复（disaster recovery）：它只有一个文件，并且内容都非常紧凑，可以（在加密后）将它传送到别的数据中心。
• RDB 可以最大化 Redis 的性能：父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘 I/O 操作。
• RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

RDB 缺点

• 如果想要避免在服务器故障时丢失数据，那么 RDB 不太适合。 RDB保存一次备份之后，到下一次保存之前，这段期间所产生的的新数据，如果还没有达到生成备份文件的条件，此时服务器宕机就会丢失这部分数据。虽然 Redis 允许你设置不同的保存点（save point）来控制保存 RDB 文件的频率， 但是因为 RDB 文件需要保存整个数据集的状态，所以它是一个非常耗费系统资源的操作。 因此若是需要至少 5 分钟才保存一次 RDB 文件的情况下， 一旦发生故障停机，可能会丢失好几分钟的数据。
• 每次保存 RDB 的时候，Redis 都要 fork() 创建出一个子进程，并由子进程来进行实际的持久化工作。 在数据集比较庞大时， fork() 可能会非常耗时，造成服务器在某某毫秒内停止处理客户端； 如果数据集非常巨大，并且 CPU 时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒。 虽然 AOF 重写也需要进行 fork() ，但无论 AOF 重写的执行间隔有多长，数据的耐久性都不会有任何损失。创建子线程和生成rdb文件会占用大量 的系统资源和处理时间

RDB 配置文件

# dbfilename：配置RDB文件的名称，默认叫 dump.rdb
dbfilename dump.rdb

# dir：配置的RDB文件存储在本地的路径，如果是在 /redis/redis-3.0.6/src 下启动的redis-cli，则数据会存储在当前src目录下
dir ./

# snapshot触发时机的配置：save <seconds> <changes> ， 可通过 save “” 关闭snapshot功能  
# changes：对于此值设置需谨慎，要评估系统的变更操作密集程度 
save 900 1        # 更改了1个key的时候，间隔900秒后，至少有一个变更操作，进行持久化存储snapshot   
save 300 10      # 更改了10个key的时候，间隔300s进行持久化存储
save 60 10000   # 更改10000个key的时候，间隔360s进行存储。

# 当生成 RDB 文件出错无法继续时，是否则色客户端的“变更操作”，是否继续处理 Redis 写命令，默认为不处理。“错误”可能因为磁盘已满/磁盘故障/OS级别异常等  
stop-writes-on-bgsave-error yes  

# 是否对rdb文件进行压缩，默认为“yes”，压缩往往意味着“额外的cpu消耗”，同时也意味这较小的文件尺寸以及较短的　　
rdbcompression yes      

# 是否对 RDB 文件进行校验和校验
rdbchecksum

#####

RDB 命令演示

Redis shutdown模拟服务器宕机
mv dump.rdb dump.rdb.bak
停止redis服务器service redis stop
启动redis-server /etc/redis/redis.conf
redis-cli
查询keys *
cp dump.rdb.bak dump.rdb
ps aux | grep redis
Kill -9 xxxx
停止redis服务器service redis stop
重启redis-server
重启redis-cli
查询keys *

AOF：只进行追加操作的文件（append-only file）

快照功能并不是非常耐久（durable）： 如果 Redis 因为某些原因而造成故障停机， 那么服务器将丢失最近写入、且仍未保存到快照中的那些数据。如果对于数据追求完全耐久能力（full durability）的要求，快照功能就不太适用。从 1.1 版本开始， Redis 增加了一种完全耐久的持久化方式： AOF 持久化。

通过修改配置文件来打开 AOF 功能：appendonly yes

每当 Redis 执行一个改变数据集的命令时（比如 SET key value [EX seconds] [PX milliseconds] [NX|XX]）， 这个命令就会被追加到 AOF 文件的末尾（对数据的每一条修改命令追加到aof文件）。这样的话，当 Redis 重新启时， 程序就可以通过重新执行 AOF 文件中的命令来达到重建数据集的目的。RDB持久化相当于备份数据库状态，而AOF持久化是备份数据库接收到的命令。

AOF文件生成的过程：命令追加、文件写入、文件同步

Redis的功能：

AOF的存储是，Redis会根据配置项，合理的触发Rewrite操作，就是将日志文件中的所有数据都重新写到另外一个新的日志文件中，但是不同的是，对于老日志文件中对于Key的多次操作，只保留最终的值的那次操作记录到日志文件中，从而缩小日志文件的大小。这里有两个配置需要注意：
auto-aof-rewrite-percentage 100 （当前写入日志文件的大小占到初始日志文件大小的某个百分比时触发Rewrite）
auto-aof-rewrite-min-size 64mb （本次Rewrite最小的写入数据良）
两个条件需要同时满足。

AOF的优点

• 提供了多种同步命令方式，默认1s同步（fsync）一次写命令，就算发生故障停机，最多丢失1s的数据。（ fsync 会在后台线程执行，所以主线程可以继续努力地处理命令请求）。
• AOF 文件是一个只进行追加操作的日志文件（append only log）， 因此对 AOF 文件的写入不需要进行查找(seek)， 即使日志因为某些原因而包含了未写入完整的命令（比如写入时磁盘已满，写入中途停机等）， redis-check-aof 工具也可以轻易地修复这种问题。
• Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。
• AOF 文件有序地保存了对数据库执行的所有写入操作，如果你不小心执行了 FLUSHALL 命令，只要 AOF 文件未被重写，那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令，并重启 Redis，就可以将数据集恢复到 FLUSHALL 执行之前的状态。

AOF 的缺点

• 对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。当Redis负载较高时，RDB比AOF性能更好。
• 根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。 在一般情况下， 每秒 fsync 的性能依然非常高， 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快， 即使在高负荷之下也是如此。 不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间（latency）。
• AOF 曾经发生过的 bug ：因为个别命令的原因，导致 AOF 文件在重新载入时，无法将数据集恢复成保存时的原样。（举个栗子，阻塞命令 BRPOPLPUSH source destination timeout 就曾引起过这样的 bug）它们会自动生成随机、复杂的数据集，并通过重新载入这些数据来确保一切正常。虽然这种 bug 在 AOF 文件中并不常见，但是对比来说，RDB 几乎是不可能出现这种 bug 的。

# 是否打开 AOF 持久化功能，默认为“no”，可通过“yes”来开启AOF功能  
appendonly yes      # 只有在“yes”下，aof重写/文件同步等特性才会生效  


# 指定AOF文件的名称  
appendfilename appendonly.aof  


# 同步频率：指定AOF操作时，文件的同步策略，有三个合法值：always everysec no,默认为everysec  会影响到服务器间隔多久完成一次命令的记录。
# always：每一条aof记录都立即同步到文件，这是最安全的方式，但大量磁盘操作和阻塞延迟造成IO开支大，速度最慢不推荐。
# everysec：将缓存区的内容每隔一秒写入AOF文件中，性能和安全都比较中庸，是Redis官方推荐的方式。
# no ：写入AOF文件中的操作由操作系统决定，Redis不直接调用。一般而言为了提高效率，操作系统会等待缓存区被填满，才会开始同步数据到磁盘。在物理服务器故障时，数据丢失量会因OS配置有关
appendfsync everysec  


# 在aof-rewrite期间，appendfsync是否暂缓文件同步，"no"表示“不暂缓”，“yes”表示“暂缓”，默认为“no”  
no-appendfsync-on-rewrite no  


# aof文件rewrite触发的最小文件尺寸(mb,gb),只有大于此aof文件大于此尺寸是才会触发rewrite，默认“64mb”，建议“512mb”  
auto-aof-rewrite-min-size 64mb  


# 相对于“上一次”rewrite，本次rewrite触发时aof文件应该增长的百分比。  
# 每一次rewrite之后，redis都会记录下此时“新aof”文件的大小(例如A)，那么当aof文件增长到A*(1 + p)之后，触发下一次rewrite，每一次aof记录的添加都会检测当前aof文件的尺寸。  
auto-aof-rewrite-percentage 100

# 当前AOF文件启动新的日志重写过程的最小值，避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。
auto-aof-rewrite-min-size 64mb