redissds（redis sds）

本篇文章给大家谈谈redissds，以及redis sds对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、Redis的五种数据结构及其底层实现原理
• 2、要懂redis，首先得看懂sds（全网最细节的sds讲解）
• 3、Redis五个基本数据类型详解
• 4、Redis底层数据结构之string
• 5、Redis --- 八种数据类型（基本命令）
• 6、Redis的内存优化

Redis的五种数据结构及其底层实现原理

redis的字符串类型是由一种叫做简单动态字符串(SDS)的数据类型来实现

SDC和C语言字符串的区别：

1：SDS保存了字符串的长度，而C语言不保存，盯棚凯只能遍历找到第一个\0的结束符才能确定字符串的长度

2：修改SDS，会检查空间是否足够，不足会先扩展空间，防止缓冲区溢出，C字符串不会检查

3：SDS的预分配空间机制，可以减少为字符串重新分配空间的次数

备注：重新分配空间方式，小于1M的数据 翻倍+1，例如：13K+13K+1，如果大于1M，每次多分配1M，例如：10M+1M+1,如果字符串变短，并不会立即缩短，而是采用惰性空间释放，有专门的API可以释放多余空间

hash结构里其实是一个字典，有许多的键值对

redis的哈希表是一个dictht结构体：

哈希表节点的结构体如下：

hash算法：

当要将一个新的键值对添加到字典里面时， 程序需要先根据键值对的键计算出哈希值和索引值， 然后再根据索引值， 将包含新键值对的哈希表节点放到哈希表数组的指定索引上面。

hash冲突解决方式：链表法，后入的放到最前面

rehash：

键值数据量变动时，时为了让哈希表的负载因子（load factor）维持在一个合理的范围之内， 当哈希表保存的键值对数量太多或者太少时， 程序需要对哈希表的大小进行相应的扩展或和仿者收缩。

如果是扩充，新数组的空间大小为 大于2*used的2的n次方，比如：used=5,则去大于10的第一个2的n次方，为16

如果是缩小，新数组的空间大小为第一个不大于used的2的n次方，比如：used=5,则新大小为4

redis的list列表是使用双向链表来实现的

···

typedef struct listNode {

struct listNode * pre; //前置节点

struct listNode * next; //后置节点

void * value; //节点的值

}

typedef struct list {

listNode *head; //表头节点

listNode tail; //表尾节点

unsigned long len; //链表所包含的节点数量

void ( dup) (void ptr); //节点值赋值函数 这里有问题

void ( free) (void ptr); //节点值释放函数

int ( match) (void *ptr, void *key) //节点值对比函数

}

···

1：有序集合的底层实现之一是跳表， 除此之外跳表它在 Redis 中没有其他应用。

2：整数集合（intset）是集合键的底层实现之一： 当一个集合只包含整数值元素， 并且这个集合的元素数量不多时， Redis 就会使用整数集合作为集合键的底层实现。

3：数据少是，使用ziplist(压缩列表)，占用连续内存，每项元素都是(数据+score)的方式连续存储，按照score从小到大排序。ziplist为了节省内存，每个元素占用的空间可以不同，对于大数据(long long),就多用一些字节存储，而对于小的数据(short)，就少用一些字节来存储。因此查找的时候需要按顺序遍历。ziplist省内存但是查找效率低。

无序集合可以用整数集合(intset)或者凯唤字典实现

Redis的5.0版本中，放出一个新的数据结构Stream。其实也是一个队列，没一个不同的key对应的是不同的队列，没个队列的元素，也就是消息，都有一个msgid，并且需要保证msgid是严格递增的。在Stream当中，消息是默认持久化的，即便是Redis重启，也能够读取到信息。

Stream的多播，与其它队列系统相似，对不同的消费者，也有消费者Group这样的概念，不同的消费组，可以消费通一个消息，对于不同的消费组，都维护一个Idx下标，表示这一个消费群组费到了哪里，每次进行消费，都会更新一下这个下标，往后面一位进行偏移。

跳跃表是一种有序数据结构，它通过在每个节点中维持多个指向其它节点的指针，从而大道快速访问节点的目的，具有以下性质：

1：有很多层结构组成

2：每一层都是一个有序的链表，排列顺序为由高到低，都至少包含两个链表节点，分别是前面的head节点和后面的nil节点

3：最底层的链表包含了所有的元素

