我们使用 Redis 时,会接触 Redis 的 5 种对象类型(字符串、哈希、列表、集合、有序集合),丰富的类型是 Redis 相对于 Memcached 等的一大优势。

在了解 Redis 的 5 种对象类型的用法和特点的基础上,进一步了解 Redis 的内存模型,对 Redis 的使用有很大帮助。


Redis内存统计


在客户端通过 redis-cli 连接服务器后(后面如无特殊说明,客户端一律使用redis-cli),通过 info 命令可以查看内存使用情况:info memory。


Redis为何这么快?一篇文章带你深入了解Redis



其中,info 命令可以显示 Redis 服务器的许多信息,包括服务器基本信息、CPU、内存、持久化、客户端连接信息等等;Memory 是参数,表示只显示内存相关的信息。

返回结果中比较重要的几个说明如下:

used_memory

Redis 分配器分配的内存总量(单位是字节),包括使用的虚拟内存(即 swap);Redis 分配器后面会介绍。used_memory_human 只是显示更友好。

used_memory_rss

Redis 进程占据操作系统的内存(单位是字节),与 top 及 ps 命令看到的值是一致的。

除了分配器分配的内存之外,used_memory_rss 还包括进程运行本身需要的内存、内存碎片等,但是不包括虚拟内存。

mem_fragmentation_ratio

内存碎片比率,该值是 used_memory_rss / used_memory 的比值。

mem_fragmentation_ratio 一般大于 1,且该值越大,内存碎片比例越大;mem_fragmentation_ratio<1,说明 Redis 使用了虚拟内存,由于虚拟内存的媒介是磁盘,比内存速度要慢很多。


Redis内存划分


Redis 作为内存数据库,在内存中存储的内容主要是数据(键值对);也有其他部分会占用内存。

Redis 的内存占用主要可以划分为以下几个部分:

数据

作为数据库,数据是最主要的部分;这部分占用的内存会统计在 used_memory 中。

Redis 使用键值对存储数据,其中的值(对象)包括 5 种类型,即字符串、哈希、列表、集合、有序集合。

进程本身运行需要的内存

Redis 主进程本身运行肯定需要占用内存,如代码、常量池等等;这部分内存大约几兆,在大多数生产环境中与 Redis 数据占用的内存相比可以忽略。

缓冲内存

缓冲内存包括客户端缓冲区、复制积压缓冲区、AOF 缓冲区等;其中,客户端缓冲区存储客户端连接的输入输出缓冲;复制积压缓冲区用于部分复制功能;AOF 缓冲区用于在进行 AOF 重写时,保存最近的写入命令。

内存碎片

内存碎片是 Redis 在分配、回收物理内存过程中产生的。例如,如果对数据的更改频繁,而且数据之间的大小相差很大,可能导致 Redis 释放的空间在物理内存中并没有释放。

但 Redis 又无法有效利用,这就形成了内存碎片,内存碎片不会统计在 used_memory 中。


Redis数据存储的细节


关于 Redis 数据存储的细节,涉及到以下几个概念。

dictEntry:Redis 是 Key-Value 数据库,因此对每个键值对都会有一个 dictEntry,里面存储了指向 Key 和 Value 的指针;next 指向下一个 dictEntry,与本 Key-Value 无关。

Key:图中右上角可见,Key(”hello”)并不是直接以字符串存储,而是存储在 SDS 结构中。

下面来分别介绍 jemalloc、RedisObject、SDS、对象类型及内部编码。

jemalloc

jemalloc 在 64 位系统中,将内存空间划分为小、大、巨大三个范围;当 Redis 存储数据时,会选择大小最合适的内存块进行存储。

jemalloc 划分的内存单元如下图所示:


Redis为何这么快?一篇文章带你深入了解Redis



例如,如果需要存储大小为 130 字节的对象,jemalloc 会将其放入 160 字节的内存单元中。

RedisObject

前面说到,Redis 对象有 5 种类型;无论是哪种类型,Redis 都不会直接存储,而是通过 RedisObject 对象进行存储。

SDS

