Redis 持久化问题 我们都知道Redis是基于内存的，而内存的特点就是掉电数据丢失，为了解决这个问题，Redis提供了两种持久化方案，一种类似快照形式，一种类似日志形式，两者各有优缺点，下面且听我娓娓道来。 Redis提供的持久化方案为RDB以及AOF，RDB全称Redis Database Backup File, 这个方案类似于快照，是某个时刻Redis的数据的备份。AOF全称Append Only File，这个方案类似于日志记录，记录从Redis启动开始，所执行的写操作的指令。两种方案各有千秋，我们先来说说RDB吧，RDB是Redis默认开启的，会在Redis主动退出的时候，自动执行一个RDB操作，生成一个xxx.rdb文件，除此之外你也可以在配置文件中配置多久执行一次RDB操作。由于RDB文件保存的是Redis的数据备份，因此在重新启动Redis做数据恢复时会很快，但是成也快照，败也快照，虽然在启动的时候快，但是在Redis运行的时候，如果主进程进行RDB操作，由于RDB操作涉及磁盘IO，耗时较多，就会导致主进程阻塞，无法执行其他命令，破坏了Redis的可用性。不过这种情况Redis已经考虑到了，提供了异步的RDB操作，而且默认也是异步的RDB操作。但是异步的RDB操作是基于多进程的，即便Linux使用的是Copy-On-Write模式，在最坏的情况下，内存中会有两分一模一样的数据，导致内存空间浪费，甚至有可能因为这个导致OOM的发生。为了解决这个问题，Redis给出了另外一种持久化方案AOF，在每次执行AOF操作的时候，不再是备份Redis中的数据了，而是记录执行成功的写操作指令，降低了在运行时的耗时操作，以及由于异步导致的内存占用问题。但是代价就是文件的大小会很大，而且存在冗余，比如之前执行了set num 123 过了一会又执行set num 999 ,在进行数据恢复的时候，我们只需要set num 999 但是却执行了这两条指令，因此在重新启动的时候，速度慢。这个问题Redis也考虑到了，通过一条指令可以整理xxx.aof文件，尽量的减少无用的指令。这个命令是 BGREWRITEAOF 稍微总结一下，RDB在启动的时候速度快，但是在运行时，可能会占用过大的内存，而AOF在启动的时候需要逐条执行指令，速度慢，但是在运行时，速度快，但是aof文件大小可能会很庞大。 现在我们可能就体会到了每种方案都不是完美的，有种鱼和熊掌不可兼得的感觉。但是有时候 一加一可能大于二，在Redis7的版本中（我忘了什么时候开始的了），一旦开启了AOF，其实就是AOF和RDB的结合模式了。具体的流程是这样的，起初会进行一次RDB操作，然后在运行时执行AOF操作，等到自动执行BGREWRITEAOF的时候，就会再进行一种RDB操作，并重新生成一个AOF文件。然后当Redis主动停机的时候也会执行一直RDB操作，同时生成一个新的AOF文件。这样就在一定程度上实现了鱼和熊掌我都要。到此，我们就阅完了Redis给持久化问题交出的答卷，不知道你从中学到了什么呢？下面我们来聊聊Redis如何解决性能问题的！ #随笔# #Redis#