Redis2 内存划分及数据存储

Miaoshuowen

已于 2022-03-28 23:15:17 修改

阅读量522

点赞数

分类专栏： # Redis 文章标签： redis Redis内存

于 2022-03-24 23:04:32 首次发布

本文链接：https://blog.csdn.net/Miaoshuowen/article/details/123722977

版权

Redis 专栏收录该内容

9 篇文章 0 订阅

订阅专栏

一、Redis内存统计

在客户端通过redis-cli连接服务器后（后面如无特殊说明，客户端一律使用redis-cli），通过info命令可以查看内存使用情况：

127.0.0.1:6379> info memory 
# Memory #Redis分配的内存总量,包括虚拟内存(字节) 
used_memory:853464 
#占操作系统的内存，不包括虚拟内存(字节) 
used_memory_rss:12247040 
#内存碎片比例 如果小于0说明使用了虚拟内存 
mem_fragmentation_ratio:15.07 
#Redis使用的内存分配器 
mem_allocator:jemalloc-5.1.0

used_memory：

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

used_memory_rss：

Redis进程占据操作系统的内存（单位是字节），与top及ps命令看到的值是一致的；除了分配器分配的内存之外，used_memory_rss还包括进程运行本身需要的内存、内存碎片等，但是不包括虚拟内存。
因此，used_memory和used_memory_rss，前者是从Redis角度得到的量，后者是从操作系统角度得到的量。二者之所以有所不同，一方面是因为内存碎片和Redis进程运行需要占用内存，使得前者可能比后者小，另一方面虚拟内存的存在，使得前者可能比后者大。
由于在实际应用中，Redis的数据量会比较大，此时进程运行占用的内存与Redis数据量和内存碎片相比，都会小得多；因此used_memory_rss和used_memory的比例，便成了衡量Redis内存碎片率的参数；这个参数就是mem_fragmentation_ratio。

mem_fragmentation_ratio

内存碎片比率，该值是used_memory_rss / used_memory的比值。
mem_fragmentation_ratio一般大于1，且该值越大，内存碎片比例越大。
mem_fragmentation_ratio<1，说明Redis使用了虚拟内存（swap），由于虚拟内存的媒介是磁盘，比内存速度要慢很多，当这种情况出现时，应该及时排查，如果内存不足应该及时处理，如增加Redis节点、增加Redis服务器的内存、优化应用等。
一般来说，mem_fragmentation_ratio在1.03左右是比较健康的状态（对于jemalloc来说）；mem_fragmentation_ratio值很大，是因为还没有向Redis中存入数据，Redis进程本身运行的内存使得used_memory_rss比used_memory大得多。

mem_allocator：

Redis使用的内存分配器，在编译时指定；可以是 libc 、jemalloc或者
tcmalloc，默认是jemalloc；

二、Redis 内存划分

Redis作为内存数据库，在内存中存储的内容主要是数据（键值对）；通过前面的叙述可以知道，除了数据以外，Redis的其他部分也会占用内存。
Redis的内存占用主要可以划分为以下几个部分：

数据

作为数据库，数据是最主要的部分；这部分占用的内存会统计在used_memory中。
Redis使用键值对存储数据，其中的值（对象）包括5种类型，即字符串、哈希、列表、集合、有序集合。这5种类型是Redis对外提供的，实际上，在Redis内部，每种类型可能有2种或更多的内部编码实现；此外，Redis在存储对象时，并不是直接将数据扔进内存，而是会对对象进行各种包装：如redisObject、SDS等；这篇文章后面将重点介绍Redis中数据存储的细节。

进程内存

Redis主进程本身运行肯定需要占用内存，如代码、常量池等等；这部分内存大约几兆，在大多数生产环境中与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中。
内存碎片的产生与对数据进行的操作、数据的特点等都有关；此外，与使用的内存分配器也有关系：如果内存分配器设计合理，可以尽可能的减少内存碎片的产生。后面将要说到的jemalloc便在控制内存碎片方面做的很好。
如果Redis服务器中的内存碎片已经很大，可以通过安全重启的方式减小内存碎片：因为重启之后，Redis重新从备份文件中读取数据，在内存中进行重排，为每个数据重新选择合适的内存单元，减小内
存碎片。

