Redis 数据库源码分析
我们都知道Redis是一个 <key,value> 的键值数据库，其实也就是一个 Map。如果让我来实现这样一个 Map，我肯定是用数组，当一个 key 来的时候，首先进行 hash 运算，接着对数据的 length 取余，把这个键值对放在对应位置。
设计与分析
我们来看一下 Redis 的设计：
c
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 */
int id; /* Database ID */
long long avg_ttl; /* Average TTL, just for stats */
list *defrag_later; /* List of key names to attempt to defrag one by one, gradually. */
} redisDb;
typedef struct dict {
dictType *type;
void *privdata;
dictht ht[2];
long rehashidx; /* rehashing not in progress if rehashidx == -1 */
unsigned long iterators; /* number of iterators currently running */
} dict;
typedef struct dictht {
dictEntry **table;
unsigned long size;
unsigned long sizemask;
unsigned long used;
} dictht;
typedef struct dictEntry {
void *key;
union {
void *val;
uint64_t u64;
int64_t s64;
double d;
} v;
struct dictEntry *next;
} dictEntry;以上是 Redis 的相关源代码，接下来分别对其进行分析：
redisDb其实就是我们说的数据库，redis 有16个这样的数据库，其中的 dict *dict 就是我们数据存放的字段
c
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 */
int id; /* Database ID */
long long avg_ttl; /* Average TTL, just for stats */
list *defrag_later; /* List of key names to attempt to defrag one by one, gradually. */
} redisDb;再看一下 dict 结构体的设计：
c
typedef struct dict {
dictType *type;
void *privdata;
dictht ht[2];
long rehashidx; /* rehashing not in progress if rehashidx == -1 */
unsigned long iterators; /* number of iterators currently running */
} dict;dictType *type里有一堆函数指针，当有 key 来时，需要通过函数指针里的 hash 函数求 hash 值，对数组长度取余后还要调用比较函数判断对应位置的 key 与当前 key 是否相等（原因是会有 hash 冲突，redis 首先使用链表法解决冲突，头插法）
dictht ht[2]，一般情况下 ht[1] 都是指向 NULL，只有在 rehash 的时候才有值。Redis 使用两个数组，当需要扩容时，读请求首先从 ht[0] 读，没有的话再去 ht[1]，写请求直接写 ht[1]，更新请求后续再说。（TBD：什么时候扩容？扩容时的扩容大小？rehash 时的请求处理？）
rehashidx，rehash 的索引，如果是-1，代表此时没有进行 rehash，否则代表需要进行迁移的数组下标。
再看一下dictht结构体的设计，ht，即 hashtable，学 java 的应该很熟悉
c
typedef struct dictht {
dictEntry **table;
unsigned long size;
unsigned long sizemask;
unsigned long used;
} dictht;dictEntry **table：一个dictEntry指针数组。key的哈希值最终映射到这个数组的某个位置上（对应一个bucket）。如果多个key映射到同一个位置，就发生了冲突，那么就拉出一个 dictEntry 链表。
size：标识dictEntry指针数组的长度。它总是2的指数。
sizemask：key 的 hash 值对 size 取模的结果其实等于 hash 值 & (size - 1)，而且%运算会一直除，而&运算一次到位。
used：记录dict中现有的数据个数。它与size的比值就是装载因子（load factor）。这个比值越大，哈希值冲突概率越高。
最终的数据是在 dictEntry 中，一起来看下：
c
typedef struct dictEntry {
void *key;
union {
void *val;
uint64_t u64;
int64_t s64;
double d;
} v;
struct dictEntry *next;
} dictEntry;一个 key 的指针，一个 value 的指针，由于 hash 函数可能会冲突，所以还有 next 指针用来解决冲突（链表法）。
图示
经过上述分析，我们可以得到这样的一个 Redis 结构图
至于其中的 SDS 和 redisObject，其实是 Redis 的内部数据结构，如果有机会的话后续再写。