Memcache与Redis比较

下文中，memcached简称M，redis简称R。

定位

M最初的定位是内存缓存的扩展，能够合理分配使用多台服务器的未使用内存。

R的定位是结构数据存储服务器，在内存中存储数据是增长性能的一种方式，因此它支持数据持久化以及不活跃数据落到磁盘。
R同时支持Pub/Sub模式的消息队列服务

数据类型支持

M使用key-value的方式存储数据，对于集合类型没有很好的支持。

R支持strings、hashes、lists、sets、sorted sets，能够更方便的适应业务场景，可是集合类型会带来额外的性能开销。

数据存储

M是全内存的方式存储数据。

R是内存优先，其中key是所有存放在内存中的，value部分存储在内存中，部分存储在磁盘中（非活跃数据）。R有两种方式将数据存储到磁盘，一种是之内存快照的方式存储（adb.c），一种是以顺序命令的方式（aof.c）。

内存管理

M使用固定长度的方式分配内存。首先选择合适大小的Slab Class（不一样的固定大小，根据数据的大小选择），而后将数据存储到Slab Class下的Chunk（固定大小）中。Chunk使用空闲列表的方式管理。

R将每一个数据块的大小存储在数据块的头部，经过一个数组（zmalloc_allocations）来管理数据块，参见zmalloc.c。
R推荐使用hashes，它有更好的存储和检索效率。相对于M来讲，R的方式可能会产生少许的内存碎片，同时R会存在数据从内存swap到磁盘的状况。

集群

M自己并不支持集群，通常是用一致性hash的方式将不一样区段的数据存储在不一样的服务器上面，所以存在单点故障和集群容量伸缩的问题。
M集群的问题能够经过缓存代理服务器规避，后端的M各自独立，代理服务器负责之间的数据同步及可用性检测。

R的cluster支持分布式存储的方式，同时支持Master-Slave应对单独故障。R的节点之间经过命令记录的方式执行同步。

数据一致性

M使用cas命令保证数据一致性。

R使用事务（Pipelining、Scripting方式）保证一组操做的原子性。

IO

M使用多线程模型，非阻塞IO复用（使用epoll或者kqueue，也能够用poll or select可是不推荐），网络IO处理使用了libevent。多线程能够发挥多核的优点，可是会带来并发读写的问题，M使用了锁来处理缓存一致性的问题，这会带来额外的性能开销。

R使用单线程模型，非阻塞IO复用，使用了一个简单事件驱动库ae（ae.c），支持epoll、kqueue和select。单线程方式有更好的性能，可是聚合计算等操做会形成阻塞。数据的持久化使用了额外的线程。

性能

• M在数据长度比较大时性能优于R（多线程IO）
• R在数据超出内存大小且冷热不明显时，性能很是差（swap优化不到位或者R不太关注swap，特别是执行数据压缩时，cpu消耗很大）
• 对于集合类型的操做，R明显是比M好的（天生支持hashes、lists、sets、sorted sets，减小网络开销）

总结

M更适合分布式缓存，若是你不care缓存穿透和缓存丢失。 R更适合数据存储，同时它的内存存储方式能够大大提升操做效率，问题在于它对于事务支持的缺乏。可是R并不适合单纯的存储系统，这方面Mongodb会是更好的选择。