Redis——Redis内存模型原理

摘要

Redis是目前最火爆的内存数据库之一，通过在内存中读写数据，大大提高了读写速度，可以说Redis是实现网站高并发不可或缺的一部分。我们使用Redis时，会接触Redis的5种对象类型（字符串、哈希、列表、集合、有序集合），丰富的类型是Redis相对于Memcached等的一大优势。在了解Redis的5种对象类型的用法和特点的基础上，进一步了解Redis的内存模型，对Redis的使用有很大帮助，例如：

• 1、估算Redis内存使用量。目前为止，内存的使用成本仍然相对较高，使用内存不能无所顾忌；根据需求合理的评估Redis的内存使用量，选择合适的机器配置，可以在满足需求的情况下节约成本。
• 2、优化内存占用。了解Redis内存模型可以选择更合适的数据类型和编码，更好的利用Redis内存。
• 3、分析解决问题。当Redis出现阻塞、内存占用等问题时，尽快发现导致问题的原因，便于分析解决问题。

一、Redis内存统计

工欲善其事必先利其器，在说明Redis内存之前首先说明如何统计Redis使用内存的情况。在客户端通过redis-cli连接服务器后（后面如无特殊说明，客户端一律使用redis-cli），通过info命令可以查看内存使用情况：info memory

info命令可以显示redis服务器的许多信息，包括服务器基本信息、CPU、内存、持久化、客户端连接信息等等；memory是参数，表示只显示内存相关的信息。

• 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使用了虚拟内存，由于虚拟内存的媒介是磁盘，比内存速度要慢很多，当这种情况出现时，应该及时排查，如果内存不足应该及时处理，如增加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；截图中使用的便是默认的jemalloc。

二、Redis的内存分配

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

2.1 数据

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

2.2 redis进程本身需要的内存

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

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

2.3 缓冲内存

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

2.4 内存碎片

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

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

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

三、redis的内存分配器

• dictEntry：Redis是Key-Value数据库，因此对每个键值对都会有一个dictEntry，里面存储了指向Key和Value的指针；next指向下一个dictEntry，与本Key-Value无关。
• Key：图中右上角可见，Key（”hello”）并不是直接以字符串存储，而是存储在SDS结构中。
• redisObject：Value(“world”)既不是直接以字符串存储，也不是像Key一样直接存储在SDS中，而是存储在redisObject中。实际上，不论Value是5种类型的哪一种，都是通过redisObject来存储的；而redisObject中的type字段指明了Value对象的类型，ptr字段则指向对象所在的地址。不过可以看出，字符串对象虽然经过了redisObject的包装，但仍然需要通过SDS存储。
• jemalloc：无论是DictEntry对象，还是redisObject、SDS对象，都需要内存分配器（如jemalloc）分配内存进行存储。以DictEntry对象为例，有3个指针组成，在64位机器下占24个字节，jemalloc会为它分配32字节大小的内存单元。

3.1 jemalloc原理

Redis在编译时便会指定内存分配器；内存分配器可以是 libc 、jemalloc或者tcmalloc，默认是jemalloc。jemalloc作为Redis的默认内存分配器，在减小内存碎片方面做的相对比较好。jemalloc在64位系统中，将内存空间划分为小、大、巨大三个范围；每个范围内又划分了许多小的内存块单位；当Redis存储数据时，会选择大小最合适的内存块进行存储。例如，如果需要存储大小为130字节的对象，jemalloc会将其放入160字节的内存单元中。

内存分配是面向虚拟内存的而言的，以页为单位进行管理的，页的大小一般为4kb，当在堆里创建一个对象时(小于4kb)，会分配一个页，当再次创建一个对象时会判断该页剩余大小是否够，够的话使用该页剩余的内存，减少系统调用。真实的内存分配算法比这个复杂了，效率不好的内存算法会导致出现很多内存碎片。内存分配的核心思想概括起来有3条

