Redis对象的底层实现及数据结构字符串

Redis是一种key/value型数据库，其中，每个key和value都是使用对象表示的。
每次当我们在redis的数据库中新创建一个键值对时，我们至少会创建两个对象，一个对象用作键值对的键(键对象)，另一个对象用作键值对的值(值对象)。
redis的每种对象都由对象结构(redisObject)与对应编码的数据结构组合而成，redis支持5种对象类型。每种对象类型至少对应两种编码方式，不同的编码方式所对应的底层数据结构是不同的。比如，我们执行以下代码：

  redis>SET message "hello redis"  

其中的key是message，是一个包含了字符串"message"的对象。而value是一个包含了"hello redis"的对象。
Redis共有五种对象的类型，分别是：
REDIS_STRING字符串对象
REDIS_LIST列表对象
REDIS_HASH哈希对象
REDIS_SET集合对象
REDIS_ZSET有序集合对象
每个对象会用到的编码以及对应的底层数据结构详见下表：

每种对象对应两至三种编码，除skiplist编码需要用到两种数据结构(字典+跳跃表)外，其余编码均用到一种底层的数据结构。

同一个对象类型，在不同的场景下用到的编码(数据结构)不同，redis支持8种编码以及8种底层的数据结构。这种方式更加灵活，可以帮助redis获得更高的性能以及尽量占用更少的内存。比如如果字符串对象中要存储的字符串内容所占字节较小，会用embstr编码的格式，如果要存储的内容所占字节较大，会用raw编码的格式。

字符串对象
字符串对象的编码可以是int、raw或者embstr。
如果一个字符串的内容可以转换为long，那么该字符串就会被转换成为long类型，对象的ptr就会指向该long，并且对象类型也用int类型表示。

普通的字符串有两种，embstr和raw。embstr应该是Redis 3.0新增的数据结构,在2.8中是没有的。如果字符串对象的长度小于39字节，就用embstr对象。否则用传统的raw对象。可以从下面这段代码看出：

embstr的好处有如下几点：

embstr的创建只需分配一次内存，而raw为两次（一次为sds分配对象，另一次为objet分配对象，embstr省去了第一次）。
相对地，释放内存的次数也由两次变为一次。

embstr的objet和sds放在一起，更好地利用缓存带来的优势。

需要注意的是，redis并未提供任何修改embstr的方式，即embstr是只读的形式。对embstr的修改实际上是先转换为raw再进
行修改。

raw和embstr的区别可以用下面两幅图所示：

列表对象
列表对象的编码可以是ziplist或者linkedlist。
ziplist是一种压缩链表，它的好处是更能节省内存空间，因为它所存储的内容都是在连续的内存区域当中的。当列表对象元素不大，每个元素也不大的时候，就采用ziplist存储。但当数据量过大时就ziplist就不是那么好用了。因为为了保证他存储内容在内存中的连续性，插入的复杂度是O(N)，即每次插入都会重新进行realloc。如下图所示，对象结构中ptr所指向的就是一个ziplist。整个ziplist只需要malloc一次，它们在内存中是一块连续的区域。

inkedlist是一种双向链表。它的结构比较简单，节点中存放pre和next两个指针，还有节点相关的信息。当每增加一个node的时候，就需要重新malloc一块内存。

哈希对象
哈希对象的底层实现可以是ziplist或者hashtable。
ziplist中的哈希对象是按照key1,value1,key2,value2这样的顺序存放来存储的。当对象数目不多且内容不大时，这种方式效率是很高的。

hashtable的是由dict这个结构来实现的

dict是一个字典，其中的指针dicht ht[2] 指向了两个哈希表

dicht[0] 是用于真正存放数据，dicht[1]一般在哈希表元素过多进行rehash的时候用于中转数据。

dictht中的table用语真正存放元素了，每个key/value对用一个dictEntry表示，放在dictEntry数组中。

集合对象
集合对象的编码可以是intset或者hashtable。

intset是一个整数集合，里面存的为某种同一类型的整数，支持如下三种长度的整数：

#define INTSET_ENC_INT16 (sizeof(int16_t))  
#define INTSET_ENC_INT32 (sizeof(int32_t))  
#define INTSET_ENC_INT64 (sizeof(int64_t))  

intset是一个有序集合，查找元素的复杂度为O(logN)，但插入时不一定为O(logN)，因为有可能涉及到升级操作。比如当集合里全是int16_t型的整数，这时要插入一个int32_t，那么为了维持集合中数据类型的一致，那么所有的数据都会被转换成int32_t类型，涉及到内存的重新分配，这时插入的复杂度就为O(N)了。是intset不支持降级操作。

有序集合对象
有序集合的编码可能两种，一种是ziplist，另一种是skiplist与dict的结合。
ziplist作为集合和作为哈希对象是一样的，member和score顺序存放。按照score从小到大顺序排列。它的结构不再复述。
skiplist是一种跳跃表，它实现了有序集合中的快速查找，在大多数情况下它的速度都可以和平衡树差不多。但它的实现比较简单，可以作为平衡树的替代品。它的结构比较特殊。下面分别是跳跃表skiplist和它内部的节点skiplistNode的结构体：
head和tail分别指向头节点和尾节点，然后每个skiplistNode里面的结构又是分层的(即level数组)
用图表示，大概是下面这个样子：

每一列都代表一个节点，保存了member和score，按score从小到大排序。每个节点有不同的层数，这个层数是在生成节点的时候随机生成的数值。每一层都是一个指向后面某个节点的指针。这种结构使得跳跃表可以跨越很多节点来快速访问。

前面说到了，有序集合ZSET是有跳跃表和hashtable共同形成的。

typedef struct zset {

// 字典 

   dict *dict;  

// 跳跃表  

    zskiplist *zsl;  

} zset;  

总结
为什么要用这种结构呢。试想如果单一用hashtable，那可以快速查找、添加和删除元素，但没法保持集合的有序性。如果单一用skiplist，有序性可以得到保障，但查找的速度太慢O（logN）。
当服务器考虑将一个键的值引用共享对象时，键的值作为目标对象，程序需要先检查共享对象和目标对象的类型是否完全相同，只有在完全相同的情况下，共享对象才会被引用。而一个共享对象保存的值越复杂，验证共享对象与目标对象所需的复杂度就会越高，消耗的CPU时间也会越多。

所以共享对象的优点是被其它键引用时，可以节省内存空间，缺点是被引用时需要进行判断，这个过程需要消耗CPU，如果共享对象简单，消耗很小的CPU并节省内存空间是值得的。

但如果对象共享很复杂，进行判断就需要消耗大量CPU，消耗大量CPU去节省内存空间是不值得的，因为redis本身的内存空间还是很大的。