redis持久化简单学习

redis持久化

一个东西的出现必然会有一个原因，那么redis存在内存中挺好的为什么会有持久化这个东西，不会拖慢redis的效率吗？
因为redis的数据都是存储在内存中，断电即丢，存在数据丢失的可能性，所以为了保证数据不丢失，出现了redis的持久化：

• RDB（Redis DataBase）
  介绍：
  在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话Snapshot快照，它恢复时是将快照文件直接读到内存里。
  是什么：
  Redis会单独创建（fork）一个子线程来进行持久化，会先将数据写到一个临时文件中，主线程是不进行任何IO操作的，这就确保了极高的性能如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失（为什么会丢失，请往下看）
  Fork:
  Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量，环境变量，程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。
  Rdb保存的是dump.rdb文件
  配置位置：
  在redis.conf配置文件中存在SNAPSHOTTING ，里面的内容是快照的相关配置
  
  可以看到有3个配置规则，分别的意思是：
• 900秒（15分钟）内有1个更改就触发保存
• 300秒（5分钟）内有10个更改就触发保存
• 60秒内有10000个更改就触发保存
  这里有个小坑，那就是当手动敲命令shutdown的时候，redis会迅速生成一个快照并覆盖原有的dump.rdb,这样的话如果在shutdown之前 执行了flushall命令 清空了redis，即使重启redis,那么也不会还原原有数据。

如果说数据极其重要，需要写进去即刻就生成对应的dum.rdb，不能等待redis自动生成，那么可以用 save命令手动生成。
如何触发RDB快照：
1.配置文件中默认的快照配置
2.命令save 或者是 bgsave
3.执行flushall命令也会产生dump.rdb，但是里面是空的，无意义
如何恢复：
将备份文件（dump.rdb）移动到redis的安装目录并启动服务即可
优势：
适合大规模的数据恢复，对数据的完整性和一致性要求不高
劣势：
在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照的所有更改
fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑

读到这里相信小伙伴可以解释上面的一个问题，“为什么rdb最后一次持久化后的数据可能丢失” ，就是因为有一个时间差：在写操作之后不会立即进行存储（上面配置的存储规则），而是有个时间间隔，如果说在这个时间间隔内宕机，则会丢失一部分数据

小总结：

• AOF（Append Only File）:
  介绍：
  AOF 持久化记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。 AOF 文件中的命令全部以 Redis 协议的格式来保存，新命令会被追加到文件的末尾。 Redis 还可以在后台对 AOF 文件进行重写（rewrite），使得 AOF 文件的体积不会超出保存数据集状态所需的实际大小。
  是什么：
  是以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来（读操作不记录），只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
  Aof保存的是appendonly.aof文件
  appendonly.aof 和dump.rdb 可以和平共存，启动之初寻找appendonly.aof,如果没有再去寻找dump.rdb来恢复数据。
  如果appendonly.aof文件出错，那么redis在启动的时候就不能成功启动。这样在redis的安装目录和redis-server 同一级有一个 redis-check-aof文件，可以通过这个文件来修复。指令：redis-check-aof --fix appendonly.aof
  
  跟rdb类似的aof也可以配置写入规则（频率）
  同步策略（appendfsync）：
• .Always：同步持久化，每次发生数据变更会被立即记录到磁盘，性能较差，但数据完整性较好
• Everysec：出厂默认推荐，异步操作，每秒记录，然后记录到磁盘，如果一秒内宕机，有数据丢失。
• no：写入aof文件，不等待磁盘同步
  AOF启动/修复/恢复:
  正常恢复：
  1.启动：修改默认的appendonly no 为yes
  2.恢复：将有内容的appendonly.aof文件放到redis的安装目录下，启动的时候redis会自动找aof文件进行数据恢复。
  异常恢复
  1.启动：修改默认的appendonly no 为yes
  2.如果aof文件出现损坏，用redis-check-aof --fix指令来修复aof文件
  3.重启redis。
  Rewrite（重写）:
  是什么：
  AOF采用文件追加方式，文件会越来越大为避免出现这种情况，新增了重写机制，当AOF文件的大小超过了所设定的阙值时，Redis就会启动AOF 文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof
  重写原理：
  AOF文件持续增长而过大时，会fork出一条新进程来将文件重写（也是先写临时文件最后在rename）,遍历新进程的内存中数据，每条记录有一条set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似
  触发机制：
  Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发
  
  no-appendfsync-on-rewrite：
  同时在执行bgrewriteaof操作和主进程写aof文件的操作，两者都会操作磁盘，而bgrewriteaof往往会涉及大量磁盘操作，这样就会造成主进程在写aof文件的时候出现阻塞的情形，现在no-appendfsync-on-rewrite参数出场了。如果该参数设置为no，是最安全的方式，不会丢失数据，但是要忍受阻塞的问题。如果设置为yes呢？这就相当于将appendfsync设置为no，这说明并没有执行磁盘操作，只是写入了缓冲区，因此这样并不会造成阻塞（因为没有竞争磁盘），但是如果这个时候redis挂掉，就会丢失数据。丢失多少数据呢？在linux的操作系统的默认设置下，最多会丢失30s的数据。
  因此，如果应用系统无法忍受延迟，而可以容忍少量的数据丢失，则设置为yes。如果应用系统无法忍受数据丢失，则设置为no。
  优势：
  使用aof持久化会让redis变的非常耐久，相比较rdb数据保存的全面。如果规则设置为1秒中写一次，那最多会丢失1秒钟之内的数据。如果aof文件过大，还会进行重写，重写后的文件包含了当前数据集的最小命令集合。
  劣势：
  相同数据集的数据而言，aof文件要远大于rdb文件，恢复速度慢于rdb.
  Aof运行速率要慢于rdb,每秒同步策略效率较好，不同步效率和rdb相同
  小总结
  
  到这里redis的持久化方式—rdb和aof的简单介绍就说完啦。

题后话，由于作者水平有限，文章中难免会有歧义的地方，欢迎大家批评指正，作者定会及时改正