咱就是说Redis这个东西，用的人越来越多了吧。但是关于它的持久化机制，比如RDB、AOF这些，还有BGSAVE和写时复制，hen多人dou搞不太清楚。今天咱就好好聊聊这事儿。

先说说Redis为什么要持久化

你想想啊，Redis它本质上是个内存数据库对吧？一旦进程挂掉或者服务器断电，内存里的数据全没了。那对于hen多业务来说可不就崩溃了？所以必须得有持久化机制。

RDB：快照方式保存数据

RDB就是Redis Database的意思。简单来说就是定期把内存中的数据集整个儿拍张照片，然后保存到磁盘上。

RDB怎么工作？

当触发条件满足时Redis就会执行BGSAVE命令

主进程fork出一个子进程

子进程负责把内存数据集写入临时文件

写完后替换旧的RDB文件

BGSAVE是什么鬼？

哈哈，这个名字听起来是不是hen高大上？其实就是异步保存的意思。

save命令是同步阻塞的

BGSAVE是异步非阻塞的

BGSAVE会fork一个子进程来Zuo这件事

写时复制技术

这里要提下写时复制技术。当主进程fork子进程时：

初始情况下子进程与父进程共享内存空间

Ru果父进程要修改某块内存：

操作系统会先拷贝这块内存到新位置

然后让父进程修改新位置上的内容

这样不会影响子进程读取原始数据

这个技术保证了快照生成期间Redis仍Neng正常运行。

AOF：追加日志方式记录操作

AOF就是Append Only File的意思。它记录的是每一次对数据库进行写操作的指令。

AOF怎么工作？

每次有写操作发生时dou会往AOF文件末尾追加一条日志记录

默认情况下是每秒fsync一次

需要重启恢复的时候，Redis会重放这些操作来恢复数据

AOF重写优化大小

长期使用后AOF文件会变得非常大：

Redis提供了BGREWRITEAOF命令Ke以对AOF进行压缩优化

原理是通过遍历当前所有键值对生成Zui少量命令来达到相同效果

比如原来有set k v, set k v', del k三条记录，重写后只需要del k就行了

RDB vs AOF对比表格

对比项	RDB	AOF
数据安全性	不安全	安全
数据完整性	不完全	较完整
性Neng影响	小	大
恢复速度	快	慢
文件体积	小	大

哪种geng适合你？

说实话啊：

对于追求性Neng和简单恢复场景 → RDBgeng合适

对于需要高可靠性要求 → AOFgeng合适

Zui佳实践是同时开启两者！因为：

Redis启动时优先使用AOF恢复

但平时Ke以用RDBZuo备份和冷备份之类的

常见问题解答

Q: Neng不Neng只用RDB而不用AOF？

当然Ke以啊！不过得注意可Neng会丢失Zui后一次快照之后到宕机之间修改过但还没被保存起来那些数据哦～特别是金融类应用可Neng就不太敢冒险啦～那那个...

Q: 写时复制真的不会影响性Neng吗？

基本不会！因为现在Linux系统中fork操作Yi经非常轻量级了。除非你正在进行海量geng新操作导致频繁触发COW才可Neng有点影响～嗯哼～所以...

Q: BGREWRITEAOF执行期间服务器会挂掉吗？不不对不对...

当然不会！就像BGSAVE一样dou是在后台异步完成～不过呢在此期间任何新增命令dou会被附加到新旧两份日志中直到重写完成为止哦！

一下吧：选哪种持久化方式完全取决于你具体需求啦！建议根据业务特点进行选择～毕竟没有银弹这种说法嘛～

---