redis源码分析之内存布局

1. 介绍

众所周知，redis是一个开源、短小、高效的key-value存储系统，相对于memcached，redis能够支持更加丰富的数据结构，包括：

1. 字符串（string）
2. 哈希表（map）
3. 列表（list）
4. 集合（set）
5. 有序集（zset）

主流的key-value存储系统，都是在系统内部维护一个hash表，因为对hash表的操作时间复杂度为O(1)。如果数据增加以后，导致冲突严重，时间复杂度增加，则可以对hash表进行rehash，以此来保证操作的常量时间复杂度。

那么，对于这样一个基于hash表的key-value存储系统，是如何提供这么丰富的数据结构的呢？这些数据结构在内存中如何存储呢？这篇文章将用大量的图片演示redis的内存布局和数据存储。

2. redisServer

在redis系统内部，有一个redisServer结构体的全局变量server，server保存了redis服务端所有的信息，包括当前进程的PID、服务器的端口号、数据库个数、统计信息等等。当然，它也包含了数据库信息，包括数据库的个数、以及一个redisDb数组。

struct redisServer {
    ……
    redisDb *db;
    int dbnum;                      /* Total number of configured DBs */
    ……
}

显然，dbnum就是redisDb数组的长度，每一个数据库，都对应于一个redisDb，在redis的客户端中，可以通过select N来选择使用哪一个数据库，各个数据库之间互相独立。例如：可以在不同的数据库中同时存在名为”redis”的key。

从上面的分析中可以看到，server是一个全局变量，它包含了若干个redisDb，每一个redisDb是一个keyspace，各个keyspace互相独立，互不干扰。

下面来看一下redisDb的定义：

/* Redis database representation. There are multiple databases identified
 * by integers from 0 (the default database) up to the max configured
 * database. The database number is the ‘id‘ field in the structure. */
typedef struct redisDb {
    dict *dict;                 /* The keyspace for this DB */
    dict *expires;              /* Timeout of keys with a timeout set */
    dict *blocking_keys;        /* Keys with clients waiting for data (BLPOP) */
    dict *ready_keys;           /* Blocked keys that received a PUSH */
    dict *watched_keys;         /* WATCHED keys for MULTI/EXEC CAS */
    struct evictionPoolEntry *eviction_pool;    /* Eviction pool of keys */
    int id;                     /* Database ID */
    long long avg_ttl;          /* Average TTL, just for stats */
} redisDb;

redis的每一个数据库是一个独立的keyspace，因此，我们理所当然的认为，redis的数据库是一个hash表。但是，从redisDb的定义来看，它并不是一个hash表，而是一个包含了很多hash表的结构。之所以这样做，是因为redis还需要提供除了set、get以外更加丰富的功能(例如：键的超时机制)。我们今天只关注最重要的数据结构：

typedef struct redisDb {
    dict *dict;                 /* The keyspace for this DB */
    ……
} redisDb;

redisDb与redisServer的关系如下所示：

下面再看dict的定义：

typedef struct dict {
    ……
    dictht ht[2];
    long rehashidx; /* rehashing not in progress if rehashidx == -1 */
    ……
} dict;

dict包含了两个hash表，这样做的目的是为了支持渐进式的rehash，即：在大多数情况下，只使用第一个hash表，如果第一个hash表的数据太多，则需要执行rehash。

dict与redisDb、redisServer的关系如下：

下面看一下dictht的定义，至此，我们总算见到了redis的hash表，与绝大多数的hash表没有什么两样：

/* This is our hash table structure. Every dictionary has two of this as we
* implement incremental rehashing, for the old to the new table. */
typedef struct dictht {
    dictEntry **table;
    unsigned long size;
    unsigned long sizemask;
    unsigned long used;
} dictht;

dictht与dict、redisDb、redisServer之间的关系如下：

redis对hash表的节点也进行了简单的封装，hash表的每一个节点都是一个dictEntry，redis的hash表看起来是这样：

