网站建设调研,wordpress安全博客,网页模板之家,开发者模式有什么好处和坏处Redis两类持续性的方法 RDB方案可以在规定时间间隔内创建数据集的时间点快照。 AOF方案记录了服务器执行的所有写操作命令#xff0c;并在服务器启动时通过重新执行这些命令来还原数据集。AOF文件完全遵循Redis协议格式保存#xff0c;新命令会被追加到文件末尾。此外#… Redis两类持续性的方法 RDB方案可以在规定时间间隔内创建数据集的时间点快照。 AOF方案记录了服务器执行的所有写操作命令并在服务器启动时通过重新执行这些命令来还原数据集。AOF文件完全遵循Redis协议格式保存新命令会被追加到文件末尾。此外Redis还能在后台对AOF文件重写以确保不超过实际需要的文件大小。 Redis还可同时使用AOF和RDB持续性方法。在这种情况下Redis重启时将优先使用AOF文件还原数据集因为AOF文件所保存数据通常比RDB文件完整。 RDB的优势 RDB是一个非常紧凑的文件保存了Redis在某一时间点上的数据集。此特点使得RDB文件非常适合备份用途。比如可以每小时备份一次RDB文件在每天备份一次以便在问题发生时可以恢复到不同版本的数据集。 RDB非常适合用于灾难恢复。它只有一个文件且内容紧凑可以加密后传输到其他数据中心或亚马逊S3中。 RDB可以最大化Redis的性能。父进程在保存RDB文件时只需要fork出一个子进程然后子进程负责处理所有保存工作父进程无需执行任何磁盘I/O操作。 RDB在恢复大数据集时速度比AOF快。 RDB的劣势 如果需要最小化数据丢失风险RDB不适合。虽然Redis允许设置不同的保存点来控制保存RDB文件的频率但由于RDB文件需要保存整个数据集状态所以并非轻松操作。因此可能需要至少5分钟才能保存一次RDB文件。在这种情况下一旦发生故障停机可能会丢失几分钟的数据。 每次保存RDB时Redis都要fork()一个子进程来进行实际持久化工作。对于大型数据集fork()可能耗时较长导致服务器在某些毫秒内停止处理客户端。如果数据集特别大且CPU时间紧张这种停机时间甚至可能长达一秒钟。尽管AOF重写也需要进行fork()但无论AOF重写的执行间隔有多长数据的耐久性都不会有损失。 AOF的优势 使用AOF持久化可以极大地提高Redis的持久性。可以设置不同的fsync策略例如无fsync、每秒一次fsync或每次写入命令时fsync。默认策略为每秒一次fsync在此配置下Redis仍然能够保持良好性能即使发生故障停机最多只会丢失一秒钟的数据fsync在后台线程执行所以主线程可以继续处理命令请求。 AOF文件是一个只进行追加操作的日志文件因此写入AOF文件不需要seek操作。即使日志中包含未完整写入的命令如写入时磁盘已满写入中断等redis-check-aof工具也可以轻松修复此类问题。 当AOF文件体积变大时Redis可以自动在后台对AOF重写。重写后的新AOF文件仅包含恢复当前数据集所需的最小命令集合。整个重写过程是安全的因为Redis在创建新AOF文件时会继续将命令追加到现有的AOF文件中即使在重写过程中发生故障停机现有的AOF文件也不会丢失。一旦新AOF文件创建完成Redis会从旧的AOF文件切换到新的AOF文件并开始追加操作。 AOF文件以有序的方式保存对数据库执行的所有写入操作这些操作以Redis协议格式保存使得AOF文件内容容易阅读和解析。导出AOF文件也很简单举个例子如果不小心执行了FLUSHALL命令只要停止服务器移除AOF文件末尾的FLUSHALL命令并重启Redis就可以将数据集恢复到FLUSHALL执行之前的状态。 AOF的劣势 对于相同的数据集来说AOF文件的体积通常比RDB文件的体积大。 根据所使用的fsync策略AOF的速度可能会慢于RDB。一般情况下每秒一次fsync的性能依然很高关闭fsync可以使AOF与RDB具有相同的速度即使在高负载下也如此。但在处理大量写入负载时RDB可以提供更可靠的最大延迟时间。 AOF曾经发生过一些bug导致在重新加载AOF文件时无法恢复到保存时的原样。这种bug并不常见并且测试套件已添加了测试以确保恢复功能正常。虽然AOF的这些bug不太常见但与RDB相比几乎不可能出现这种问题。 本文由 mdnice 多平台发布
