redis设计原理009持久化策略

目录

RDB

备份原理

优点

缺点

AOF

不能保证绝对不丢失数据

重写

    流程

    结论

优点

缺点

如何选择RDB和AOF

同时开启

混合模式

运行过程

数据

数据恢复

优点

缺点

优化方案

总结

---

RDB

---

通过快照（snapshotting）完成的，当符合一定条件时Redis会自动将内存中的数据进行快照并持久化到硬盘

RDB是Redis默认采用的持久化方式

在指定的时间间隔内将内存中的数据集快照写入磁盘，它恢复时是将快照文件直接读到内存里。

备份原理

---

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效

优点

---

1.   紧凑压缩的二进制文件 节省空间
2.   fork子进程性能最大化
3.   启动效率高 恢复速度快

缺点

---

1.   一旦Redis异常退出，就会丢失最后一次快照以后更改的所有数据
2.   虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能
3.   fork过程非常耗时，会造成毫秒级不能响应客户端请求

AOF

---

写一条，保存一条，历史的状态

以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，Redis启动之初会读取该文件重新构建数据，换言之，Redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

不能保证绝对不丢失数据

---

  执行系统调用write函数，将一些内容写入到某个文件里面时，为了提高效率，系统通常不会直接将内容写入硬盘里面，而是先将内容放入一个内存缓冲区(buffer)里面，等到缓冲区被填满，或者用户执行fsync调用和fdatasync调用时才将储存在缓冲区里的内容真正的写入到硬盘里，未写入磁盘之前，数据可能会丢失

重写

---

       原因

---

  比如我有业务很简单，就来回delete set同一个key。就这个业务运行了10年，那么aof文件将记录无数个delete k上，set   k1x。其实都是重复的，但是我aof每次都追加，文件变成了1T大小。这时候Redis宕机了，要恢复，你想想1TB大小的aof文去恢复，累死了。最主要的是1TB大小只记录了两个命令，所以压缩其实就是来处理这件事的

    流程

---

1. Redis可以在AOF文件体积变得过大时，自动地在后台对AOF进行rewrite。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行
2. 因为Redis在创建新AOF文件的过程中，会继续将命令追加到现有的AOF文件里面，即使重写过程中发生停机，现有的AOF文件也不会丢失。
3. 而一旦新AOF文件创建完毕，Redis就会从旧AQF文件切换到新AOF文件，并开始对新AOF文件进行追加操作

    结论

---

合并重复的操作，AOF会使用尽可能少的命令来记录

优点

---

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

缺点

---

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

如何选择RDB和AOF

---

同时开启

---

1. Redis先加载AOF文件来恢复原始数据，因为AOF数据比RDB地更完整，但是aof存在潜在的bug,如把错误的操作记录写入了aof,会导出数据恢复失败，所以可以把RDB作为后备数据。
2. 为了考虑性能，可以只在Slave上开启RDB,并且15min备份一次，如果为了避免AOF rewite的Io以及阻塞，可以在Redis集群中不开启AOF,靠集群的备份机制来保证可用性，在启动时选取较新的RDB文件，如果集群全部崩溃，会丢失15mi前的数据。

混合模式

---

        Redis4.0开始支持该模式

        解决的问题：Redis在重启时通常是加载AOF文件，但加载速度慢。因为RDB数据不完整，所以加载AOF

        开启后，AOF在重写时会直接读取RDB中的内容。

运行过程

---

  通过bgwriteaof完成，不同的是当开启混合持久化后

1. 子进程会把内存中的数据以RDB的方式写入aof中
2. 把重写缓冲区中的增量命令以AOF方式写入到文件
3. 将含有RDB个数和AOF个数的AOF数据覆盖旧的AOF文件

数据

        新的AOF文件中，一部分数据来自RDB文件，一部分来自Redisi运行过程时的增量数据

数据恢复

  当我们开启了混合持久化时，启动Redis依然优先加载aof文件，aof文件加载可能有两种情况如下：

1. aof文件开头是rdb地的格式，先加载rdb地内容再加载剩余的aof
2. aof文件开头不是rdb的格式，直接以aof格式加载整个文件

优点

        既能快速备份又能避免大量数据丢失

缺点

        RDB是压缩格式，AOF在读取它时可读性较差

优化方案

---

1. 独立部署，硬盘优化
2. 缓存禁用持久化
3. 主从模式，从持久化
4. 优化fork处理

总结

---

1. 官方推荐量都启用
2. 如果对数据不敏感,可以选单独用RDB.
3. 不建议独用,因为可能会出Bug.
4. 如果只是做纯内存缓存,可以都不用