Memcached 及 Redis 架构分析和比较
Memcached和Redis作为两种Inmemory的key-value数据库，在设计和思想方面有着很多共通的地方，功能和应用方面在很多场合下(作为分布式缓存服务器使用等) 也很相似，在这里把两者放在一起做一下对比的介绍
基本架构和思想
首先简单介绍一下两者的架构和设计思路
Memcached
Memcached采用客户端-服务器的架构，客户端和服务器端的通讯使用自定义的协议标准，只要满足协议格式要求，客户端Library可以用任何语言实现。
从用户的角度来说，服务器维护了一个键-值关系的数据表，服务器之间相互独立，互相之间不共享数据也不做任何通讯操作。客户端需要知道所有的服务器，并自行负责管理数据在各个服务器间的分配。
在服务器端，内部的数据存储，使用基于Slab的内存管理方式，有利于减少内存碎片和频繁分配销毁内存所带来的开销。各个Slab按需动态分配一个page的内存（和4Kpage的概念不同，这里默认page为1M），page内部按照不同slab class的尺寸再划分为内存chunk供服务器存储KV键值对使用
Memcached的基本应用模型如下图所示
Redis
Redis的基本应用模式和上图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的客户端-服务器通讯协议完全采用文本格式（在将来可能的服务器间通讯会采用二进制格式）
事务
redis通过Multi / Watch /Exec等命令可以支持事务的概念，原子性的执行一批命令。在2.6以后的版本中由于添加了对Script脚本的支持，而脚本固有的是以transaction事务的方式执行的，并且更加易于使用，所以不排除将来取消Multi等命令接口的可能性
Memcached的应用模式中，除了increment/decrement这样的原子操作命令，不存在对事务的支持
数据备份，有效性，持久化等
memcached不保证存储的数据的有效性，Slab内部基于LRU也会自动淘汰旧数据，客户端不能假设数据在服务器端的当前状态，这应该说是Memcached的Feature设定，用户不必太多关心或者自己管理数据的淘汰更新工作，当然是否适合你的应用，取决于具体的需求，它也可能成为你需要精确自行控制Cache生命周期的一个障碍
Memcached也不做数据的持久化工作，但是有许多基于memcached协议的项目实现了数据的持久化，例如memcacheDB使用BerkeleyDB进行数据存储，但本质上它已经不是一个Cache Server，而只是一个兼容Memcached的协议key-valueData Store了
Redis可以以master-slave的方式配置服务器，Slave节点对数据进行replica备份，Slave节点也可以充当Read only的节点分担数据读取的工作
Redis内建支持两种持久化方案，snapshot快照和AOF 增量Log方式。快照顾名思义就是隔一段时间将完整的数据Dump下来存储在文件中。AOF增量Log则是记录对数据的修改操作（实际上记录的就是每个对数据产生修改的命令本身），两种方案可以并存，也各有优缺点，具体参见 http://redis.io/topics/persistence
以上Redis的数据备份持久化方案等，如果不需要，为了提高性能，也完全可以Disable