三、Redis数据存储的细节

Redis是一个K-V NoSQL非关系型数据库。 Redis有五种数据类型，分别string类、hash类型、list类型、set类型、zset类型。这五种类型，都是针对K-V中的V进行设计的。

1、概述

关于Redis数据存储的细节，涉及到内存分配器（如jemalloc）、简单动态字符串（SDS）、5种对象类型及内部编码、redisObject。在讲述具体内容之前，先说明一下这几个概念之间的关系。
下图是执行set hello world时，所涉及到的数据模型。
在这里插入图片描述

（1）dictEntry

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

（2）Key

图中右上角可见，Key（”hello”）并不是直接以字符串存储，而是存储在SDS结构中。
Redis是一个K-V NoSQL非关系型数据库。 Redis有五种数据类型，分别string类、hash类型、list类型、set类型、zset类型。这五种类型，都是针对K-V中的V进行设计的。

（3）redisObject

Value(“world”)既不是直接以字符串存储，也不是像Key一样直接存储在SDS中，而
是存储在redisObject中。实际上，不论Value是5种类型的哪一种，都是通过redisObject来存储的；而redisObject中的type字段指明了Value对象的类型，ptr字段则指向对象所在的地址。不过可以看出，字符串对象虽然经过了redisObject的包装，但仍然需要通过SDS存储。
实际上，redisObject除了type和ptr字段以外，还有其他字段图中没有给出，如用于指定对象内部编码的字段；后面会详细介绍。

（4）jemalloc

无论是DictEntry对象，还是redisObject、SDS对象，都需要内存分配器（如
jemalloc）分配内存进行存储。以DictEntry对象为例，有3个指针组成，在64位机器下占24个字节，jemalloc会为它分配32字节大小的内存单元。
下面来分别介绍jemalloc、redisObject、SDS、对象类型及内部编码。

2、jemalloc

Redis在编译时便会指定内存分配器；内存分配器可以是 libc 、jemalloc或者tcmalloc，默认是jemalloc。

jemalloc作为Redis的默认内存分配器，在减小内存碎片方面做的相对比较好。jemalloc在64位系统中，将内存空间划分为小、大、巨大三个范围；每个范围内又划分了许多小的内存块单位；当Redis存储数据时，会选择大小最合适的内存块进行存储。

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

在这里插入图片描述

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

3、redisObject

前面说到，Redis对象有5种类型；无论是哪种类型，Redis都不会直接存储，而是通过redisObject对象进行存储。
redisObject对象非常重要，Redis对象的类型、内部编码、内存回收、共享对象等功能，都需要redisObject支持，下面将通过redisObject的结构来说明它是如何起作用的。redisObject的定义如下（列出了与保存数据有关的三个属性）：

`typedef` `struct` `redisObject {`` 
	unsigned type:4;`` 
	unsigned encoding:4;`` 
	unsigned lru:REDIS_LRU_BITS; `` 
	/* lru time (relative to server.lruclock) */`` ` 
	`int` `refcount;`` `
	`void` `*ptr;``
	}
 robj;`

redisObject的每个字段的含义和作用如下：

（1）type

type字段表示对象的类型，占4个比特；目前包括REDIS_STRING(字符串)、REDIS_LIST (列表)、REDIS_HASH(哈希)、REDIS_SET(集合)、REDIS_ZSET(有序集合)。
当我们执行type命令时，便是通过读取RedisObject的type字段获得对象的类型；

（2）encoding

