Redis 的持久化机制 RDB 和 AOF 的优缺点分别是什么？
回答·27
最热
最新
- rdb是把内存中的数据持久化，可以用save和bgsave执行，save是在当前进程，会阻塞redis的使用，bgsave创建一个新的进程执行，执行策略是间隔执行，持久化耗时比较久，数据的完整性相对较差，但恢复速度更快，存储比aof小。 aof是把redis的增删改命令追加到文件，存储会更大，恢复时间更久，数据完整性较好。默认间隔1s执行一次。文件过大可以进行压缩命令操作
- rdb他的优点 1可以设置周期 2他只会生成一个文件可以保存在较为安全的磁盘里 3他在保存的时候是使用子程序fork来进行存储不会占用主程序的命令 缺点 因为是快照读，是以周期来存，如果服务器在这段时间宕机是有丢数据的风险 在数据不严谨的情况下使用 aof优点 是以日志的形式进行存储redis的写命令，安全性能高 缺点 耗费资源 在两者都开启的情况下，会以aof处理，默认为rdb
- 我来补充一下 RDB 的缺点吧，数据安全性低。RDB 是间隔一段时间进行持久化，如果持久化之间 Redis 发生故障，会发生数据丢失。所以这种方式更适合数据要求不严谨的时候。
- AOF恢复数据的完整度会更高一些
- rdb也叫redis数据快照，它是把内存中所有的数据一次性记录到磁盘中，通过bgsave命令fork主进程得到一个子进程，子进程共享主进程的内存数据，完成fork后子进程读取内存数据并写入rdb文件。rdb文件是紧凑的二进制数据文件，宕机恢复时，可以直接加载到内存，所以速度较快，但数据完整性不如aof。 aof是命令日志文件，会记录redis处理的每一个命令，它比rdb文件大的多，而且它会记录对同一个key的多次写操作，但只有最后一次写操作有意义，通过执行bgrewriteaof，可以让aof文件执行重写功能，用最少的命令达到相同的效果。aof默认是关闭的，可以通过修改appendonly来开启aof，刷盘策略默认是everysec，每隔一秒把缓冲区中的命令写入aof文件，性能适中，最多丢失一秒的数据，数据完整性更高，但体积大，重写时要执行所有的命令，速度较慢。
- Redis 缓存和 JVM 缓存的区别主要在于它们的存储位置和用途。 1. 存储位置： - Redis 缓存：Redis 缓存是一种内存数据结构存储，它将数据存储在内存中，因此访问速度非常快。它通常用于存储经常访问的数据，如用户信息、商品信息等。 - JVM 缓存：JVM 缓存是 Java 虚拟机（JVM）内部的一种缓存机制，它将常用的对象存储在堆内存中，以便快速访问。JVM 缓存主要用于提高程序运行效率，减少内存访问次数。 2. 用途： - Redis 缓存：主要用于提高系统性能，减轻数据库压力，实现缓存击穿、缓存雪崩等策略。 - JVM 缓存：主要用于提高程序运行效率，减少内存访问次数，避免重复计算。 下面是一个简单的示例，说明如何使用 Redis 缓存和 JVM 缓存： ```java // 使用 Redis 缓存的示例 import redis.clients.jedis.Jedis; public class RedisCacheExample { public static void main(String[] args) { // 连接 Redis 服务器 Jedis jedis = new Jedis("localhost"); // 将数据存储到 Redis 缓存中 jedis.set("user:1", "张三"); // 从 Redis 缓存中获取数据 String userName = jedis.get("user:1"); System.out.println("从 Redis 缓存中获取的用户名为：" + userName); } } ``` ```java // 使用 JVM 缓存的示例 import java.util.HashMap; import java.util.Map; public class JVMCacheExample { private static Map<String, String> cache = new HashMap<>(); public static void main(String[] args) { // 将数据存储到 JVM 缓存中 cache.put("user:1", "张三"); // 从 JVM 缓存中获取数据 String userName = cache.get("user:1"); System.out.println("从 JVM 缓存中获取的用户名为：" + userName); } } ``` 在这个例子中，我们分别使用了 Redis 缓存和 JVM 缓存来存储和获取用户信息。通过这种方式，我们可以提高程序运行效率，减轻数据库压力，实现缓存击穿、缓存雪崩等策略。
- RDB持久化机制会生成一个快照文件，将某个时间点上的redis数据全部保存到磁盘上。 优点:快速、紧凑、适合备份。 缺点:可能会丢失一部分数据。 AOF持久化机制是在redis执行“写”命令时，将这些命令追加到AOF文件的末尾 这样的AOF文件就是一个完整的操作日志，适合重建原始数据。 优点:完整性好 缺点:没有RDB性能好，文件较大，恢复速度较慢。
- RDB，Redis Database，会生成快照，也就是二进制文件，占内存较小，按照时间进行数据同步，更适合做定期备份，用于灾难恢复。数据恢复速度比较快。缺点是数据安全性比较差，RDB文件可读性比较差。 AOF，仅追加文件，默认是不开启的，每一次写操作都会以日志的形式记录到一个AOF文件中的持久化技术。当需要恢复内存数据时，会将这些写操作重新执行一次，用于恢复到之前的内存状态。当aof文件满足条件时，redis主进程会fork出一个子进程bgrewriteaof，用于完成rewrite操作。优点是数据安全性比较好，文件的可读性也比较强。但缺点是AOF文件较大，写操作会影响系统性能。在数据恢复时需要重新加载AOF文件进行rewrite操作，数据恢复较慢。
- RDB持久化是通过快照的方式，即在指定的时间间隔内将内存中的数据集快照写入磁盘。在创建快照之后，用户可以备份该快照，可以将快照复制到其他服务器以创建相同数据的服务器副本，或者在重启服务器后恢复数据。RDB是redis默认的持久化的方式。 RDB持久化会生成RDB文件，该文件是一个压缩过的二进制文件，可以通过该文件还原快照时的数据库状态，即生成该RDB文件时的服务器数据，RDB文件默认为当前工作目录下的dump.rdb，可以根据配置文件中的dbfilename和dir设置RDB的文件名和文件位置。 AOF（Append Only File）持久化功能会把被执行的写命令写到AOF文件的末尾，记录数据的变化。默认情况下，redis不开启AOF持久化。在配置文件中可以更改开启，开启后，没执行一条更改redis数据的命令，都会把该命令追加到AOF文件中，这会降低redis的性能，但大部分情况下这个影响是能够接受的。使用较快的硬盘可以提高AOF的性能。 RDB的优点：简称“3更” 1.体积更小：相同的数据量rdb数据比aof的小，因为rdb是紧凑型文件 2.恢复更快：因为rdb是数据的快照，基本上就是数据的复制，不用重新读取再写入内存 3.性能更高:父进程在保存rdb时候只需要fork一个子进程，无需父进程的进行其他io操作，也保证了服务器的性能。 缺点： 1.故障丢失:因为rdb是全量的，我们一般是使用shell脚本实现30分钟或者1小时或者每天对redis进行rdb备份，（注，也可以是用自带的策略），但是最少也要5分钟进行一次的备份，所以当服务死掉后，最少也要丢失5分钟的数据。 2.耐久性差:相对aof的异步策略来说，因为rdb的复制是全量的，即使是fork的子进程来进行备份，当数据量很大的时候对磁盘的消耗也是不可忽视的，尤其在访问量很高的时候，fork的时间也会延长，导致cpu吃紧，耐久性相对较差。 aof的优点 1.数据保证：我们可以设置fsync策略，一般默认是everysec，也可以设置每次写入追加，所以即使服务死掉了，咱们也最多丢失一秒数据 2.自动缩小：当aof文件大小到达一定程度的时候，后台会自动的去执行aof重写，此过程不会影响主进程，重写完成后，新的写入将会写到新的aof中，旧的就会被删除掉。但是此条如果拿出来对比rdb的话还是没有必要算成优点，只是官网显示成优点而已。 缺点呢：和rdb相反嘛，毕竟只有两种。 1.性能相对较差：它的操作模式决定了它会对redis的性能有所损耗 2.体积相对更大：尽管是将aof文件重写了，但是毕竟是操作过程和操作结果仍然有很大的差别，体积也毋庸置疑的更大。 3.恢复速度更慢：
- AOF在数据安全方面比较好，aof 持久化可以配置 appendfsync 属性，有 always，每进行一次命令操作就记录到 aof 文件中一次。 而且通过 append 模式写文件，即使中途服务器宕机，可以通过 redis-check-aof 工具解决数据一致性问题。 还有比较方便的是，AOF 机制的 rewrite 模式。AOF 文件没被 rewrite 之前（文件过大时会对命令进行合并重写），可以删除其中的某些命令（比如误操作的 flushall）