another redis desktop内存分析 redis内存模型

转载

mob64ca1403c772 2024-06-20 19:55:20

文章标签 redis Redis 字符串数据 文章分类 Redis 数据库

Redis学习（二）Redis内存模型

Redis内存统计

> info memory
# Memory
#Redis分配的内存总量，包括虚拟内存（字节）
used_memory：1696776
# 占操作系统的内存，不包括虚拟内存（字节）
used_memory_rss:3612672
# 内存比例碎片 如果小于0说明使用了虚拟内存
mem_fragmentation_ratio:2.18
# Redis使用的内存分配器
mem_allocator:jemalloc-5.1.0

Redis内存分配

数据

作为数据库，数据是主要的部分；这部分占用的内存会统计在used_memory中
Redis使用键值对存储数据，其中的值包含五中类型，即string、list、hash、set、zset
这5中类型是Redis对外提供的，实际上，在Redis内部，每种类型可能又有2种或多种的内部编码实现

进程

Redis主进程本身运行肯定是要占内存的，如代码、常量池等等，这部分内存大约几M，在大多数生产环境中Redis数据占用内存相比可以忽略。
这部分内存不是由jemalloc分配，因此不会统计在used_memory中
除了主进程，Redis创建的子进程也会占用内存，比如Redis执行AOF、RDB重写时创建的子进程，这部分也不属于Redis进程，也不会统计在used_memory和userd_memory_rss中

缓冲内存

缓冲内存包括客户端缓冲区、复制积压缓冲区、AOF缓冲区等；

客户端缓冲区存储客户端连接的输入输出缓冲；
复制积压缓冲区用于部分复制功能；
AOF缓冲区用于在进行AOF重写时，保存最近的写入命令；
这部分由内存jemalloc分配，会统计在used_memory中；

内存碎片

内存碎片是Redis在分配、回收物理内存过程中产生的。

例如：对数据频繁的修改，而且数据之间的大小相差很大，可能导致Redis释放的空间在物理内存中并没有释放，但Redis又无法有效的利用，这就形成了内存碎片，内存碎片不会统计在used_memory中

内存碎片的产生与对数据进行的操作、数据的特点等都有关；此外，与使用的内存分配器也有关系，如果内存分配器设计合理，可以尽少的减少内存碎片的产生。如果Redis服务器中的内存碎片已经很大，可以通过安全重启的方式减小内存碎片；因为重启后，Redis重新从备份文件中读取数据，在内存中进行重排，为每个数据重新选择合适的内存单元，减小内存碎片。

Redis数据结构

