Redis AOF和RDB

同步频率

always

每个写命令都同步

everysec

每秒同步一次

no

让操作系统来决定何时同步

always选项会严重减低服务器的性能

everysec选项比较合适，可以保证系统崩溃时只丢失一秒左右的数据，并且Redis每秒执行一次同步对服务器几乎没有任何影响；

no选项并不能给服务器带来多大的提升，而且也会增加系统崩溃时数据丢失的数量。

随着服务器写请求的增多，AOF文件会越来越大。Redis提供了一种将AOF重写的特性，能够去除AOF文件中的冗余写命令。

RDB：

Redis主进程fork一个子进程，让子进程执行磁盘IO操作来进行持久化。

RDB将数据写入一个临时文件，持久化结束后，用这个临时文件替换上次持久化的文件，这些数据文件代表了某一个时刻中redis的数据。

但是，RDB是间隔一段时间进行持久化的，如果持久化之间redis发生故障，这一段时间内的数据就会丢失（RDB最大的缺点，导致不适合做第一优先的恢复方案，如果你依赖RDB做第一优先恢复方案，会导致丢失比较多的数据）。

为什么是子进程？

（主要是出于Redis性能的考虑，(1)Redis RDB持久化机制会阻塞主进程，这样主进程就无法响应客户端请求。(2)Redis对客户端响应请求的工作模型是单进程和单线程的，如果在主进程内启动一个线程，这样会造成对数据的竞争条件，为了避免使用锁降低性能。基于以上两点这就是为什么Redis通过启动一个进程来执行RDB了）

AOF：

可以简单的认为AOF就是日志文件，此文件只会记录"变更操作"(例如：set/del等)，将"操作 + 数据"以格式化指令的方式append（追加，顺序写磁盘，没有任何磁盘寻址的开销，因此效率非常高）到操作日志文件的尾部（一般设置每秒一次），在append操作返回后(已经写入到文件或者即将写入)，才进行实际的数据变更。"日志文件"保存了历史所有的操作过程；当server需要数据恢复时，可以直接replay此日志文件，即可还原所有的操作过程。
但是AOF文件比RDB文件大，且恢复速度慢。

若AOF文件过大，可以使用BGREWRITEAOF命令（BGrewriteAOF），优化aof文件

Redis AOF和RDB

标签：tab   body   越来越大   enter   ever   数据   内容   竞争   http