Redis 使用对象来表示数据库中的键和值， 每次当我们在 Redis 的数据库中新创建一个键值对时， 我们至少会创建两个对象， 一个对象用作键值对的键（键对象）， 另一个对象用作键值对的值（值对象）。

举个例子， 以下 SET 命令在数据库中创建了一个新的键值对， 其中键值对的键是一个包含了字符串值 "msg" 的对象， 而键值对的值则是一个包含了字符串值 "hello world" 的对象：

redis> SET msg "hello world"
OK

Redis 中的每个对象都由一个 redisObject 结构表示， 该结构中和保存数据有关的三个属性分别是 type 属性、 encoding 属性和 ptr 属性

typedef struct redisObject {

    // 类型
    unsigned type:4;

    // 编码
    unsigned encoding:4;

    // 指向底层实现数据结构的指针
    void *ptr;

   int refcount; //引用数
    // ...

} robj;

type：表示键值的数据类型，包括 String、List、Set、ZSet、Hash
encoding：表示键值的内部编码方式，从 Redis源码看目前取值有如下几种：

#define OBJ_ENCODING_RAW 0        /* Raw representation */
#define OBJ_ENCODING_INT 1        /* Encoded as integer */
#define OBJ_ENCODING_HT 2         /* Encoded as hash table */
#define OBJ_ENCODING_ZIPMAP 3     /* Encoded as zipmap */
#define OBJ_ENCODING_LINKEDLIST 4 /* No longer used: old list encoding. */
#define OBJ_ENCODING_ZIPLIST 5    /* Encoded as ziplist */
#define OBJ_ENCODING_INTSET 6     /* Encoded as intset */
#define OBJ_ENCODING_SKIPLIST 7   /* Encoded as skiplist */
#define OBJ_ENCODING_EMBSTR 8     /* Embedded sds string encoding */
#define OBJ_ENCODING_QUICKLIST 9  /* Encoded as linked list of ziplists */

refcount：表示该键值被引用的数量，即一个键值可被多个键引用

对于 Redis的常用 5 种数据类型（String、Hash、List、Set、sorted set），每种数据类型都提供了 最少两种 内部的编码格式，而且每个数据类型内部编码方式的选择 对用户是完全透明的，Redis会根据数据量自适应地选择较优化的内部编码格式。

如果想查看某个键的内部编码格式，可以使用 OBJECT ENCODING keyname 指令来进行，比如：

127.0.0.1:6379> 
127.0.0.1:6379> set foo bar
OK
127.0.0.1:6379> 
127.0.0.1:6379> object encoding foo  // 查看某个Redis键值的编码
"embstr"
127.0.0.1:6379> 
127.0.0.1:6379> 

String类型的内部编码情况

字符串是 Redis最基本的数据类型，Redis 中字符串对象的编码可以是 int，raw 或者 embstr 中的某一种，分别介绍如下

• int 编码：保存long 型的64位有符号整数
• embstr 编码：保存长度小于44字节的字符串(3.2之前版本是39)

• raw 编码：保存长度大于44字节的字符串

  
  
  image.png

实际情况就是 Redis 内部会根据用户给的不同键值而使用不同的编码格式，而这一切对用户完全透明!

Redis 是使用 SDS（“简单动态字符串”）这个结构体来存储字符串，代码里定义了 5种 SDS结构体：

struct __attribute__ ((__packed__)) sdshdr5 {
    unsigned char flags; /* 3 lsb of type, and 5 msb of string length */
    char buf[];
};
struct __attribute__ ((__packed__)) sdshdr8 {
    uint8_t len; /* used */
    uint8_t alloc; /* excluding the header and null terminator */
    unsigned char flags; /* 3 lsb of type, 5 unused bits */
    char buf[];
};
struct __attribute__ ((__packed__)) sdshdr16 {
    uint16_t len; /* used */
    uint16_t alloc; /* excluding the header and null terminator */
    unsigned char flags; /* 3 lsb of type, 5 unused bits */
    char buf[];
};
struct __attribute__ ((__packed__)) sdshdr32 {
    uint32_t len; /* used */
    uint32_t alloc; /* excluding the header and null terminator */
    unsigned char flags; /* 3 lsb of type, 5 unused bits */
    char buf[];
};
struct __attribute__ ((__packed__)) sdshdr64 {
    uint64_t len; /* used */
    uint64_t alloc; /* excluding the header and null terminator */
    unsigned char flags; /* 3 lsb of type, 5 unused bits */
    char buf[];
};

可以看出，除了结构体字段数据类型的不同，其字段含义相差无几，其中：

len：字符串的长度（实际使用的长度）
alloc：分配内存的大小
flags：标志位，低三位表示类型，其余五位未使用
buf：字符数组

我们知道对于每个sds都有一个sdshdr，里面的len和free记录了这个sds的长度和空闲空间，但是这样的处理十分粗糙，使用的unsigned int可以表示很大的范围，但是对于很短的sds有很多的空间被浪费了(两个unsigned int 8个字节)。而这个commit则将原来的sdshdr改成了sdshdr16，sdshdr32，sdshdr64，里面的unsigned int 变成了uint8_t,uint16_t.。。。（还加了一个char flags）这样更加优化小sds的内存使用。

相信大家这里已经明白了为什么39变成了44.
本身就是针对短字符串的embstr自然会使用最小的sdshdr8，而sdshdr8与之前的sdshdr相比正好减少了5个字节（sdsdr8 = uint8_t * 2 + char = 1*2+1 = 3, sdshdr = unsigned int * 2 = 4 * 2 = 8）,所以其能容纳的字符串长度增加了5个字节变成了44.

了解了这些基本的数据结构以后，我们就来看看下面这些例子：

set foo 123
set foo abc
set foo abcdefghijklmnopqrstuvwxyzabcdeffasdffsdaadsx

这三种情形下 Redis 内部到底是怎么存数据的！

INT 编码格式
命令示例： set foo 123

当字符串键值的内容可以用一个 64位有符号整形 来表示时，Redis会将键值转化为 long型来进行存储，此时即对应 OBJ_ENCODING_INT 编码类型。
OBJ_ENCODING_INT 编码类型内部的内存结构可以形象地表示如下：

image.png

而且 Redis 启动时会预先建立 10000 个分别存储 0~9999 的 redisObject 变量作为共享对象，这就意味着如果 set字符串的键值在 0~10000 之间的话，则可以 直接指向共享对象 而不需要再建立新对象，此时键值不占空间！
因此，当执行如下指令时：

set key1 100
set key2 100

其实 key1 和 key2 这两个键值都直接引用了一个 Redis 预先已建立好的共享 redisObject 对象，就像下面这样：

image.png

源码之前，了无秘密，我们再对照下面的源码，来理解一下上述过程

image.png

EMBSTR编码格式

命令示例： set foo abc

Redis 在保存长度小于 44 字节的字符串时会采用 OBJ_ENCODING_EMBSTR 编码方式，口说无凭，我们来瞅瞅源码：

image.png

从上述代码中很容易看出，对于长度小于 44的字符串，Redis 对键值采用OBJ_ENCODING_EMBSTR 方式，EMBSTR 顾名思义即：embedded string，表示嵌入式的String。从内存结构上来讲 即字符串 sds结构体与其对应的 redisObject 对象分配在 同一块连续的内存空间，这就仿佛字符串 sds 嵌入在 redisObject 对象之中一样，这一切从下面的代码即可清楚地看到：

image.png

因此，对于指令 set foo abc 所设置的键值，其内存结构示意图如下：

image.png

RAW 编码格式

指令示例： set foo abcdefghijklmnopqrstuvwxyzabcdeffasdffsdaadsx

正如指令示例，当字符串的键值为长度大于 44 的 超长字符串 时，Redis 则会将键值的内部编码方式改为 OBJ_ENCODING_RAW 格式，这与上面的 OBJ_ENCODING_EMBSTR 编码方式的不同之处在于 此时动态字符串 sds 的内存与其依赖的 redisObject 的 内存不再连续 了，以 set foo abcdefghijklmnopqrstuvwxyzabcdeffasdffsdaadsx 为例，其键值的内存结构如下所示：

image.png