9 数据库

9.1 服务器中的数据库

Redis服务器将所有的数据库都保存在服务器状态redis.h/redisServer结构的db数组中,db数组的每个项都是一个redis.h/redisDb结构,每个redisDb结构代表一个数据库:

struct redisServer{
    //...

    // 一个数组,保存着服务器中的所有数据库
    redisDb *db;

    //...
};

在初始化服务器时,程序会根据服务器状态的dbnum属性来决定应该创建多少个数据库:

struct redisServer{
    //...

    // 服务器的数据库数量
    int dbnum;

    //...
};

dbnum属性的值由服务器配置的database选项决定,默认情况下,该选项的值为16,所以Redis服务器默认会创建16个数据库。

9.2 切换数据库

每个Redis客户端都有自己的目标数据库,每当客户端执行数据库写命令或者数据库读命令的时候,目标数据库就会成为这些命令的操作对象。
默认情况下,Redis客户端的目标数据库为0号数据库,客户端可以通过执行SELECT命令来切换目标数据库。
在服务器内部,客户端状态redisClient结构的db属性记录了客户端当前目标数据库,这个属性是一个指向redisDb结构的指针:

struct redisClient{
    //...

    // 记录着客户端当前正在使用的数据库
    redisDb *db;

    //...
}redisClient;

redisClient.db指针指向redisServer.db数据的其中一个元素,而被指向的元素就是客户端的目标数据库。
通过修改redisClient.db指针,让它指向服务器中的不同数据库,从而实现切换目标数据库的功能--这就是SELECT命令的实现原理。

9.3 数据库键空间

Redis是一个键值对(key-value pair)数据库服务器,服务器中的每个数据库都由一个redis.h/redisDb结构表示,其中,redisDb结构的dict字典保存了数据库中的所有键值对,我们将这个字典成为键值对的键空间(key space)

typedef struct redisDb{
    //...

    // 数据库键空间,保存着数据库中的所有键值对
    dict *dict;

    //...
}redisDb;

键空间和用户所见的数据库是直接对应的:

  • 键空间的键也就是数据库的键,每个键都是一个字符串对象。
  • 键空间的值也就是数据库的值,每个值可以是字符串对象、列表对象、哈希表对象、集合对象和有序集合对象中的任意一种Redis对象。

因为数据库的键空间是一个字典,所以所有针对数据库的操作,比如添加一个键值对到数据库,或者从数据库中删除一个键值对,又或者在数据库中获取某个键值对等,实际上都是通过对键空间字典进行操作来实现的。

9.3.1 添加新建

添加一个新键值对到数据库,实际上就是将一个新键值对添加到键空间字典里面,其中键位字符串对象,而值则为任意一种类型的Redis对象。

9.3.2 删除键

删除数据库中的一个键,实际上就是在键空间里面删除键所对应的键值对对象。

9.3.3 更新键

对一个数据库键进行更新,实际上就是对键空间里面的键所对应的值对象进行更新,根据值对象的类型不同,更新的具体方法也会有所不同。

9.3.4 对键取值

对一个数据库键进行取值,实际上就是在键空间中取出键所对应的值对象,根据值对象的类型不同,具体的取值方法也会有所不同。

9.3.5 其他键空间操作

除了添加、删除、更新、取值操作之外,还有很多针对数据库本身的Redis命令,也是通过对键空间进行处理来完成的。
例如FLUSHDBRANDOMAKEYDBSIZEEXISTSRENAMEKEYS等,这些命令都是通过对键空间进行操作来实现的。

9.3.6 读写建空间时的维护操作

当使用Redis命令对数据库进行读写时,服务器不仅会对键空间执行指定的读写操作,还会执行一些额外的维护操作,其中包括:

  • 在读取一个键之后(读操作和写操作都要对键进行读取),服务器会根据键是否存在来更新服务器的键空间命中(hit)次数或键空间不命中(miss)次数。
  • 在读取一个键之后,服务器会更新键的LRU(最后一次使用)时间,这个值可以用于计算键的空闲时间
  • 如果服务器在读取一个键时,发现该键已经过期,那么服务器会先删除这个过期键,然后才执行余下的其他操作
  • 如果有客户端使用WATCH命令监视了某个键,那么服务器在对被监视的键进行修改之后,会将这个键标记为脏(dirty),从而让事务程序注意到这个键已经被修改过。
  • 服务器每次修改一个键之后,都会对脏(dirty)键计数器的值增1,这个计数器会触发服务器的持久化以及复制操作。
  • 如果服务器开启了数据库通知功能,那么在对键进行修改之后,服务器将按配置发送响应的数据库通知。

9.4 设置键的生存时间活过期时间

通过EXPIRE命令或者PEXPIRE命令,客户端可以以秒或者毫秒精度为数据库中的某个键设置生存时间(Time To Live,TTL),在经过指定秒数或者毫秒数之后,服务器就会自动删除生生存时间为0的键:
EXPIRE命令和PEXPIRE命令类似,客户端可以通过EXPIREAT命令和PEXPIREAT命令,以秒或者毫秒精度给数据库中的某个键设置过期时间
TTL命令和PTTL命令接受一个带有生存时间或者过期时间的键,返回这个键剩余生存是时间,也就是,返回距离这个键被服务器自动删除还有多长时间:

