Redis持久化的两种方式

---

前言

Redis是基于内存的缓存机制,假定Redis服务器中途突然出现故障，那内存的数据就会丢失。针对这个问题,Redis提供了两种持久化方式,分别是RDB和AOF。

---

一、Redis持久化机制

RDB(Redis DataBase)：根据我们自己配置的时间或者手动去执行SAVE命令，Redis就会去生成RDB文件。这是Redis持久化的默认方式。

注意:RDB文件实际上就是一个经过压缩的二进制文件，Redis可以通过这个文件在启动的时候来还原我们的数据。

AOF(Append Only File):把Redis服务器接收到的所有写命令都记录到日志中。

注意:Redis重跑一遍这个记录下的日志文件，就相当于还原了数据。

两种方式的优缺点

RDB
1.RDB在启动的时候恢复数据会比AOF快很多。
2.可能会导致部分数据丢失(中途突然宕机,没有轮询到RDB事件)

AOF
1.数据完整性高
2.恢复起来比较慢,需要执行一条条指令。

---

二、RDB

Redis是单线程,RDB会执行SAVE或BESAVE命令,而生成文件非常耗时,如果只有一个线程处理，那其他的请求如果应对?

解决办法:
虽然Redis是单线程的,定时的RDB实际上就是一个时间事件,Redis发现RDB的事件可执行时，则调用BGSAVE命令,而BGSAVE命令实际上会fork出一个子进程来进行完成持久化（生成RDB文件）,在fork的过程中，父进程(主线程)肯定是阻塞的,但fork完之后，是fork出来的子进程去完成持久化。

总结:Redis在较新的版本中，有些地方都使用了多线程来进行处理,只不过核心的处理命令请求和响应还是单线程,但可以采取其他的办法提高运行的效率,减少阻塞时间。

---

三、AOF

AOF是在命令执行完之后,把命令写在buffer缓冲区的（直接追加写),可以设置每次操作都记录或者每秒记录一次。Redis会启一个线程去刷盘，也不是用主线程去干的。

存在问题:
如果这些写入磁盘的命令集合不做任何处理，随着操作的不断增加,该文件就会变得非常大。

解决办法:fork个子进程会对原始命令集合进行重写,相当于压缩,压缩完替换掉原始文件。

---

总结

官网是不建议仅仅只使用RDB的，如果对数据丢失容忍度是有要求的，建议是开启AOF+RDB一起用。在Redis4.0以后也支持了AOF和RDB混合，具体使用什么样的持久化方式还是要根据业务要求。

---