redis--数据库

除了说明数据库是如何储存数据对象之外，本章还会讨论键的过期信息是如何保存，而 Redis又是如何删除过期键的

 

数据库的结构

Redis 中的每个数据库，都由一个 redis.h/redisDb 结构表示：

 

typedef struct redisDb {     // 保存着数据库以整数表示的号码     int id;      // 保存着数据库中的所有键值对数据     // 这个属性也被称为键空间（ key space）     dict *dict;      // 保存着键的过期信息     dict *expires;      // 实现列表阻塞原语，如 BLPOP     // 在列表类型一章有详细的讨论     dict *blocking_keys;     dict *ready_keys;      // 用于实现 WATCH 命令     // 在事务章节有详细的讨论     dict *watched_keys;} redisDb; 

 

数据库的切换

redisDb 结构的 id 域保存着数据库的号码，

并不是给切换数据库的select 命令使用的，而是给redis 内部程序使用的。

 

比如说，给AOF程序，复制程序，RDB程序，需要知道当前数据库的号码。

 

数据库键空间

因为 Redis 是一个键值对数据库（ key-value pairs database），所以它的数据库本身也是一个字

典（俗称 key space）

• 字典的键是一个字符串对象。
• 字典的值则可以是包括字符串、 列表、 哈希表、 集合或有序集在内的任意一种Redis类型对象。

在 redisDb 结构的 dict 属性中，保存着数据库的所有键值对数据。

 

键值空间例子：

 

 

键空间的操作

因为数据库本身是一个字典，所以对数据库的操作基本上都是对字典的操作，

加上以下一些维护操作：

• 更新键的命中率和不命中率，这个值可以用 INFO 命令查看
• 更新键的 LRU 时间，这个值可以用 OBJECT 命令来查看；
• 删除过期键（稍后会详细说明）；
• 如果键被修改了的话，那么将键设为脏（用于事务监视），并将服务器设为脏（等待 RDB保存）
• 将对键的修改发送到 AOF 文件和附属节点，保持数据库状态的一致；

 

增删改查，实际上就是对字典空间的操作。

注意修改，是先释放原来的空间，新建空间的过程。

 

其他操作

• FLUSHDB 命令：删除键空间中的所有键值对。
• RANDOMKEY 命令：从键空间中随机返回一个键。
• DBSIZE 命令：返回键空间中键值对的数量。
• EXISTS 命令：检查给定键是否存在于键空间中。
• RENAME 命令：在键空间中，对给定键进行改名。

 

键的过期时间

EXPIRE 、PEXPIRE 、EXPIREAT 和 PEXPIREAT 四个命令，客户端可以给某个存

在的键设置过期时间，当键的过期时间到达时，键就不再可用：

 redis> SETEX key 5 valueOK redis> GET key"value" redis> GET key // 5 秒过后(nil) 命令 TTL 和 PTTL 则用于返回给定键距离过期还有多长时间： redis> SETEX key 10086 valueOK redis> TTL key(integer) 10082 redis> PTTL key(integer) 10068998 

 

过期时间的保存

在数据库中，所有键的过期时间都被保存在 redisDb 结构的 expires 字典里：

typedef struct redisDb {// ...dict *expires;// ...} redisDb; 

 

expires 字典的键是一个指向 dict 字典（键空间）里某个键的指针，

而字典的值则是键所指向的数据库键的到期时间，这个值以long long类型表示。

 

设置生存时间

 

Redis 有四个命令可以设置键的生存时间（可以存活多久）和过期时间（什么时候到期）：
• EXPIRE 以秒为单位设置键的生存时间；
• PEXPIRE 以毫秒为单位设置键的生存时间；
• EXPIREAT 以秒为单位，设置键的过期 UNIX 时间戳；

• PEXPIREAT 以毫秒为单位，设置键的过期 UNIX 时间戳。

 

虽然有不同形式的设置方式，但expires字典的值值保存以毫秒为单位的过期UNIX时间戳，

这就是说，通过转换后，所有命令的效果最后都和pexpireat命令的效果一样。

 

例子：

从expire命令到pexpireat 命令的转换可以用一下伪代码表示：

 def EXPIRE(key, sec):     # 将 TTL 从秒转换为毫秒     ms = sec_to_ms(sec)      # 获取以毫秒计算的当前 UNIX 时间戳     ts_in_ms = get_current_unix_timestamp_in_ms()      # 毫秒 TTL 加上毫秒时间戳，就是 key 到期的时间戳     PEXPIREAT(ms + ts_in_ms, key) 

 

过期键的判定

通过 expires 字典，可以用以下步骤检查某个键是否过期：

1. 检查键是否存在于 expires 字典：如果存在，那么取出键的过期时间；

2. 检查当前 UNIX 时间戳是否大于键的过期时间：如果是的话，那么键已经过期；否则，键未过期

 

过期键的删除

• 定时删除
  • 在设置键的过期时间时，创建一个定时事件，当过期时间到达时，由事件处理器自动执行键的删除操作。
  • 优点
    • 定时删除策略对内存是最友好的：
    • 因为它保证过期键会在第一时间被删除，过期键所消耗的内存会立即被释放。
  • 缺点
    • 它对 CPU 时间是最不友好的：
    • 因为删除操作可能会占用大量的CPU时间，
    • 每设置一个过期时间，就会产生一个定时事件，CPU就需要处理这个定时事件
    • 此外，Redis事件处理器对时间事件的实现方式---无序表，查找一个时间复杂度为O(N)
      • 并不适合用来处理大量时间事件
• 惰性删除
  • 放任键过期不管，但是在每次从dict字典中取出键值时，要检查键是否过期，如果过期的话，就删除它，并返回空；如果没过期，就返回键值。
  • 优点
    • 对CPU时间来说是最友好的：
    • 它只会在取出键时进行检查，这可以保证删除操作只会在非做不可的情况下进行
    • 并且删除的目标仅限于当前处理的键，这个策略不会在删除其他无关的过期键上花费任何 CPU 时间
  • 缺点
    • 对内存是最不友好的：
    • 如果一个键已经过期，而这个键又仍然保留在数据库中，内存不会被释放
• 定期删除
  • 每隔一段时间，对expires字典进行检查，删除里面的过期键。
  • 是前两种方案的折中选择：
    • 它每隔一段时间执行一次删除操作，
      • 并通过限制删除操作执行的时长和频率，籍此来减少删除操作对CPU时间的影响。
    • 另一方面，通过定期删除过期键，它有效地减少了因惰性删除而带来的内存浪费

 

redis使用，惰性删除加上定期删除，这两个策略相互配合，可以在合理利用CPU时间和节约内存空间之间取得平衡。

 

定期删除策略的过程

 

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

def activeExpireCycle():

     # 遍历数据库（不一定能全部都遍历完，看时间是否足够）

     for db in server.db:

  

          # MAX_KEY_PER_DB 是一个 DB 最大能处理的 key 个数

          # 它保证时间不会全部用在个别的 DB 上（避免饥饿）

          i = 0

          while (i < MAX_KEY_PER_DB):

  

               # 数据库为空，跳出 while ，处理下个 DB

               if db.is_empty(): break

  

               # 随机取出一个带 TTL 的键

               key_with_ttl = db.expires.get_random_key()

  

               # 检查键是否过期，如果是的话，将它删除

               if is_expired(key_with_ttl):

                    db.deleteExpiredKey(key_with_ttl)

                    

               # 当执行时间到达上限，函数就返回，不再继续

               # 这确保删除操作不会占用太多的 CPU 时间

               if reach_time_limit(): return

               

               i += 1

　　

过期键对AOF，RDB和复制的影响

过期键会被保存在更新后的 RDB 文件、 AOF 文件或者重写后的 AOF 文件里面吗？

附属节点会会如何处理过期键？处理的方式和主节点一样吗？

 

更新后的RDB文件

• 在创建新的 RDB 文件时，程序会对键进行检查，过期的键不会被写入到更新后的 RDB 文件中。
• 因此，过期键对更新后的 RDB 文件没有影响。

 

AOF 文件

• 在键已经过期，但是还没有被惰性删除或者定期删除之前，这个键不会产生任何影响，AOF 文件也不会因为这个键而被修改。
• 当过期键被惰性删除、或者定期删除之后，程序会向 AOF 文件追加一条 DEL 命令，来显式地记录该键已被删除。

 

例子：GET message 试图访问message 键值，但message已经过期

服务器执行三个动作：

• 从数据库中删除message
• 追加一条DEL message 命令到AOF文件
• 向客户端返回 NTL

 

AOF 重写

和 RDB 文件类似，当进行 AOF 重写时，程序会对键进行检查，过期的键不会被保存到重写后的 AOF 文件

因此，过期键对重写后的 AOF 文件没有影响。

 

复制

当服务器带有附属节点时，过期键的删除由主节点统一控制：

• 如果服务器是主节点，那么它在删除一个过期键之后，会显式地向所有附属节点发送一个 DEL 命令。
• 如果服务器是附属节点，那么当它碰到一个过期键的时候，它会向程序返回键已过期的回复，但并不真正的删除过期键。
  • 因为程序只根据键是否已经过期、而不是键是否已经被删除来决定执行流程，
  • 所以这种处理并不影响命令的正确执行结果。
  • 当接到从主节点发来的DEL命令之后，附属节点才会真正的将过期键删除掉。

 

数据库空间的收缩和扩展

 

tryResizeHashTables 函数的完整定义如下：

 

/** 对服务器中的所有数据库键空间字典、以及过期时间字典进行检查，* 看是否需要对这些字典进行收缩。*** 如果字典的使用空间比率低于 REDIS_HT_MINFILL* 那么将字典的大小缩小，让 USED/BUCKETS 的比率 <= 1*/void tryResizeHashTables(void) {     int j;         for (j = 0; j < server.dbnum; j++) {          // 缩小键空间字典          if (htNeedsResize(server.db[j].dict))               dictResize(server.db[j].dict);                // 缩小过期时间字典               if (htNeedsResize(server.db[j].expires))                    dictResize(server.db[j].expires);     }}