Redis 和 Memcached 用谁？

如果简单地比较Redis与Memcached的区别，大多数都会得到以下观点：

1  Redis不仅仅支持简单的k/v类型的数据，同时还提供list，set，zset，hash等数据结构的存储。

2  Redis支持数据的备份，即master-slave模式的数据备份。

3  Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用。

Memcached采用客户端-服务器的架构，客户端和服务器端的通讯使用自定义的协议标准，只要满足协议格式要求，客户端Library可以用任何语言实现。

从用户的角度来说，服务器维护了一个键-值关系的数据表，服务器之间相互独立，互相之间不共享数据也不做任何通讯操作。客户端需要知道所有的服务器，并自行负责管理数据在各个服务器间的分配。

在服务器端，内部的数据存储，使用基于Slab的内存管理方式，有利于减少内存碎片和频繁分配销毁内存所带来的开销。各个Slab按需动态分配一个page的内存（和4Kpage的概念不同，这里默认page为1M），page内部按照不同slab class的尺寸再划分为内存chunk供服务器存储KV键值对使用

Memcached的基本应用模型:

edis的基本应用模式和上图memcached的基本相似，不难发现网上到处都是关于redis是否可以完全替代memcached使用的问题

Redis内部的数据结构终也会落实到key-Value对应的形式，不过从暴露给用户的数据结构来看，要比memcached丰富，除了标准的通常意义的键值对，Redis还支持List，Set， Hashes，Sorted Set等数据结构

基本命令

Memcached的命令或者说通讯协议非常简单，Server所支持的命令基本就是对特定key的添加，删除，替换，原子更新，读取等，具体包括 Set, Get, Add, Replace, Append, Inc/Dec 等等

Memcached的通讯协议包括文本格式和二进制格式，用于满足简单网络客户端工具（如telnet）和对性能要求更高的客户端的不同需求

Redis的命令在KV（String类型）上提供与Memcached类似的基本操作，在其它数据结构上也支持基本类似的操作（当然还有这些数据结构所特有的操作，如Set的union，List的pop等）而支持更多的数据结构，在一定程度上也就意味着更加广泛的应用场合

除了多种数据结构的支持，Redis相比Memcached还提供了许多额外的特性，比如Subscribe/publish命令，以支持发布/订阅模式这样的通知机制等等，这些额外的特性同样有助于拓展它的应用场景

Redis的客户端-服务器通讯协议完全采用文本格式（在将来可能的服务器间通讯会采用二进制格式）

数据备份，有效性，持久化等

memcached不保证存储的数据的有效性，Slab内部基于LRU也会自动淘汰旧数据，客户端不能假设数据在服务器端的当前状态，这应该说是Memcached的Feature设定，用户不必太多关心或者自己管理数据的淘汰更新工作，当然是否适合你的应用，取决于具体的需求，它也可能成为你需要自行控制Cache生命周期的一个障碍

Memcached也不做数据的持久化工作，但是有许多基于memcached协议的项目实现了数据的持久化，例如memcacheDB使用BerkeleyDB进行数据存储，但本质上它已经不是一个Cache Server，而只是一个兼容Memcached的协议key-valueData Store了

Redis可以以master-slave的方式配置服务器，Slave节点对数据进行replica备份，Slave节点也可以充当Read only的节点分担数据读取的工作

性能

性能方面，两者都有一些自己考虑和实现

Memcached

memcached自身并不主动定期检查和标记哪些数据需要被淘汰，只有当再次读取相关数据时才检查时间戳，或者当内存不够使用需要主动淘汰数据时进一步检查LRU数据

Redis

Redis为了减少大量小数据CMD操作的网络通讯时间开销 RTT (Round Trip Time)，支持pipeline和script技术

• 所谓的pipeline就是支持在一次通讯中，发送多个命令给服务器批量执行，带来的代价是服务器端需要更多的内存来缓存查询结果。

• Redis内嵌了LUA解析器，可以执行lua脚本，脚本可以通过eval等命令直接执行，也可以使用script load等方式上传到服务器端的script cache中重复使用

这两种方式都可以有效地减少网络通讯开销，增加数据吞吐率

对于KV的操作，Memcached和Redis都支持Multiple的Get和Set命令（Memcached的Multiple Set命令貌似只在二进制的协议中支持），这同样有利于性能的提升

实际性能方面，网上有很多测试比较，给出的结果各不相同，这无疑和各种测试的测试用例，测试环境，和测试时具体使用的客户端Library实现有关。但是总体看下来，比较靠谱的结论是在kv类操作上，两者的性能接近，Memcached的结构更加简单，理论上应该会略微快一些。

集群

memcached的服务器端互相完全独立，客户端通常通过对键值应用Hash算法决定数据的分区，为了减少服务器的增减对Hash结果的影响，导致大面积的缓存失效，多数客户端实现了一致性hash算法

Redis计划在服务器端内建对集群的支持，但是目前代码还处于alpha阶段（貌似已经Design了两三年了？）在此之前，同样可以认为每个Redis服务器实例相互之间是完全独立的，需要依靠客户端处理分区算法和可用服务器列表管理的工作。

Redis官方推荐的用于Sharding的客户端程序库是Twitter的开源项目Twemproxy， Twemproxy同时支持Memcached和Redis的文本通讯协议。

需要注意的是，Redis的许多命令在集群环境下是不能正确运行的，例如set的交集，以及跨节点的事务操作等等，因为目前的Redis集群设计，根本目标也就是服务器之间互相汇报一下存活状态，以及对数据做荣誉备份平衡负载等而已，本质上对数据的跨节点操作并不提供任何额外支持，所以在数据服务的层面上来说，各个服务器依旧是完全独立的。

这些操作如果一定要实现，当然可以通过客户端代码来实现（效率有多高且不说），类似的问题memcached集群当然也会遇上，但是原本memcached就不支持复杂的操作和数据类型，许多运算逻辑原本就是由客户端代码或应用程序自己处理的。

综上来说，如果要实现类似HBase支持的scan操作，不论是Redis还是memcached都无法做到，但是对于Redis来说，能否用于批处理类应用，不能一概而论，取决于具体的数据的格式逻辑和使用方式。通过适当的调整应用程序使用数据的方式，还是有可能在一定程度上实现对MR类批处理，或范围查询类应用逻辑的支持的。对于大型的系统，希望数据能及时持久化，或者安全行较高的，使用redis,而memcached只是提高访问效率的，推断未来很多memcached将被redis取代。

本文参考链接：

memcached官网 ：http://memcached.org/

Redis官网 ：https://redis.io/

                     中文：http://www.redis.cn/

刘旭晖 Raymond BLOG：http://blog.csdn.net/colorant/