1、首先讲内存区(memory pool)以最小单位(chunk)定义出来 ，然后区分对象大小分别管理内存，小内存定义不同的规格(bins),根据不同的bin分配固定大小的内存块，并用一个表
管理起来,大对象则以页为单位进行管理，配合小对象所在的页，降低碎片，设计一个好的存储方案（metadata)减少对内存的占用,同时优化内存信息的存储。以使对每个bin或大内存区域的访问性能最优且有上限。

2、当释放内存时，要能够合并小内存为大内存，该保留的保留下次可快速响应，不该保留的释放给系统。

3、多线程环境下，每个线程可以独立的占有一段内存区间(TLS),这样线程内操作可以不加锁

jemalloc是freebsd的内存分配算法,他的layout如下：

• 1：arena:把内存分成许多不同的小块来分而治之，该小块便是arena,让我们想象一下，给几个小朋友一张大图纸，让他们随意地画点。结果可想而知，他们肯定相互顾忌对方而不敢肆意地画（synchronization），从而影响画图效率。但是如果老师事先在大图纸上划分好每个人的区域，小朋友们就可以又快又准地在各自地领域上画图。这样的概念就是arena。它是jemalloc的核心分配管理区域，对于多核系统，会默认分配4*cores个arena 。线程采用轮询的方式来选择响应的arena进行内存分配。
• 2: chunk。具体进行内存分配的区域，默认大小是4M，chunk以page为单位进行管理，每个chunk的前6个page用于存储后面page的状态，比如是否分配或已经分配
• 3：bin:用来管理各个不同大小单元的分配，比如最小的Bin管理的是8字节的分配，每个Bin管理的大小都不一样，依次递增。
• 4：run:每个bin在实际上是通过对它对应的正在运行的Run进行操作来进行分配的，一个run实际上就是chunk里的一块区域，大小是page的整数倍，具体由实际的bin来决定，比如8字节的bin对应的run就只有1个page，可以从里面选取一个8字节的块进行分配。在run的最开头会存储着这个run的信息，比如还有多少个块可供分配。
• 5：tcache。线程对应的私有缓存空间，默认是使用的。因此在分配内存时首先从tcache中找，miss的情况下才会进入一般的分配流程。

arena和bin的关系：每个arena有个bin数组，每个bin管理不同大小的内存（run通过它的配置去获取相应大小的内存），每个tcahe有一个对应的arena，它本身也有一个bin数组（称为tbin），前面的部分与arena的bin数组是对应的，但它长度更大一些，因为它会缓存一些更大的块；而且它也没有对应的run的概念

chunk与run的关系：chunk默认是4M，而run是在chunk中进行实际分配的操作对象，每次有新的分配请求时一旦tcache无法满足要求，就要通过run进行操作，如果没有对应的run存在就要新建一个，哪怕只分配一个块，比如只申请一个8字节的块，也会生成一个大小为一个page（默认4K）的run；再申请一个16字节的块，又会生成一个大小为4096字节的run。run的具体大小由它对应的bin决定，但一定是page的整数倍。因此实际上每个chunk就被分成了一个个的run。

内存分配的，具体流程如下：

•  1.   如果请求size不大于arena的最小的bin（笔者机器上是3584字节），那么就通过线程对应的tcache来进行分配。首先确定size的大小属于哪一个tbin，比如2字节的size就属于最小的8字节的tbin，然后查找tbin中有没有缓存的空间，如果有就进行分配，没有则为这个tbin对应的arena的bin分配一个run，然后把这个run里面的部分块的地址依次赋给tcache的对应的bin的avail数组，相当于缓存了一部分的8字节的块，最后从这个availl数组中选取一个地址进行分配；
•  2.   如果请求size大于arena的最小的bin，同时不大于tcache能缓存的最大块（笔者机器上是32K），也会通过线程对应的tcache来进行分配，但方式不同。首先看tcache对应的tbin里有没有缓存块，如果有就分配，没有就从chunk里直接找一块相应的page整数倍大小的空间进行分配（当这块空间后续释放时，这会进入相应的tcache对应的tbin里）；
• 3.   如果请求size大于tcache能缓存的最大块，同时不大于chunk大小（默认是4M），具体分配和第2类请求相同，区别只是没有使用tcache；
• 4.   如果请求大于chunk大小，直接通过mmap进行分配。

