偶看新闻经常反胃恶心:REDIS学习V
来源：百度文库 编辑：偶看新闻 时间：2024/04/29 04:02:57
Snapshotting
默认redis是会以快照的形式将数据持久化到磁盘的（一个二进制文件，dump.rdb，这个文件名字可以指定），在配置文件中的格式是：
save N M
表示在N秒之内，redis至少发生M次修改则redis抓快照到磁盘。
当然我们也可以手动执行save或者bgsave（异步）做快照。
工作原理简单介绍一下：
当redis需要做持久化时，redis会fork一个子进程；
子进程将数据写到磁盘上一个临时RDB文件中；
当子进程完成写临时文件后，将原来的RDB替换掉，这样的好处就是可以copy-on-write
还有一种持久化方法是Append-only file
snapshotting方法在redis异常死掉时，最近的数据会丢失（丢失数据的多少视你save策略的配置），所以这是它最大的缺点，当业务量很大时，丢失的数据是很多的。有一些方法可以做到全部数据不丢失，但redis的可行性就要差些。AOF就可以做到全程持久化，只需要在配置文件中开启（默认是no），
appendonly yes
开启AOF之后，redis每执行一个修改数据的命令，都会把它添加到aof文件中，当redis重启时，将会读取AOF文件进行“重放”以恢复到redis关闭前的最后时刻。
随着修改数据的执行AOF文件会越来越大，其中很多内容记录某一个key的变化情况。因此redis有了一种比较有意思的特性：在后台重建AOF文件，而不会影响client端操作。在任何时候执行BGREWRITEAOF命令，都会把当前内存中最短序列的命令写到磁盘，这些命令可以完全构建当前的数据情况，而不会存在多余的变化情况（比如状态变化，计数器变化等），缩小的AOF文件的大小。
所以当使用AOF时，redis推荐同时使用BGREWRITEAOF。
AOF文件刷新的方式，有三种，参考配置参数appendfsync ：
每提交一个修改命令都调用fsync刷新到AOF文件，非常非常慢，但也非常安全；
每秒钟都调用fsync刷新到AOF文件，很快，但可能会丢失一秒以内的数据；
依靠OS进行刷新，redis不主动刷新AOF，这样最快，但安全性就差。
默认并推荐每秒刷新，这样在速度和安全上都做到了兼顾。
可能由于系统原因导致了AOF损坏，redis无法再加载这个AOF，可以按照下面步骤来修复：
首先做一个AOF文件的备份，复制到其他地方；
修复原始AOF文件，执行：
$ redis-check-aof --fix
可以通过diff –u命令来查看修复前后文件不一致的地方；
重启redis服务。
LOG Rewrite的工作原理，同样用到了copy-on-write：
首先redis会fork一个子进程；
子进程将最新的AOF写入一个临时文件；
父进程增量的把内存中的最新执行的修改写入（这时仍写入旧的AOF，rewrite如果失败也是安全的）；
当子进程完成rewrite临时文件后，父进程会收到一个信号，并把之前内存中增量的修改写入临时文件末尾；
这时redis将旧AOF文件重命名，临时文件重命名，开始向新的AOF中写入。