Redis的持久化

1. Redis持久化

字指定的时间间隔内将内存中的数据集快照也就是snapshot快照,写入到磁盘.这就是Redis的持久化.
恢复的时候是将快照文件和字节读取到内存中.

2. RDB(RedisDataBase)

2.1 原理

Redis会单独fork一个子进程来进行持久化,会先将数据写入到一个开临时文件,当持久化过程结束了.在使用这个临时文件替换掉上次的持久化好的文件.
整个过程不进行任何的IO操作,所以有极高的性能.如果需要大规模的恢复数据.而且对数据的完整性不是非常的敏感的话,nameRED方式要比AOF方式更加高效.
但是RDB的缺点是最后一次的持久化数据,可能会丢失.

2.2 RDB的配置

1. 在redis.conf中的位置

• save <time> <frequence># 表示在指定time时间内执行了 frequence 频率的操作,会触发自动保存.
• save "" # 表示禁用
• save 900 10 # 表示在900秒内执行了10次就会保存.

2. dump.rdb 的存放和产生

一般情况下,dump.rdb文件不会存放在本机,为了保证容灾的会恢复,会放在多级备份的服务器中.
注意:当执行flushdb或者flushall的时候也会生成新的dump.rdb,但是此时的dum.rdb是空的.

3. rdb 是什么.

是整个内存的压缩的 snapshot 快照,rdb 数据的结构可配置复合 的快照触发条件.

4. 配置的位置

是启动redis服务的文件目录下.

5. 触发条件

• Save：save时只管保存，其它不管，全部阻塞
• BGSAVE：Redis会在后台异步进行快照操作,快照同时还可以响应客户端请求。可以通过lastsave命令获取最后一次成功执行快照的时间
• 默认的触发条件

6. 如何恢复?

• 将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可
• CONFIG GET dir获取目录

7. rdb的优势和不足

1. 优势:

- 适合大规模的数据恢复
- 对数据完整性和一致性要求不高

2. 不足

• 在一定间隔时间做一次备份，所以如果redis意外down掉的话，就
  会丢失最后一次快照后的所有修改
• fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑

8. 如何停止?

动态所有停止RDB保存规则的方法：redis-cli config set save “”(不建议这么做)

3. AOF(Append Only File)

3.1 为什么出现AOF?

为了解决RDB方式最后一次dump可能出现数据丢失的问题而推出的以日志记录的方式的记录每次写操作.当redis重启之后,再根据日志内容从前到后执行一次.

3.2 如何配置

在redis.conf配置文件中,APPEND ONLY MODE 中
appdend only no # 默认是 no 修改为 yes 即可.
append filename “appendonly.aiof” # 默认的文件名

3.3 特点

开启aof之后所有别的写操作都会以日志的方式记录在appendonly.aof文件中,包括flushdb或者flushall.

3.4 如何恢复?

1. 修改默认的appendonly no，改为yes
2. 将有数据的aof文件复制一份保存到对redis启动的对应目录(config get dir)
3. 恢复：重启redis然后自动重新加载
4. 如果appendonly.aof文件出错怎么办 ?
   使用命令:redis-check-aof --fix appendonly.aof #就可以修复该文件,然后重新启动会自动加载.

3.5 rewrite是什么?

AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制,
当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，
只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof

3.6 rewrite的原理?

AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，
遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件，
而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似

3.7 触发机制?

Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发

3.8 aof的优势和不足?

1. 优势:

• 每修改同步：appendfsync always 同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好
• 每秒同步：appendfsync everysec 异步操作，每秒记录 如果一秒内宕机，有数据丢失
• 不同步：appendfsync no 从不同步

2. 不足：

• 相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
• aof运行效率要慢于rdb,每秒同步策略效率较好，不同步效率和rdb相同

4. 总结

• RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
• AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些
  命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.
  Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大
• 只做缓存：如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.
• 同时开启两种持久化方式

因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。

如果Enalbe AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。
代价一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可
避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。
默认超过原大小100%大小时重写可以改到适当的数值。

如果不Enable AOF ，仅靠Master-Slave Replication 实现高可用性也可以。能省掉一大笔IO也减少了rewrite时带来
的系统波动。代价是如果Master/Slave同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的
RDB文件，载入较新的那个。新浪微博就选用了这种架构