回收流程大体和分配流程类似，有tcache机制的会将回收的块进行缓存，没有tcache机制的直接回收（不大于chunk的将对应的page状态进行修改，回收对应的run；大于chunk的直接munmap）。需要关注的是jemalloc何时会将内存还给操作系统，因为ptmalloc中存在因为使用top_chunk机制（详见华庭的文章）而使得内存无法还给操作系统的问题。目前看来，除了大内存直接munmap，jemalloc还有两种机制可以释放内存：

• 1.   当释放时发现某个chunk的所有内存都已经为脏（即分配后又回收）就把整个chunk释放；
• 2.   当arena中的page分配情况满足一个阈值时对dirty page进行purge（通过调用madvise来进行）。这个阈值的具体含义是该arena中的dirty page大小已经达到一个chunk的大小且占到了active page的1/opt_lg_dirty_mult（默认为1/32）。active page的意思是已经正在使用中的run的page，而dirty page就是其中已经分配后又回收的page。

性能优化的方式

• 方式:使用各种缓存、使用重用的方式来提高性能。
• 无论是cpu、kernel、应用层，都会用到缓存的概念。减少低速设备访问次数、减少低速操作的次数、使用重复使用(重用）的方式来减少反复分配释放资源造成的操作指令浪费。
• 对cpu和kernel层来说，cache是高速、RAM是中速、磁盘和flash是低速。对于应用来说，系统调用是费时的慢速操作。
• 反复分配和释放资源是费时的，所以应用使用“线程池”来重用线程。cpu使用TLB缓存了线性地址到物理地址的转换记录，省去查找页表项。cpu使用cache缓存来减少对RAM的访问。
• kernel使用“页高速缓存”来减少对磁盘的访问。再加上多次相连的io操作进行操作合并，来减少操作次数。
• kernel通过slab、slub缓存来减少“内存管理区”apialloc page和free page的调用次数，也方便管理相同大小object。
• 应用层通过使用dlmalloc、 jemalloc来管理自己的heap，来减少系统调用mmap·brk的操作次数。
• 应用层通过线程池来减少对操作系统反复创建和释放线程。

3.2 redisObject

前面说到，Redis对象有5种类型；无论是哪种类型，Redis都不会直接存储，而是通过redisObject对象进行存储。redisObject对象非常重要，Redis对象的类型、内部编码、内存回收、共享对象等功能，都需要redisObject支持，下面将通过redisObject的结构来说明它是如何起作用的。

redisObject的定义如下（不同版本的Redis可能稍稍有所不同）：
	
typedef struct redisObject {
　　unsigned type:4;// type字段表示对象的类型，占4个比特
　　unsigned encoding:4;// encoding表示对象的内部编码
　　unsigned lru:REDIS_LRU_BITS; /* lru time (relative to server.lruclock) */
　　int refcount;
　　void *ptr;
} 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命令，可以查看对象采用的编码方式，如下图所示：

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

refcount与共享对象：refcount记录的是该对象被引用的次数，类型为整型，占4个字节。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之间的整数会作为共享对象。

ptr：ptr指针指向具体的数据，如前面的例子中，set hello world，ptr指向包含字符串world的SDS。ptr指针占据的字节数与系统有关，例如64位系统中占8个字节。

总结：综上所述，redisObject的结构与对象类型、编码、内存回收、共享对象都有关系；在64位系统中，一个redisObject对象的大小为16字节：4bit+4bit+24bit+4Byte+8Byte=16Byte。

使用 RedisObject 的优点主要有两个，分别是：

1. 通过不同类型的对象，Redis 可以在执行命令之前，根据对象的类型来判断一个对象是否可以执行给定的命令。
2. 我们可以针对不同的使用场景，为对象设置不同的实现，从而优化内存或查询速度。

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

Redis支持5种对象类型，而每种结构都有至少两种编码；这样做的好处在于：一方面接口与实现分离，当需要增加或改变内部编码时，用户使用不受影响，另一方面可以根据不同的应用场景切换内部编码，提高效率。Redis各种对象类型支持的内部编码如下图所示(图中版本是Redis3.0，Redis后面版本中又增加了内部编码，关于Redis内部编码的转换，都符合以下规律：编码转换在Redis写入数据时完成，且转换过程不可逆，只能从小内存编码向大内存编码转换。

详细的Redis的对象的底层实现参考：Redis——底层数据结构原理_庄小焱的博客-CSDN博客

五、Redis内存优化

5.1 估算redis的内存用量

要估算redis中的数据占据的内存大小，需要对redis的内存模型有比较全面的了解，包括前面介绍的hashtable、sds、redisobject、各种对象类型的编码方式等。下面以最简单的字符串类型来进行说明。

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

综上，一个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;
　　}
}

