什么是持久化
redis的数据全部在内存中,如果突然宕机,数据就会全部丢失,因此必须有一种机制来保证redis的数据不会因为故障而丢失,这种机制就是redis的持久化机制
那能不能从后端数据库恢复这些数据呢?不能,因为存在两大问题:一是,需要频繁访问数据库,会给数据库带来巨大的压力;而是,这些数据是从慢查询数据库中读取出来的,性能肯定比不上从redis中读取,导致使用这些数据的应用程序响应变慢。因此redis引入了自己独有的持久化机制。
redis有哪些持久化机制
redis的持久化机制有两种,一种是RDB快照,另一种是AOF日志。
- RBD快照:RDB持久化机制,是对redis中的数据执行周期性的持久化
- AOF日志:AOF持久化机制,将每台写入命令以append-only的模式写入到一个日志文件中。因为这个模式是只追加的方式,所以没有任何磁盘寻址的开销,所以很快,有点像mysql中的binlog
- (ps:Redis 4.0引入混合持久化,混合持久化=RDB快照+AOF日志)
两者之间的相似:都可以把redis内存中的数据持久化到磁盘上去,然后再将这些数据备份到别的地方去
两者之间的区别:
- 快照是一次全量备份,AOF日志是连续的增量备份。
- 快照是内存数据的二进制序列化形式,在存储上非常紧凑,而AOF日志记录的是内存数据修改的指令记录文本。
(ps:两种机制全部开启的时候,redis在重启的时候会默认使用AOF去重构数据,因为AOF的数据比RDB更完整
两者机制各自的优缺点:
- RDB
- 优点:
- 会生成多个数据文件,每个数据文件分布都代表了某一时刻redis里面的数据。
- 很合适做冷备:数据运维设置定时任务,定时同步到远端的服务器,这样一旦线上挂了,你想恢复多少分钟之前的数据,就去远端拷贝一份之前的数据就好了
- RDB对redis的性能影响小,因为在同步数据的时候它fork了一个进程去做持久化,而且它的数据恢复速度比AOF快
- 缺点:
- RDB都是快照文件,都是默认五分钟甚至更久的时间才会生成一次,这意味着你这次同步到下次同步这中间五分钟的数据都很可能全部丢失掉。AOF则最多丢一秒的数据,数据完整性上高下立判。
- RDB在生成数据快照的时候,如果文件很大,客户端可能会暂停几毫秒甚至几秒
- 优点:
- AOF
- 优点:
- RDB五分钟一次生成快照,AOF一秒一次去通过一个后台的下承诺fsync操作,最多丢一秒的数据
- AOF在对日志文件进行操作的时候是以append-only的方式去写的,即以追加的方式写数据,少了很大磁盘寻址的开销,写入性能很好,文件也不容易破损
- AOF的日志是通过一个叫非常可读的方式记录的,这样的特性就适合做灾难性数据误删除的紧急恢复了,比如公司的实习生通过flushall清空了所有的数据,只要这个时候后台重写还没发生,你马上拷贝一份AOF日志文件,把最后一条flushall命令删了就完事了。
- 缺点:
- 一样的数据,AOF文件比RDB还要大。
- AOF开启后,Redis支持写的QPS会比RDB支持写的要低,因为其每秒都要去异步刷新fsync一次日志
- 优点:
Redis 4.0 混合持久化
-
重启redis时,我们很少使用rdb来恢复内存状态,因为会丢失大量数据。我们通常使用AOF日志重放,但是重放AOF日志相对于使用rdb来说慢很多,这样在redis实例很大的时候,启动需要花费很长时间。
-
为此,redis4.0引入了一种新的持久化选项------混合持久化。如下图,将rdb文件的内容和增量的AOF日志文件存在一起。这里的AOF日志不再是不再是全量的日志,而自持久化开始到持久化结束这段时间发送的增量AOF日志,通常这部分AOF日志很小。
-
于是在redis重启的时候,可以先加载rdb的内容,然后再重放增量AOF日志,就可以完全替代之前的AOF全量文件重放,重启效率得到大大提升
运维
快照是通过开启子进程的方式进行的,它是一个比较消耗资源的操作
- 遍历整个内存,大块写操会加重系统负载
- AOF的fsync是一个耗时的IO操作,它会降低redis的性能,同时也会增加系统IO负担
所以通常redis的主节点不会进行持久化操作,持久化操作主要在从节点运行。从节点是备份节点,没有来自客户端请求的压力,它的操作系统资源往往比较充沛
但是如果出现网络分区,从节点长期连不上主节点,就会出现数据不一致的问题,特别是在网络分区出现的情况下,主节点一旦不小心宕机了,那么数据就会丢失,所以在生产环境下要做好实时监控工作,保证网络畅通或者能快速修复。另外,还应该再增加一个从节点以降低网络分区的概率,只要有一个从节点数据同步正常,数据也就不会轻易丢失