IT序号网

redis--数据库知识解答

sanshao 2021年06月13日 数据库 152 0
数据库

 
除了说明数据库是如何储存数据对象之外,本章还会讨论键的过期信息是如何保存,而 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 value 
OK 
  
redis> GET key 
"value" 
  
redis> GET key // 5 秒过后 
(nil) 
  
命令 TTL 和 PTTL 则用于返回给定键距离过期还有多长时间: 
  
redis> SETEX key 10086 value 
OK 
  
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时间和节约内存空间之间取得平衡。
 
定期删除策略的过程
 
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); 
     } 
} 
 
小结
    • 数据库主要由 dict 和 expires 两个字典构成,其中 dict 保存键值对,而 expires 则保存键的过期时间。
    • 数据库的键总是一个字符串对象,而值可以是任意一种 Redis 数据类型,包括字符串、哈希、集合、列表和有序集。
    • expires 的某个键和 dict 的某个键共同指向同一个字符串对象,而 expires 键的值则是该键以毫秒计算的 UNIX 过期时间戳。
    • Redis 使用惰性删除和定期删除两种策略来删除过期的键。
    • 更新后的 RDB 文件和重写后的 AOF 文件都不会保留已经过期的键。
    • 当一个过期键被删除之后,程序会追加一条新的 DEL 命令到现有 AOF 文件末尾。
    • 当主节点删除一个过期键之后,它会显式地发送一条 DEL 命令到所有附属节点。
      • 附属节点即使发现过期键,也不会自作主张地删除它,而是等待主节点发来 DEL 命令,
      • 这样可以保证主节点和附属节点的数据总是一致的。
    • 数据库的 dict 字典和 expires 字典的扩展策略和普通字典一样。
      • 它们的收缩策略是:当节点的填充百分比不足 10% 时,将可用节点数量减少至大于等于当前已用节点数量。

发布评论
IT序号网

微信公众号号:IT虾米 (左侧二维码扫一扫)欢迎添加!

redis-慢查询日志知识解答
你是第一个吃螃蟹的人
发表评论

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。