曾经看到这么一个案例，有一个团队需要开发一个图片存储系统，要求这个系统能快速记录图片id和图片存储对象id，同时还需要能够根据图片的id快速找到图片存储对象id。我们假设用10位数来表示图片id和图片存储对象id，例如图片的id为1101021043，它所对应的图片存储对象的id为2301010051，可以看到图片id和图片存储id正好是一一对应的，是典型的key-value形式，所以首先会想到直接使用string类型来保存数据。把图片id和图片存储id分别作为键值对的key和value来保存。但是随着存储的数据量越来越大，redis的内存的使用量也快速上升，结果遇到了大内存redis实例因为生成rdb而响应变慢的问题。很显然string类型并不是一种好的选择，
那有什么办法可以降低内存消耗吗？
string类型的数据结构
首先我们得先了解为什么string保存数据时所消耗的内存空间较大。在刚才的案例中，由于图片id和图片存储对象id都是10位数，我们可以用两个8字节的long类型来表示这两个id。所以一组图片id及其存储对象id的记录，实际只需要16字节就可以了。但是通过对redis内存分析，一组图片id及其存储对象id却占用了64字节，那为什么string类型会用64字节呢。其实，除了要记录实际的数据，string类型还需要额外的内存空间来记录数据的长度、空间使用信息等，这些信息也叫做元数据。当实际保存的数据较小时，元数据的空间开销就显的比较大了。我们先来看一下string类型是如何保存数据的。当你保存64位有符号的整数时，string类型会把它保存为一个8字节的long类型整数，这种保存方式通常也叫作int编码方式。但是，当你保存的数据中包含字符时，string类型就会用简单动态字符串结构体(sds)来保存。如下图所示：
- len：4个字节，表示buf的已用长度。
- alloc：4个字节，表示buf分配的长度，一般大于len。
- buf：字节数组，保存实际数据。为了表示数组的结尾，redis会自动在数组最后添加一个”\0″。
可以看到，在sds结构体中，除了有保存实际数据的buf，还有len和alloc的额外元数据的开销。另外对于string类型来说，除了sds的额外开销外，还有一个叫做redisobject结构体的开销。因为redis的数据类型有很多，不同的数据类型都有相同的元数据要记录（例如最后一次访问时间），所以redis会采用一个叫做redisobject结构体来统一记录这些元数据。一个redisobject包含了一个8字节的元数据和一个8字节的指针，这个指针指向具体数据所在，例如string类型的sds结构体所在的内存地址。如下图所示：
为了节省内存空间，redis对long类型整数和sds的内存布局做了专门的设计。一方面，当保存的是 long 类型整数时，redisobject 中的指针就直接赋值为整数数据了，这样就不用额外的指针再指向整数了，节省了指针的空间开销。另一方面，当保存的是字符串数据，并且字符串小于等于 44 字节时，redisobject 中的元数据、指针和 sds 是一块连续的内存区域，这样就可以避免内存碎片。这种布局方式也被称为 embstr 编码方式。当字符串大于44字节时，sds的数据量就开始变多了，redis 就不再把sds 和
redisobject 布局在一起了，而是会给 sds 分配独立的空间，并用指针指向 sds 结构。这种布局方式被称为 raw 编码模式。如下图所示：
现在我们来计算一下一对图片id和图片存储对象id的内存的使用量。由于10位数的图片id和图片存储对象id是long类型整数，所以可以直接用int编码的redisobject保存。相对应的redisobject元数据部分占8字节，指针部分被直接赋值为8字节的整数了。此时，每个id会使用16字节，加起来一共是32字节。但是，另外的 32 字节去哪儿了呢？
由于redis是使用全局哈希表来保存所有的键值对，哈希表的每一项是一个dictentity的结构体来指向一个键值对。dictentity由三个8字节的指针组成，分别来指向key、value以及下一个dictentity。如下图所示。
由于redis使用的内存分配库为jemalloc，jemalloc在分配内存时，会根据申请的字节数n，找一个比n大的，最接近n的2的幂次数作为分配的空间。
所以申请一个24字节的dictentity，实际会分配32个字节。
到目前位置，你应该明白了为什么string类型来保存图片id和图片存储对象id会占用64个字节了。一个有效信息只有16个字节，在使用string类型保存时，却要占用64个字节内存空间，有48个字节用来保存元数据信息了，这是不是极大的浪费了内存空间。那么有没有更加节省内存的方法呢？
用压缩列表节省内存
redis里有一种叫做压缩列表的结构，非常节省内存。我们先回顾一下压缩列表的构成。表头有三个字段zlbytes、zllen和zltail，分别表示列表的长度、列表尾的偏移量以及列表中entry的个数。压缩列表表尾有一个zlend，表示列表结束。如下图所示。
由于压缩列表采用一系列的entry保存数据，这些entry会挨个儿放置在内存中，不需要再用额外的指针进行连接，这样就可以节省指针所占用的空间。每个entry由以下几部分组成。
- pre_len：表示前一个entry的长度。prev_len有两种取值情况：1 字节或 5 字节。当上一个 entry 长度小于 254 字节时，prev_len 取值为 1 字节，否则，就取值为 5 字节。
- len：表示自身的长度，占4个字节。
- encoding：表示编码方式，占1个字节。
- content：保存实际数据。
假设我们使用entry来保存图片存储对象id(占8个字节)，此时，每个entry的prev_len占用1个字节就行，因为每一个entry的前一个entry的长度小于264字节。这样一来，一个图片对象id所占用的内存大小是14（1+4+1+8）个字节，实际上会分配16个字节。
redis里基于压缩列表实现了list、hash和sorted set集合类型，这样做的最大好处就是节省了dictentity的内存开销。对于string类型来说，一个键值对就有一个dictentity，占用32个字节。对于集合类型来说，一个key对应了很多数据，却只是占用了一个dictentity，这样就节省了内存空间。
如何用集合类型存储单值的键值对的数据
在保存单值键值对的数据时，我们可以使用基于hash类型的二级编码方式。这里所说的二级编码，是指把单值的数据拆成两部分，前一部分作为hash的key，后一部分作为hash的value。 以图片的id为1101021043，它所对应的图片存储对象的id为2301010051为例，我们将图片的id的前7位（1101021）作为hash类型的键，后3位（043）和图片存储对象id为2301010051作为hash类型的key和value。我们按照这种设计，在redis中插入一条记录，只占用了16字节，所以和使用string类型占用64字节对比，节省了很多空间。 最后，我们再思考一个问题，为什么要把图片id的前7位作为hash类型的键，后3位作为hash类型的key呢。我们在redis存储结构里介绍过redis的hash类型的两种底层实现结构，分别是压缩列表和哈希表。hash 类型设置了用压缩列表保存数据时的两个阈值，一旦超过了阈值，hash 类型就会用哈希表来保存数据了。这两个阈值分别对应以下两个配置项：
- hash-max-ziplist-entries：表示用压缩列表保存时哈希集合中的最大元素个数。
- hash-max-ziplist-value：表示用压缩列表保存时哈希集合中单个元素的最大长度。
在内存节省空间方面，哈希表就没有压缩列表那么高效。我们只用后3位作为hash类型的key，也就保证哈希集合中元素的个数不会超过1000，同时我们通过设置hash-max-ziplist-entries=1000，来确保hash类型底层使用的是压缩列表这种数据结构。
到此这篇关于redis中一个string类型引发的惨案的文章就介绍到这了,更多相关redis string类型内容请搜索www.887551.com以前的文章或继续浏览下面的相关文章希望大家以后多多支持www.887551.com！