在上一篇通过源码编译构建出可调式环境之后,想必你想更深入了解我的整体架构。当你熟悉我的整体架构和每个模块,遇到问题才能直击本源,直捣黄龙,一笑破苍穹。
我的核心模块如图 1-10。
图1-10
图 1-10
a simple event-driven programming library
。aeApiState
结构体对 epoll、select、kqueue、evport
四种 I/O 多路复用的实现进行适配,让上层调用方感知不到在不同操作系统实现 I/O 多路复用的差异。SET、DEL、GET
等。掌握了整体架构和模块后,接下来进入 src 源码目录,使用如下指令执行 redis-server
可执行程序启动 Redis。
./redis-server ../redis.conf
每个被启动的服务我都会抽象成一个 redisServer,源码定在server.h
的redisServer
结构体。
这个结构体包含了存储键值对的数据库实例、redis.conf 文件路径、命令列表、加载的 Modules、网络监听、客户端列表、RDB AOF 加载信息、配置信息、RDB 持久化、主从复制、客户端缓存、数据结构压缩、pub/sub、Cluster、哨兵等一些列 Redis 实例运行的必要信息。
结构体字段很多,不再一一列举,部分核心字段如下。
truct redisServer {
pid_t pid; /* 主进程 pid. */
pthread_t main_thread_id; /* 主线程 id */
char *configfile; /*redis.conf 文件绝对路径*/
redisDb *db; /* 存储键值对数据的 redisDb 实例 */
int dbnum; /* DB 个数 */
dict *commands; /* 当前实例能处理的命令表,key 是命令名,value 是执行命令的入口 */
aeEventLoop *el;/* 事件循环处理 */
int sentinel_mode; /* true 则表示作为哨兵实例启动 */
/* 网络相关 */
int port;/* TCP 监听端口 */
list *clients; /* 连接当前实例的客户端列表 */
list *clients_to_close; /* 待关闭的客户端列表 */
client *current_client; /* 当前执行命令的客户端*/
};
其中redisDb *db
指针非常重要,它指向了一个长度为 dbnum(默认 16)的 redisDb 数组,它是整个存储的核心,我就是用这玩意来存储键值对。
redisDb 结构体定义如下。
typedef struct redisDb {
dict *dict;
dict *expires;
dict *blocking_keys;
dict *ready_keys;
dict *watched_keys;
int id;
long long avg_ttl;
unsigned long expires_cursor;
list *defrag_later;
clusterSlotToKeyMapping *slots_to_keys;
} redisDb;
dict 和 expires
❝MySQL:“为什么分开存储?”
好问题,之所以分开存储,是因为过期时间并不是每个 key 都会设置,它不是键值对的固有属性,分开后虽然需要两次查找,但是能节省内存开销。
blocking_keys 和 ready_keys
底层数据结构是 dict 字典,主要是用于实现 BLPOP 等阻塞命令。
当客户端使用 BLPOP 命令阻塞等待取出列表元素的时候,我会把 key 写到 blocking_keys 中,value 是被阻塞的客户端。
当下一次收到 PUSH 命令执时,我会先检查 blocking_keys 中是否存在阻塞等待的 key,如果存在就把 key 放到 ready_keys 中,在下一次 Redis 事件处理过程中,会遍历 ready_keys 数据,并从 blocking_keys 中取出阻塞的客户端响应。
watched_keys
用于实现 watch 命令,存储 watch 命令的 key。
id
Redis 数据库的唯一 ID,一个 Redis 服务支持多个数据库,默认 16 个。
avg_ttl
用于统计平均过期时间。
expires_cursor
统计过期事件循环执行的次数。
defrag_later
保存逐一进行碎片整理的 key 列表。
slots_to_keys
仅用于 Cluster 模式,当使用 Cluster 模式的时候,只能有一个数据库 db 0。slots_to_keys 用于记录 cluster 模式下,存储 key 与哈希槽映射关系的数组。
Redis 使用 dict 结构来保存所有的键值对(key-value)数据,这是一个散列表,所以 key 查询时间复杂度是 O(1) 。
所谓散列表,我们可以类比 Java 中的 HashMap
,其实就是一个数组,数组的每个元素叫做哈希桶。
dict 结构体源码在 dict.h
中定义。
struct dict {
dictType *type;
dictEntry **ht_table[2];
unsigned long ht_used[2];
long rehashidx;
int16_t pauserehash;
signed char ht_size_exp[2];
};
dict 的结构体里,有 dictType *type
,**ht_table[2]
,long rehashidx
三个很重要的结构。
重点关注 ht_table 数组,数组每个位置叫做哈希桶,就是这玩意保存了所有键值对,每个哈希桶的类型是 dictEntry。
❝MySQL:“Redis 支持那么多的数据类型,哈希桶咋保存?”
他的玄机就在 dictEntry 中,每个 dict 有两个 ht_table,用于存储键值对数据和实现渐进式 rehash。
dictEntry 结构如下。
typedef struct dictEntry {
void *key;
union {
// 指向实际 value 的指针
void *val;
uint64_t u64;
int64_t s64;
double d;
} v;
// 散列表冲突生成的链表
struct dictEntry *next;
void *metadata[];
} dictEntry;
*key
指向键值对的键的指针,指向一个 sds 对象,key 都是 string 类型。val
指针存储。*next
指向另一个 dictEntry 结构, 多个 dictEntry 可以通过 next 指针串连成链表, 从这里可以看出, ht_table 使用链地址法来处理键碰撞:当多个不同的键拥有相同的哈希值时,哈希表用一个链表将这些键连接起来。哈希桶并没有保存值本身,而是指向具体值的指针,从而实现了哈希桶能存不同数据类型的需求。
dictEntry
的 *val
指针指向的值实际上是一个 redisObject
结构体,这是一个非常重要的结构体。
我的 key 只能是字符串类型,而 value 可以是 String、Lists、Set、Sorted Set、散列表等数据类型。
键值对的值都被包装成 redisObject 对象, redisObject
在 server.h
中定义。
typedef struct redisObject {
unsigned type:4;
unsigned encoding:4;
unsigned lru:LRU_BITS;
int refcount;
void *ptr;
} robj;
如图 1-11 是由 redisDb、dict、dictEntry、redisObejct 关系图:
图1-11
图 1-11
注意,一开始的时候,我只使用 ht_table[0] 这个散列表读写数据,ht_table[1] 指向 NULL,当这个散列表容量不足,触发扩容操作,这时候就会创建一个更大的散列表 ht_table[1]。
接着我会使用渐进式 rehash 的方式将 ht_table[0] 的数据迁移到 ht_table[1] 上,全部迁移完成后,再修改下指针,让 ht_table[0] 指向扩容后的散列表,回收掉原来的散列表,ht_table[1] 再次指向 NULL。
当客户端发送一个指令请求,Redis 服务端会发生什么?