总结： redis内存有一个全局变量redisServer server，该变量包含若干个数据库，每个数据库都用一个redisDb表示，redisDb包含若干个字典，其中，存储数据的是dict* dict，dict内部包含两个hash表，一般情况下面，我们只会使用ht[0]，在rehash时，我们会同时使用两个hash表，hash表的每一项，都是一个dictEntry结构体的变量。

从宏观角度来看，redis的数据存储应该是这样的：

3. 存储不同的数据类型

在上一节中，详细介绍了redis的hash表以及核心数据结构之间的关系，至此，以及对redis存储数据有了一个初步的印象，但是，到目前为止还没有回答文章最开始的问题：redis如何存储不同的数据结构？

要理解redis如何存储不同的数据结构，首先来看一下redisObject的定义：

typedef struct redisObject {
    unsigned type:4;
    unsigned encoding:4;
    unsigned lru:REDIS_LRU_BITS; /* lru time (relative to server.lruclock) */
    int refcount;
    void *ptr;
} robj;

其中，type是逻辑数据类型，即redis提供给用户的字符串、列表、hash表等。type的取值如下：

/* Object types */
#define REDIS_STRING 0
#define REDIS_LIST 1
#define REDIS_SET 2
#define REDIS_ZSET 3
#define REDIS_HASH 4

type虽然很关键，但是，在我们这篇文章中，更多的需要关注encoding字段，该字段的含义是逻辑数据类型的具体实现。encoding的取值如下：

#define REDIS_ENCODING_RAW 0     /* Raw representation */
#define REDIS_ENCODING_INT 1     /* Encoded as integer */
#define REDIS_ENCODING_HT 2      /* Encoded as hash table */
#define REDIS_ENCODING_ZIPMAP 3  /* Encoded as zipmap */
#define REDIS_ENCODING_LINKEDLIST 4 /* Encoded as regular linked list */
#define REDIS_ENCODING_ZIPLIST 5 /* Encoded as ziplist */
#define REDIS_ENCODING_INTSET 6  /* Encoded as intset */
#define REDIS_ENCODING_SKIPLIST 7  /* Encoded as skiplist */
#define REDIS_ENCODING_EMBSTR 8  /* Embedded sds string encoding */
#define REDIS_ENCODING_QUICKLIST 9 /* Encoded as linked list of ziplists */

例如，对于list这种数据类型，在redis内部，可以使用ziplist实现（更加省内存），也可以使用linkedlist实现。

在满足以下两个条件时，使用ziplist实现，否则，使用linkedlist实现。

1. 列表对象保存的所有字符串元素的长度都小于64字节
2. 列表对象保存的元素数量小于512

再次强调：对于同一种数据类型，redis内部提供了多种实现，不同的实现适用于不同的场景，且用户只能通过redis.conf文件进行有限的控制，具体使用哪一种实现，完全是redis内部决定。可以通过object encoding key查看当前key的内部编码，即内部实现。

这篇文章介绍redis的内存布局，自然更应该关系的是内部的具体实现，而不是逻辑数据类型。不管是逻辑类型(type)还是具体实现(encoding)，都保存在redisObject中，redisObject相当于是所有数据结构的父类，redis的hash表的每一个项都是dictEntry，而每一个dictEntry，都指向一个redisObject。

redis在数据的存取时，首先通过key找到对应的dictEntry，接着通过dictEntry获取redisObject对象，然后通过redisObject的encoding的取值，对redisObject的ptr指针进行强制类型转换。

例如： 对于一个简短的list，redis很有可能使用的是quicklist存储，因此，在读取list的数据时，redis首先通过key找到dictEntry，然后通过dictEntry找到redisObject， 通过redisObject的encoding对ptr指针进行强制类型转换，在本例中，将ptr强制转换为quicklist，转换为quicklist以后，就能够获取head和tail指针，可以使用head和tail访问数据。

原文地址：https://www.cnblogs.com/zheli/p/9521016.html