encoding表示对象的内部编码，占4个比特。
对于Redis支持的每种类型，都有至少两种内部编码，例如对于字符串，有int、embstr、raw三种编码。通过encoding属性，Redis可以根据不同的使用场景来为对象设置不同的编码，大大提高了Redis的灵活性和效率。以列表对象为例，有压缩列表和双端链表两种编码方式；如果列表中的元素较少，
Redis倾向于使用压缩列表进行存储，因为压缩列表占用内存更少，而且比双端链表可以更快载入；当列表对象元素较多时，压缩列表就会转化为更适合存储大量元素的双端链表。
通过object encoding命令，可以查看对象采用的编码方式；
5种对象类型对应的编码方式以及使用条件，将在下一篇文章介绍。

（3）lru

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会优先选择空转时间最长的对象进行释放。

（4）refcount

refcount与共享对象

refcount记录的是该对象被引用的次数，类型为整型。refcount的作用，主要在于对象的引用计数和内存回收。当创建新对象时，refcount初始化为1；当有新程序使用该对象时，refcount加1；当对象不再被一个新程序使用时，refcount减1；当refcount变为0时，对象占用的内存会被释放。
Redis中被多次使用的对象(refcount>1)，称为共享对象。Redis为了节省内存，当有一些对象重复出现时，新的程序不会创建新的对象，而是仍然使用原来的对象。这个被重复使用的对象，就是共享对象。目前共享对象仅支持整数值的字符串对象。

共享对象的具体实现

Redis的共享对象目前只支持整数值的字符串对象。之所以如此，实际上是对内存和CPU（时间）的平衡：共享对象虽然会降低内存消耗，但是判断两个对象是否相等却需要消耗额外的时间。对于整数值，判断操作复杂度为O(1)；对于普通字符串，判断复杂度为O(n)；而对于哈希、列表、集合和有序集合，判断的复杂度为O(n^2)。
虽然共享对象只能是整数值的字符串对象，但是5种类型都可能使用共享对象（如哈希、列表等的元素可以使用）。
就目前的实现来说，Redis服务器在初始化时，会创建10000个字符串对象，值分别是0-9999的整数值；当Redis需要使用值为0~9999的字符串对象时，可以直接使用这些共享对象。10000这个数字可以通过调整参数REDIS_SHARED_INTEGERS（4.0中是OBJ_SHARED_INTEGERS）的值进行改变。
共享对象的引用次数可以通过object refcount命令查看，如下图所示。命令执行的结果页佐证了只有0~9999之间的整数会作为共享对象。

（5）ptr

ptr指针指向具体的数据，如前面的例子中，set hello world，ptr指向包含字符串world的SDS。

（6）总结

综上所述，redisObject的结构与对象类型、编码、内存回收、共享对象都有关系；一个redisObject对象的大小为16字节：

4bit+4bit+24bit+4Byte+8Byte=16Byte。

4、SDS

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

（1）SDS结构

sds的结构如下：

`struct` `sdshdr {`` ``int` `len;`` ``int` `free``;`` ``char` `buf[];``};`

其中，buf表示字节数组，用来存储字符串；len表示buf已使用的长度，free表示buf未使用的长度。下面是两个例子。

通过SDS的结构可以看出，buf数组的长度=free+len+1（其中1表示字符串结尾的空字符）；所以，一个SDS结构占据的空间为：free所占长度+len所占长度+ buf数组的长度
=4+4+free+len+1=free+len+9。

（2）SDS与C字符串的比较

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’不一定是结尾）。

Miaoshuowen

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
Redis2 内存划分及数据存储

一、Redis内存统计在客户端通过redis-cli连接服务器后（后面如无特殊说明，客户端一律使用redis-cli），通过info命令可以查看内存使用情况：127.0.0.1:6379> info memory # Memory #Redis分配的内存总量,包括虚拟内存(字节) used_memory:853464 #占操作系统的内存，不包括虚拟内存(字节) used_memory_rss:12247040 #内存碎片比例如果小于0说明使用了虚拟内存 mem_fragmentati
复制链接

扫一扫