Redis设计与实现2.1:数据库和事件
数据库和事件
这是《Redis设计与实现》系列的文章,系列导航:Redis设计与实现笔记
数据库
数据库的结构定义在 redis.h/redisServer
这个结构体中,这个结构体有许多的字段用以记录 Redis 数据库的状态。学习数据库的过程中会慢慢地接触这里面的各种字段。
struct redisServer {
//...
}
不同的数据库
在上述结构中, int dbnum
保存了数据库的数量,默认为16;redisDb *db
指向了服务器中所有的数据库(如下 1
处)
而客户端 redisClient
中也有一个 redisDB *db
指向当前选用的数据库(如 2
处)。
我们可以用 SELECT N
来选择第 N 个数据库,但是一般并不推荐用多个数据库,因为 Redis 没有命令可以获取当前用的是哪个数据库,这样会容易造成使用错数据库的尴尬场景。
数据库中的数据
Redis 是一个键值对的数据库服务器,服务器的每一个数据库都由一个 redis.h/redisDB
结构表示,该结构中的 dict
字典保存了数据库中的所有键值对,我们称这个字典为键空间:
typedef struct redisDb {
//...
dict *dict;
//...
}redisDb;
键空间保存了所有对象,键一般为字符串名称,而值则对应各种类型的对象,如:
针对这些键值对,可以进行各种增删改查的操作。
另外,其他的一些命令如EXISTS
、RENAME
、KEYS
、FLUSHDB
、RANDOMKEY
、DBSIZE
都是通过对键空间进行操作来实现的。
读写键空间时的维护操作:
- 更新服务器中键空间命中和不命中的次数
- 更新键的LRU时间
- 如果服务器在读取一个键时发现已经过期,则会先删除这个键,再执行余下的操作
- 如果有客户端使用WATCH监视了某个键,那么服务器在对被监视的键进行修改后,会将这个键标记为脏,从而让事务程序注意到这个键已经被修改了
- 服务器修改一个键,都会对脏键计数器的值 + 1,这个计数器会触发服务器的持久化以及复制操作
- 如果开启了通知,会按照配置发送相应的数据库通知
超时管理
可以通过
EXPIRE
、PEXPIRE
、EXPIREAT
、PEXPIREAT
来设置过期的剩余时间或时间。这几种的命令都是通过
PEXPIREAT
来实现的。
保存过期时间
redisDb 结构的 expires 字典保存了数据库中所有键的过期时间,称之为过期字典。
过期字典的键为一个指针,指向键空间某个键对象;
过期字典的值为 long long 类型的整数,保存了所有键所指向的数据库键的过期时间。
一个结构图:
给键的过期时间进行增删改查就相当于对这个字典进行增删改查,很容易想到如何做,就不多赘述了。
过期删除策略
三种常见过期删除策略:
- 定时删除:在设置过期时间的同时设置定时器,让定时器执行删除
- 惰性删除:查询时才判断是否过期及删除
- 定期删除:每隔一段时间对数据库进行检查,删除其中的过期键
对比:
策略 优点 缺点 定时删除 对内存友好 对CPU不友好 惰性删除 对CPU友好 对内存不友好,不访问就不释放了 定期删除 是前两种的折中 需要合理配置参数
Redis 服务器实际使用的是惰性删除和定期删除两种策略。
其中惰性删除由 db.c/expireIfNeeded
函数实现,所有读写数据库的 Redis 命令在执行之前都会调用其对输入键进行检查。
定期删除由 redis.c/activeExpireCycle
函数实现,每当 Redis 的服务器周期性操作 redis/serverCron
函数执行时,这个函数就会被调用,它在规定的时间内,分多次遍历服务器中的各个数据库,从数据库的 expires 字典中随机检查一部分键的过期时间,并删除其中的过期键。
对备份的影响
RDB:
- 创建时,会对数据库中的键进行检查,已过期的键不会被保存到新创建的 RDB 文件中。
- 导入时,如果是以主服务器模式运行,则忽略过期键;
如果是以从服务器模式运行,则不论是否过期全部导入。
AOF:
- 如果数据库中某个键过期了但没有被删除,则什么都不做
- 如果过期了且被删除了,就在AOF文件中追加一条 DEL 命令
- AOF重写时,会过滤掉过期的键
对主从复制的影响
复制模式下,从服务器的删除由主服务器控制:
- 主服务器过期,则分发 DEL 命令
- 从服务器过期,不会将过期键删除,而是像没过期一样处理过期键
由主服务器控制删除,可以保证主从数据一致性。
通知功能
通知功能可以让客户端通过订阅给定的频道或者模式,来获知数据库中键的变化。
通知分为:
- 键空间通知:某个键执行了什么命令
- 键事件通知:某个命令什么时候被执行
通过配置 notify-keyspace-events
来决定服务器所发送通知的类型:
- AKE:空间 + 事件
- AK:空间
- AE:事件
- K$:只发送和字符串键相关的键空间通知
- El:只发送和列表键相关的键事件通知
(这里只是列举部分,具体用法请参阅文档)
发送通知
void notifyKeyspaceEvent(int type, char *event, robj *key, int dbid);
type 是类型,程序根据这个值和前面的配置进行对比以确定是否发送通知。
剩下的三个分别是事件的名称、产生事件的键、产生事件的数据库号码,函数会根据这三个参数来构建通知的内容和接收通知的频道名称。
例如 SADD 命令的实现函数中发送通知的相关代码:
void saddCommand(redisClient *c) {
// ...
if (added) {
notifyKeyspaceEvent(REDIS_NOTIFY_SET, "sadd", c->argv[1], c->db-id);
}
// ...
}
发送通知的实现
当调用 pubsubPublishMessage
发送通知后,订阅数据库通知的客户端就会收到这个消息。
事件
Redis是一个事件驱动程序,服务器需要处理以下两类事件:
- 文件事件:主要是和套接字(也就是网络)有关的事件
- 时间事件:
serverCron
等需要在特定的时间执行
文件事件
Redis 基于 Reactor 模式 开发了自己的网络事件处理器,称为文件事件处理器:
- 使用 I/O 多路复用程序 来同时监听多个套接字
- 当被监听的套接字准备好执行连接应答、读取、写入、关闭等操作时,与操作相关的文件事件就会产生,文件事件处理器就会调用关联的事件处理器进行处理
虽然文件事件处理器以单线程方式运行,但通过使用 I/O多路复用程序 来监听多个套接字,文件事件处理器既实现了高性能的网络通信模型,又可以很好地与Redis服务器中其他同样以单线程方式运行的模块进行对接,这保持了Redis内部单线程设计的简单性。
上述内容牵扯到了网络编程的相关知识,等我学完相关部分再来补充!
构成
四个部分:
- 套接字
- I/O多路复用程序
- 文件事件分派器
- 事件处理器
尽管多个文件事件可能并发发生,但是IO多路复用程序会把他们全放入一个队列里,让文件时间分派器依次处理。
实现
通过包装常见的select
、epoll
、evport
、kqueue
这些I/O多路复用函数库来实现。
因为 Redis 为每个 I/O多路复用函数库都实现了相同的 API,所以这些程序的底层实现是可以互换的。
程序会在编译时自动选择系统中性能最高的 I/O多路复用函数库来作为 Redis 的 I/O多路复用程序的底层实现。
事件类型
- AE_READABLE:当套接字变得可读,如客户端执行 write、close操作,或者有了新的可应答套接字时产生
- AE_WRITABLE:当套接字变得可写,如客户端执行了 read 操作时产生
如果一个套接字即可读又可写,那么先读后写。
文件事件处理器
- 连接应答处理器:对连接服务器的各个客户端进行应答
- 命令请求处理器:接收客户端传来的命令请求
- 命令回复处理器:向客户端返回命令的执行结果
- 复制处理器:主从服务器进行复制时为复制功能关联
时间事件
时间事件分为:
- 定时事件
- 周期性事件
一个时间事件的组成:
-
id
-
when:UNIX时间戳,记录事件到达时间
-
timeProc:时间事件处理器,一个函数,时间事件到达时执行
根据这个函数的返回值是
ae.h/AE_NOMORE
或整数值来判断是周期事件还是定时事件。
实现
用无序链表保存所有事件,每当时间事件执行器运行时,他就遍历整个链表(因为无序),查找可以执行的事件。
serverCron函数
这个函数在前面和之后都会反复提到,它负责对 Redis 自身的资源和状态进行检查和调整,具体职责包括:
- 更新服务器的各种统计信息,比如时间、内存占用、数据库占用情况等
- 清理数据中的过期键值对
- 关闭和清理连接失效的客户端
- 尝试进行持久化操作
- 如果是主服务器,则对从服务器进行定期的同步
- 如果处于集群模式,对集群进行定期同步和连接测试
事件的调度和执行
Redis 主函数的逻辑和伪代码:
说明如下(摘自原文):
aeApiPoll
函数的最大阻塞时间由到达时间最接近当前时间的时间事件决定,这个方法既可以避免服务器对时间事件进行频繁的轮询(忙等待),也可以确保aeApiPoll函数不会阻塞过长时间。- 因为文件事件是随机出现的,如果等待并处理完一次文件事件之后,仍未有任何时间事件到达,那么服务器将再次等待并处理文件事件。随着文件事件的不断执行,时间会逐渐向时间事件所设置的到达时间逼近,并最终来到到达时间,这时服务器就可以开始处理到达的时间事件了。
- 对文件事件和时间事件的处理都是同步、有序、原子地执行的,服务器不会中途中断事件处理,也不会对事件进行抢占,因此,不管是文件事件的处理器,还是时间事件的处理器,它们都会尽可地减少程序的阻塞时间,并在有需要时主动让出执行权,从而降低造成事件饥饿的可能性。比如说,在命令回复处理器将一个命令回复写人到客户端套接字时,如果写入字节数超过了一个预设常量的话,命令回复处理器就会主动用break跳出写人循环,将余下的数据留到下次再写;另外,时间事件也会将非常耗时的持久化操作放到子线程或者子进程执行。
- 因为时间事件在文件事件之后执行,并且事件之间不会出现抢占,所以时间事件的实际处理事件通常会晚一点。
(由于这一段高度概括,之后看源码再仔细学习)