Radis持久化存储的选择

最新推荐文章于 2024-01-05 11:02:23 发布

1条有梦想的咸鱼

最新推荐文章于 2024-01-05 11:02:23 发布

阅读量137

点赞数

本文链接：https://blog.csdn.net/weixin_41921180/article/details/84304954

版权

前言:

查了资料之后知道持久化存储有两种方案，RDB和AOF

RDB:

中文名字叫快照/内存快照，过程很好理解，就是Redis按照一定的时间周期将目前服务中的所有数据全部写到磁盘中。具体过程有很多细节需要处理，本文章主要是在两者之间的选择，所以细节不多说了。

由于生产环境中我们为Redis开辟的内存区域比较大，那么将内存中的数据同步到硬盘的过程可能就会持续比较长的时间。在正常的快照操作中，一方面Redis主进程会fork一个新的快照进程专门来做这个事情，这样保证了Redis服务不会停止对客户端包括写请求在内的任何响应。另一方面这段时间发生的数据变化会以副本的方式存放在另一个新的内存区域，待快照操作结束后才会同步到原来的内存区域。

如果在快照操作的这段时间，服务奔溃，将以上一次完成的TDB快照文件作为恢复内存数据的参考。也就是说，在快照操作过程中不影响上一次的本分数据。Redis服务会在磁盘上创建一个临时文件进行数据操作，待操作成功后才会用这个临时文件替换掉上一次的备份。

由于是周期性的同步，所以RDB存在的最大问题就是在Redis异常奔溃，需要从最近一次RDB文件恢复数据时，就会丢失最近一批最新的数据，这批数据可能会很多。另外，虽然使用专门的快照进程进行快照数据同步的方式，本身不会造成Redis服务出现卡顿，但如果需要快照的数据量特别大，操作系统基本上会将CPU资源互换用到快照操作上去，这可能间接造成包括Redis主进程在内的其他进程被挂起。所以在非常高并发的情况下并不是最好的解决方法。

AOF:

全称是Append Only File 字面理解“只进行增加的文件”，在Redis服务启动后，每一次影响数据状态的操作命令都会被记录。以便在服务奔溃后按照操作命令恢复数据。Redis提供的一种重写AOF文件的功能，保证了AOF文件中可以存储尽可能少的操作命令就能保证数据恢复到最新状态，这个功能称为日志重写功能。

这样看起来AOF恢复速度比RDB慢，查资料，慢大概25%到50%，存到磁盘的文件AOF比RDB大，约2.5倍，但是不会丢失数据

RDB优点：

（1）RDB会生成多个数据文件，每个数据文件都代表了某一个时刻中redis的数据，这种多个数据文件的方式，非常适合做冷备。
（2）RDB对redis对外提供读写服务的时候，影像非常小，因为redis 主进程只需要fork一个子进程出来，让子进程对磁盘io来进行rdb持久化
(3).RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

RDB缺点

（1）如果redis要故障时要尽可能少的丢失数据，RDB没有AOF好，例如1:00进行的快照，在1:10又要进行快照的时候宕机了，这个时候就会丢失10分钟的数据。
（2）RDB每次fork出子进程来执行RDB快照生成文件时，如果文件特别大，可能会导致客户端提供服务暂停数毫秒或者几秒

AOF的优点：

（1）AOF可以更好的保护数据不丢失，一般AOF会以每隔1秒，通过后台的一个线程去执行一次fsync操作，如果redis进程挂掉，最多丢失1秒的数据。
（2）AOF以appen-only的模式写入，所以没有任何磁盘寻址的开销，写入性能非常高。
（3）AOF日志文件的命令通过非常可读的方式进行记录，这个非常适合做灾难性的误删除紧急恢复，如果某人不小心用flushall命令清空了所有数据，只要这个时候还没有执行rewrite，那么就可以将日志文件中的flushall删除，进行恢复。