4：如果一个元素出现在某一层的链表中，那么在该层之下的链表也全部都会出现

5：链表中的每个节点都包含两个指针，一个指向同一层的下一个链表节点，另一个指向下一层的通一个链表节点

多个跳跃表节点构成一个跳跃表

1：搜索，从最高层的链表节点开始，如果比当前节点要大和比当前层的下一个节点要小，那么则往下找，也及时和当前层的下一层的节点下一个节点

2：插入，首先确定插入的层数，有一种方法是抛一个硬币，如果是正面就累加，直到遇到反面为止，最后记录正面的次数作为插入的层数，当确定插入的层数K后，则需要将新元素插入从底层到K层

3：删除，在各个层中找到包含指定值得节点，然后将节点从链表中删除即可，如果删除以后只剩下头尾两个节点，则删除这一层。

整数集合是Redis用于保存整数值集合的抽象数据类型，它可以保存int16_t、int32_t、int64_t的整数值，并且保证集合中不会出现重复元素。

整数集合的每个元素都是contents数组的一个数据项，他们按照从小到大的顺序排列，并且不包含任何重复项。

length属性记录了contents数组的大小。

需要注意的是虽然contents数组声明为int8_t类型，但是实际上contents数组并不保存任何int8_t类型的值，其真正类型由encoding来决定。

压缩列表(ziplist)是Redis为了节省内存而开发的，是由一系列特殊编码的连续内存块组成的顺序型数据结构，一个压缩列表可以包含任意多个节点(entry)，每个节点可以保存一个字节数组或一个整数值。

压缩列表的原理：压缩列表并不是对数据利用某种算法进行压缩的，而是将数据按照一定规则编码在一块连续的内存区域，目的是节省内存。

压缩列表的每个节点构成如下：

要懂redis，首先得看懂sds（全网最细节的sds讲解）

sds.h

可以看到sds 这种结构在不同长度下，大体的结构是相同，唯一不同的 sdshdr5也没用到过。

上面主要讲了sds是如何扩容的，可以看到sds的最大特点是可以预分配内存，在扩容方面也非常的高效。不用复制来复制去

在宏返闷看下面之前首先要对内存对齐有个基本概念，为什么要内存对齐了，这里就涉及到cpu的工作原理相关了，可以百度cpu工作原理，主要是跟内存地址和世绝寄存器的映射关系有关，但是有两条定理可以在这里了解。

可以看到不同类型的sds 下面，pad 的位数也是不同的，那么我们要从sds 指针位置访问到flag，在不知道类型的情况下是不可能了，那么有同学又要发问了，去掉sdshdr8的结构不就行了吗，从理论来说这样牺牲的内存也不会太多，也保证了性能，但是这仅仅是在32位系统下面的结构，如果在64位系统，那可能又是另外一个结构了。 好的那么有同学又要说了 我们能不能把指针放到flag开始的位置。答案也是不能，1，这样我们就没办法完美兼容string，蔽弯 2， 这样我们也会引入各种类型判断调整，所以redis 最后还是用到内存不对齐这个方案。

Redis五个基本数据类型详解

docker pull redis

docker run -p 6379:6379 --name redis -v {路径}/redis.conf:/etc/redis/redis.conf -v {路径}/data:/data -d redis redis-server /etc/redis/redis.conf --appendonly yes

如果在setnx之后执行expire之前进程意外crash或者要重启维护了，那会怎么样？

set指令有非常复杂的参数，这个应该是可以同时把setnx和expire合成圆好厅一条指令来用的！后面会讲具体怎么做。

下面是sds定义

而对于SDS，由于len属性和free属性的存在，对于修改字符串SDS实现了空间预分配和惰性空间释放两种策略：

1、空间预分配：对字符串进行空间扩展的时候，扩展的内存比实际需要的多，这样可橘隐以减少连续执行字符串增长操作所需的内存重分配次数。

2、惰性空间释放：对字符串进行缩短操作时，程序不立即使用内存重新分配来回收缩短后多余的字节，而是使用 free 属性将这些字节的数量记录下来，等待后续使用。（当然SDS也提供了相应的API，当我们有需要袜磨时，也可以手动释放这些未使用的空间。）