5.2 优化内存占用

• 利用jemalloc特性进行优化，上一小节所讲述的90000个键值便是一个例子。由于jemalloc分配内存时数值是不连续的，因此key/value字符串变化一个字节，可能会引起占用内存很大的变动；在设计时可以利用这一点。例如，如果key的长度如果是8个字节，则SDS为17字节，jemalloc分配32字节；此时将key长度缩减为7个字节，则SDS为16字节，jemalloc分配16字节；则每个key所占用的空间都可以缩小一半。
• 使用整型/长整型，如果是整型/长整型，Redis会使用int类型（8字节）存储来代替字符串，可以节省更多空间。因此在可以使用长整型/整型代替字符串的场景下，尽量使用长整型/整型。
• 共享对象，利用共享对象，可以减少对象的创建（同时减少了redisObject的创建），节省内存空间。目前redis中的共享对象只包括10000个整数（0-9999）；可以通过调整REDIS_SHARED_INTEGERS参数提高共享对象的个数；例如将REDIS_SHARED_INTEGERS调整到20000，则0-19999之间的对象都可以共享。考虑这样一种场景：论坛网站在redis中存储了每个帖子的浏览数，而这些浏览数绝大多数分布在0-20000之间，这时候通过适当增大REDIS_SHARED_INTEGERS参数，便可以利用共享对象节省内存空间。
• 避免过度设计，然而需要注意的是，不论是哪种优化场景，都要考虑内存空间与设计复杂度的权衡；而设计复杂度会影响到代码的复杂度、可维护性。如果数据量较小，那么为了节省内存而使得代码的开发、维护变得更加困难并不划算；还是以前面讲到的90000个键值对为例，实际上节省的内存空间只有几MB。但是如果数据量有几千万甚至上亿，考虑内存的优化就比较必要了。

5.3 优化redis内存碎片

内存碎片率是一个重要的参数，对redis 内存的优化有重要意义。如果内存碎片率过高（jemalloc在1.03左右比较正常），说明内存碎片多，内存浪费严重；这时便可以考虑重启redis服务，在内存中对数据进行重排，减少内存碎片。如果内存碎片率小于1，说明redis内存不足，部分数据使用了虚拟内存（即swap）；由于虚拟内存的存取速度比物理内存差很多（2-3个数量级），此时redis的访问速度可能会变得很慢。因此必须设法增大物理内存（可以增加服务器节点数量，或提高单机内存），或减少redis中的数据。要减少redis中的数据，除了选用合适的数据类型、利用共享对象等，还有一点是要设置合理的数据回收策略（maxmemory-policy），当内存达到一定量后，根据不同的优先级对内存进行回收。

博文参考

内存管理思想_哔哩哔哩_bilibili

《Redis开发与运维》

《Redis设计与实现》

https://redis.io/documentation

http://redisdoc.com/server/info.html

https://searchdatabase.techtarget.com.cn/7-20218/

http://www.imooc.com/article/3645