在前两篇关于Redis的文章中,已经详细的介绍了Redis常用的数据结构相关内容,如果还没看的小伙伴可以先过一遍【Redis基本数据类型,Redis跳跃表详解】。本篇文章主要介绍:Redis数据持久化机制(RDB & AOF)。在此之前需要先了解一下Redis服务器的数据库以及Redis对过期键的处理策略是怎样的,有助于理解持久化机制内容。
Redis服务器中的数据库
对于我们都很熟悉的数据库MySQL,我们知道在MySQL中可以创建多个库。同样地,Redis服务器中也是有数据库这一概念的。如果不指定具体的数量,默认会有16个数据库,并且数据库与数据库之间的数据是隔离的。
- Redis数据库的原理
Redis服务器是通过redisServer结构体表示的,其中redisDb一个是用来保存所有的数据库的数组,dbnum表示数据库的数量(默认16,可以修改配置),Redis中对于每个数据库是通过redisDb结构体表示的。redisServer和redisDb的源码如下:
struct redisServer{ // redisDb数组,表示服务器中所有的数据库 redisDb *db; // 服务器中数据库的数量 int dbnum; };
typedef struct redisDb { // 数据库ID标识 int id; // 键空间,存放着所有的键值对 dict *dict; // 过期哈希表,保存着键的过期时间 dict *expires; // 被watch命令监控的key和相应client dict *watched_keys; // 数据库内所有键的平均TTL(生存时间) long long avg_ttl; } redisDb;
从源码中可以知道,最重要的属性是dict *dict,它是用来存放所有的键值对。对于dict数据结构(哈希表)可以参考上篇文章Redis基本数据类型,这里不再赘述。我们将存储所有键值对的dict称为键空间。其示意图参考如下:
![1ec167308412bc909363f63a2b975595.png](https://i-blog.csdnimg.cn/blog_migrate/715bf71ea722864e4aa3d322bf6ff131.jpeg)
键值对存储示意图
另外,我们知道Redis是C/S架构的,Redis客户端是通过redisClient结构体表示的,源码如下:
typedef struct redisClient{ // 客户端当前所选数据库 redisDb *db; }redisClient;
【小结】:Redis的数据库是使用字典(哈希表)作为底层存储实现的,对数据库的增删改查都是构建在字典的操作之上的。
基于上述键值对存储结构示意图,执行Redis命令如:GET message -- "Hello Redis"。
![1fe30c5e8956906aa8a783f0649b37d8.png](https://i-blog.csdnimg.cn/blog_migrate/e4b0b11679eb102468193a74e294d7d7.jpeg)
查询键示意图
Redis键过期处理策略
- 键的过期时间
Redis是基于内存的,内存是非常昂贵的资源,并且容量是比较小的。所以我们需要处理掉不常使用的数据,保留常用数据。Redis提供了键的过期时间(生存时间)设置。
- 设置键的生存时间可以通过EXPIRE或者PEXPIRE命令;
- 设置键的过期时间可以通过EXPIREAT或者PEXPIREAT命令;
其中EXPIRE、PEXPIRE、EXPIREAT都是通过PEXPIREAT命令实现的。
- 键过期策略
通过设置过期时间,过期键到时间会立即删除吗?回答这个问题,需要了解一下删除策略:
- 定时删除:到时间点就把所有过期的键删除(对内存是友好的,对CPU不友好);
- 惰性删除:每次从键空间取键的时候,判断键是否过期,如果是就删除(对内存不友好,对CPU友好);
- 定期删除:每隔一段时间删除过期键,限制删除的执行时长和频率(内存和CPU的折中);
【注】:Redis采用惰性删除&定期删除两种策略,所以在Redis中如果过期键到了过期时间了未必被立即删除。
- 内存淘汰机制
基于上述删除策略,如果遗漏了很多过期的键,也没有办法及时去查(惰性删除),大量过期的键堆积在内存中,导致Redis内存几乎耗尽,这种情况如何处理呢?
当然,我们可以设置内存最大使用量,当内存使用量超出时,会执行数据淘汰策略。
Redis的内存淘汰策略机制有以下几种:
![4df65d1ed0116eee381d14d4cf1f1863.png](https://i-blog.csdnimg.cn/blog_migrate/2ab3bfc7002f2ac51e71caff65349299.jpeg)
Redis数据淘汰策略机制
一般使用场景:使用Redis缓存数据时,为了提高缓存命中率,需要保证缓存数据都是热点数据。可以将内存最大使用量设置为热点数据占用的内存量,然后启用allkeys-lru淘汰策略,将最近最少使用的数据淘汰。
Redis持久化机制
Redis的数据全部存储在内存中,如果异常突然宕机,数据就会全部丢失,因此必须有一套机制来保证Redis数据不会因为故障的发生而丢失,这种机制就是Redis持久化机制,它会将内存中的数据状态保存到磁盘中。
介绍Redis持久化机制之前,先看一下从客户端发起请求开始,到服务器真实写入磁盘,这期间发生哪些操作,以一张示意图表示:
![50a810d7d7a9cbe47abb2ebb97db311d.png](https://i-blog.csdnimg.cn/blog_migrate/875616d6bad81b0be77bf247e0a88690.jpeg)
持久化过程简易图
对上图进行简单描述:
- Client向数据库发送写命令(数据在Client内存中);
- 数据库接收到Client的写请求(数据在Server内存中);
- 数据库调用系统API将数据写入磁盘(数据在内核缓冲区中);
- 操作系统将写缓冲区传输到磁盘控制器(数据在磁盘缓存中);
- 磁盘控制器将数据写入实际的物理介质中(数据在磁盘中)。
Redis提供了两种不同的持久化机制来将数据存储到磁盘中:
(1) RDB(基于快照):将某一时刻的所有数据保存到一个RDB文件中
(2) AOF(Append-Only-File):当Redis服务器执行写命令时,将执行的写命令保存到AOF文件中
- RDB持久化机制(快照持久化)
RDB触发机制分为手动触发和自动触发两种。RDB持久化所生成的RDB文件是一个经过压缩处理的二进制文件,Redis可以通过这个文件还原数据库的数据。
- 手动触发
- SAVE:会阻塞Redis服务器进程,服务器不能接收任何请求,直到RDB文件创建完毕
- BGSAVE:Redis进程执行fork()操作创建出一个子进程,在后台完成RDB持久化过程
- 自动触发
save 900 1 # 在900秒(15分钟)之后,至少有1个key发生变化 save 300 10 # 在300秒(5分钟)之后,至少有10个key发生变化 save 60 10000 # 在60秒(1分钟)之后,至少有10000个key发生变化
Redis持久化流程(BGSAVE执行流程):
![2f115b51ee2b4836e0f8bd9cfdc46adb.png](https://i-blog.csdnimg.cn/blog_migrate/4025970c39acd38af5bb82fff55fd809.jpeg)
BGSAVE执行流程图
【总结】:通过手动调用SAVE或者BGSAVE命令或者配置条件触发,将数据库某一时刻的数据快照,生成RDB文件实现持久化。
- AOF持久化机制(文件追加)
AOF是通过保存Redis服务器所执行的写命令来记录数据库的数据的。以独立日志的方式记录每次写命令,重启时再重新执行AOF文件中的命令达到恢复数据的目的。
AOF的使用:在redis.conf配置文件中,将appendonly设置为yes,默认是no。
- AOF持久化机制实现
AOF持久化机制实现分三个步骤:
Step1:命令追加:命令写入aof_buf缓冲区
Step2:文件写入:调用flushAppendOnlyFile函数,考虑是否要将aof_buf缓冲区写入AOF文件中
Step3:文件同步:考虑是否将内存缓冲区数据真正写入到磁盘
![290de26d9fe36d3fb74498341241c66a.png](https://i-blog.csdnimg.cn/blog_migrate/78eab29402915dbb75052a2adda37a8d.jpeg)
AOF持久化步骤
其中,flushAppendOnlyFile函数的行为是由服务器的appendfsyn配置项决定的:
appendfsync always # 每次有数据修改发生时都会写入AOF文件。 appendfsync everysec # 每秒钟同步一次,该策略为AOF的默认策。 appendfsync no # 从不同步。高效但是数据不会被持久化
有一个问题需要在这里进行简单的说明:写命令为什么先写入缓冲区?
由于Redis是单线程响应命令,所以每次写AOF文件都直接追加到硬盘中,那么写入的性能完全取决于硬盘的负载,所以Redis会将命令写入到缓冲区中,然后执行文件同步操作,再将缓冲区内容同步到磁盘中,这样就很好的保持了高性能。
- AOF重写
Redis在长期运行的过程中,AOF日志会越变越长。如果实例宕机重启,重放整个AOF日志会非常耗时,导致长时间 Redis 无法对外提供服务。所以需要对AOF日志 “瘦身”。
Redis提供了bgrewriteaof指令用于对AOF日志进行瘦身。其 原理 就是 开辟一个子进程 对内存进行 遍历 转换成一系列Redis的操作指令,序列化到一个新的AOF日志文件 中。序列化完毕后再将操作期间发生的 增量AOF日志 追加到这个新的AOF日志文件中,追加完毕后就立即替代旧的AOF日志文件了,瘦身工作就完成了。
【说明】:AOF重写不需要对现有的AOF文件进行任何的读取、分析。AOF重写是通过读取服务器当前数据库的数据来实现的!
Redis将AOF重写程序放到子进程里执行(bgrewriteaof命令),像BGSAVE命令一样fork出一个子进程来完成重写AOF的操作,从而不会影响到主进程。AOF后台重写是不会阻塞主进程接收请求的,新的写命令请求可能会导致当前数据库和重写后的AOF文件的数据不一致!
☆ 为了解决数据不一致的问题,Redis服务器设置了一个AOF重写缓冲区,这个缓存区会在服务器创建出子进程之后使用。
![fecc2e425f195ee27285a294c5d400f3.png](https://i-blog.csdnimg.cn/blog_migrate/209f747fd8f04ae056c5a05f1b142b6b.jpeg)
AOF后台重写过程
- RDB & AOF比较
- RDB的优点:载入时恢复数据快,文件体积小
- RDB的缺点:会一定程度上丢失数据(因为系统如果在定时持久化之前出现宕机,此时还没来得及写入磁盘的数据都将会丢失)
- AOF的优点:丢失数据少(默认配置只丢失一秒的数据)
- AOF的缺点:恢复数据相对较慢,文件体积大
【说明】:如果Redis服务器同时开启了RDB和AOF持久化,服务器会优先使用AOF文件来还原数据(因为AOF更新频率比RDB更新频率要高,还原的数据更完善)
往期精彩文章
Redis系列(二):跳跃表详解
Redis系列(一):与Redis的第一次相识
MySQL系列之精华篇
MySQL系列之MVCC多版本并发控制
MySQL系列之数据库锁
MySQL系列之数据库索引
MySQL系列之事务隔离