redis中有两种持久化（aof和rdb），下面本篇文章带大家了解一下这两种持久化，看看它们的优缺点，介绍一下为什么redis需要两种持久化，希望对大家有所帮助！
redis的两种持久化方式众所周知，redis中提供了aof，rdb两种持久化，下面先来简单回顾一下。
rdb持久化rdb持久化，就是把当前时间点的数据库的状态保存到磁盘中，又称快照持久化。rdb可以手动触发，也可以根据服务器配置定期执行。rdb生成的文件，是一个经过压缩的二进制文件，数据库可以通过该文件还原到该时间点的状态。redis提供前台rdb持久化命令save和后台rdb持久化命令bgsave，前台执行时，redis的其他命令会被阻塞，而后台执行时，redis还可以继续处理客户端的命令请求。rdb二进制文件中，保存的是键值对数据，采用经过压缩的自定义编码，带校验。通过od命令可以转化为可读。主从复制时，初始化的全量复制采用rdb文件。【相关推荐：redis视频教程】
aof持久化aof持久化，全称是appen only file，意思是追加的持久化方式，其中保存的是写命令，而非数据。aof持久化过程分为命令追加、文件写入、文件同步三个步骤。命令追加：redis服务端每执行完一个写命令，都会以aof协议格式将该写命令追加到服务器状态的aof_buf缓冲区末尾。文件写入：redis中，每结束一个事件循环之前，都会调用flushappendonlyfile函数，将aof_buf缓冲区中的内容写入到aof文件。文件同步：同步sync指的是文件写入到操作系统缓冲区中时，是否直接同步到磁盘中。通过配置，可以选择立即同步、每秒同步、不主动同步而由操作系统控制，这三种同步方式。关于文件i/o缓冲：https://www.litreily.top/2018/10/25/io-cache/redis优先使用aof文件来恢复数据。aof文件由于存储命令，且没有经过压缩，其体积要大于rdb文件。aof文件可以定期采用bgrewriteaof重写，减少重复命令、已失效命令，合并命令等。aof文件支持后台重写，采用fork子进程的形式实现。子进程带有服务器进程的数据副本，再避免使用锁的情况下保证数据安全性。另外也采用aof重写缓冲区解决了数据不一致。两种持久化分别的优缺点rdb的优点文件体积小，适合拷贝做冷备
相比aof，备份恢复速度更快
rdb的缺点丢失数据多
fork子进程来做bgsave，消耗一定的内存资源
aof的优点丢失数据少
增加了写缓冲区，无需寻址，速度快
append-only，也无需做磁盘寻址，效率高
aof的缺点文件体积大
aof每次都需要做一下写入aof_buf的操作，开启aof持久化后，qps会略微降低
redis为什么需要两种持久化？经过上面的回顾，我们可以看到，rdb与aof持久化有明显区别。
存储的内容：rdb存储某一时间点的数据；aof存储执行的写命令。
文件大小：rdb文件较小；aof文件较大。
写入方式：rdb可采用前台/后台写入方式；aof采用每次执行写命令，都将命令存入缓冲区的方式，另外可定期重写。
数据丢失：rdb丢失从宕机到上一次rdb同步之间的所有数据；aof根据i/o缓冲区所配置的刷新方式，不丢失或丢失1s或几秒的数据。
根据这些对比，可以看到rdb持久化更适合保存一个时间点的数据，在主从复制或者数据全量异地灾备时，拷贝到其他地方，而aof持久化由于丢失数据较少，比较适合作为本地备份，在reids挂掉重启时作为故障恢复。这就是我理解的为什么redis需要两种持久化方式。
更多编程相关知识，请访问：编程入门！！
以上就是redis中的两种持久化方式，为什么需要两种持久化？的详细内容。