前言
只有光头才能变强
今天继续来学习Redis,上一篇从零单排学Redis【青铜】已经将Redis常用的数据结构过了一遍了。如果还没看的同学可以先去看一遍再回来~
这篇主要讲的内容有:
- Redis服务器的数据库
- Redis对过期键的处理
- Redis持久化策略(RDB和AOF)
本文力求简单讲清每个知识点,希望大家看完能有所收获
一、Redis服务器中的数据库
我们应该都用过MySQL,MySQL我们可以在里边创建好几个库:
MySQL创建几个数据库
同样地,Redis服务器中也有数据库这么一个概念。如果不指定具体的数量,默认会有16个数据库。
通过SELECT命令可以切换到0~15的数据库
上面的命令我们也可以发现:当切换到15号数据库,存进15号库的数据,再切换到0号数据库时,是获取不到的!
- 这说明,数据库与数据库之间的数据是隔离的。
1.1Redis数据库的原理
Redis服务器用redisServer结构体来表示,其中redisDb是一个数组,用来保存所有的数据库,dbnum代表数据库的数量(这个可以配置,默认是16)
struct redisServer{ //redisDb数组,表示服务器中所有的数据库 redisDb *db; //服务器中数据库的数量 int dbnum; };
我们知道Redis是C/S结构,Redis客户端通过redisClient结构体来表示:
typedef struct redisClient{ //客户端当前所选数据库 redisDb *db; }redisClient;
Redis客户端连接Redis服务端时的示例图:
Redis客户端连接Redis服务端时的示例图
Redis中对每个数据库用redisDb结构体来表示:
typedef struct redisDb { int id; // 数据库ID标识 dict *dict; // 键空间,存放着所有的键值对 dict *expires; // 过期哈希表,保存着键的过期时间 dict *watched_keys; // 被watch命令监控的key和相应client long long avg_ttl; // 数据库内所有键的平均TTL(生存时间) } redisDb;
从代码上我们可以发现最重要的应该是dict *dict
,它用来存放着所有的键值对。对于dict
数据结构(哈希表)我们在上一篇也已经详细说了。一般我们将存储所有键值对的dict
称为键空间。
键空间示意图:
键空间示意图
Redis的数据库就是使用字典(哈希表)来作为底层实现的,对数据库的增删改查都是构建在字典(哈希表)的操作之上的。
例如:
redis > GET message "hello world"
查找键的示意图
1.2键的过期时间
Redis是基于内存,内存是比较昂贵的,容量肯定比不上硬盘的。就我们现在一台普通的机子,可能就8G内存,但硬盘随随便便都1T了。
因为我们的内存是有限的。所以我们会干掉不常用的数据,保留常用的数据。这就需要我们设置一下键的过期(生存)时间了。
- 设置键的生存时间可以通过
EXPIRE
或者PEXPIRE
命令。 - 设置键的过期时间可以通过
EXPIREAT
或者PEXPIREAT
命令。
其实EXPIRE
、PEXPIRE
、EXPIREAT
这三个命令都是通过PEXPIREAT
命令来实现的。
我们在redisDb结构体中还发现了dict *expires;
属性,存放所有键过期的时间。
举个例子基本就可以理解了:
redis > PEXPIREAT message 1391234400000 (integer) 1
设置了message键的过期时间为1391234400000
新增一个过期时间的键
既然有设置过期(生存)时间的命令,那肯定也有移除过期时间,查看剩余生存时间的命令了:
- PERSIST(移除过期时间)
- TTL(Time To Live)返回剩余生存时间,以秒为单位
- PTTL以毫秒为单位返回键的剩余生存时间
1.2.1过期策略
上面我们已经能够了解到:过期键是保存在哈希表中了。那这些过期键到了过期的时间,就会立马被删除掉吗??
要回答上面的问题,需要我们了解一下删除策略的知识,删除策略可分为三种
- 定时删除(对内存友好,对CPU不友好)
- 到时间点上就把所有过期的键删除了。
- 惰性删除(对CPU极度友好,对内存极度不友好)
- 每次从键空间取键的时候,判断一下该键是否过期了,如果过期了就删除。
- 定期删除(折中)
- 每隔一段时间去删除过期键,限制删除的执行时长和频率。
Redis采用的是惰性删除+定期删除两种策略,所以说,在Redis里边如果过期键到了过期的时间了,未必被立马删除的!
1.2.2内存淘汰机制
如果定期删除漏掉了很多过期key,也没及时去查(没走惰性删除),大量过期key堆积在内存里,导致redis内存块耗尽了,咋整?
我们可以设置内存最大使用量,当内存使用量超出时,会施行数据淘汰策略。
Redis的内存淘汰机制有以下几种:
内存淘汰机制
一般场景:
使用 Redis 缓存数据时,为了提高缓存命中率,需要保证缓存数据都是热点数据。可以将内存最大使用量设置为热点数据占用的内存量,然后启用allkeys-lru淘汰策略,将最近最少使用的数据淘汰
二、Redis持久化
Redis是基于内存的,如果不想办法将数据保存在硬盘上,一旦Redis重启(退出/故障),内存的数据将会全部丢失。
- 我们肯定不想Redis里头的数据由于某些故障全部丢失(导致所有请求都走MySQL),即便发生了故障也希望可以将Redis原有的数据恢复过来,这就是持久化的作用。
Redis提供了两种不同的持久化方法来讲数据存储到硬盘里边:
- RDB(基于快照),将某一时刻的所有数据保存到一个RDB文件中。
- AOF(append-only-file),当Redis服务器执行写命令的时候,将执行的写命令保存到AOF文件中。
2.1RDB(快照持久化)
RDB持久化可以手动执行,也可以根据服务器配置定期执行。RDB持久化所生成的RDB文件是一个经过压缩的二进制文件,Redis可以通过这个文件还原数据库的数据。
RDB文件还原数据
有两个命令可以生成RDB文件:
SAVE
会阻塞Redis服务器进程,服务器不能接收任何请求,直到RDB文件创建完毕为止。BGSAVE
创建出一个子进程,由子进程来负责创建RDB文件,服务器进程可以继续接收请求。
Redis服务器在启动的时候,如果发现有RDB文件,就会自动载入RDB文件(不需要人工干预)
- 服务器在载入RDB文件期间,会处于阻塞状态,直到载入工作完成。
除了手动调用SAVE
或者BGSAVE
命令生成RDB文件之外,我们可以使用配置的方式来定期执行:
在默认的配置下,如果以下的条件被触发,就会执行BGSAVE
命令
save 900 1 #在900秒(15分钟)之后,至少有1个key发生变化, save 300 10 #在300秒(5分钟)之后,至少有10个key发生变化 save 60 10000 #在60秒(1分钟)之后,至少有10000个key发生变化
原理大概就是这样子的(结合上面的配置来看):
struct redisServer{ // 修改计数器 long long dirty; // 上一次执行保存的时间 time_t lastsave; // 参数的配置 struct saveparam *saveparams; };
遍历参数数组,判断修改次数和时间是否符合,如果符合则调用besave()
来生成RDB文件
Redis服务器的状态
总结:通过手动调用SAVE
或者BGSAVE
命令或者配置条件触发,将数据库某一时刻的数据快照,生成RDB文件实现持久化。