江苏龙网

  1. 主页 > 生活百科 > >

redis初学者你有福了—带你进入Redis不一样的世界( 四 )

Redis


如果需要进行大规模数据的恢复 ， 且对于数据恢复的完整性不是非常敏感 ， 那RDB方式要比AOF方式更加的高效 。
虽然RDB有不少优点 ， 但它的缺点也是不容忽视的 。如果你对数据的完整性非常敏感 ， 那么RDB方式就不太适合你 ， 因为即使你每5分钟都持久化一次 ， 当redis故障时 ， 仍然会有近5分钟的数据丢失 。所以 ， redis还提供了另一种持久化方式 ， 那就是AOF 。
【聊聊redis持久化 – AOF】
AOF ， 英文是Append Only File ， 即只允许追加不允许改写的文件 。
如前面介绍的 ， AOF方式是将执行过的写指令记录下来 ， 在数据恢复时按照从前到后的顺序再将指令都执行一遍 ， 就这么简单 。
我们通过配置redis.conf中的appendonly yes就可以打开AOF功能 。如果有写操作（如SET等） ， redis就会被追加到AOF文件的末尾 。
默认的AOF持久化策略是每秒钟fsync一次（fsync是指把缓存中的写指令记录到磁盘中） ， 因为在这种情况下 ， redis仍然可以保持很好的处理性能 ， 即使redis故障 ， 也只会丢失最近1秒钟的数据 。
如果在追加日志时 ， 恰好遇到磁盘空间满、inode满或断电等情况导致日志写入不完整 ， 也没有关系 ， redis提供了redis-check-aof工具 ， 可以用来进行日志修复 。
因为采用了追加方式 ， 如果不做任何处理的话 ， AOF文件会变得越来越大 ， 为此 ， redis提供了AOF文件重写（rewrite）机制 ， 即当AOF文件的大小超过所设定的阈值时 ， redis就会启动AOF文件的内容压缩 ， 只保留可以恢复数据的最小指令集 。举个例子或许更形象 ， 假如我们调用了100次INCR指令 ， 在AOF文件中就要存储100条指令 ， 但这明显是很低效的 ， 完全可以把这100条指令合并成一条SET指令 ， 这就是重写机制的原理 。
在进行AOF重写时 ， 仍然是采用先写临时文件 ， 全部完成后再替换的流程 ， 所以断电、磁盘满等问题都不会影响AOF文件的可用性 ， 这点大家可以放心 。
AOF方式的另一个好处 ， 我们通过一个“场景再现”来说明 。某同学在操作redis时 ， 不小心执行了FLUSHALL ， 导致redis内存中的数据全部被清空了 ， 这是很悲剧的事情 。不过这也不是世界末日 ， 只要redis配置了AOF持久化方式 ， 且AOF文件还没有被重写（rewrite） ， 我们就可以用最快的速度暂停redis并编辑AOF文件 ， 将最后一行的FLUSHALL命令删除 ， 然后重启redis ， 就可以恢复redis的所有数据到FLUSHALL之前的状态了 。是不是很神奇 ， 这就是AOF持久化方式的好处之一 。但是如果AOF文件已经被重写了 ， 那就无法通过这种方法来恢复数据了 。
虽然优点多多 ， 但AOF方式也同样存在缺陷 ， 比如在同样数据规模的情况下 ， AOF文件要比RDB文件的体积大 。而且 ， AOF方式的恢复速度也要慢于RDB方式 。
如果你直接执行BGREWRITEAOF命令 ， 那么redis会生成一个全新的AOF文件 ， 其中便包括了可以恢复现有数据的最少的命令集 。
如果运气比较差 ， AOF文件出现了被写坏的情况 ， 也不必过分担忧 ， redis并不会贸然加载这个有问题的AOF文件 ， 而是报错退出 。这时可以通过以下步骤来修复出错的文件：
1.备份被写坏的AOF文件
2.运行redis-check-aof –fix进行修复
3.用diff -u来看下两个文件的差异 ， 确认问题点
4.重启redis ， 加载修复后的AOF文件
【聊聊redis持久化 – AOF重写】
AOF重写的内部运行原理 ， 我们有必要了解一下 。
在重写即将开始之际 ， redis会创建（fork）一个“重写子进程” ， 这个子进程会首先读取现有的AOF文件 ， 并将其包含的指令进行分析压缩并写入到一个临时文件中 。
与此同时 ， 主工作进程会将新接收到的写指令一边累积到内存缓冲区中 ， 一边继续写入到原有的AOF文件中 ， 这样做是保证原有的AOF文件的可用性 ， 避免在重写过程中出现意外 。


推荐阅读


上一篇：Linux useradd 命令介绍

下一篇：北方与南方的差异 南方人和北方人有什么区别?说得太到位了