9.4.1 设置过期时间

Redis有四个不同的命令可以用于设置键的生存时间(键可以存在多久)或过期时间(键什么时候会被删除):

  • EXPIRE <key><ttl>命令用于将键key的生存时间设置为ttl
  • PEXPIRE <key><ttl>命令用于将键key的生存时间设置为ttl毫秒
  • EXPIREAT <key><timestamp>命令用于将键key的生存时间设置为timestamp所指定的秒数时间戳
  • PEXPIREAT <key><timestamp>命令用于将键key的生存时间设置为timestamp所指定的毫秒数时间戳

虽然有多种不同单位和不同形式的设置命令,但实际上EXPIREPEXPIREEXPIREAT三个命令都是使用PEXPIREAT命令来实现的:

9.4.2 保存过期时间

redisDb结构的expires字典保存了数据库中所有键的过期时间,我们称这个字典为过期字典:

  • 过期字典的键是一个指针,这个指针指向键空间中的某个键对象(某个数据库键)
  • 过期字典的值是一个long long类型的整数,这个整数保存了键所指向的数据库键的过期时间--一个毫秒精度的UNIX时间戳。
typedef struct redisDb{
    //...

    // 过期字典,保存着键的过期时间
    dict *expires;

    //...
}redisDb;

一个数据库键设置过期时间时,服务器会在数据库的过期字典中关联给定的数据库键和过期时间。

9.4.3 移除过期时间

PERSIST命令可以移除一个键的过期时间
PERSIST命令就是PEXPIREAT命令的反操作:PERSIST命令在过期字典中查找给定的键,并解除键和值(过期时间)在过期字典中的关联。

9.4.4 计算并返回剩余生存时间

TTL命令以秒为单位返回键的剩余生存时间,而PTTL命令则以毫秒为单位返回键的剩余生存时间:
TTLPTTL两个命令都是通过计算键的过期时间和当前时间之间的差来实现的。

9.4.5 过期键的判定

通过过期字典,程序可以用一下步骤检查一个给定键是否过期:
1) 检查给定键是否存在于过期字典:如果存在,那么取得键的过期时间。
2) 检查当前UNIX时间戳是否大于键的过期时间:如果是的话,那么贱已经过期;否者的话,键未过期。

9.5 过期键删除策略

问题:如果一个键过期了,那么它什么时候会被删除呢?
这个问题有三种可能的答案,它们分别代表了三种不同的删除策略:

  • 定时删除:在设置键的过期时间的同时,创建一个定时器(timer),让定时器在键的过期时间来临时,立即执行对键的删除操作。
  • 惰性删除:放任键过期不管,但是每次从键空间中获取键时,都检查取得的键是否过期,如果过期的话,就删除该键;如果没有过期,就返回该键。
  • 定期删除:每隔一段时间,程序就对数据库进行一次检查,删除里面的过期键。只与要删除多少过期键,已经要检查多少个数据库,有算法决定

在这三种策略中,第一种和第三种为主动删除策略,第二种则为被动删除策略。

9.5.1 定时删除

定时删除策略对内存是最友好的:通过使用定时器,定时删除策略可以保证过期键会尽可能快的被删除,并释放过期键所占用的内存。
定时删除策略的缺点是,对CPU时间是最不友好的:在过期键比较多的情况下,删除过期键会占用相当一部分CPU时间,在内存不紧张但是CPU时间非常紧张的情况下,将CPU时间用在删除和当前任务无关的过期键删除上,无疑会对服务器的响应时间和吞吐量造成影响。

9.5.2 惰性删除

惰性删除策略对CPU时间来说是最友好的:程序只会在取出键时才对键进行过期检查,可以保证删除过期键的操作只会在费做不可的情况下进行,并且删除的目标仅限于当前处理的键,这个策略不会再删除其他无关的过期键上花费任何CPU时间。
惰性删除策略的缺点是,对内存是最不友好的:如果一个键已经过期,而这个键有仍然保留在数据库中,那么只要这个过期键不被删除,它所占用的内存就不会被释放。

9.5.3 定期删除

从上面来看,两种删除方式在单一使用时都有明显的缺陷:

  • 定时删除咱用了太多的CPU时间,影响服务器的响应时间和吞吐量。
  • 惰性删除浪费太多内存,有内存泄漏的危险

定期删除策略是前两种策略的一种整合和折中:

  • 定期删除策略每隔一段时间执行一次删除过期键操作,并通过限制删除操作执行的时长和频率来减少删除操作对CPU时间的影响。
  • 除此以外,通过定期删除过期键,定期删除策略有效的减少了因为过期键而带来的内存浪费。

定期删除的难点是确定删除操作执行的时长和频率

  • 如果删除操作执行的太过频繁,或者执行的时间太长,定期删除策略就会退化为定时删除策略。
  • 如果删除操作执行的太少,或者执行时间太短,定期删除策略又会和惰性删除策略一样。

