Redis持久化存储

Redis持久化存储

Redis虽然是一个内存级别的缓存程序，也就是Redis是使用内存进行数据的缓存的，但是其可以将内存的数据按照一定的策略保存到硬盘上，从而实现数据持久保存的目的。

目前，Redis支持两种不同方式的数据持久化保存机制，分别是RDB和AOF，这两种方式分别类似于MySQL数据库的MySQL dump和二进制日志方式。

RDB模式

1.1 RDB模式工作原理

RDB（Redis Database）：基于时间的快照，其默认只保留当前最新的一次快照，特点是执行速度比较快，缺点是可能会丢失从上次快照到当前时间点之间未做快照的数据。

1.2 RDB实现快照的具体过程

Redis从master主进程先fork出一个子进程，使用写时复制机制，子进程将内存的数据保存为一个临时文件，比如tmp-x.rdb，当数据保存完成之后再将上一次保存的RDB文件替换掉，然后关闭子进程，这样就可以保证每一次RDB快照保存的数据都是完整的。

因为直接替换RDB文件的时候，可能会出现突然断电等问题，导致RDB文件还没有保存完整就因为突然关机停止保存，进而导致数据丢失的情况。后续可以手动将每次生成的RDB文件进行备份，这样可以最大化保存历史数据。

1.3 RDB实现方式

实现RDB进行Redis数据备份主要有save、bgsave和自动备份三种方式。

1.3.1 save

save为同步方式，当Redis数据库中的数据量特别大时，使用该方式会阻塞其它命令，不推荐使用。例如笔者通过python脚本写入500万个key。

另打开一个会话窗口同时使用save保存并新创建一个key，刚开始时可能没反应，但数据量到了150万以后再执行相同命令，则会出现卡顿现象，要等保存的命令执行完毕才能将同时执行命令中的key写入。

1.3.2 bgsave

使用bgsave方式时是在异步后台执行，不影响其它命令的执行。例如还是以上的脚本，由于数据量够大，还在写入中，笔者换成bgsave方式，则可以在保存数据的同时写入新的key。

1.3.3 自动备份

使用自动备份方式时需要在Redis配置文件中指定规则，自动执行。例如笔者在配置文件中设置30秒内有2个数据更新则启动自动保存。

先创建一个key，返回查看RDB文件大小并无变动。

再创建一个key，返回查看已发生了变动。

1.4 RDB模式优缺点

1.4.1 RDB模式的优点

RDB模式的优点主要表现为：

①RDB快照保存了某个时间点的数据，可以通过脚本执行Redis指定bgsave或者save（不推荐）命令自定义时间点备份，可以保留多个备份，当出现问题可以恢复到不同时间点的版本，很适合备份，并且此文件格式也支持有不少第三方工具可以进行后续的数据分析；

②RDB可以最大化Redis的性能，父进程在保存RDB文件时唯一要做的就是fork出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无需执行任何磁盘I/O操作；

③RDB在恢复大量数据，比如几个G的数据时，速度比AOF快。

1.4.2 RDB模式的缺点

RDB模式的缺点表现为：

①不能实时保存数据，可能会丢失自上一次执行RDB备份到当前的内存数据；

②当数据量特别大的时候，从父进程fork子进程进行保存至RDB文件需要一点时间，可能是毫秒或者秒，取决于磁盘I/O性能。

AOF模式

2.1 AOF模式工作原理

AOF（Append Only File），按照操作顺序依次将操作追加到指定的日志文件末尾。

AOF和RDB一样使用了写时复制机制，AOF默认为每秒钟fsync一次，即将执行的命令保存到AOF文件中，这样即使Redis服务器发生故障，最多只丢失1秒钟之内的数据。

也可以设置不同的fsync策略aways，即设置每次执行命令的时候都执行fsync，fsync会在后台执行线程，所以主线程可以继续处理用户的正常请求而不受到写入AOF文件的I/O影响。

注意事项：

同时启用RDB和AOF进行恢复时，默认AOF文件的优先级要高于RDB文件，即会使用AOF文件进行恢复。

2.2 AOF配置

AOF默认是不开启的，需要在Redis配置文件中将appendonly部分no改为yes开启AOF功能。

2.2.1 直接修改问题

由于RDB和AOF同时存在时，AOF文件的优先级要高一点，如果首次通过配置文件修改并重启Redis服务会导致原有数据全部丢失。

2.2.2 建议设置方式

建议在不修改默认配置文件的前提下，通过登录Redis进行动态修改。

等AOF文件生成后，再修改配置文件的对应内容，等待下次重启时，可以从现有的AOF文件中读取数据。

2.3 AOF模式的优缺点

2.3.1 AOF模式的优点

AOF模式的优点表现为：

①数据安全性相对较高，根据所使用的fsync策略，默认是appendfsync everysec，即每秒执行一次fsync。在这种配置下，Redis仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失1秒钟的数据；

②由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中不需要seek，即使出现宕机现象，也不会破坏日志文件中已经存在的内容；

③Redis可以在AOF文件体积变得过大时，自动在后台对AOF进行重写，重写后的新AOF文件包含了恢复当前数据集所需的最小命令集合；

④AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作，事实上也可以通过该文件完成数据的重建。

2.3.2 AOF模式的缺点

AOF模式的缺点表现为：

①即使有些操作是重复的也会全部记录，AOF文件的大小要大于RDB文件；

②AOF在回复大数据集时的速度比RDB的恢复速度慢；

③根据fsync策略的不同，AOF的速度可能会慢于RDB；

④④bug出现的可能性会更多。

RDB模式与AOF模式的选择

①如果主要充当缓存功能，或者可以承受数分钟数据的丢失，通常生产环境一般只需要RDB模式即可，此也是默认值；

②如果数据需要持久保存，一点不能丢失，可以选择同时开启RDB模式和AOF模式；

③一般不建议只开启AOF。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。