持久化机制

持久化

Redis是基于内存运行的，将redis数据写入到硬盘这一过程就叫持久化

RDB

全称Redis Database

在指定的时间间隔内将某一时刻的内存快照（Snapshot），以二进制的方式写入磁盘

触发

持久化流程

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到 一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。

整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。

如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。

优点

• 1.适合大规模的数据恢复
• 2.对数据完整性和一致性要求不高
• 3.节省磁盘空间
• 4.恢复速度快

缺点

• 1.最后一次持久化后的数据可能丢失
• 2.使用了写时复制技术，会比较消耗性能

AOF

全称Append Of File

以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来(读操作不记录)，

只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，

换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

持久化流程

• 1.客户端的请求写命令会被append追加到AOF缓冲区内
• 2.AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中
• 3.AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量
• 4.Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的

同步频率设置

• appendfsync always

始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性比较好

• appendfsync everysec

每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。

• appendfsync no

redis不主动进行同步，把同步时机交给操作系统。

Rewrite压缩

优点

• 1.备份机制更稳健，丢失数据概率更低。
• 2.读的日志文本，通过操作AOF稳健，可以处理误操作。

缺点

• 1.比起RDB占用更多的磁盘空间
• 2.恢复备份速度要慢
• 3.每次读写都同步的话，有一定的性能压力
• 4.存在个别Bug，造成恢复不能

注意

AOF和RDB同时开启，系统默认取AOF的数据（数据不会存在丢失）

究竟使用哪个？

官方推荐两个都启用。

如果对数据不敏感，可以选单独用RDB。

不建议单独用 AOF，因为可能会出现Bug。

如果只是做纯内存缓存，可以都不用。