谈谈redis,memcache的区别和具体应用场景

Redis 简介

Redis 是彻底开源免费的，遵照BSD协议，是一个高性能的key-value数据库。可是它自己是支持内存数据的持久化的，并且提供两种主要的持久化策略：RDB快照和AOF日志。

MemCache 简介

memcache是一个分布式的高速缓存系统，其本质上就是一个内存key-value数据库，可是不支持数据的持久化，服务器关闭以后数据所有丢失。

3. Memcached和Redis关键技术对比

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

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

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个字节，依此类推。

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

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释放内存。

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

3.2 Redis和Memcached的集群实现机制对比

Memcached是全内存的数据缓冲系统，Redis虽然支持数据的持久化，可是全内存毕竟才是其高性能的本质。做为基于内存的存储系统来讲，机器物理内存的大小就是系统可以容纳的最大数据量。若是须要处理的数据量超过了单台机器的物理内存大小，就须要构建分布式集群来扩展存储能力。

3.2.1 Memcached的分布式存储：客户端分步

Memcached自己并不支持分布式，所以只能在客户端经过像一致性哈希这样的分布式算法来实现Memcached的分布式存储。图6 给出了Memcached的分布式存储实现架构。当客户端向Memcached集群发送数据以前，首先会经过内置的分布式算法计算出该条数据的目标节点，而后数据会直接发送到该节点上存储。但客户端查询数据时，一样要计算出查询数据所在的节点，而后直接向该节点发送查询请求以获取数据。

3.2.2 Redis的分布式存储 : 服务端分布

相较于Memcached只能采用客户端实现分布式存储，Redis更偏向于在服务器端构建分布式存储。尽管Redis当前已经发布的稳定版本尚未添加分布式存储功能，但Redis开发版中已经具有了Redis Cluster的基本功能。预计在2.6版本以后，Redis就会发布彻底支持分布式的稳定版本，时间不晚于2012年末。下面咱们会根据开发版中的实现，简单介绍一下Redis Cluster的核心思想。

Redis Cluster是一个实现了分布式且容许单点故障的Redis高级版本，它没有中心节点，具备线性可伸缩的功能。图7给出Redis Cluster的分布式存储架构，其中节点与节点之间经过二进制协议进行通讯，节点与客户端之间经过ascii协议进行通讯。在数据的放置策略上，Redis Cluster将整个key的数值域分红4096个哈希槽，每一个节点上能够存储一个或多个哈希槽，也就是说当前Redis Cluster支持的最大节点数就是4096。Redis Cluster使用的分布式算法也很简单：crc16( key ) % HASH_SLOTS_NUMBER。

为了保证单点故障下的数据可用性，Redis Cluster引入了Master节点和Slave节点。如图4所示，在Redis Cluster中，每一个Master节点都会有对应的两个用于冗余的Slave节点。这样在整个集群中，任意两个节点的宕机都不会致使数据的不可用。当Master节点退出后，集群会自动选择一个Slave节点成为新的Master节点。

图8 Redis Cluster中的Master节点和Slave节点