Redis内存模型总结

一  Redis内存统计

　　在客户端通过redis-cli连接服务器后，通过info命令可以查看内存使用情况：

　　info memory

　　

　　返回结果中比较重要的几个说明如下：

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

　　（2）used_memory_rss：Redis进程占据操作系统的内存（单位是字节），与top及ps命令看到的值是一致的；除了分配器分配的内存之外，used_memory_rss还包括进程运行本身需要的内存、内存碎片等，但是不包括虚拟内存。

　　used_memory是从Redis角度得到的量，used_memory_rss是从操作系统角度得到的量。二者之所以有所不同，一方面是因为内存碎片和Redis进程运行需要占用内存，使得前者可能比后者小，另一方面虚拟内存的存在，使得前者可能比后者大。

　　（3）mem_fragmentation_ratio：内存碎片比率，该值是used_memory_rss / used_memory的比值。

　　mem_fragmentation_ratio一般大于1，且该值越大，内存碎片比例越大。mem_fragmentation_ratio<1，说明Redis使用了虚拟内存，由于虚拟内存的媒介是磁盘，比内存速度要慢很多，当这种情况出现时，应该及时排查，如果内存不足应该及时处理，如增加Redis节点、增加Redis服务器的内存、优化应用等。

　　一般来说，mem_fragmentation_ratio在1.03左右是比较健康的状态（对于jemalloc来说）；上面截图中的mem_fragmentation_ratio值很大，是因为还没有向Redis中存入数据，Redis进程本身运行的内存使得used_memory_rss 比used_memory大得多。

　　（4）mem_allocator：Redis使用的内存分配器，在编译时指定；可以是 libc 、jemalloc或者tcmalloc，默认是jemalloc；截图中使用的便是默认的jemalloc。

二  Redis内存划分

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

　　Redis的内存占用主要可以划分为以下几个部分：

1  数据

　　作为数据库，数据是最主要的部分；这部分占用的内存会统计在used_memory中。

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

2  进程本身运行需要的内存

　　Redis主进程本身运行肯定需要占用内存，如代码、常量池等等；这部分内存大约几兆，在大多数生产环境中与Redis数据占用的内存相比可以忽略。这部分内存不是由jemalloc分配，因此不会统计在used_memory中。

　　补充说明：除了主进程外，Redis创建的子进程运行也会占用内存，如Redis执行AOF、RDB重写时创建的子进程。当然，这部分内存不属于Redis进程，也不会统计在used_memory和used_memory_rss中。

3  缓冲内存

　　缓冲内存包括客户端缓冲区、复制积压缓冲区、AOF缓冲区等；其中，客户端缓冲存储客户端连接的输入输出缓冲；复制积压缓冲用于部分复制功能；AOF缓冲区用于在进行AOF重写时，保存最近的写入命令。在了解相应功能之前，不需要知道这些缓冲的细节；这部分内存由jemalloc分配，因此会统计在used_memory中。

4  内存碎片

　　内存碎片是Redis在分配、回收物理内存过程中产生的。例如，如果对数据的更改频繁，而且数据之间的大小相差很大，可能导致redis释放的空间在物理内存中并没有释放，但redis又无法有效利用，这就形成了内存碎片。内存碎片不会统计在used_memory中。

　　内存碎片的产生与对数据进行的操作、数据的特点等都有关；此外，与使用的内存分配器也有关系：如果内存分配器设计合理，可以尽可能的减少内存碎片的产生。后面将要说到的jemalloc便在控制内存碎片方面做的很好。

　　如果Redis服务器中的内存碎片已经很大，可以通过安全重启的方式减小内存碎片：因为重启之后，Redis重新从备份文件中读取数据，在内存中进行重排，为每个数据重新选择合适的内存单元，减小内存碎片。

二、Redis数据存储细节　

1  Redis存储结构

　　

从上图可以看出：

　　（1）redis的存储结构从外层往内层依次是redisDb、dict、dictht、dictEntry。

　　（2）redis的Db默认情况下有16个，每个redisDb内部包含一个dict的数据结构。

　　（3）redis的dict内部包含dictht的数组，数组个数为2，主要用于hash扩容使用。

　　（4）dictht内部包含dictEntry的数组，可以理解就是hash的桶，然后如果冲突通过挂链法解决。

2  redis 数据存储过程

　　数据存储过程以set为例作为说明，过程如下：

　　　　从redisDb当中找到dict，每个db就一个dict而已。

　　　　从dict当中选择具体的dictht对象。

　　　　首先根据key计算hash桶的位置，也就是index。

　　　　新建一个DictEntry对象用于保存key/value，将新增的entry挂到dictht的table对应的hash桶当中，每次保存到挂链的头部。

　　　　dictSetKey的宏保存key

　　　　dictSetVal的宏保存value

　　下图是执行set hello world时，所涉及到的数据模型。

　　 

　　Redis是Key-Value数据库，因此对每个键值对都会有一个dictEntry，里面有三个指针：　　

　　　　（1）Key：指向hello这个key的sds，图中右上角可见，Key（”hello”）并不是直接以字符串存储，而是存储在SDS结构中。

　　　　（2）val：指向存储world的RedisObject，value(“world”)既不是直接以字符串存储，也不是像Key一样直接存储在SDS中，而是存储在redisObject中。实际上，不论Value是5种类型的哪一种，都是通过redisObject来存储的；而redisObject中的type字段指明了Value对象的类型，ptr字段则指向对象所在的地址。字符串对象虽然经过了redisObject的包装，但仍然需要通过SDS存储。

　　　　实际上，redisObject除了type和ptr字段以外，还有其他字段图中没有给出，如用于指定对象内部编码的字段；后面会详细介绍。

　　　　（3）next指向下一个dictEntry，与本Key-Value无关。

　　jemalloc：无论是DictEntry对象，还是redisObject、SDS对象，都需要内存分配器（如jemalloc）分配内存进行存储。以DictEntry对象为例，有3个指针组成，在64位机器下占24个字节，jemalloc会为它分配32字节大小的内存单元。jemalloc在64位系统中，将内存空间划分为小、大、巨大三个范围；每个范围内又划分了许多小的内存块单位；当Redis存储数据时，会选择大小最合适的内存块进行存储。

　　

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

三、RedisObject

　　Redis对象有5种类型，无论是哪种类型，Redis都不会直接存储，而是通过redisObject对象进行存储。Redis对象的类型、内部编码、内存回收、共享对象等功能，都需要redisObject支持。

　　redisObject的定义如下（不同版本的Redis可能稍稍有所不同）：

　　typedef struct redisObject {
　　　　unsigned type:;  //表示对象类型，即字符串、列表等
　　　　unsigned encoding:;  //表示对象的内部编码
　　　　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支持的每种类型，都有至少两种内部编码，例如对于String，有int、embstr、raw三种编码。

　　通过encoding属性，Redis可以根据不同的使用场景来为对象设置不同的编码，大大提高了Redis的灵活性和效率。

　　以列表对象为例，有压缩列表和双端链表两种编码方式；如果列表中的元素较少，Redis倾向于使用压缩列表进行存储，因为压缩列表占用内存更少，而且比双端链表可以更快载入；当列表对象元素较多时，压缩列表就会转化为更适合存储大量元素的双端链表。

　　通过object encoding命令，可以查看对象采用的编码方式，如下图所示：

　　

（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初始化为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。

　　redisObject的结构与对象类型、编码、内存回收、共享对象都有关系；一个redisObject对象的大小为16字节:4bit+4bit+24bit+4Byte+8Byte=0.5Byte+0.5Byte+3Byte+4Byte+8Byte=16Byte。

四、SDS

　　Redis使用了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结构

　　SDS在C字符串的基础上加入了free和len字段，带来了很多好处：

　　　　1.获取字符串长度：SDS是O(1)，C字符串是O(n)，即SDS直接获取len的值即可。

　　　　2.缓冲区溢出：使用C字符串的API时，如果字符串长度增加（如strcat操作）而忘记重新分配内存，很容易造成缓冲区的溢出；而SDS由于记录了长度，相应的API在可能造成缓冲区溢出时会自动重新分配内存，杜绝了缓冲区溢出。

　　　　3.修改字符串时内存的重分配：对于C字符串，如果要修改字符串，必须要重新分配内存（先释放再申请），因为如果没有重新分配，字符串长度增大时会造成内存缓冲区溢出，字符串长度减小时会造成内存泄露。而对于SDS，由于可以记录len和free，因此解除了字符串长度和空间数组长度之间的关联，可以在此基础上进行优化：空间预分配策略（即分配内存时比实际需要的多）使得字符串长度增大时重新分配内存的概率大大减小；惰性空间释放策略使得字符串长度减小时重新分配内存的概率大大减小。

　　　　4.存取二进制数据：SDS可以，C字符串不可以。因为C字符串以空字符作为字符串结束的标识，而对于一些二进制文件（如图片等），内容可能包括空字符串，因此C字符串无法正确存取；而SDS以字符串长度len来作为字符串结束标识，因此没有这个问题。

　　此外，由于SDS中的buf仍然使用了C字符串（即以’\0’结尾），因此SDS可以使用C字符串库中的部分函数；但是需要注意的是，只有当SDS用来存储文本数据时才可以这样使用，在存储二进制数据时则不行（’\0’不一定是结尾）。

　　Redis在存储对象时，一律使用SDS代替C字符串。例如set hello world命令，hello和world都是以SDS的形式存储的。而sadd myset member1 member2 member3命令，不论是键（”myset”），还是集合中的元素（”member1”、 ”member2”和”member3”），都是以SDS的形式存储。除了存储对象，SDS还用于存储各种缓冲区。

　　只有在字符串不会改变的情况下，如打印日志时，才会使用C字符串。

（3）空间预分配和惰性释放策略

　　利用 SDS结构，除了可以用 θ(1)复杂度获取字符串的长度之外，还可以减少追加（append）操作所需的内存重分配次数，以下就来详细解释这个优化的原理。

　　1. 空间预分配：　

　　空间预分配用于优化 SDS 的字符串增长操作：

　　　　当 SDS 的 API 对一个 SDS 进行修改（例如执行append操作）， 并且需要对 SDS 进行空间扩展的时候， 程序不仅会为 SDS 分配修改所必须要的空间， 还会为 SDS 分配额外的未使用空间。

　　其中， 额外分配的未使用空间数量由以下公式决定：

　　　　如果对 SDS 进行修改之后， SDS 的长度（也即是 len 属性的值）将小于 1 MB ， 那么程序分配和 len 属性同样大小的未使用空间， 这时 SDS len 属性的值将和 free 属性的值相同。

　　　　举个例子，如果进行修改之后， SDS 的 len 将变成 13 字节， 那么程序也会分配13 字节的未使用空间， SDS 的 buf 数组的实际长度将变成 13 + 13 + 1 = 27 字节（额外的一字节用于保存空字符）。

　　　　如果对 SDS 进行修改之后， SDS 的长度将大于等于 1 MB ， 那么程序会分配 1 MB 的未使用空间。 举个例子， 如果进行修改之后， SDS 的 len 将变成 30 MB ， 那么程序会分配 1 MB 的未使用空间， SDS 的 buf 数组的实际长度将为 30 MB + 1 MB + 1 byte 。

　　　　通过空间预分配策略， Redis 可以减少连续执行字符串增长操作所需的内存重分配次数。

　　2.惰性空间释放

　　惰性空间释放用于优化 SDS 的字符串缩短操作：

　　当 SDS 的 API 需要缩短 SDS 保存的字符串时， 程序并不立即使用内存重分配来回收缩短后多出来的字节， 而是使用 free 属性将这些字节的数量记录起来， 并等待将来使用。

　　3.示例说明

　　为了易于理解，我们用一个 Redis 执行实例作为例子，解释一下，当执行以下代码时， Redis 内部发生了什么：

redis> SET msg "hello world"
OK
redis> APPEND msg " again!"
(integer)
redis> GET msg
"hello world again!"

　　首先， SET 命令创建并保存 "hello world" 到一个SDS中，这个SDS的值如下：

struct sdshdr {
    len = ;
    free = ;
    buf = "hello world\0";
}

　　当执行 APPEND 命令时，相应的SDS被更新，字符串 " again!" 会被追加到原来的 "hello world" 之后：

struct sdshdr {
    len = ;
    free = ;
    buf = "hello world again!\0"; // 空白的地方为预分配空间，共  +  +  个字节
}

　　注意， 当调用 SET 命令创建 sdshdr 时， sdshdr 的 free 属性为 0 ， Redis 也没有为 buf 创建额外的空间 —— 而在执行 APPEND 之后， Redis 为 buf 创建了多于所需空间一倍的大小。

　　在这个例子中， 保存 "hello world again!" 共需要 18 + 1 个字节， 但程序却为我们分配了 18 + 18 + 1 = 37 个字节 —— 这样一来， 如果将来再次对同一个 sdshdr 进行追加操作， 只要追加内容的长度不超过 free 属性的值， 那么就不需要对 buf 进行内存重分配。

五、Redis的对象类型与内部编码

　　Redis支持5种对象类型，而每种结构都有至少两种编码；这样做的好处在于：一方面接口与实现分离，当需要增加或改变内部编码时，用户使用不受影响，另一方面可以根据不同的应用场景切换内部编码，提高效率。

　　Redis各种对象类型支持的内部编码如下图所示：

　　

　　关于Redis内部编码的转换，都符合以下规律：编码转换在Redis写入数据时完成，且转换过程不可逆，只能从小内存编码向大内存编码转换。

1、字符串

　　（1）字符串是最基础的类型，因为所有的键都是字符串类型，且字符串之外的其他几种复杂类型的元素也是字符串。字符串长度不能超过512MB。

　　（2）内部编码：字符串类型的内部编码有3种，它们的应用场景如下：

　　　　　　int：8个字节的长整型。字符串值是整型时，这个值使用long整型表示。例如：set a 12;

　　　　　　embstr：<=39字节的字符串。embstr与raw都使用redisObject和sds保存数据，区别在于，embstr的使用只分配一次内存空间（因此redisObject和sds是连续的），而raw需要分配两次内存空间（分别为redisObject和sds分配空间）。因此与raw相比，embstr的好处在于创建时少分配一次空间，删除时少释放一次空间，以及对象的所有数据连在一起，寻找方便。而embstr的坏处也很明显，如果字符串的长度增加需要重新分配内存时，整个redisObject和sds都需要重新分配空间，因此redis中的embstr实现为只读。

　　　　　　raw：大于39个字节的字符串。

　　

　　　　embstr和raw进行区分的长度，是39；是因为redisObject的长度是16字节，sds的长度是9+字符串长度；因此当字符串长度是39时，embstr的长度正好是16+9+39=64，jemalloc正好可以分配64字节的内存单元。

　　(3)编码转换：当int数据不再是整数，或大小超过了long的范围时，自动转化为raw。

　　　　而对于embstr，由于其实现是只读的，因此在对embstr对象进行修改时，都会先转化为raw再进行修改，因此，只要是修改embstr对象，修改后的对象一定是raw的，无论是否达到了39个字节。示例如下图所示：

　　　　

2、列表

　　（1）列表（list）用来存储多个有序的字符串，每个字符串称为元素；一个列表可以存储2^32-1个元素。Redis中的列表支持两端插入和弹出，并可以获得指定位置（或范围）的元素，可以充当数组、队列、栈等。

　　（2）列表的内部编码可以是压缩列表（ziplist）或双端链表（linkedlist）。

　　　　双端链表：由一个list结构和多个listNode结构组成；典型结构如下图所示：

　　

　　通过图中可以看出，双端链表同时保存了表头指针和表尾指针，并且每个节点都有指向前和指向后的指针；链表中保存了列表的长度；dup、free和match为节点值设置类型特定函数，所以链表可以用于保存各种不同类型的值。而链表中每个节点指向的是type为字符串的redisObject。

　　压缩列表：压缩列表是Redis为了节约内存而开发的，是由一系列特殊编码的连续内存块(而不是像双端链表一样每个节点是指针)组成的顺序型数据结构；具体结构相对比较复杂，略。与双端链表相比，压缩列表可以节省内存空间，但是进行修改或增删操作时，复杂度较高；因此当节点数量较少时，可以使用压缩列表；但是节点数量多时，还是使用双端链表划算。

　　压缩列表不仅用于实现列表，也用于实现哈希、有序列表；使用非常广泛。

　　（3）只有同时满足下面两个条件时，才会使用压缩列表：列表中元素数量小于512个；列表中所有字符串对象都不足64字节。如果有一个条件不满足，则使用双端列表；且编码只可能由压缩列表转化为双端链表，反方向则不可能。

　　下图展示了列表编码转换的特点：

　　

　　其中，单个字符串不能超过64字节，是为了便于统一分配每个节点的长度；这里的64字节是指字符串的长度，不包括SDS结构，因为压缩列表使用连续、定长内存块存储字符串，不需要SDS结构指明长度。后面提到压缩列表，也会强调长度不超过64字节，原理与这里类似。

3、哈希

　　（1）哈希（作为一种数据结构），不仅是redis对外提供的5种对象类型的一种（与字符串、列表、集合、有序结合并列），也是Redis作为Key-Value数据库所使用的数据结构。为了说明的方便，在本文后面当使用“内层的哈希”时，代表的是redis对外提供的5种对象类型的一种；使用“外层的哈希”代指Redis作为Key-Value数据库所使用的数据结构。

　　（2）内层的哈希使用的内部编码可以是压缩列表（ziplist）和哈希表（hashtable）两种；Redis的外层的哈希则只使用了hashtable。

　　与哈希表相比，压缩列表用于元素个数少、元素长度小的场景；其优势在于集中存储，节省空间；同时，虽然对于元素的操作复杂度也由O(1)变为了O(n)，但由于哈希中元素数量较少，因此操作的时间并没有明显劣势。

　　hashtable：一个hashtable由1个dict结构、2个dictht结构、1个dictEntry指针数组（称为bucket）和多个dictEntry结构组成。

　　bucket是一个数组，数组的每个元素都是指向dictEntry结构的指针。redis中bucket数组的大小计算规则如下：大于dictEntry的、最小的2^n；例如，如果有1000个dictEntry，那么bucket大小为1024；如果有1500个dictEntry，则bucket大小为2048。

　　正常情况下（即hashtable没有进行rehash时）各部分关系如下图所示：

　　

　　Redis中内层的哈希既可能使用哈希表，也可能使用压缩列表。

　　只有同时满足下面两个条件时，才会使用压缩列表：哈希中元素数量小于512个；哈希中所有键值对的键和值字符串长度都小于64字节。如果有一个条件不满足，则使用哈希表；且编码只可能由压缩列表转化为哈希表，反方向则不可能。

　　下图展示了Redis内层的哈希编码转换的特点：

　　

4、集合

　　（1）集合（set）与列表类似，都是用来保存多个字符串，但集合与列表有两点不同：集合中的元素是无序的，因此不能通过索引来操作元素；集合中的元素不能有重复。

一个集合中最多可以存储2^32-1个元素；除了支持常规的增删改查，Redis还支持多个集合取交集、并集、差集。

　　（2）集合的内部编码可以是整数集合（intset）或哈希表（hashtable）。

　　（3）只有同时满足下面两个条件时，集合才会使用整数集合：集合中元素数量小于512个；集合中所有元素都是整数值。如果有一个条件不满足，则使用哈希表；且编码只可能由整数集合转化为哈希表，反方向则不可能。

　　下图展示了集合编码转换的特点：

　　

5、有序集合

　　（1）有序集合与集合一样，元素都不能重复；但与集合不同的是，有序集合中的元素是有顺序的。与列表使用索引下标作为排序依据不同，有序集合为每个元素设置一个分数（score）作为排序依据。

　　（2）有序集合的内部编码可以是压缩列表（ziplist）或跳跃表（skiplist）。

　　（3）只有同时满足下面两个条件时，才会使用压缩列表：有序集合中元素数量小于128个；有序集合中所有成员长度都不足64字节。如果有一个条件不满足，则使用跳跃表；且编码只可能由压缩列表转化为跳跃表，反方向则不可能。

　　下图展示了有序集合编码转换的特点：

　　

六  应用举例

1  估算Redis内存使用量

　　要估算redis中的数据占据的内存大小，需要对redis的内存模型有比较全面的了解，包括前面介绍的hashtable、sds、redisobject、各种对象类型的编码方式等。

　　下面以最简单的字符串类型来进行说明。

　　假设有90000个键值对，每个key的长度是7个字节，每个value的长度也是7个字节（且key和value都不是整数）；下面来估算这90000个键值对所占用的空间。在估算占据空间之前，因为胡长度为7个字节，因此首先可以判定字符串类型使用的编码方式：embstr。

　　90000个键值对占据的内存空间主要可以分为两部分：一部分是90000个dictEntry占据的空间；一部分是键值对所需要的bucket空间。

　　每个dictEntry占据的空间包括：

　　　　1)  一个dictEntry，24字节，jemalloc会分配32字节的内存块

　　　　2) 一个key，7字节，所以SDS(key)需要7+9=16个字节，jemalloc会分配16字节的内存块

　　　　3)  一个redisObject，16字节，jemalloc会分配16字节的内存块

　　　　4)  一个value，7字节，所以SDS(value)需要7+9=16个字节，jemalloc会分配16字节的内存块

　　　　5) 综上，一个dictEntry需要32+16+16+16=80个字节。

　　bucket空间：bucket数组的大小为大于90000的最小的2^n，是131072；每个bucket元素为8字节（因为64位系统中指针大小为8字节）。

　　因此，可以估算出这90000个键值对占据的内存大小为：90000*80 + 131072*8 = 8248576。

public class RedisTest {

　　public static Jedis jedis = new Jedis("localhost", 6379);

　　public static void main(String[] args) throws Exception{
　　　　Long m1 = Long.valueOf(getMemory());
　　　　insertData();
　　　　Long m2 = Long.valueOf(getMemory());
　　　　System.out.println(m2 - m1);
　　}

　　public static void insertData(){
　　　　for(int i = 10000; i < 100000; i++){
　　　　　　jedis.set("aa" + i, "aa" + i); //key和value长度都是7字节，且不是整数
　　　　}
　　}

　　public static String getMemory(){
　　　　String memoryAllLine = jedis.info("memory");
　　　　String usedMemoryLine = memoryAllLine.split("\r\n")[1];
　　　　String memory = usedMemoryLine.substring(usedMemoryLine.indexOf(':') + 1);
　　　　return memory;
　　}
}

　　运行结果：8247552

作为对比将key和value的长度由7字节增加到8字节，则对应的SDS变为17个字节，jemalloc会分配32个字节，因此每个dictEntry占用的字节数也由80字节变为112字节。此时估算这90000个键值对占据内存大小为：90000*112 + 131072*8 = 11128576。

在redis中验证代码如下（只修改插入数据的代码）：

public static void insertData(){
　　for(int i = 10000; i < 100000; i++){
　　　　jedis.set("aaa" + i, "aaa" + i); //key和value长度都是8字节，且不是整数
　　}
}

　　运行结果：11128576；估算准确。

2  优化内存占用

　　了解redis的内存模型，对优化redis内存占用有很大帮助。下面介绍几种优化场景。

（1）利用jemalloc特性进行优化

　　上一小节所讲述的90000个键值便是一个例子。由于jemalloc分配内存时数值是不连续的，因此key/value字符串变化一个字节，可能会引起占用内存很大的变动；在设计时可以利用这一点。

　　例如，如果key的长度如果是8个字节，则SDS为17字节，jemalloc分配32字节；此时将key长度缩减为7个字节，则SDS为16字节，jemalloc分配16字节；则每个key所占用的空间都可以缩小一半。

（2）使用整型/长整型

　　如果是整型/长整型，Redis会使用int类型（8字节）存储来代替字符串，可以节省更多空间。因此在可以使用长整型/整型代替字符串的场景下，尽量使用长整型/整型。

（3）共享对象

　　利用共享对象，可以减少对象的创建（同时减少了redisObject的创建），节省内存空间。目前redis中的共享对象只包括10000个整数（0-9999）；可以通过调整REDIS_SHARED_INTEGERS参数提高共享对象的个数；例如将REDIS_SHARED_INTEGERS调整到20000，则0-19999之间的对象都可以共享。

　　考虑这样一种场景：论坛网站在redis中存储了每个帖子的浏览数，而这些浏览数绝大多数分布在0-20000之间，这时候通过适当增大REDIS_SHARED_INTEGERS参数，便可以利用共享对象节省内存空间。

（4）避免过度设计

　　然而需要注意的是，不论是哪种优化场景，都要考虑内存空间与设计复杂度的权衡；而设计复杂度会影响到代码的复杂度、可维护性。

　　如果数据量较小，那么为了节省内存而使得代码的开发、维护变得更加困难并不划算；还是以前面讲到的90000个键值对为例，实际上节省的内存空间只有几MB。但是如果数据量有几千万甚至上亿，考虑内存的优化就比较必要了。

参考：https://www.cnblogs.com/kismetv/p/8654978.html

　　　Redis的内存优化　　https://cachecloud.github.io/2017/02/16/Redis%E5%86%85%E5%AD%98%E4%BC%98%E5%8C%96/?utm_source=tuicool&utm_medium=referral

　　　redis数据淘汰原理　　 https://www.jianshu.com/p/60cc093d6c36