在原来的单链表基础上，我们查询数据需要从头遍历到尾，时间复杂度太高了。我们在思考提高查询效率时，在原有链表上添加索引，如果还是觉得查询太慢我们又在索引上再增加一级索引，以此类推。跳跃表的实质就是在单链表上一级一级地增加索引来达到加快查询的目的。

参考：

[img]

Redis底层数据结构之string

我们都知道， Redis 是由 C 语言编写的。在 C 语言中，字符串标准形式是以空字符 \0 作为结束符的，但是 Redis 里面的字符串却没有直接沿用 C 语言的字符串。主要是因为 C 语言中获取字符串长度可以调用 strlen 这个标准函数，这个函数的时间复杂度是 O(N) ，由于 Redis 是单线程的，承受不了这个时间复杂度。

在上一篇文亮亏章中，我们介绍了 Redis 的 RedisObject 的数据结构，如下所示：

对于不同的对象， Redis 会使用不同的类型来存储。对于同一种类型 type 会有不同的存储形式 encoding 。对于 string 类型的字符串，其底层编码方式共有三种，分别为 int 、 embstr 和 raw 。

使用 object encoding key 可以查看 key 对应的 encoding 类型，如下所示：

对于 embstr 和 raw 这两种 encoding 类型，其存储方式还不太一样。对于 embstr 类型，它将 RedisObject 对象头和 SDS 对象在内存中地址是连在一起的，但对于派亩 raw 类型，二者在内存地址不是连续的。

在介绍 string 类型的存储类型时，我们说到，对于 embstr 和 raw 两种类型其存储方式不一样，但 ptr 指针最后都指向一个 SDS 的结构。那什么是 SDS 呢？ Redis 中的字符串称之为 Simple Dynamic String ，简称为 SDS 。与普通 C 语言的原始字符串结构相比， sds 多了一个 sdshdr 的头部信息， sdshdr 基本数据结构如下所示：

可以看出， SDS 的结构有点类似于 Java 中的 ArrayList 。 buf[] 表示真正存储的字符串内容， alloc 表示所分配的数组的长度， len 表示字符串的实际长度，并且由于 len 这个属性的存在， Redis 可以在 O(1) 的时间复杂度内获取数组长度。

为了追求对于内存的极致优化，对于不同长度的字符串， Redis 底层会采用不同的结构体来表示。在 Redis 中的 sds.h 源码中存在着五种 sdshdr ，分别如下：

上面说了， Redis 底层会根据字符串的长度来决定具体使用哪种类型的 sdshdr 。可以看出， sdshdr5 明显区别于其他四种结构，它一般只用于存储长度不会变化，且长度小于32个字符的字符串。但现在一般都不再使用该结构， 因为其结构没有 len 和 alloc 这两个属性,不具备动态扩容操作 ，一旦预分配的内存空间使用完，就需要重新分配内存并完成数据的复制和迁移，类似于 ArrayList 的扩容操作，这种操作对性能的影响很大。

上面介绍 sdshdr 属性的时候说过， flag 这个属性用于标识使用哪种 sdshdr 类型， flag 的低三位标识当前 sds 的类型，分别如下所示：

同时，注意到在每个 sdshdr 的头定义上都有一个 attribute((packed)) ，这个是为了告诉 gcc 取消优化对齐 ，这样，每个字段分配的内存地址就是 紧紧排列在一起的 ， Redis 中字符串参数的传递直接使用 char* 指针，其实现原理在于，由于 sdshdr 内存分配禁止了优化对齐，所以 sds[-1] 指向的就是 flags 属性的内存地址，而通过 flags 属性又可以确定 sdshdr 的属性，进而可以读取头部字段确定 sds 的相关属性。

sds的逻辑图如下所示：

相比较于 C 语言原始的字符串，尘键森 sdshdr 的具备一些优势。

由于 sdshdr 中存在 len 这个属性，所以可以在 O(1) 的时间复杂度下获得长度；而传统的 C 语言得使用 strlen 这个标准函数获取，时间复杂度为 O(N) 。

原始的 C 语言一直使用与长度匹配的内存，这样在追加字符串导致字符串长度发生变化时，就必须进行内存的重新分配。内存重新分配涉及到复杂算法和系统调用，耗费性能和时间。对于 Redis 来说，它是单线程的，如果使用原始的字符串结构，势必会引发频繁的内存重分配，这个显然是不合理的。

