Redis持久化方式

雨点打透心脏的1/2处 2022-05-14 02:29 199阅读 0赞

文章转自：[http://www.cnblogs.com/tdws/p/5754706.html][http_www.cnblogs.com_tdws_p_5754706.html]

Redis持久化有2种方式，**RDB**和**AOF。**持久化过程中并不需要我们开发人员过多的参与，我们要做的是什么呢？除了深入了解**RDB**和**AOF**的**作用原理**，剩下的就是根据实际情况来制定合适的策略了，再复杂一点，也就是**定制一个高可用的，数据安全的策略**了。

先来看RDB持久化方式：

在RDB方式下，你有两种选择，一种是手动执行持久化数据命令来让redis进行一次数据快照，另一种则是根据你所配置的配置文件的策略，达到策略的某些条件时来自动持久化数据。而手动执行持久化命令，你依然有两种选择，那就是**save**命令和**bgsave**命令。

**save**操作在Redis主线程中工作，因此会**阻塞**其他请求操作，应该避免使用。

![686162-20160809193246949-550996729.png][]

（默认下，持久化到**dump.rdb**文件，并且在redis重启后，自动读取其中文件，据悉，通常情况下**一千万**的字符串类型键，**1GB**的快照文件，同步到内存中的 时间是**20-30秒**）

bgSave则是调用Fork,产生子进程，父进程继续处理请求。子进程将数据写入临时文件，并在写完后，替换原有的.rdb文件。Fork发生时，父子进程内存共享，所以为了不影响子进程做数据快照，在这期间修改的数据，将会被复制一份，而不进共享内存。所以说，RDB所持久化的数据，是Fork发生时的数据。在这样的条件下进行持久化数据，如果因为某些情况宕机，则会丢失一段时间的数据。如果你的实际情况对数据丢失没那么敏感，丢失的也可以从传统数据库中获取或者说丢失部分也无所谓，那么你可以选择RDB持久化方式。

再谈一下配置文件的策略，实际上它和bgsave命令持久化原理是相同的。

![686162-20160809194228027-1719282689.png][]

这是配置文件**默认的策略**，他们之间的关系是或，每隔**900**秒，在这期间变化了至少**一个**键值，做快照。或者每**三百秒**，变化了**十个**键值做快照。或者每**六十**秒，变化了至少**一万**个键值，做快照。

下面再来说一说AOF快照方式：

AOF,append only file。

![686162-20160809204651262-669790552.png][]

开启AOF需要将配置文件中的appendonly修改为yes。开启AOF持久化后，你所执行的每一条指令，都会被记录到**appendonly.aof**文件中。但事实上，**并不会立即将命令写入到硬盘文件中，而是写入到硬盘缓存**，在接下来的策略中，配置多久来从硬盘缓存写入到硬盘文件。所以在一定程度一定条件下，还是会有数据丢失，不过你可以大大减少数据损失。

![686162-20160809204603559-692481331.png][]

这里是配置AOF持久化的策略。redis默认使用**everysec**，就是说每秒持久化一次，而always则是每次操作都会立即写入aof文件中。而**no**则是不主动进行同步操作，是默认30s一次。当然**always**一定是效率最低的，个人认为**everysec**就够用了，数据安全性能又高。

Redis也允许我们同时使用两种方式，再重启redis后会从**aof**中恢复数据，因为**aof**比**rdb**数据损失小嘛。

区别和深入理解：

**RDB**每次进行快照方式会重新记录整个数据集的所有信息。RDB在恢复数据时更快，可以最大化redis性能，子进程对父进程无任何性能影响。

**AOF**有序的记录了redis的命令操作。意外情况下数据丢失甚少。他不断地对aof文件添加操作日志记录，你可能会说，这样的文件得多么庞大呀。是的，的确会变得庞大，但redis会有优化的策略，比如你对一个**key1**键的操作，set key1 001 ,  set key1 002, set key1 003。那优化的结果就是将前两条去掉咯，那具体优化的配置在配置文件中对应的是![686162-20160809211516715-145676984.png][]

前者是指超过上一次aof重写aof文件大小的百分之多少，会再次优化，如果没有重写过，则以启动时为主。后者是限制了允许重写的最小aof文件大小。**bgrewriteaof**命令是手动重写命令，会fork子进程，在临时文件中重建数据库状态，对原aof无任何影响，当重建旧的状态后，也会把fork发生后的一段时间内的数据一并追加到临时文件，最后替换原有aof文件，新的命令继续向新的aof文件中追加。

[http_www.cnblogs.com_tdws_p_5754706.html]: http://www.cnblogs.com/tdws/p/5754706.html
[686162-20160809193246949-550996729.png]: /images/20220514/695c45c3ac424b359ce0893b7d93c4dd.png
[686162-20160809194228027-1719282689.png]: /images/20220514/2d2746aa0fb94adc8dd4e0b7676da3a3.png
[686162-20160809204651262-669790552.png]: /images/20220514/f7d4239fda374ff49fe4435d93c35b10.png
[686162-20160809204603559-692481331.png]: /images/20220514/24fc5e7ddabb4f42849739edd6723fac.png
[686162-20160809211516715-145676984.png]: /images/20220514/c34a26d3e4164fdd9c82a1078ae211f5.png