Redis 没有直接使用 C 字符串(即以空字符’’结尾的字符数组)作为默认的字符串表示,而是使用了 SDS。SDS 是简单动态字符串(Simple Dynamic String)的缩写。

SDS 结构


Redis为何这么快?一篇文章带你深入了解Redis



其中,buf 表示字节数组,用来存储字符串;len 表示 buf 已使用的长度;free 表示 buf 未使用的长度。

举个例子:


Redis为何这么快?一篇文章带你深入了解Redis



Redis为何这么快?一篇文章带你深入了解Redis



通过 SDS 的结构可以看出,buf 数组的长度=free+len+1(其中 1 表示字符串结尾的空字符)。

所以,一个 SDS 结构占据的空间为:free 所占长度+len 所占长度+ buf 数组的长度=4+4+free+len+1=free+len+9。

004

Redis的对象类型与内部编码


Redis 支持 5 种对象类型,而每种结构都有至少两种编码。

这样做的好处在于:一方面接口与实现分离,当需要增加或改变内部编码时,用户使用不受影响,另一方面可以根据不同的应用场景切换内部编码,提高效率。

Redis 各种对象类型支持的内部编码如下图所示(图中版本是 Redis3.0):


Redis为何这么快?一篇文章带你深入了解Redis



关于 Redis 内部编码的转换,都符合以下规律:编码转换在 Redis 写入数据时完成,且转换过程不可逆,只能从小内存编码向大内存编码转换。

字符串

字符串是最基础的类型,因为所有的键都是字符串类型,且字符串之外的其他几种复杂类型的元素也是字符串,字符串长度不能超过 512MB。

内部编码

字符串类型的内部编码有 3 种,它们的应用场景如下:

int:8 个字节的长整型。字符串值是整型时,这个值使用 long 整型表示。

embstr:<=39 字节的字符串。embstr 与 raw 都使用 RedisObject 和 sds 保存数据。

区别在于:embstr 的使用只分配一次内存空间(因此 RedisObject 和 sds 是连续的),而 raw 需要分配两次内存空间(分别为 RedisObject 和 sds 分配空间)。

raw:大于 39 个字节的字符串。

示例如下图所示:


Redis为何这么快?一篇文章带你深入了解Redis



embstr 和 raw 进行区分的长度,是 39;是因为 RedisObject 的长度是 16 字节,sds 的长度是 9+ 字符串长度。

因此当字符串长度是 39 时,embstr 的长度正好是 16+9+39=64,jemalloc 正好可以分配 64 字节的内存单元。

编码转换

当 int 数据不再是整数,或大小超过了 long 的范围时,自动转化为 raw。而对于 embstr,由于其实现是只读的,因此在对 embstr 对象进行修改时,都会先转化为 raw 再进行修改。

因此,只要是修改 embstr 对象,修改后的对象一定是 raw 的,无论是否达到了 39 个字节。

示例如下图所示:


Redis为何这么快?一篇文章带你深入了解Redis




列表

列表(list)用来存储多个有序的字符串,每个字符串称为元素;一个列表可以存储 2^32-1 个元素。

Redis 中的列表支持两端插入和弹出,并可以获得指定位置(或范围)的元素,可以充当数组、队列、栈等。

内部编码

列表的内部编码可以是压缩列表(ziplist)或双端链表(linkedlist)。

双端链表:由一个 list 结构和多个 listNode 结构组成;典型结构如下图所示:


Redis为何这么快?一篇文章带你深入了解Redis



通过图中可以看出,双端链表同时保存了表头指针和表尾指针,并且每个节点都有指向前和指向后的指针。

压缩列表:压缩列表是 Redis 为了节约内存而开发的,是由一系列特殊编码的连续内存块(而不是像双端链表一样每个节点是指针)组成的顺序型数据结构,具体结构相对比较复杂。

当节点数量较少时,可以使用压缩列表;压缩列表不仅用于实现列表,也用于实现哈希、有序列表;使用非常广泛。

编码转换

只有同时满足下面两个条件时,才会使用压缩列表:列表中元素数量小于 512 个;列表中所有字符串对象都不足 64 字节。

如果有一个条件不满足,则使用双端列表;且编码只可能由压缩列表转化为双端链表,反方向则不可能。

下图展示了列表编码转换的特点:


Redis为何这么快?一篇文章带你深入了解Redis



其中,单个字符串不能超过 64 字节,是为了便于统一分配每个节点的长度。

哈希

哈希(作为一种数据结构),不仅是 Redis 对外提供的 5 种对象类型的一种(与字符串、列表、集合、有序结合并列),也是 Redis 作为 Key-Value 数据库所使用的数据结构。

内部编码

内层的哈希使用的内部编码可以是压缩列表(ziplist)和哈希表(hashtable)2 种;Redis 的外层的哈希则只使用了 hashtable。

hashtable:一个 hashtable 由 1 个 dict 结构、2 个 dictht 结构、1 个 dictEntry 指针数组(称为 bucket)和多个 dictEntry 结构组成。

正常情况下(即 hashtable 没有进行 rehash 时),各部分关系如下图所示:


Redis为何这么快?一篇文章带你深入了解Redis



下面从底层向上依次介绍各个部分:

dictEntry:dictEntry 结构用于保存键值对,结构定义如下。


Redis为何这么快?一篇文章带你深入了解Redis



其中,各个属性的功能如下:

  • key:键值对中的键。

  • val:键值对中的值,使用 union(即共用体)实现,存储的内容既可能是一个指向值的指针,也可能是 64 位整型,或无符号 64 位整型。

  • next:指向下一个 dictEntry,用于解决哈希冲突问题。


在 64 位系统中,一个 dictEntry 对象占 24 字节(key/val/next 各占 8 字节)。

bucket:bucket 是一个数组,数组的每个元素都是指向 dictEntry 结构的指针。Redis 中 bucket 数组的大小计算规则如下:大于 dictEntry 的、最小的 2^n。

例如,如果有 1000 个 dictEntry,那么 bucket 大小为 1024;如果有 1500 个 dictEntry,则 bucket 大小为 2048。

编码转换

下图展示了 Redis 内层的哈希编码转换的特点:


Redis为何这么快?一篇文章带你深入了解Redis




集合

集合中的元素是无序的,因此不能通过索引来操作元素;集合中的元素不能有重复。一个集合中最多可以存储 2^32-1 个元素。

内部编码

集合的内部编码可以是整数集合(intset)或哈希表(hashtable)。

整数集合的结构定义如下:


Redis为何这么快?一篇文章带你深入了解Redis



其中,encoding 代表 contents 中存储内容的类型,虽然 contents(存储集合中的元素)是 int8_t 类型。

但实际上其存储的值是 int16_t、int32_t 或 int64_t,具体的类型便是由 encoding 决定的,length 表示元素个数。

编码转换

下图展示了集合编码转换的特点:


Redis为何这么快?一篇文章带你深入了解Redis




有序集合

有序集合与集合一样,元素都不能重复;但与集合不同的是,有序集合中的元素是有顺序的。有序集合为每个元素设置一个分数(score)作为排序依据。

内部编码

跳跃表是一种有序数据结构,通过在每个节点中维持多个指向其他节点的指针,从而达到快速访问节点的目的。

Redis 的跳跃表实现由 zskiplist 和 zskiplistNode 两个结构组成:前者用于保存跳跃表信息(如头结点、尾节点、长度等),后者用于表示跳跃表节点,具体结构相对比较复杂。

编码转换

只有同时满足下面两个条件时,才会使用压缩列表:有序集合中元素数量小于 128 个;有序集合中所有成员长度都不足 64 字节。

如果有一个条件不满足,则使用跳跃表;且编码只可能由压缩列表转化为跳跃表,反方向则不可能。

下图展示了有序集合编码转换的特点:


Redis为何这么快?一篇文章带你深入了解Redis




Redis在国内外各大公司都能看到其身影,比如我们熟悉的新浪,阿里,腾讯,百度,搜狐,优酷,美团,小米等等。

零基础学习Redis,这几方面尤其重要:Redis 客户端、Redis 高级功能、Redis 持久化和开发运维常用问题探讨、Redis 复制的原理和优化策略、Redis 分布式解决方案等。