因而， sds 每次进行内存分配时，都会通过内存的预分配来减少因为修改字符串而引发的内存重分配次数。这个原理可以参数 Java 中的 ArrayList ，一般在使用 ArrayList 时都会建议使用带有容量的构造方式，这样可以避免频繁 resize 。

对于 SDS 来说，当其使用 append 进行字符串追加时，程序会用 alloc-len 比较下剩下的空余内存是否足够分配追加的内容 ，如果不够自然触发内存重分配，而如果剩余未使用内存空间足够放下，那么将直接进行分配，无需内存重分配。其扩容策略为， 当字符串占用大小小于1M时，每次分配为 len * 2，也就是保留100%的冗余；大于1M后，为了避免浪费，只多分配1M的空间。

通过这种预分配策略， SDS 将连续增长 N 次字符串所需的内存重分配次数 从必定 N 次降低为最多 N 次。

缓冲区溢出是指当某个数据超过了处理程序限制的范围时，程序出现的异常操作。 原始的 C 语言中，是由编码者自己来分配字符串的内存，当出现内存分配不足时就会发生 缓存区溢出 。而 sds 的修改函数在修改前会判断内存，动态的分配内存，杜绝了 缓冲区溢出 的可能性。

对于原始的 C 语言字符串来说，它会通过判断当前字符串中是否存在空字符 \0 来确定是否已经是字符串的结尾。因而在某些情况下，如使用空格进行分割一段字符串时，或者是图片或者视频等二进制文件中存在 \0 等，就会出问题。而 sds 不是通过空字符串来判断字符串是否已经到结尾，而是通过 len 这个字段的值。所以说， sds 还具备 二进制安全 这个特性，即可以安全的存储具有特殊格式的二进制数据。

Redis --- 八种数据类型（基本命令）

String、Hash、List、Set和Zset。

等同于java中的， MapString,String string 是redis里面的最基本的数据类型，一个key对应一个value。

应用场景 ：String是最常用的一种数据类型，普通的key/value存储都可以归为此类，如用户信息，登录信息和配置信息等；

实现方式 ：String在redis内部存储默认就是一个字符串，被redisObject所引用，当遇到incr、decr等操作（自增自减等原子操作）时会转成数值型进行计算，此时redisObject的encoding字段为int。

Redis虽然是用C语言写的，但却没有直接用C语言的字符串，而是自己实现了一套字符串。目的就是为了提升速度，提升性能。 Redis构建了一个叫做简单动态字符串（Simple Dynamic String），简称SDS。

Redis的字符串也会遵守C语言的字符串的实现规则，即 最后一个字符为空字符。然而这个空并搭字符不会被计算在len里头。

Redis动态扩展步骤：

Redis字符串的性能优势

常用命令 ：set/get/decr/incr/mget等，具体如下；

ps：计数器（字符串的内容为整数的时候可以使用），如 set number 1。

补充：

等同于java中的： MapString,MapString,String ，redis的hash是一个string类型的field和value的映射表， 特别适合存储对象。 在redis中，hash因为是一个集合，所以有两层。第一层是key：hash集合value，第二层是hashkey：string value。所以判断是否采用hash的时候可以参照有两层key的设计来做参考。并且注意的是， 设置过期时间只能在第一层的key上面设置。

应用场景 ：我们要存储一个用户信息对象数据，其中包括用户ID、用户姓名、年龄和生日，通过用户ID我们希望获取该用户的姓名或者年龄或者生日枝旅；

实现方式 ：Redis的Hash实际是内部存储的Value为一个HashMap，并提供了直接存取这个Map成员的接口。如，Key是用户ID, value是一个Map。 这个Map的key是成员的属性名，value是属性值 。这样对数据的修改和存取都可以直接通过其内部Map的Key(Redis里称内部Map的key为field), 也就是通过 key(用户ID) + field(属性标签) 就可以操作对应属性数据。 当前HashMap的实现有两种方式 ：当HashMap的成员比较少时Redis为了节省内存会采用类似一维数组的方式来紧凑存储，而不会采用真正的HashMap结构，这时对应的value的redisObject的encoding为zipmap，当成员数量增大时会自动转成猛蔽凳真正的HashMap,此时redisObject的encoding字段为int。

常用命令 ：hget/hset/hgetall等，具体如下：

等同于java中的 MapString,ListString ，list 底层是一个链表，在redis中，插入list中的值，只需要找到list的key即可，而不需要像hash一样插入两层的key。 list是一种有序的、可重复的集合。

