为什么需要持久化？通常，所有redis数据都存储在内存中。一旦数据库出现故障重启，所有数据都会丢失，即使是rediscluster或者redissentinel模式。主从同步数据恢复还是需要一定时间的。持久化功能是为了有效避免进程退出导致的数据丢失问题，下次重启时可以使用之前持久化的文件实现数据恢复。开启Redis持久化后，数据会存储在磁盘上，数据库进行增量同步的时间比全量同步要短很多。生产环境的故障数据恢复起着非常重要的作用！Redis数据持久化有两种方案。Redis的持久化有两种方案：RDB是一种快照数据存储，周期性地将Redis中当前时间点的所有数据保存到磁盘。AOF是一种额外的存储方式，实时记录Redis对磁盘的写操作。这两种解决方案有什么区别？让我一一告诉你吧~1。RDB持久化当Redis写入触发RDB持久化条件时（也可以通过手动执行dgsave命令触发），Redis主进程fork一个子进程创建一个临时的RDB存储文件。创建文件后，将临时文件重命名以替换原来的RDB文件。RDB文件是一个单一的文件，非常适合用于数据的容灾备份和恢复。通过RDB文件恢复数据库耗时较短。通常，一个1G的快照文件加载到内存中只需要20秒左右。缺点：RDB持久化只是周期性的保存Redis数据。当Redis在触发下一次存储之前崩溃时，内存中的所有数据都会丢失。另外，当数据量很大时，fork子进程的运行会消耗大量的CPU。如下监控图所示，每1800s触发一次RDB持久化，Redis消耗的CPU会飙升。二级阻塞可能发生在fork子进程的过程中。参数：如果save选项配置为空save""，将关闭RDB持久化。可以配置多个开启RDB持久化的触发条件，例如900秒内1次写入触发快照/300秒内10次写入触发快照，可根据自身Redis写入情况自由配置，兼顾性能和数据安全.建议启用stop-writes-on-bgsave-error。当redisbgsave出错时，客户端的请求被拒绝。bgsave失败通常是因为磁盘或内存空间不足，需要监控以提高数据安全性。2、AOF持久化AOF通过保存Redis写操作命令来实现持久化。使用AOF进行持久化会大大提高Redis数据的安全性，异常宕机最多丢失1s的数据。AOF文件记录了redis的写操作，格式清晰，易于理解和修改，有利于数据重构。缺点：随着redis写入的增加，AOF存储文件会越来越大，会影响数据库数据的恢复时间和磁盘空间，所以我们需要配置AOF重写来减小AOF文件的大小，这里可以使用默认配置这两个触发条件或者我们可以手动调用BGREWRITEAOF命令触发。参数：appendonly设置是否开启AOF持久化。appendfsync有三种持久化模式：always/everysec/no，兼顾数据存储的速度和安全性，配置为everysec，每秒同步一次数据到磁盘。3、RDB和AOF持久化的优缺点比较两种方式各有优缺点。下面对比一下redis的两种数据持久化方式：4、选择Redis恢复数据时，会先检查AOF文件是否存在，如果不存在，则尝试加载RDB文件。在实际生产环境中，根据数据量、应用对数据的安全要求、预算约束等不同情况，存在多种持久化策略。例如，根本不使用任何持久化，使用RDB或AOF中的一种，或者同时启用RDB和AOF持久化。PS：持久化的选择必须和Redis的主从策略一起考虑，因为主从复制和持久化也有数据备份的功能，主机master和slave可以独立选择持久化方案。
