Redis数据结构——字典

除了用来表示数据库之外，字典也是哈希键的底层实现

typedef struct dictEntry {
    void *key; //键
    union {        //值
        void *val;
        uint64_t u64;
        int64_t s64;
        double d;
    } v;
    struct dictEntry *next; //指向下个哈希表节点，形成链表
} dictEntry;

typedef struct dictType {
    unsigned int (*hashFunction)(const void *key);
    void *(*keyDup)(void *privdata, const void *key);
    void *(*valDup)(void *privdata, const void *obj);
    int (*keyCompare)(void *privdata, const void *key1, const void *key2);
    void (*keyDestructor)(void *privdata, void *key);
    void (*valDestructor)(void *privdata, void *obj);
} dictType;

/* 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;    //哈希表大小掩码，用于计算索引值，总数等于size -1
    unsigned long used; //该哈希表已有节点的数量
} dictht;

typedef struct dict {
    dictType *type; //类型特定函数
    void *privdata; //私有数据
    dictht ht[2];  //哈希表
    // rehash 索引
    //当rehash不在进行时，值为-1
    long rehashidx; /* rehashing not in progress if rehashidx == -1 */
    int iterators; /* number of iterators currently running */
} dict;

当有两个或以上数量的键被分配到了哈希表数组的同一个索引上面时，我们称这些键发生了冲突(collision).
   Redis的哈希表使用链地址法(separate chaining)来解决键冲突，每个哈希表节点都有一个next指针，多个哈希表节点可以用next指针构成一个单向链表，被分配到同一个索引上的多个节点可以用这个单向链表连接起来，这就解决了键冲突的问题。

Rehash
   随着操作的不断执行，哈希表保存的键值对会逐渐的增多或者减少，为了让哈希表的负载因子(load factor)维持在一个合理的范围之内，当哈希表保存的键值对数量太多或者太少时，程序需要对哈希表的大小进行相应的扩展或者收缩。

哈希表的扩展与收缩

当以下条件中的任意一个被满足时，程序会自动开始对哈希表执行扩展操作。
   1) 服务器目前没有在执行BGSAVE命令或者BGREWRITEAOF命令，并且哈希表的负载因子大于等于1.
   2）服务器目前正在执行BGSAVE命令或者BGREWRITEAOF命令，并且哈希表的负载因子大于等于5
   其中哈希表的负载因子可以通过公式：
   # 负载因子 = ht[0].used/ ht[0].size
   计算出。
   例如, 对于一个大小为4,包含4个键值对的哈希表来说，这个哈希表的负载因子为： load_factor = 4/4 = 1.
    又例如：对于一个大小为512,包含256个键值对的哈希表来说，
   这个哈希表的负载因子为: load_factor = 256/512 = 0.5
根据BGSAVE命令或BGREWRITEAOF命令是否正在执行，服务器执行扩展操作所需的负载因子并不相同，这是因为在执行BGSAVE命令或BGREWRITEAOF命令的过程中，Redis需要创建当前服务器进程的子进程，而大多数操作系统都采用写
时复制(copy-on-write)技术来优化子进程的使用效率，所以在子进程存在期间，服务器会提高执行扩张操作所需的负载因子，从而尽可能地避免在子进程存在期间进行哈希扩展操作，这可以避免不必要的内存写入操作，最大限度地节约内容。
另一方面，当哈希表的负载因子小于0.1时，程序自动开始对哈希表进行收缩操作。

渐进式Rehash：
   为了避免rehash对服务器性能造成影响，服务器不是一次性将ht[0]里面的所有键值对全部rehash到ht[1],而是分多次，渐进式地将ht[0]里面的键值对慢慢地rehash 到ht[1]。

哈希表渐进式rehash的详细步骤：
   1）为ht[1] 分配空间，让字典同时持有ht[0]和ht[1]两个哈希表。
   2）在字典中维持一个索引计数器变量rehashidx，并将它的值设置为0，表示rehash   工作正式开始。
   3）在rehash进行期间，每次对字典执行添加，删除，查找或者更新操作时，程序除了执行指定额操作以外，还会顺带将   ht[0] 哈希表在rehashidx索引上的所有键值对rehash到ht[1],当rehash工作完成之后，程序将rehashidx属性的值增一。
   4) 随着字典操作的不断执行，最终在某个时间点上，ht[0]的所有键值对都会被rehash到ht[1],这时程序将rehashidx属性的值设为-1,表示rehash操作完成。

   渐进式rehash的好处在于它采用分而治之的方式，将rehash键值对所需的计算工作均摊到对字典的每个添加，删除，查找和更新操作上，从而避免了集中式rehash而带来的庞大计算量。

   渐进式rehash执行期间的哈希表操作
       因为在进行渐进式rehash的过程中，字典会同时使用ht[0] 和ht[1] 两个哈希表，
   所以在渐进式rehash进行期间，字典的删除(delete)，查找(find), 更新(update)等操作会在两个哈希表上进行。
   例如：要在字典里面查找一个键的话，程序会先在ht[0]里面进行查找，
   如果没有找到的话，就会继续在ht[1] 里面进行查找，诸如此类。
另外，在渐进式rehash执行期间，新添加到字典的键值对一律会被保存到ht[1]里面，而ht[0]则不再进行任何添加操作，这一措施保证了ht[0]包含的键值对数量会只减不增，并随着rehash操作的执行而最终变成空表。

总结：
字典被广泛用于实现redis的各种功能，其中包括数据库和哈希键。
redis中的字典使用哈希表作为底层实现，每个字典代用两个哈希表，一个平时使用，另一个仅在进行rehash时使用。

当字典被用作数据库的底层实现，或者哈希键的底层实现时，Redis使用MurmurHash2算法来计算键的哈希值。

哈希表使用链地址法来解决键冲突，被分配到同一个索引上的多个键值对会连接成一个单向链表。

在对哈希表进行扩展或者收缩操作时，程序需要将现有哈希表包含的所有键值对rehash到新哈希表里面，并且这个rehash过程并不是一次性完成的，而是渐进式地完成的。