9.6 Redis的过期键删除策略

Redis服务器实际使用的是惰性删除策略和定期删除策略两种策略:通过配合使用这两种删除策略,服务器可以很好的在合理使用CPU时间和避免浪费内存空间之间取得平衡。

9.6.1 惰性删除策略的实现

过期键的惰性删除策略由db.c/expireIfNeeded函数实现,所有读写数据库的Redis命令在执行之前都会调用expireIfNeeded函数对输入键进行检查:

  • 如果输入键已经过期,那么expireIfNeeded函数将输入键从数据库中删除
  • 如果输入键没有过期,那么expireIfNeeded函数不做动作。

命令调用expireIfNeeded来删除过期键

expireIfNeeded函数就想一个过滤器,它可以在命令真正执行之前,过滤掉过期的输入键,从而避免命令接触到过期键。
另外,因为每个被访问的键都可能因为过期而被expireIfNeeded函数删除,所以每个命令的实现函数都必须能同时处理键存在以及键不存在的这两种情况。

  • 当键存在时,命令按照键存在的情况执行
  • 当键不存在或者键因为过期而被expireIfNeeded函数删除时,命令按照键不存在的情况执行。

9.6.2 定期删除策略的实现

过期键的定期删除策略由redis.c/activeExpireCycle函数实现,每当Redis的服务器周期性操作redis.c/serverCron函数执行时,activeExpireCycle函数就会被调用,它在规定的时间内,分多次遍历服务器中的各个数据库,从数据库的expires字典中随机检查一部分键的过期时间,并删除其中的过期键。
activeExpireCycle函数的工作模式可以总结如下:

  • 函数每次运行时,都从一定数量的数据库中取出一定数量的随机键进行检查,并删除其中的过期键。
  • 全局变量current_db会记录当前activeExpireCycle函数检查的进度,并在下一次activeExpireCycle函数调用时,接着上一次的进度进行处理。
  • 随着activeExpireCycle函数的不断执行,服务器中的所有数据库都会被检查一遍,此时函数将current_db变量重置为0,然后再次开始新一轮的检查工作。

9.7 AOF、RDB和复制功能对过期键的处理

9.7.1 生成RDB文件

在执行SAVE命令或者BGSAVE命令创建一个新的RDB文件时,程序会对数据库中的键进行检查,已过期的键不会保存到新创建的RDB文件中。
因此,数据库中包含过期键不会对新生成的RDB文件造成影响。

9.7.2 载入RDB文件

在启动Redis服务器时,如果服务器开启了RDB功能,那么服务器将对RDB文件进行载入:

  • 如果服务器以主服务器模式运行,那么在载入RDB文件时,程序会对文件中保存的额键进行检查,未过期的键会被载入到数据库中,而过期键则会被忽略,所以过期键对载入RDB文件的主服务器不会造成影响。
  • 如果服务器以从服务器模式运行,那么在载入RDB文件时,文件中所保存的所有键,不论是否过期,都会被载入到数据库中。不过,因为主从服务器在进行数据同步的时候,从服务器的数据库就会被清空,所以一般来讲,过期键对载入RDB文件的从服务器也不会造成影响。

9.7.3 AOF文件写入

当服务器以AOF持久化模式运行时,如果数据库中的某个键已经过期,但它还没有被惰性删除或者定期删除,那么AOF文件不会因为这个过期键而产生任何影响。
当过期键被惰性删除或者定期删除之后,程序会向AOF文件追加一条DEL命令,来显示地记录该键已被删除。

9.7.4 AOF重写

和生成RDB文件时类似,在执行AOF重写的过程中,程序会对数据库中的键进行检查,已过期的键不会被保存到重写后的AOF文件中。
因此,数据库中包含过期键不会对AOF重写造成影响。

9.7.5 复制

当服务器运行在复制模式下时,从服务器的过期键删除动作由主服务器控制:

  • 主服务器在删除一个过期键之后,会显示的向所有从服务器发送一个DEL命令,告知从服务器删除这个过期键。
  • 从服务器在执行客户端发送的读命令时,即使喷到过期键也不会将过期键删除,而是继续想处理未过期键依赖来进行处理过期键。
  • 从服务器只有在接到主服务器发来的DEL命令之后,才会删除过期键

通过由主服务器来控制从服务器统一地删除过期键,可以保证主从服务器数据的一致性,也正是因为这个原因,当一个过期键仍然存在于主服务器的数据库时,这个过期键在从服务器里的复制品也会继续存在。

9.8 数据库通知

数据库通知功能可以让客户端通过订阅给定的频道或者模式,来获知数据库中键的变化,以及数据库中命令的执行情况。
这一类关注"某个键执行了什么命令"的通知称为键空间通知。除此之外,还有另一类称为键事件通知的通知,他们关注的是"某个命令被什么键执行了"。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,324评论 5 476
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,303评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,192评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,555评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,569评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,566评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,927评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,583评论 0 257
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,827评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,590评论 2 320
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,669评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,365评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,941评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,928评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,159评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,880评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,399评论 2 342