redis 持久化方式有哪些（图解Redis-持久化机制）
redis 持久化方式有哪些（图解Redis-持久化机制）优点RDB文件异步持久化自动保存配置结构RDB文件采用二进制存储，如下是一个详细的文件结构图RDB文件结构
Redis作为一个内存数据库，它将自己的数据库状态存储在内存里，所以如果不想办法将存储的内存数据库状态保存到磁盘里，那么一旦进程退出，服务器中所有的数据库状态将永久消失。为了解决这个问题，Redis提供了RDB与AOF持久化功能。通常来说，应该同时使用两种持久化方案，以保证数据安全：
- 如果数据不敏感，且可以从其他地方重新生成，可以关闭持久化
- 如果数据比较重要，且能够承受几分钟的数据丢失，比如缓存等，只需要使用RDB即可
- 如果是用做内存数据，要使用Redis的持久化，建议是RDB和AOF都开启，即混合模式
- 如果只用AOF，优先使用everysec的配置选择，因为它在可靠性和性能之间取了一个平衡
当RDB与AOF两种方式都开启时，Redis会优先使用AOF恢复数据，因为AOF保存的文件比RDB文件更完整
RDB模式（内存快照）RDB（Redis Database Backup File，Redis数据备份文件）持久化方式：是指用数据集快照的方式记录 Redis 数据库的所有键值对，在某个时间点将数据写入一个临时文件，持久化结束后，用这个临时文件替换上次持久化的文件，达到数据恢复。
自动间隔性保存自动保存基于serverCron函数（每间隔100毫秒执行一次）该函数会检查自动保存配置saveparams看是否满足条件，若满足则执行BGSAVE命令。
自动保存配置结构
RDB文件结构RDB文件采用二进制存储，如下是一个详细的文件结构图
RDB文件结构
持久化流程
RDB文件异步持久化
模式优缺点优点
- RDB快照是一个压缩过的非常紧凑的文件。保存着某个时间点的数据集，适合做数据的备份，灾难恢复
- 在使用BISAVE保存RDB文件时，服务器进程只需要fork一个子进程来完成RDB文件创建，父进程不会阻塞可以继续处理客户端的请求
- 恢复大数据集的时候比AOF快
缺点
- RDB的数据安全性是不如AOF的，保存整个数据集的过程是比繁重的，备份的频率不能太频繁，因此在两次备份的间隔期间服务宕机则会导致期间数据丢失
- Redis数据集较大时，fork的子进程要完成快照会比较耗CPU、耗时长
AOF（Append Only File，追加日志文件）持久化方式：是指所有的命令行记录以 Redis 命令请求协议的格式完全持久化存储保存为 aof 文件。Redis 是先执行命令，把数据写入内存，然后才记录日志。因为该模式是只追加的方式，所以没有任何磁盘寻址的开销，所以很快，有点像 Mysql 中的binlog，AOF更适合做热备。
持久化流程
AOF文件持久化
数据加载
AOF数据加载
文件加载步骤
- 创建一个不带网络连接的伪客户端
- 从 AOF 文件中分析并读取出一条写命令
- 使用伪客户端执行被读出的写命令
- 循环执行中间步骤，直到 AOF 文件中的所有写命令都被处理完毕为止
AOF文件重写
为何需要文件重写
- 为了解决 AOF 文件体积膨胀的问题
- 通过重写创建一个新的 AOF 文件来替代现有的 AOF 文件，新的 AOF 文件不会包含任何浪费空间的冗余命令
文件重写的实现原理
- 不需要对现有的 AOF 文件进行任何操作
- 从数据库中直接读取键现在的值
- 用一条命令记录键值对，从而代替之前记录这个键值对的多条命令
优点
- 数据更完整，安全性更高，秒级数据丢失（取决fsync策略，如果是everysec，最多丢失1秒的数据）
- AOF文件是一个只进行追加的日志文件，且写入操作是以Redis协议的格式保存的，内容是可读的，适合误删紧急恢复
缺点
- 对于相同的数据集，AOF文件的体积要大于RDB文件，数据恢复也会比较慢
- 根据所使用的fsync策略，AOF的速度可能会慢于RDB。 不过在一般情况下，每秒fsync的性能依然非常高
以上就是Redis持久化机制介绍，如果各位还想了解更多，欢迎评论 关注，Redis图解系列专栏持续更新中。
