redis中的对象（一）

 

redis并没有直接用数据结构来存储数据，而是将他们聚合为一个对象

redis有五大数据类型，str，list，dict(map)，set，orderset。这五个数据库类型的底层基本都是由上一篇讲过的数据结构定义的

redis中的对象均是以键值对的形式来存储的。我们讨论的对象是“值”的对象，而键的对象均是string

一个对象有三个属性

 

1.TYPE:

是一个常量，主要有上述几种。当然这是“值”的对象类型

 

2. ENCODING：说明了对象使用了怎样的编码结构作为底层实现，其值为这几个中的一个（均是前几个章节介绍过的）

 

 

3.PTR：是一个指针，指向对象的底层实现数据结构

 

 

每一个对象均有最少两种的不同数据结构实现方式

就拿HASH类型来讲。当字典中存入的值为int或较短的字符串时，就会使用ZIPLIST来作为底层实现。当是其他值时，便会使用字典

可以使用OBJECT ENCODING (建名)来查看对象的编码（编码并不是固定的，而是根据数据的差异而变化的）。

 

 

String对象：

embstr只需要调用一次便可以创建objectRedis和sdshdr结构，而raw需要两次。同时内存回收时也是如此，而且embstr在内存中是连续的，故而更有优势。

正是因为redis这种特点，使得其非常灵活。

下面是string对象的简化表示，他存储的值是“three”

 

 

接下来是string编码转换的一些特性

同时，embstr并没有提供任何修改的方法，所以它是只读的。若对其修改那么它也会自动变为raw类型、

部分API

字符串对象是唯一一种会被其他四个对象引用的对象（即其他四个对象底层中会使用到string对象）

List对象：

有两种编码，ziplist和linkedlist，即压缩列表和双端链表

ziplist：

linkedlist：（嵌套了string对象）

 

Redis3.2版本之后，这两种数据编码被整合为一个：quicklist。其实原理类似于内存的段页式分配，quicklist是先将其分为linkedlist，每个linkedlist的小段中再分为ziplist。

 

在3.2版本之前，当 1.插入的数据小于64字节 2.数据的总数小于512时，会使用ziplist，不满足时会使用linkedlist。初步猜测是为了减少内存空间的碎片化，并且这种方式更加灵活，使得时空局部性有良好的应用。而3.2之后，统一使用quicklist对其进行代替。所以写到这里，可以发现List对象只有一种实现的编码方式------quicklist

 

其实也很好理解。当插入的数据满足之前提到的两个条件时，会使用一个quicklist节点来存储，当不满足该条件时（如数据总数为567），那么会将其拆分成两个quicklist节点，用两个ziplist来存储。这两个节点之间的关系是使用linkedlist来进行连接。

 

哈希对象

他的底层可以是ziplist或者hashtable

当数据较小或者数量不多时，会使用ziplist，不然会使用hashtable

ziplist：

hashtable：

他们同样存在编码转换的现象

集合对象

底层实现既可以是intset也可以是hashtable

若是存入纯数字，则时intset。当存入字符时，会使用hashtable。

使用hashtable时仅使用“键”的部分，其“值”的部分设置为null

 

orderset有序集合和跳跃表会在后续给出，由于两个都需要了解跳跃表，所以打算去看看论文再说。