简单动态字符串（SDS）
Redis没有直接使用C字符串(即以空字符’\0’结尾的字符数组)作为默认的字符串表示，而是使用了SDS。SDS 是简单动态字符串(Simple Dynamic String)的缩写。它是自己构建了一种名为简单动态字符串（simple dynamic string,SDS）的抽象类型，并将 SDS 作为Redis的默认字符串表示。
SDS 定义：
struct sdshdr{ //记录buf数组中已使用字节的数量 //等于 SDS 保存字符串的长度 int len; //记录 buf 数组中未使用字节的数量 int free; //字节数组，用于保存字符串 char buf[]; }
我们看上面对于SDS数据类型的定义：
len保存了SDS保存字符串的长度
buf[]数组用来保存字符串的每个元素
free记录了buf数组中未使用的字节数量
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 用来存储文本数据时才可以这样使用，在存储二进制数据时则不行
链表
链表在Redis中的应用非常广泛，列表(List)的底层实现之一就是双向链表。此外发布与订阅、慢查询、监视器等功能也用到了链表。

typedef struct listNode {
    //前置节点
    struct listNode *prev;
    //后置节点
    struct listNode *next;
    //节点的值
    void *value;
}listNode


typedef struct list {
    //表头节点
    listNode.head;
    //表尾节点
    listNode.tail;
    //链表所包含的节点数量
    unsigned long len;
    //节点值复制函数
    void *(*dup)(void *ptr);
    //节点值释放函数
    void *(*free)(void *ptr);
    //节点值对比函数
    int (*match)(void *ptr,void *key);
} list;

Redis链表的优势：
双向：链表具有前置节点和后置节点的引用，获取这两个节点时间复杂度都为O(1)。单向：节点类保留下一节点的引用。链表类只保留头节点的引用，只能从头节点插入删除
无环：表头节点的 prev 指针和表尾节点的 next 指针都指向 NULL,对链表的访问都是以 NULL 结束
带链表长度计数器：通过 len 属性获取链表长度的时间复杂度为 O(1)。
多态：链表节点使用 void* 指针来保存节点值，可以保存各种不同类型的值。
字典
连接在一起的键k1和键k0
字典又称为符号表或者关联数组、或映射（map），是一种用于保存键值对的抽象数据结构。
字典中的每一个键 key 都是唯一的，通过 key 可以对值来进行查找或修改。
Redis 的字典使用哈希表作为底层实现。
哈希（作为一种数据结构），不仅是 Redis 对外提供的 5 种对象类型的一种（hash），也

• 是 Redis 作 为 Key-Value 数据库所使用的数据结构。
typedef struct dictht{
    //哈希表数组
    ictEntry **table;
    //哈希表大小
    unsigned long size;
    //哈希表大小掩码，用于计算索引值
    //总是等于 size-1
    unsigned long sizemask;
    //该哈希表已有节点的数量
    unsigned long used;
}dictht
/*哈希表是由数组 table 组成，table 中每个元素都是指向 dict.h/dictEntry 结构，
dictEntry 结构定义如下：
*/
typedef struct dictEntry{
    //键
    void *key;
    //值
    union{
    void *val;
    uint64_tu64;
    int64_ts64;
    }v;
    //指向下一个哈希表节点，形成链表
    struct dictEntry *next;
}dictEntry

跳跃表
普通单链表查询一个元素的时间复杂度为O(n)，即使该单链表是有序的。
查询查找46：55-21-55-37-55-46 大数从右找到头，小数就向下一层
插入
跳跃表的初始状态------>插入完成
以此类推，我们插入剩余的元素，当然因为规模小，结果可能不是一个理想的跳跃表，最理想的跳跃表是隔一个一跳
删除
直接删除元素，然后调整一下删除元素后的指针即可。跟普通的链表删除操作完全一样。

typedef struct zskiplistNode {
    //层
    struct zskiplistLevel{
    //前进指针
    struct zskiplistNode *forward;
    //跨度
    unsigned int span;
}level[];
//后退指针
struct zskiplistNode *backward;
    //分值
    double score;
    //成员对象
    robj *obj;
    } zskiplistNode
    --链表
    typedef struct zskiplist{
    //表头节点和表尾节点
    structz skiplistNode *header, *tail;
    //表中节点的数量
    unsigned long length;
    //表中层数最大的节点的层数
    int level;
}zskiplist;

搜索：从最高层的链表节点开始，如果比当前节点要大和比当前层的下一个节点要小，那么则往下找，也就是和当前层的下一层的节点的下一个节点进行比较，以此类推，一直找到最底层的最后一个节点，如果找到则返回，反之则返回空。
插入：首先确定插入的层数，有一种方法是假设抛一枚硬币，如果是正面就累加，直到遇见反面为止，最后记录正面的次数作为插入的层数。当确定插入的层数k后，则需要将新元素插入到从底层到k层。
删除：在各个层中找到包含指定值的节点，然后将节点从链表中删除即可，如果删除以后只剩下头尾两个节点，则删除这一层。
整数集合
整数集合（intset）是集合（set）的底层实现之一，当一个集合（set）只包含整数值元素，并且这个集合的元素不多时，Redis就会使用整数集合(intset)作为该集合的底层实现。整数集合（intset）是 Redis用于保存整数值的集合抽象数据类型，它可以保存类型为int16_t、int32_t 或者int64_t 的整数值，并且保证集合中不会出现重复元素。

typedef struct intset{
    //编码方式
    uint32_t encoding;
    //集合包含的元素数量
    uint32_t length;
    //保存元素的数组
    int8_t contents[];
}intset;

压缩列表
压缩列表（ziplist）是列表键和哈希键的底层实现之一。当一个列表只包含少量列表项时，并且每个列表项是小整数值或短字符串，那么Redis会使用压缩列表来做该列表的底层实现。压缩列表（ziplist）是Redis为了节省内存而开发的，是由一系列特殊编码的连续内存块组成的顺序型数据结构，一个压缩列表可以包含任意多个节点（entry），每个节点可以保存一个字节数组或者一个整数值。
放到一个连续内存区
previous_entry_ength：记录压缩列表前一个字节的长度。
encoding：节点的encoding保存的是节点的content的内容类型
content：content区域用于保存节点的内容，节点内容类型和长度由encoding决定。
对象
上面的是Redis的数据类型，Redis不是用这些数据结构直接实现Redis的键值对数据库，而是基于这些数据结构创建了一个对象系统。包含字符串对象，列表对象，哈希对象，集合对象和有序集合对象。根据对象的类型可以判断一个对象是否可以执行给定的命令，也可针对不同的使用场景，对象设置有多种不同的数据结构实现，从而优化对象在不同场景下的使用效率。
Redis中的每个对象都是由如下结构表示（列出了与保存数据有关的三个属性）

typedef struct redisObject {
    unsigned type:4;//类型 五种对象类型
    unsigned encoding:4;//编码
    void *ptr;//指向底层实现数据结构的指针
    //...
    int refcount;//引用计数
    //...
    unsigned lru:22;//记录最后一次被命令程序访问的时间
    //...
}robj;

type
type 字段表示对象的类型，占 4 个比特；目前包括 REDIS_STRING(字符串)、REDIS_LIST (列表)、 REDIS_HASH(哈希)、REDIS_SET(集合)、REDIS_ZSET(有序集合)。
当我们执行 type 命令时，便是通过读取 RedisObject 的 type 字段获得对象的类型
encoding
encoding 表示对象的内部编码，占 4 个比特。对于 Redis 支持的每种类型，都有至少两种内部编码，例如对于字符串，有 int、embstr、raw 三种编码。
通过 encoding 属性，Redis 可以根据不同的使用场景来为对象设置不同的编码，大大提高了 Redis 的灵活性和效率。
以列表对象为例，有压缩列表和双端链表两种编码方式；如果列表中的元素较少，Redis 倾向于使用压缩列表进行存储，因为压缩列表占用内存更少，而且比双端链表可以更快载入。
当列表对象元素较多时，压缩列表就会转化为更适合存储大量元素的双端链表。
通过 object encoding 命令，可以查看对象采用的编码方式。例：object encoding a1 “int”
lru
lru 记录的是对象最后一次被命令程序访问的时间，占据的比特数不同的版本有所不同（如 4.0 版本占 24 比特，2.6 版本占 22 比特）。
通过对比 lru 时间与当前时间，可以计算某个对象的空转时间；object idletime 命令可以显示该空转时间（单位是秒）。object idletime 命令的一个特殊之处在于它不改变对象的 lru 值。
ru 值除了通过 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 命令查看，如object refcount a1 (integer) 2147483647。命令执行的结果页佐证了只有 0~9999 之间的整数会作为共享对象。
ptr
ptr 指针指向具体的数据，比如：set hello world，ptr 指向包含字符串 world 的 SDS。
综上所述，RedisObject 的结构与对象类型、编码、内存回收、共享对象都有关系。

缓存淘汰策略

最大缓存

在Redis中，允许用户设置最大使用内存大小maxmemory，默认为0，指没有最大缓存，如果有新的数据添加，超过最大缓存，则会使Redis崩溃，所以一定要设置。
redis内存数据集大小上升到一定大小的时候，就会实行数据淘汰策略。

淘汰策略

Redis淘汰策略配置：maxmemory-policy voltile-lur，支持热配置

Redis提供6中诗句淘汰策略：

名称	描述
volatile-lru	从已经设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰
volatile-ttl	从已经设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰
volatile-random	从已经设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰
allkeys-lru	从数据集（serve.db[i].dict）中挑选最近最少使用的数据淘汰
allkeys-random	从数据集（server.db[i].dict）中任意选择数据淘汰
no-enviction(驱逐)	禁止驱逐数据