Redis数据库原理深入刨析

1.服务器和客户端实现的数据库

 Redis服务器在启动时，会根据redis.conf文件的中databases xx这个配置决定创建多少个数据库（默认配置是16），启动后默认使用的0号数据库，当然可以使用select dbnum这个命令来切换。需要注意的是在redis集群模式下，只有0号数据库可以用，是无法切换到其他库的。

 Redis服务器会将所有的数据库都保存在服务器状态的redisServer的db数组中，数组的每一项都代表了一个数据库，用redisDb结构来表示，首先看一下redisServer.db的源码：

struct redisServer {
	...
	// 代表数据库的数组
    redisDb *db;
    // 这个记录的配置文件中数据库的数量
	int dbnum;  
    ...
}

 我们通过客户端向Redis写入的任何数据都会记录到这个db数组中，根据前面描述，我们知道可以通过select命令切换到另一个目标数据库，但是客户端是怎么记录的它当前操作的哪个数据库呢？我们继续看一下源码：

typedef struct client {
    ...
    // 指针指向当前客户端正在操作的数据库
    redisDb *db;            
	...
} client;

 看，在client客户端状态中，有一个db指针，指向了server.db数组中的某一项，代表了当前客户端正在操作的数据库。所以通过切换client.db的指针，调整客户端操作的数据库，这就是select命令的实现原理。

2.数据库字典的实现

 Redis是支持key-value键值对存储的，这其实是通过dict结构来实现的，在前面讲到的内容中，服务器和客户端都指向了一个redisDb的结构，在这个db结构中，就包含存储了键值对的字典结构，首先看一下源码：

typedef struct redisDb {
	...
	// 这个存放的就是键值对
    dict *dict;                 
    // 这个存放的是键值对的过期时间，下面一节会说到
    dict *expires;              
    ...
} redisDb;

 dict这个指针就指向了存储键值对的字典结构，key是字符串robj类型，value可以是任何的robj类型。当我们分别新增、删除、更新或者查询的时候，其实就是根据输入的key在这个字典上做curd的操作。我们在Redis写入两个键值对，图示如下：

 除了对数据库键值对的curd操作，基于整个数据操作的一些命令也是在这个dict上面实现的，比如清空所有键值对的flushdb，或者exists、del、dbsize命令等等。在执行命令前后，redis还会执行一些其他操作，比如检查是否超出最大内存，更新lru时间，记录慢查询日志，或者向monitor客户端发送命令等等，这就是redis数据字典的实现原理。

3.键值对的生命周期管理

 这里说的生命周期，其实就是指键值对的过期时间。通常我们使用expire key这个命令设置键的过期时间，但其实Redis是有四个命令支持设置过期时间的：

• expire key seconds 将key的生命周期设置为second秒；
• pexpire key milliseconds 将key的生命周期设置为milliseconds毫秒；
• expireat key timestamp 将key的过期时间设置在timestamp这个秒的时间戳过期；
• pexpireat key timestamp 将key的过期时间设置在timestamp这个毫秒的时间戳过期；

 值得说明的是，虽然有这么多命令支持设置过期时间，但是最终经过转换都是指向pexpireat这一个命令来实现。现在的问题是，这么多键值对的过期时间，在redis服务端是怎么保存和维护的呢？

 前面在看redisDb源码的时候，有一个expires属性，我们再把源码拿过来看一下：

typedef struct redisDb {
	...
    // 这个存放的是键的过期时间
    dict *expires;              
    ...
} redisDb;

 这就很清晰了，通过expires这个指针，指向了一个dict结构，字典中记录的就是所有键值对的过期时间。其中，key是键值对的键，value是long类型的毫秒精度的Unix时间戳，即过期的时间点。值得注意的是，保存键值对的dict字典和保存过期时间的expires字典，key指针都指向相同的一个键字符串对象，所以在内存空间上是不会存在浪费的。

 除此之外，跟过期时间操作相关的两个命令，当然也是基于expires这个字典来实现的：

• ttl 返回键值对的剩余时间
• persist删除键值对的过期时间

4.过期键的管理策略

 既然有过期时间，那么键值对过期之后，是不是立即被删除了呢？答案肯定不是，redis通过惰性删除和定期删除两种策略实现对过期键的管理：

• 惰性删除策略：当程序访问到某个键值对的时候，会对过期时间检查，如果过期就删除，否则不处理。
• 定期删除策略：基于serverCron时间事件函数，从一定数量的数据库中取出一定数量的随机键进行检查，并删除其中过期的键值对。

 使用这两种过期键管理策略可以最大程度上在合理使用CPU时间和避免浪费内存空间之间取得平衡。

5.持久化对过期键的处理

rdb 持久化

• save或者bgsave会检查键的过期时间，已过期的键不会保存到的持久化的rdb文件中。
• 服务器启动载入rdb文件时，如果是主服务器，过期键会被忽略加载；如果是从服务器，不论是否过期，都会被加载。

aof 持久化

• 写入aof文件时，key是会写入的，过期之后，通过追加del命令，才会显示的删除此过期键。
• bgrewriteaof 重写时会检查键的过期时间，已过期的键不会写入新的aof文件中。
• 服务器启动载入aof文件时，过期键也会被忽略，不会被加载。

6.主从复制对过期键的处理

 主从复制，为了保证数据的一致性，通常由主服务器执行更新的操作，然后将命令发送给从服务器。在3.2版本之前，由于惰性删除策略的存在，主服务器遇到对过期键的访问，会删除此键值对，并给客户端返回null值，但是从服务器由于不能执行删除操作，即便是此键已过期，也会返回对应的value值，出现数据不一致导致的脏读问题。

 在3.2版本之后，这个问题得到了修改，从服务器会判断当前键是否过期，如果已过期并且是从服务器的话，也会返回null值。

到此这篇关于Redis数据库原理深入刨析的文章就介绍到这了,更多相关Redis数据库内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们！