为什么需要持久化呢?
通常情况下redis的数据全部存储在内存中,数据库一旦故障发生重启数据会全部丢失，即使是在redis cluster或者redis  sentinel模式下主从同步数据的恢复仍然需要一段时间。
持久化功能在于能够有效地避免因进程退出造成的数据丢失问题，在下次重启时利用之前持久化的文件即可实现数据恢复。
使用redis持久化后，数据会被存储到磁盘上。在数据库执行增量同步时，所需的时间远远少于执行全量同步的时间。在生产环境下故障的数据恢复有着非常重要的作用!
redis数据持久化有两种方案
redis持久化有两种方案：
rdb是一种快照式的数据存储，它会周期性的保存当前时间点redis所有的数据到磁盘中。
aof是一种追加式的存储方式，会实时的记录redis的写操作到磁盘中。
这两种方案又存在什么样的区别呢?下面让小编一一道来吧~
1. rdb持久化
当redis的写入触发rdb持久化条件后(也可以手动执行dgsave命令来触发)，redis主进程fork一个子进程来创建临时rdb存储文件，创建文件完成后对这个临时文件rename替换原先的rdb文件。rdb文件是一个单文件很适合数据的容灾备份与恢复，通过rdb文件恢复数据库耗时较短，通常1g的快照文件载入内存只需20s左右。
缺点：
rdb持久化只会周期性的保存redis数据，当还未触发下一次存储的情况下redis宕机，则内存中的数据会全部丢失。
另外当数据量较大的情况下，fork子进程这个操作很消耗cpu，如下图的监控图，每1800s触发的rdb持久化，redis消耗的cpu都会飙升。在fork子进程过程中可能会发生长达秒级别的阻塞情况。
参数：
save选项如果配置为空save  ，则关闭rdb持久化，这个开启rdb持久化触发条件可以配置多条，例如900秒内有1次写入触发快照/300秒内有10次写入触发快照，这个可以根据自身redis写入情况自由配置来平衡性能与数据安全。
stop-writes-on-bgsave-error建议开启，当redis  bgsave发生错误的时候拒绝客户端的请求，bgsave失败一般是磁盘或者内存空间不够，需要监控来提高数据安全性。
2. aof持久化
aof是通过保存redis写操作的命令来实现持久化，使用aof来持久化，redis数据的安全性将大幅提高，异常宕机情况下最多丢失1s的数据。redis的写操作被记录在aof文件中，该文件的格式清晰易懂，可以轻松修改，从而方便地进行数据重建。
缺点：
随着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可以独立的选择持久化方案。
以上就是redis持久化方法有哪些的详细内容。