redis技术之旅五

redis技术之旅五 redis的持久化策略（RDB/AOF）
redis虽然是一种key/values 数据库，但是和memcached不同的是，其可以数据持久化。redis的所有数据保存在内存中，然后通过不定期异步保存到磁盘（“半持久化”），也可以把每一次数据变化都写入到一个append only file（aof）（“全持久化”）
redis提供两种不同级别的持久化方式：
RDB，持久话可以在指定的时间间隔生成数据集的时间点快照。
AOF，持久化记录redis服务器的所有操作命令，并在服务器启动的时候通过replay这些命令来还原数据。AOF文件中的命令全部以redis协议的格式保存，新命令追加到文件尾部。redis会在后台对aof进行不定期的重写，是的aof文件不会过大。
redis这两种持久化方式彼此并不冲突，你可以选择全部开启，也可以选择开启任意的一种，或不开启持久化，默认采用的是RDB的持久化方式。
下面针对这两种持久话的优缺点进行介绍：

RDB的优点：
rdb的文件十分紧凑，还可以启用压缩配置，它保存了某个时间点的完整数据集快照，文件适用于备份。可以将文件拷贝到远程的灾备中心做灾备使用。RDB可以最大化redis的性能，在进行rdb持久化的时候，父进程只需要fork出子进程就可以处理客户端的访问了，父进程不需要执行任何的磁盘IO访问。
RDB的缺点：
RDB是一个基于某个时间点的快照，这就决定了其并不能保证数据的最小丢失（时间点以后的所有数据操作全部丢失,在业务量很大的时候会丢失非常多的数据），而每次保存rdb时，redis都需要fork出一个子进程，并由其实际完成持久化操作，在数据集很大的时候，fork操作可能会非常消耗时间，如果数据集非常大而且CPU时间紧张的情况下，fork操作有可能花费一秒甚至几秒的时间。虽然aof也会fork进程，但其数据的耐久性不会有影响。

AOF的优点：
aof持久化对数据耐久新最好，可以通过设置不同的fsync策略执行落盘操作。aof文件是一个追加的写入的操作，写入是不需要seek，即使因为某些原因日志写入了不完整的命令，可以使用 redis-check-aof 命令修复aof文件。
redis还可以在aof文件变的过大的时候重写aof文件，重写后的aof文件是恢复当前数据集所需最小的命令集。整个的重写操作是绝地的安全的，redis在重写的过程中除非重写成功，会将新的aof替换老的aof，否则是不会对老的aof文件执行任何操作的。
AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松。 导出（export） AOF 文件也非常简单： 举个例子， 如果你不小心执行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的状态
AOF的缺点：
对于相同的数据集来说，AOF文件会比RDB文件大，占用更多的磁盘空间。
根据不同的fsync策略，AOF的速度可能会慢于RDB。aof过去曾经历过一些bug。

RDB和AOF应该如何选择???
一般来说， 如果想达到足以媲美 PostgreSQL 的数据安全性， 你应该同时使用两种持久化功能。
如果你非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失， 那么你可以只使用 RDB 持久化。
有很多用户都只使用 AOF 持久化， 但我们并不推荐这种方式： 因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快， 除此之外， 使用 RDB 还可以避免之前提到的 AOF 程序的 bug 。

RDB与AOF涉及的参数配置
RDB参数为：
save “”
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error
rdbcompression
rdbchecksum
dbfilename
dir
把数据库存到磁盘上:
save
会在指定秒数和数据变化次数之后把数据库写到磁盘上。
下面的例子将会进行把数据写入磁盘的操作:
900秒（15分钟）之后，且至少1次变更
300秒（5分钟）之后，且至少10次变更
60秒之后，且至少10000次变更
注意：你要想不写磁盘的话就把所有 “save” 设置注释掉就行了。
通过添加一条带空字符串参数的save指令也能移除之前所有配置的save指令
像下面的例子：
save “”
save 900 1
save 300 10
save 60 10000

默认如果开启RDB快照(至少一条save指令)并且最新的后台保存失败，Redis将会停止接受写操作
这将使用户知道数据没有正确的持久化到硬盘，否则可能没人注意到并且造成一些灾难。
如果后台保存进程能重新开始工作，Redis将自动允许写操作
然而如果你已经部署了适当的Redis服务器和持久化的监控，你可能想关掉这个功能以便于即使是
硬盘，权限等出问题了Redis也能够像平时一样正常工作，
stop-writes-on-bgsave-error yes