应用场景 ：Redis list的应用场景非常多，也是Redis最重要的数据结构之一，比如twitter的关注列表，粉丝列表等都可以用Redis的list结构来实现；

实现方式 ：Redis list的实现为一个 双向链表 ，即可以支持反向查找和遍历，更方便操作，不过带来了部分额外的内存开销，Redis内部的很多实现，包括 发送缓冲队列 等也都是用的这个数据结构。

常用命令 ：lpush/rpush/lpop/rpop/lrange等，具体如下：

性能总结 :

它是一个字符串链表，left、right都可以插入添加。

等同于java中的 MapString,SetString ，Set 是一种无序的，不能重复的集合。并且在redis中，只有一个key它的底层由hashTable实现的，天生去重。

应用场景 ：Redis set对外提供的功能与list类似是一个列表的功能，特殊之处在于set是可以自动去重的，当你需要存储一个列表数据，又不希望出现重复数据时，set是一个很好的选择，并且 set提供了判断某个成员是否在一个set集合内的重要接口 ，这个也是list所不能提供的；如保存一些标签的名字。标签的名字不可以重复，顺序是可以无序的。

实现方式 ：set 的内部实现是一个 value永远为null的HashMap，实际就是通过计算hash的方式来快速排重的，这也是set能提供判断一个成员是否在集合内的原因。

常用命令 ：sadd/spop/smembers/sunion等，具体如下：

ZSet(Sorted Set：有序集合) 每个元素都会关联一个double类型的分数score，分数允许重复，集合元素按照score排序（ 当score相同的时候，会按照被插入的键的字典顺序进行排序 ），还可以通过 score 的范围来获取元素的列表。

应用场景 ：Redis sorted set的使用场景与set类似，区别是set不是自动有序的，而sorted set可以 通过用户额外提供一个优先级(score)的参数来为成员排序，并且是插入有序的，即自动排序。 当你需要一个有序的并且不重复的集合列表，那么可以选择sorted set数据结构，比如twitter 的public timeline可以以发表时间作为score来存储，这样获取时就是自动按时间排好序的。

底层实现 ： zset 是 Redis 提供的一个非常特别的数据结构，常用作排行榜等功能，以用户 id 为 value ，关注时间或者分数作为 score 进行排序。实现机制分别是 zipList 和 skipList 。规则如下：

zipList：满足以下两个条件

skipList：不满足以上两个条件时使用跳表、组合了hash和skipList

为什么用skiplist不用平衡树？

主要从内存占用、对范围查找的支持和实现难易程度这三方面总结的原因。

拓展：mysql为什么不用跳表？

常用命令 ：zadd/zrange/zrem/zcard等；

官网地址：

可以用来推算两地之间的距离，方圆半径内的人。

关于经度纬度的限制：

一般我们使用Hyperloglog做基数统计。

什么是基数？就是一个集合中不重复的数的个数。

集合A：{1,3,5,7,9,7}

集合B：{1,3,5,7,9}

AB集合的基数都是5

应用：统计网站的访问量（一个人访问网站很多次仍然算作一次）。

优点：占用的内存是固定的，找2^64次方个数的基数，只需要12KB内存。

缺点：有0.81%的错误率，可以忽略不计

概述： bitmap 存储的是连续的二进制数字（0 和 1），通过 bitmap, 只需要一个 bit 位来表示某个元素对应的值或者状态，key 就是对应元素本身 。 我们知道 8 个 bit 可以组成一个 byte，所以 bitmap 本身会极大的节省储存空间。

应用场景: 适合需要保存状态信息（比如是否签到、是否登录...）并需要进一步对这些信息进行分析的场景。比如用户签到情况、活跃用户情况、用户行为统计（比如是否点赞过某个视频）。

针对上面提到的一些场景，这里进行进一步说明。

使用场景一：用户行为分析 很多网站为了分析你的喜好，需要研究你点赞过的内容。

使用场景二：统计活跃用户

使用时间作为 key，然后用户 ID 为 offset，如果当日活跃过就设置为 1

那么我该如果计算某几天/月/年的活跃用户呢(暂且约定，统计时间内只有有一天在线就称为活跃)，有请下一个 redis 的命令

使用场景三：用户在线状态

对于获取或者统计用户在线状态，使用 bitmap 是一个节约空间效率又高的一种方法。

只需要一个 key，然后用户 ID 为 offset，如果在线就设置为 1，不在线就设置为 0。

补充 ：

巨人的肩膀：

Redis的内存优化

一. redisObject对象

二. 缩减键值对象

三. 共享对象池

四. 字符串优化

五. 编码优化

六. 控制key的数量

Redis存储的所有值对象在内部定义为redisObject结构体，内部结构如下图所示。

表示当前对象使用的数据类型，Redis主要支持5种数据类型:string,hash,list,set,zset。可以使用type {key}命令查看对象所属类型，type命令返回的是值对象类型，键都是string类型。

表示Redis内部编码类型，encoding在Redis内部使用，代表当前对象内部采用哪种数据结构实现。理解Redis内部编码方式对于优化内存非常重要 ，同一个对象采用不同的编码实现内存占用存在明显差异，具体细节见之后编码优化部分。

记录对象最后一次被访问的时间，当配置了 maxmemory和maxmemory-policy=volatile-lru | allkeys-lru 时， 用于辅助LRU算法删除键数据。可以使用object idletime {key}命令在不更新lru字段情况下查看当前键的空闲时纯茄答间。

记录当前对象被引用的次数，用于通过引用次数回收内存，当refcount=0时，可以安全回收当前对象空间。使用object refcount {key}获取当前对象引用。当对象为整数且范围在[0-9999]时，Redis可以使用共享对象的方式来节省内存。具体细节见之后共享对象池部分。

与对象的数据内容相关，如果是整数直接存储数据，否则表示指向数据的指针。Redis在3.0之后对值对象是字符串且长度=39字节的数据，内部编码为embstr类型，字符串sds和redisObject一起分配，从而只要一次内存操作。

降低Redis内存使用最直接的方式就是缩减键（key）和值（value）的长度。

其中java-built-in-serializer表示JAVA内置序列化方式，更多数据见jvm-serializers项目: ，其它语言也有各自对应的高效序列化工具。

值对象除了存储二进制数据之外，通常还会使用通用格式存储数据比如:json，xml等作为字符串存储在Redis中。这种方式优点是方便调试和跨语言，但是同样的数据相比字节数组所需的空间更大，在内存紧张的情况下，可以使用通用压缩算法压缩json,xml后再存入Redis，从而降低内存占用，例如使用GZIP压缩后的json可降低约60%的空间。

对象共享池指Redis内部维护[0-9999]的整数对象池。创建大量的整数类型redisObject存在内存开销，每个redisObject内部结构至少占16字节，甚至超过了整数自身空间消耗。所以Redis内存维护一个[0-9999]的整数对象池，用于节约内存。 除了整数值对象，其他类型如list,hash,set,zset内部元素也可以使用整数对象池。因此开发中在满足需求的前提下，尽量使用整数对象以节省内存。

整数对象池在Redis中通过变量REDIS_SHARED_INTEGERS定义，不能通过配置修改做慧。可以通过object refcount 命令查看对象引用数验证是否启用整数对象池技术，如下:

设置键foo等于100时，直接使用共享池内整数对象，因此引用数是2，再设置键bar等于100时，引用数又变为3，如下图所示。

使用整数对象池究竟能降低多少内存？让我们通过测试来对比对象池的内存优化效果，如下表所示。

使用共享对象池后，相同的数据内存使用降低30%以上。可见当数据大量使用[0-9999]的整数时，纳烂共享对象池可以节约大量内存。需要注意的是对象池并不是只要存储[0-9999]的整数就可以工作。当设置maxmemory并启用LRU相关淘汰策略如:volatile-lru，allkeys-lru时，Redis禁止使用共享对象池，测试命令如下：

LRU算法需要获取对象最后被访问时间，以便淘汰最长未访问数据，每个对象最后访问时间存储在redisObject对象的lru字段。对象共享意味着多个引用共享同一个redisObject，这时lru字段也会被共享，导致无法获取每个对象的最后访问时间。如果没有设置maxmemory，直到内存被用尽Redis也不会触发内存回收，所以共享对象池可以正常工作。

综上所述，共享对象池与maxmemory+LRU策略冲突，使用时需要注意。 对于ziplist编码的值对象，即使内部数据为整数也无法使用共享对象池，因为ziplist使用压缩且内存连续的结构，对象共享判断成本过高，ziplist编码细节后面内容详细说明。

首先整数对象池复用的几率最大，其次对象共享的一个关键操作就是判断相等性，Redis之所以只有整数对象池，是因为整数比较算法时间复杂度为O(1)，只保留一万个整数为了防止对象池浪费。如果是字符串判断相等性，时间复杂度变为O(n)，特别是长字符串更消耗性能(浮点数在Redis内部使用字符串存储)。对于更复杂的数据结构如hash,list等，相等性判断需要O(n2)。对于单线程的Redis来说，这样的开销显然不合理，因此Redis只保留整数共享对象池。

字符串对象是Redis内部最常用的数据类型。所有的键都是字符串类型， 值对象数据除了整数之外都使用字符串存储。比如执行命令:lpush cache:type “redis” “memcache” “tair” “levelDB” ，Redis首先创建”cache:type”键字符串，然后创建链表对象，链表对象内再包含四个字符串对象，排除Redis内部用到的字符串对象之外至少创建5个字符串对象。可见字符串对象在Redis内部使用非常广泛，因此深刻理解Redis字符串对于内存优化非常有帮助:

Redis没有采用原生C语言的字符串类型而是自己实现了字符串结构，内部简单动态字符串(simple dynamic string)，简称SDS。结构下图所示。

Redis自身实现的字符串结构有如下特点:

因为字符串(SDS)存在预分配机制，日常开发中要小心预分配带来的内存浪费，例如下表的测试用例。

从测试数据可以看出，同样的数据追加后内存消耗非常严重，下面我们结合图来分析这一现象。阶段1每个字符串对象空间占用如下图所示。

阶段1插入新的字符串后，free字段保留空间为0，总占用空间=实际占用空间+1字节，最后1字节保存‘\0’标示结尾，这里忽略int类型len和free字段消耗的8字节。在阶段1原有字符串上追加60字节数据空间占用如下图所示。

追加操作后字符串对象预分配了一倍容量作为预留空间，而且大量追加操作需要内存重新分配，造成内存碎片率(mem_fragmentation_ratio)上升。直接插入与阶段2相同数据的空间占用，如下图所示。

阶段3直接插入同等数据后，相比阶段2节省了每个字符串对象预分配的空间，同时降低了碎片率。

字符串之所以采用预分配的方式是防止修改操作需要不断重分配内存和字节数据拷贝。但同样也会造成内存的浪费。字符串预分配每次并不都是翻倍扩容，空间预分配规则如下:

字符串重构:指不一定把每份数据作为字符串整体存储，像json这样的数据可以使用hash结构，使用二级结构存储也能帮我们节省内存。同时可以使用hmget,hmset命令支持字段的部分读取修改，而不用每次整体存取。例如下面的json数据：

分别使用字符串和hash结构测试内存表现，如下表所示。

根据测试结构，第一次默认配置下使用hash类型，内存消耗不但没有降低反而比字符串存储多出2倍，而调整hash-max-ziplist-value=66之后内存降低为535.60M。因为json的videoAlbumPic属性长度是65，而hash-max-ziplist-value默认值是64，Redis采用hashtable编码方式，反而消耗了大量内存。调整配置后hash类型内部编码方式变为ziplist，相比字符串更省内存且支持属性的部分操作。下一节将具体介绍ziplist编码优化细节。

Redis对外提供了string,list,hash,set,zet等类型，但是Redis内部针对不同类型存在编码的概念，所谓编码就是具体使用哪种底层数据结构来实现。编码不同将直接影响数据的内存占用和读写效率。使用object encoding {key}命令获取编码类型。如下:

Redis针对每种数据类型(type)可以采用至少两种编码方式来实现，下表表示type和encoding的对应关系。

了解编码和类型对应关系之后，我们不禁疑惑Redis为什么需要对一种数据结构实现多种编码方式？

主要原因是Redis作者想通过不同编码实现效率和空间的平衡。比如当我们的存储只有10个元素的列表，当使用双向链表数据结构时，必然需要维护大量的内部字段如每个元素需要:前置指针，后置指针，数据指针等，造成空间浪费，如果采用连续内存结构的压缩列表(ziplist)，将会节省大量内存，而由于数据长度较小，存取操作时间复杂度即使为O(n2)性能也可满足需求。

Redis内存优化

编码类型转换在Redis写入数据时自动完成，这个转换过程是不可逆的，转换规则只能从小内存编码向大内存编码转换。例如：

以上命令体现了list类型编码的转换过程，其中Redis之所以不支持编码回退，主要是数据增删频繁时，数据向压缩编码转换非常消耗CPU，得不偿失。以上示例用到了list-max-ziplist-entries参数，这个参数用来决定列表长度在多少范围内使用ziplist编码。当然还有其它参数控制各种数据类型的编码，如下表所示：

掌握编码转换机制，对我们通过编码来优化内存使用非常有帮助。下面以hash类型为例，介绍编码转换的运行流程，如下图所示。

理解编码转换流程和相关配置之后，可以使用config set命令设置编码相关参数来满足使用压缩编码的条件。对于已经采用非压缩编码类型的数据如hashtable,linkedlist等，设置参数后即使数据满足压缩编码条件，Redis也不会做转换，需要重启Redis重新加载数据才能完成转换。

ziplist编码主要目的是为了节约内存，因此所有数据都是采用线性连续的内存结构。ziplist编码是应用范围最广的一种，可以分别作为hash、list、zset类型的底层数据结构实现。首先从ziplist编码结构开始分析，它的内部结构类似这样:….。一个ziplist可以包含多个entry(元素)，每个entry保存具体的数据(整数或者字节数组)，内部结构如下图所示。

ziplist结构字段含义：

根据以上对ziplist字段说明，可以分析出该数据结构特点如下:

下面通过测试展示ziplist编码在不同类型中内存和速度的表现，如下表所示。

测试数据采用100W个36字节数据，划分为1000个键，每个类型长度统一为1000。从测试结果可以看出：

intset编码是集合(set)类型编码的一种，内部表现为存储有序，不重复的整数集。当集合只包含整数且长度不超过set-max-intset-entries配置时被启用。执行以下命令查看intset表现：

以上命令可以看出intset对写入整数进行排序，通过O(log(n))时间复杂度实现查找和去重操作，intset编码结构如下图所示。

intset的字段结构含义：

根据以上测试结果发现intset表现非常好，同样的数据内存占用只有不到hashtable编码的十分之一。intset数据结构插入命令复杂度为O(n)，查询命令为O(log(n))，由于整数占用空间非常小，所以在集合长度可控的基础上，写入命令执行速度也会非常快，因此当使用整数集合时尽量使用intset编码。上表测试第三行把ziplist-hash类型也放入其中，主要因为intset编码必须存储整数，当集合内保存非整数数据时，无法使用intset实现内存优化。这时可以使用ziplist-hash类型对象模拟集合类型，hash的field当作集合中的元素，value设置为1字节占位符即可。使用ziplist编码的hash类型依然比使用hashtable编码的集合节省大量内存。

当使用Redis存储大量数据时，通常会存在大量键，过多的键同样会消耗大量内存。Redis本质是一个数据结构服务器，它为我们提供多种数据结构，如hash，list，set，zset 等结构。使用Redis时不要进入一个误区，大量使用get/set这样的API，把Redis当成Memcached使用。对于存储相同的数据内容利用Redis的数据结构降低外层键的数量，也可以节省大量内存。如下图所示，通过在客户端预估键规模，把大量键分组映射到多个hash结构中降低键的数量。

hash结构降低键数量分析：

通过这个测试数据，可以说明：

关于hash键和field键的设计：

使用hash结构控制键的规模虽然可以大幅降低内存，但同样会带来问题，需要提前做好规避处理。如下:

本文主要讲解Redis内存优化技巧，Redis的数据特性是”ALL IN MEMORY”，优化内存将变得非常重要。对于内存优化建议读者先要掌握Redis内存存储的特性比如字符串，压缩编码，整数集合等，再根据数据规模和所用命令需求去调整，从而达到空间和效率的最佳平衡。建议使用Redis存储大量数据时，把内存优化环节加入到前期设计阶段，否则数据大幅增长后，开发人员需要面对重新优化内存所带来开发和数据迁移的双重成本。当Redis内存不足时，首先考虑的问题不是加机器做水平扩展，应该先尝试做内存优化。当遇到瓶颈时，再去考虑水平扩展。即使对于集群化方案，垂直层面优化也同样重要，避免不必要的资源浪费和集群化后的管理成本。

关于redissds和redis sds的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。