Memcached与Redis(三)

3. Memcached和Redis关键技术对比

做为内存数据缓冲系统，Memcached和Redis均具备很高的性能，可是二者在关键实现技术上具备很大差别，这种差别决定了二者具备不一样的特色和不一样的适用条件。下面咱们会对二者的关键技术进行一些对比，以此来揭示二者的差别。

3.1 Memcached和Redis的内存管理机制对比

对于像Redis和Memcached这种基于内存的数据库系统来讲，内存管理的效率高低是影响系统性能的关键因素。传统C语言中的malloc/free函数是最经常使用的分配和释放内存的方法，可是这种方法存在着很大的缺陷：首先，对于开发人员来讲不匹配的malloc和free容易形成内存泄露；其次，频繁调用会形成大量内存碎片没法回收从新利用，下降内存利用率；最后，做为系统调用，其系统开销远远大于通常函数调用。因此，为了提升内存的管理效率，高效的内存管理方案都不会直接使用malloc/free调用。Redis和Memcached均使用了自身设计的内存管理机制，可是实现方法存在很大的差别，下面将会对二者的内存管理机制分别进行介绍。

3.1.1 Memcached的内存管理机制

Memcached默认使用Slab Allocation机制管理内存，其主要思想是按照预先规定的大小，将分配的内存分割成特定长度的块以存储相应长度的key-value数据记录，以彻底解决内存碎片问题。Slab Allocation机制只为存储外部数据而设计，也就是说全部的key-value数据都存储在Slab Allocation系统里，而Memcached的其它内存请求则经过普通的malloc/free来申请，由于这些请求的数量和频率决定了它们不会对整个系统的性能形成影响

Slab Allocation的原理至关简单。 如图3所示，它首先从操做系统申请一大块内存，并将其分割成各类尺寸的块Chunk，并把尺寸相同的块分红组Slab Class。其中，Chunk就是用来存储key-value数据的最小单位。每一个Slab Class的大小，能够在Memcached启动的时候经过制定Growth Factor来控制。假定Figure 1中Growth Factor的取值为1.25，因此若是第一组Chunk的大小为88个字节，第二组Chunk的大小就为112个字节，依此类推。

图3 Memcached内存管理架构

当Memcached接收到客户端发送过来的数据时首先会根据收到数据的大小选择一个最合适的Slab Class，而后经过查询Memcached保存着的该Slab Class内空闲Chunk的列表就能够找到一个可用于存储数据的Chunk。当一条数据库过时或者丢弃时，该记录所占用的Chunk就能够回收，从新添加到空闲列表中。从以上过程咱们能够看出Memcached的内存管理制效率高，并且不会形成内存碎片，可是它最大的缺点就是会致使空间浪费。由于每一个Chunk都分配了特定长度的内存空间，因此变长数据没法充分利用这些空间。如图 4所示，将100个字节的数据缓存到128个字节的Chunk中，剩余的28个字节就浪费掉了。

图4 Memcached的存储空间浪费

3.1.2 Redis的内存管理机制

Redis的内存管理主要经过源码中zmalloc.h和zmalloc.c两个文件来实现的。Redis为了方便内存的管理，在分配一块内存以后，会将这块内存的大小存入内存块的头部。如图 5所示，real_ptr是redis调用malloc后返回的指针。redis将内存块的大小size存入头部，size所占据的内存大小是已知的，为size_t类型的长度，而后返回ret_ptr。当须要释放内存的时候，ret_ptr被传给内存管理程序。经过ret_ptr，程序能够很容易的算出real_ptr的值，而后将real_ptr传给free释放内存。

图5 Redis块分配

Redis经过定义一个数组来记录全部的内存分配状况，这个数组的长度为ZMALLOC_MAX_ALLOC_STAT。数组的每个元素表明当前程序所分配的内存块的个数，且内存块的大小为该元素的下标。在源码中，这个数组为zmalloc_allocations。zmalloc_allocations[16]表明已经分配的长度为16bytes的内存块的个数。zmalloc.c中有一个静态变量used_memory用来记录当前分配的内存总大小。因此，总的来看，Redis采用的是包装的mallc/free，相较于Memcached的内存管理方法来讲，要简单不少。