当导出到 .rdb 数据库时是否用LZF压缩字符串对象？
默认设置为 “yes”，因为几乎在任何情况下它都是不错的。
如果你想节省CPU的话你可以把这个设置为 “no”，但是如果你有可压缩的key和value的话，
那数据文件就会更大了。
rdbcompression yes

因为版本5的RDB有一个CRC64算法的校验和放在了文件的最后。这将使文件格式更加可靠但在
生产和加载RDB文件时，这有一个性能消耗(大约10%)，所以你可以关掉它来获取最好的性能。
生成的关闭校验的RDB文件有一个0的校验和，它将告诉加载代码跳过检查
rdbchecksum yes

持久化数据库的文件名
dbfilename dump.rdb

工作目录
数据库会写到这个目录下，文件名就是上面的 “dbfilename” 的值。
累加文件也放这里。
注意你这里指定的必须是目录，不是文件名。
dir ./

---

AOF参数为：
appendonly
appendfsync
no-appendfsync-on-rewrite
auto-aof-rewrite-percentage
auto-aof-rewrite-min-size
默认情况下，Redis是异步的把数据导出到磁盘上。这种模式在很多应用里已经足够好，但Redis进程
出问题或断电时可能造成一段时间的写操作丢失(这取决于配置的save指令)。
AOF是一种提供了更可靠的替代持久化模式，例如使用默认的数据写入文件策略（参见后面的配置）
在遇到像服务器断电或单写情况下Redis自身进程出问题但操作系统仍正常运行等突发事件时，Redis
能只丢失1秒的写操作。AOF和RDB持久化能同时启动并且不会有问题。
如果AOF开启，那么在启动时Redis将加载AOF文件，它更能保证数据的可靠性。
请查看 http://redis.io/topics/persistence 来获取更多信息.
appendonly no

纯累加文件名字（默认：”appendonly.aof”）
appendfilename “appendonly.aof”

fsync() 系统调用告诉操作系统把数据写到磁盘上，而不是等更多的数据进入输出缓冲区。
有些操作系统会真的把数据马上刷到磁盘上；有些则会尽快去尝试这么做。
Redis支持三种不同的模式：
no：不要立刻刷，只有在操作系统需要刷的时候再刷。比较快。
always：每次写操作都立刻写入到aof文件。慢，但是最安全。
everysec：每秒写一次。折中方案。
默认的 “everysec” 通常来说能在速度和数据安全性之间取得比较好的平衡。根据你的理解来
决定，如果你能放宽该配置为”no” 来获取更好的性能(但如果你能忍受一些数据丢失，可以考虑使用
默认的快照持久化模式)，或者相反，用“always”会比较慢但比everysec要更安全。
请查看下面的文章来获取更多的细节
http://antirez.com/post/redis-persistence-demystified.html
如果不能确定，就用 “everysec”
appendfsync always
appendfsync everysec
appendfsync no

如果AOF的同步策略设置成 “always” 或者 “everysec”，并且后台的存储进程（后台存储或写入AOF
日志）会产生很多磁盘I/O开销。某些Linux的配置下会使Redis因为 fsync()系统调用而阻塞很久。
注意，目前对这个情况还没有完美修正，甚至不同线程的 fsync() 会阻塞我们同步的write(2)调用。
为了缓解这个问题，可以用下面这个选项。它可以在 BGSAVE 或 BGREWRITEAOF 处理时阻止fsync()。
这就意味着如果有子进程在进行保存操作，那么Redis就处于”不可同步”的状态。
这实际上是说，在最差的情况下可能会丢掉30秒钟的日志数据。（默认Linux设定）
如果把这个设置成”yes”带来了延迟问题，就保持”no”，这是保存持久数据的最安全的方式。
no-appendfsync-on-rewrite no

自动重写AOF文件
如果AOF日志文件增大到指定百分比，Redis能够通过 BGREWRITEAOF 自动重写AOF日志文件。
工作原理：Redis记住上次重写时AOF文件的大小（如果重启后还没有写操作，就直接用启动时的AOF大小）
这个基准大小和当前大小做比较。如果当前大小超过指定比例，就会触发重写操作。你还需要指定被重写
日志的最小尺寸，这样避免了达到指定百分比但尺寸仍然很小的情况还要重写。
指定百分比为0会禁用AOF自动重写特性。
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb