Redis内存模型
Redis内存统计
1 | 127.0.0.1:6379># Memoryinfo memory |
Redis内存分配
数据:作为数据库,数据是最主要的部分;这部分占用的内存会统计在 used_memory 中。Redis 使用键值对存储数据,其中的值(对象)包括 5 种类型,即字符串、哈希、列表、集合、有序集合。这 5 种类型是 Redis 对外提供的,实际上,在 Redis 内部,每种类型可能有 2 种或更多的内部编码实现
进程: Redis 主进程本身运行肯定需要占用内存,如代码、常量池等等;这部分内存大约几M,在大多数生产环境中与 Redis 数据占用的内存相比可以忽略。这部分内存不是由 jemalloc 分配,因此不会统计在 used_memory 中。补充说明:除了主进程外,Redis 创建的子进程运行也会占用内存,如 Redis 执行 AOF、RDB 重写时创建的子进程。当然,这部分内存不属于 Redis 进程,也不会统计在 used_memory 和 used_memory_rss 中。
缓冲内存:缓冲内存包括客户端缓冲区、复制积压缓冲区、AOF 缓冲区等;其中,客户端缓冲区存储客户端连接的输入输出缓冲;复制积压缓冲区用于部分复制功能;AOF 缓冲区用于在进行 AOF 重写时,保存最近的写入命令。在了解相应功能之前,不需要知道这些缓冲的细节;这部分内存由 jemalloc 分配,因此会统计在used_memory 中。
内存碎片:内存碎片是 Redis 在分配、回收物理内存过程中产生的。例如,如果对数据的更改频繁,而且数据之间的大小相差很大,可能导致 Redis 释放的空间在物理内存中并没有释放。但 Redis 又无法有效利用,这就形成了内存碎片,内存碎片不会统计在 used_memory 中。内存碎片的产生与对数据进行的操作、数据的特点等都有关;此外,与使用的内存分配器也有关系:如果内存分配器设计合理,可以尽可能的减少内存碎片的产生。如果 Redis 服务器中的内存碎片已经很大,可以通过安全重启的方式减小内存碎片:因为重启之后,Redis 重新从备份文件中读取数据,在内存中进行重排,为每个数据重新选择合适的内存单元,减小内存碎片。
Redis数据结构
Redis 没有直接使用 C 字符串(即以空字符’\0’结尾的字符数组)作为默认的字符串表示,而是使用了SDS。SDS 是简单动态字符串(Simple Dynamic String)的缩写。它是自己构建了一种名为 简单动态字符串(simple dynamic string,SDS)的抽象类型,并将 SDS 作为Redis的默认字符串表示。
简单动态字符串(simple dynamic string,SDS)定义:
1 | struct sdshdr{ |
buf数组的长度=free+len+1
buf数组的长度=free+len+1
好处:
SDS 在 C 字符串的基础上加入了 free 和 len 字段,带来了很多好处:
获取字符串长度:SDS 是 O(1),C 字符串是 O(n)。
缓冲区溢出:使用 C 字符串的 API 时,如果字符串长度增加(如 strcat 操作)而忘记重新分配内存,很容易造成缓冲区的溢出。而 SDS 由于记录了长度,相应的 API 在可能造成缓冲区溢出时会自动重新分配内存,杜绝了缓冲区溢出。
修改字符串时内存的重分配:对于 C 字符串,如果要修改字符串,必须要重新分配内存(先释放再申请),因为如果没有重新分配,字符串长度增大时会造成内存缓冲区溢出,字符串长度减小时会造成内存泄露。而对于 SDS,由于可以记录 len 和 free,因此解除了字符串长度和空间数组长度之间的关联,可以在此基础上进行优化。空间预分配策略(即分配内存时比实际需要的多)使得字符串长度增大时重新分配内存的概率大大减小;惰性空间释放策略使得字符串长度减小时重新分配内存的概率大大减小。
存取二进制数据:SDS 可以,C 字符串不可以。因为 C 字符串以空字符作为字符串结束的标识,而对于一些二进制文件(如图片等)。内容可能包括空字符串,因此 C 字符串无法正确存取;而 SDS 以字符串长度 len 来作为字符串结束标识,因此没有这个问题。此外,由于 SDS 中的 buf 仍然使用了 C 字符串(即以’\0’结尾),因此 SDS 可以使用 C 字符串库中的部分函数。但是需要注意的是,只有当 SDS 用来存储文本数据时才可以这样使用,在存储二进制数据时则不行(’\0’不一定是结尾)。
使用:所有的key;数据里的字符串;AOF缓冲区和用户输入缓冲。
链表定义
1 | typedef struct listNode { |
Redis链表优势:
①、双向:链表具有前置节点和后置节点的引用,获取这两个节点时间复杂度都为O(1)。与传统链表(单链表)相比,Redis链表结构的优势有:普通链表(单链表):节点类保留下一节点的引用。链表类只保留头节点的引用,只能从头节点插入删除
②、无环:表头节点的 prev 指针和表尾节点的 next 指针都指向 NULL,对链表的访问都是以 NULL结束。
③、带链表长度计数器:通过 len 属性获取链表长度的时间复杂度为 O(1)。
④、多态:链表节点使用 void* 指针来保存节点值,可以保存各种不同类型的值。
链表和列表区别
linkedlist和arraylist
链表在Redis中的应用非常广泛,列表(List)的底层实现之一就是双向链表。此外发布与订阅、慢查询、监视器等功能也用到了链表。
字典
字典又称为符号表或者关联数组、或映射(map),是一种用于保存键值对的抽象数据结构。字典中的每一个键 key 都是唯一的,通过 key 可以对值来进行查找或修改。Redis 的字典使用哈希表作为底层实现。哈希(作为一种数据结构),不仅是 Redis 对外提供的 5 种对象类型的一种(hash),也是 Redis 作为 Key-Value 数据库所使用的数据结构。
1 | typedef struct dictht{ |
整数集合
整数集合
整数集合(intset)是集合(set)的底层实现之一,当一个集合(set)只包含整数值元素,并且这个集合的元素不多时,Redis就会使用整数集合(intset)作为该集合的底层实现。整数集合(intset)是
Redis用于保存整数值的集合抽象数据类型,它可以保存类型为int16_t、int32_t 或者int64_t 的整数值,并且保证集合中不会出现重复元素。
1 | typedef struct intset{ |
压缩列表
压缩列表(ziplist)是列表键和哈希键的底层实现之一。当一个列表只包含少量列表项时,并且每个列表项时小整数值或短字符串,那么Redis会使用压缩列表来做该列表的底层实现。
压缩列表(ziplist)是Redis为了节省内存而开发的,是由一系列特殊编码的连续内存块组成的顺序型数据结构,一个压缩列表可以包含任意多个节点(entry),每个节点可以保存一个字节数组或者一个整数值。放到一个连续内存区。
previous_entry_ength: 记录压缩列表前一个字节的长度。
encoding:节点的encoding保存的是节点的content的内容类型
content:content区域用于保存节点的内容,节点内容类型和长度由encoding决定。
对象
前面我们讲了Redis的数据结构,Redis不是用这些数据结构直接实现Redis的键值对数据库,而是基于这些数据结构创建了一个对象系统。包含字符串对象,列表对象,哈希对象,集合对象和有序集合对象。根据对象的类型可以判断一个对象是否可以执行给定的命令,也可针对不同的使用场景,对象设置有多种不同的数据结构实现,从而优化对象在不同场景下的使用效率。Redis中的每个对象都是由如下结构表示(列出了与保存数据有关的三个属性)
1 | typedef struct redisObject { |
type 字段表示对象的类型,占 4 个比特;目前包括 REDIS_STRING(字符串)、REDIS_LIST (列表)、REDIS_HASH(哈希)、REDIS_SET(集合)、REDIS_ZSET(有序集合)。当我们执行 type 命令时,便是通过读取 RedisObject 的 type 字段获得对象的类型,如下所示:
1 | 127.0.0.1:6379> type a1 string |
encoding 表示对象的内部编码,占 4 个比特。对于 Redis 支持的每种类型,都有至少两种内部编码,例如对于字符串,有 int、embstr、raw 三种编码。通过 encoding 属性,Redis 可以根据不同的使用场景来为对象设置不同的编码,大大提高了 Redis 的灵活性和效率。
以列表对象为例,有压缩列表和双端链表两种编码方式;
如果列表中的元素较少,Redis 倾向于使用压缩列表进行存储,因为压缩列表占用内存更少,而且比双端链表可以更快载入。
当列表对象元素较多时,压缩列表就会转化为更适合存储大量元素的双端链表。
通过 object encoding 命令,可以查看对象采用的编码方式,如下所示:
1 | 127.0.0.1:6379> object encoding a1 "int" |
lru 记录的是对象最后一次被命令程序访问的时间,占据的比特数不同的版本有所不同(如 4.0 版本占24 比特,2.6 版本占 22 比特)。
通过对比 lru 时间与当前时间,可以计算某个对象的空转时间;object idletime 命令可以显示该空转时间(单位是秒)。object idletime 命令的一个特殊之处在于它不改变对象的 lru 值。
lru 值除了通过 object idletime 命令打印之外,还与 Redis 的内存回收有关系。如果 Redis 打开了 maxmemory 选项,且内存回收算法选择的是 volatile-lru 或 allkeys—lru,那么当Redis 内存占用超过 maxmemory 指定的值时,Redis 会优先选择空转时间最长的对象进行释放。
refcount
refcount 与共享对象:refcount 记录的是该对象被引用的次数,类型为整型。refcount 的作用,主要在于对象的引用计数和内存回收。
当创建新对象时,refcount 初始化为 1;当有新程序使用该对象时,refcount 加 1;当对象不再被一个新程序使用时,refcount 减 1;当 refcount 变为 0 时,对象占用的内存会被释放。
Redis 中被多次使用的对象(refcount>1),称为共享对象。Redis 为了节省内存,当有一些对象重复出现时,新的程序不会创建新的对象,而是仍然使用原来的对象。这个被重复使用的对象,就是共享对象。目前共享对象仅支持整数值的字符串对象。共享对象的引用次数可以通过 object refcount 命令查看,如下所示。命令执行的结果页佐证了只有0~9999 之间的整数会作为共享对象。
1 | 127.0.0.1:6379> object refcount a1 (integer) 2147483647 |
ptr 指针指向具体的数据,比如:set hello world,ptr 指向包含字符串 world 的 SDS。