Redis持久化出于内部数据安全的考虑，Redis会将自身的数据以文件的形式保存到硬盘中，服务器重启后会自动将硬盘上的数据恢复到内存中（在Redis中），Redis持久化分为：RDB持久化模式AOF持久化模式可以同时启用两种持久化RDB（RedisDataBase）持久化模式RDB持久化是指在指定时间间隔内将数据快照写入内存实际操作过程是fork一个子进程，先将数据写入一个临时文件，写入成功后替换之前的文件，使用二进制压缩存储Redis将数据库快照保存在一个名为dump的二进制文件中.rdbRDB持久化快照名称及路径（redis.conf文件）：RDB持久化备份频率：$save9001#如果900秒内修改超过1个key，则发起快照save$save30010#如果超过1个key300秒内修改如果修改了10个key，发起快照保存$save6010000#如果60秒内修改超过10000个key，发起快照保存优点：非常适合备份，比如可以保存过去24小时每小时同时，每天保存过去30天的数据，这样即使出现问题，您也可以根据需要恢复到不同版本的数据。转移到异地数据中心非常方便，非常适合容灾。RDB是父进程在保存RDB文件时唯一需要做的就是fork一个子进程，接下来的工作就由子进程来完成，父进程不需要做其他的IO操作，所以RDB的持久化方式可以最大限度的发挥Redis4的性能。相对于AOF，在恢复大数据的时候，RDB的效率更高。缺点：如果要保证数据的高可用，即最大程度避免数据丢失，那么RDB将不是一个好的选择。因为一旦系统在计划的持久化之前宕机，你可能会丢失几分钟的数据。由于RDB是通过fork子进程来辅助完成数据持久化的，如果数据很大，可能会导致整个服务器停止服务数百毫秒，甚至1秒手动启动RDB持久化方法：输入save或者bgsave（bgsave是开一个单独的线程）AOF（AppendOnlyFile）持久化方式AOF持久化以日志的形式记录服务器的处理过程每一次写入，删除操作，查询操作，当服务器重启时，这些命令都会被重新执行以恢复原始数据。启用AOF持久化（redis.conf）注意：AOF持久化名称和路径只有重启Redis后才会生效：AOF持久化优化备份频率：#每次向AOF文件追加新命令时执行一次同步：非常慢，而且非常safe$always#每秒同步一次：速度足够快（类似于使用RDB持久化），并且只有在发生故障时才会丢失1秒的数据#推荐的（也是默认的）措施是每秒同步一次。这种策略可以兼顾速度和安全性。$everysec#Neversynchronize：将数据交给操作系统处理。更快更不安全的选择$noAOF持久备份优化：因为AOF的工作方式是不断在文件末尾追加命令，随着写命令的不断增加，AOF文件的体积也会越来越大例如，如果你在计数器上调用INCR100次，AOF文件需要使用100个条目来保存计数器的当前值。然而在实际中，只需要一条SET命令就足以保存计数器的当前值，剩下的99条记录其实是多余的。bgrewriteaof命令优化AOF文件AOF文件损坏：服务器可能在程序中写入AOF文件系统宕机时，宕机会导致AOF文件损坏，此时Redis会拒绝加载AOF文件重启，保证数据一致性不被破坏。修复错误的AOF文件：为已有的AOF文件创建一个备份使用Redis自带的redis-check-aof程序修复原来的AOF文件：$redis-check-aof–fix使用diff-u比较修复后的返回upAOF文件和原始AOF文件，查看两个文件的差异，重启Redis服务器，等待服务器加载修复后的AOF文件，进行数据恢复优点：AOF持久化可以带来更高的数据安全性。Redis中提供了三种同步策略，分别是每秒同步、每次修改同步和不同步。使用默认每秒同步的效率也很高（同步由后台线程处理，主线程会尽量处理客户端请求），一旦失败最多丢失1秒数据AOF文件是一个append-only的日志文件，所以不需要写seek，即使由于某些原因（磁盘空间已满，写时宕机等）没有执行完整的写命令，也可以使用redis-check-aof工具为了修复这些问题，当AOF文件变得过大时，Redis可以在后台自动重写AOF：重写的新AOF文件包含恢复当前数据所需的最少命令集。整个重写操作是绝对安全的，因为Redis在创建新AOF文件的过程中，会不断向已有的AOF文件追加命令。即使重写过程中出现宕机，已有的AOF文件也不会丢失。一旦创建了新的AOF文件，Redis将从旧的AOF文件切换到新的AOF文件，并开始追加到新的AOF文件。AOF文件有序的存储了所有对数据库的写操作。这些写操作都是以Redis协议的格式保存的，所以AOF文件的内容非常容易让人看懂，也非常容易分析（parse）文件。导出AOF文件也很简单：比如不小心执行了FLUSHALL命令，但是只要AOF文件没有被覆盖，那么只要停止服务器，去掉AOF文件末尾的FLUSHALL命令，即可重启Redis，数据集可以恢复到FLUSHALL执行前的状态。缺点：同样的数据，AOF文件通常比RDB文件大。根据同步策略的不同，AOF的运行效率可能会比RDB慢。总之每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。但是，在处理巨大的写入负载时，RDB可以提供更有保障的最大延迟（latency）从RDB切换到AOF在Redis2.2或更高版本中，可以在不重启AOF的情况下从RDB切换到AOF：Createabackupforthelatestdump。rdb文件并将备份放在安全的地方执行以下两个命令：#开启AOF功能，Redis会阻塞，直到创建初始AOF文件#之后，Redis将继续处理命令请求，并开始追加写入commandtotheendoftheAOFfile$redis-cliconfigsetappendonlyyes#关闭RDB功能$redis-cliconfigsetsave保证write命令会正确的追加到AOF文件的末尾注意：在redis中.conf开启AOF功能，否则服务器重启后，之前通过CONFIGSET设置的配置将被遗忘，程序会按照原来的配置启动服务器。总结：如果你非常重视数据安全，你应该同时使用这两种持久化功能。如果几分钟内数据丢失，就只能使用RDB持久化了。选择两者的标准是看你愿意牺牲一些性能，换取更高的缓存一致性（AOF），还是愿意在写操作频繁的时候不启用备份来换取更高的性能，做备份（RDB)手动运行保存时。注意：在未来，Redis可能会将AOF和RDB集成到一个单一的持久化模型中。相关文档：英文：https://redis.io/topics/persi...中文：http://www.redis.cn/topics/pe...相关链接：Linux下PHP安装Redis扩展（二）Redis主从配置（三）Redis集群搭建及简单使用（四）
