1. 服务器中的数据库
Redis 服务器将所有数据库都保存在服务器状态 redis.h/redisServer 结构的 db 数组中, db 数组的每个项都是一个 redis.h/redisDb 结构, 每个 redisDb 结构代表一个数据库。在初始化服务器时, 程序会根据服务器状态的 dbnum 属性来决定应该创建多少个数据库,默认为 16。如图 9- 所示:
1 | struct redisServer { |
2. 切换数据库
每个 Redis 客户端都有自己的目标数据库, 每当客户端执行数据库写和令或者数据库读命令的时候,目标数据库就会成为这些命令的操作对象。
默认情况下, Redis客户端的目标数据库为 0 号数据库, 但客户端可以通过执行 SELECT 命令来切换目标数据库。
在服务器内部, 客户端状态 redisClient 结构的 db 属性记录了客户端当前的目标数据库, 这个属性是一个指向 redisDb 结构的指针:
1 | typedef struct redisClient { |
比如说, 如果某个客户端的目标数据库为 1 号数据库, 那么这个客户端所对应的客户端状态和服务器状态之间的关系如图9-2所示。
3. 数据库键空间
Redis 是一个键值对 (key-value Pair) 数据库服务器, 服务器中的每个数据库都由一个 redis.h/redisDb 结构表示, 其中, redisDb 结构的 dict 字典保存了数据库中的所有键值对, 我们将这个字典称为键空间(key space):
1 | typedef struct redisDb { |
键空间和用户所见的数据库是直接对应的:
- 键空间的键也就是数据库的键,每个键都是一个字符串对象。
- 键空间的值也就是数据库的值,每个值可以是字符串对象、列表对象、哈希表对象等
示例如下:
4. 设置键的生存时间或过期时间
4.1 设置过期时间
Redis 有四个不同的命令可以用于设置键的生存时间 (键可以存在多久) 或过期时间 (键什么时候会被删除):
EXPIRE <key> <ttl> 命令用于将键 key 的生存时间设置为 ttl 秒,即 ttl 秒后过期。
PEXPIRE <key> <ttl> 命令用于将键 key 的生存时间设置为 ttl 毫秒,即 ttl 毫秒后过期。
EXPIREAT <key> <timestamp> 命令用于将键 key 的过期时间设置为 timestamp,即在 timestamp 秒数时间戳到来时过期。
PEXPIREAT <key> <timestamp> 命令用于将键 key 的过期时间设置为 timestamp 所指定的毫秒数时间戳,即在 timestamp 毫秒数时间戳到来时过期。
4.2 保存过期时间
redisDb 结构的 expires 字典保存了数据库中所有键的过期时间, 我们称这个字典为过期字典:
- 过期字典的键是一个指针, 这个指针指向键空间中的某个键对象 (也即是某个数据库键)。
- 过期字典的值是一个long long 类型的整数, 这个整数保存了键所指向的数据库键的过期时间,一个毫秒精度的UNIX时间戳。
1 | typedef struct redisDb { |
示例如下:
5. 过期键删除策略
5.1 定时删除
定时删除策略对内存是最友好的: 通过使用定时器, 定时删除策略可以保证过期键会尽可能快地被删除, 并释放过期键所占用的内存。另一方面, 定时删除策略的缺点是,它对CPU时间是最不友好的:在过期键比较多的情况下、删除过期键这一行为可能会占用相当一部分CPU时间,在内存不紧张但是CPU时间非常紧张的情况下,将CPU时间用在删除和当前任务无关的过期键上,无疑会对服务器的响应时间和吞吐量造成影响。
5.2 惰性删除
惰性删除策略对CPU时间来说是最友好的:程序只会在取出键时才对键进行过期检查,这可以保证删除过期键的操作只会在非做不可的情况下进行,并且删除的目标仅限于当前处理的键,这个策略不会在删除其他无关的过期键上花费任何CPU时间。惰性删除策略的缺点是,它对内存是最不友好的:如果一个键已经过期,而这个键又仍然保留在数据库中,那么只要这个过期键不被删除,它所占用的内存就不会释放。
5.3 定期删除
定期删除策略是前两种策略的一种整合和折中: 定期删除策略每隔一段时间执行一次删除过期键操作,并通过限制删除操作执行的时长和频率来减少删除操作对CPU时间的影响。除此之外,通过定期删除过期键,定期删除策略有效地减少了因为过期键而带来的内存浪费。
定期删除策略的难点是确定删除操作执行的时长和频率:如果删除操作执行得太频繁,或者执行的时间太长,定期删除策略就会退化成定时删除策略,以至于将CPU时间过多地消耗在删除过期键上面。如果删除操作执行得太少,或者执行的时间太短,定期删除策略又会和惰性删除策略一样,出现浪费内存的情况。
6. Redis 的过期删除策略
Redis服务器实际使用的是惰性删除和定期删除两种策略: 通过配合使用这两种删除策略,服务器可以很好地在合理使用CPU时间和避免浪费内存空间之间取得平衡。
6.1 惰性删除的实现
过期键的惕性删除策略由db.c/expireIfNeeded函数实现,所有读写数据库的 Redis和令在执行之前都会调用expireIfNeeded函数对输人键进行检查,过程如图 9-15 所示:
另外,因为每个被访问的键都可能因为过期而被expireIfNeeded函数删除,所以每个命令的实现函数都必须能同时处理键存在以及键不存在这两种情况:
- 当键存在时,命令按照键存在的情况执行。
- 当键不存在或者键因为过期而被expireIfNeeded函数删除时,命令按照键不存在的情况执行。
举个例子,图9-16展示了GET命令的执行过程,在这个执行过程中,命令需要判断键是否存在以及键是否过期,然后根据判断来执行合适的动作。
7. AOF、RDB 和复制功能对过期键的处理
7.1 生成 RDB 文件
在执行 SAVE 命令或者 BGSAVE 命令创建一个新的RDB文件时,程序会对数据库中的键进行检查,已过期的键不会被保存到新创建的RDB文件中。
7.2 载入 RDB 文件
在启动Redis服务器时,如果服务器开启了RDB功能,那么服务器将对RDB文件进行载入:
- 如果服务器以主服务器模式运行,那么在载人RDB文件时,程序会对文件中保存的键进行检查,未过期的键会被载人到数据库中,而过期键则会被忽略,所以过期键对载人RDB文件的主服务器不会造成影响。
- 如果服务器以从服务器模式运行,那么在载人RDB文件时,文件中保存的所有键,不论是否过期,都会被载入到数据库中。不过,因为主从服务器在进行数据同步的时候,从服务器的数据库就会被清空,所以一般来讲,过期键对载入RDB文件的从服务器也不会造成影响。
7.3 AOF 文件写入
当服务器以AOF持久化模式运行时,如果数据库中的某个键已经过期,但它还没有被惰性删除或者定期删除,那么AOF文件不会因为这个过期键而产生任何影响。
当过期键被惰性删除或者定期删除之后,程序会向AOF文件追加(append)一条DEL命令,来显式地记录该键已被删除。
7.4 AOF 重写
和生成RDB文件时类似,在执行AOF重写的过程中,程序会对数据库中的键进行检查,已过期的键不会被保存到重写后的AOF文件中。
7.5 复制
当服务器运行在复制模式下时,从服务器的过期键删除动作由主服务器控制:
- 主服务器在删除一个过期键之后,会显式地向所有从服务器发送一个DEL命令,告知伊服务器删除这个过期键。
- 从服务器在执行客户端发送的读命令时,即使碰到过期键也不会将过期键删除,而是继续像处理未过期的键一样来处理过期键。
- 从服务器只有在接到主服务器发来的DEL命令之后,才会删除过期键。