两者相似之处

　　Memcached与Redis都属于内存内、键值数据存储方案。它们都从属于数据管理解决方案中的NoSQL家族，而且都基于同样的键值数据模型。双方都选择将全部数据保存在内存当中，这自然也就让它们成为非常理想的缓冲层实现方案。从性能表现的角度来看，两类数据存储机制也具备诸多共通性，包括拥有几乎相同的特征(与指标)表现、而且高度关注工作负载的数据吞吐量与延迟状况。

何时使用Memcached

　　Memcached最初是由Brad Fitzpatrick于2003年开发而成。

　　相对Memcached而言，Redis的面世时间更晚且具备更多功能，因此开发人员通常将其视为默认性首选方案。不过有两类特殊场景仍然是Memcached的一家天下。首先就是对小型静态数据进行缓存处理，最具代表性的例子就是HTML代码片段。Memcached的内部内存管理机制虽然不像Redis的那样复杂，但却更具实际效率——这是因为Memcached在处理元数据时所消耗的内存资源相对更少。作为Memcached所支持的惟一一种数据类型，字符串非常适合用于保存那些只需要进行读取操作的数据，因为字符串本身无需进行进一步处理。

　　除此之外，Memcached在横向扩展方面也比Redis更具优势。由于其在设计上的思路倾向以及相对更为简单的功能设置，Memcached在实现扩展时的难度比Redis低得多。不过根据我们了解到的情况，目前已经有多种经过测试且切实有效的方案能够将Redis扩展至多台服务器之上，而其即将发布的3.0版本(感兴趣的朋友可以点击此处查看其候选版本说明)将包含专门针对横向扩展场景的内置集群化机制。

何时应该使用Redis

　　Redis则由Salvatore Sanfilippo于2009年创建，被人们称为“强化版的Memcached”。除非大家需要考虑某种限定性条件(例如处理传统应用程序)对于Memcached的特殊依赖性，或者自己的实际用例属于前面提到的两类场景中的一种，否则请直接选择Redis并加以运用。凭借着Redis所带来的卓越缓存方案，我们将拥有强大的处理能力——例如对缓存内容及持久性进行细节调整的能力——以及出色的整体执行效率。

　　Redis还能为我们带来最大程度的灵活性空间，从而保证管理员在打理缓存对象时拥有充裕的施展平台。在这方面，Memcached将键名限制在250字节，值也被限制在不超过1MB，且只适用于普通字符串。相比之下，Redis则将键名与值的最大上限各自设定为512MB，且支持二进制格式，支持六种数据类型。因此能够更加智能地对数据进行缓存处理及操作，这相当于为应用程序开发人员敞开了一道通往无尽可能性的大门。

　　相对于将对象保存为序列化字符串，Redis允许开发人员以散列方式将对象域及值加以保存，并利用单一键对其进行管理。Redis散列机制的存在保证开发人员无需经历获取完整字符串、反序列化、更新值、对象重新序列化并在每次值更新后利用其替代缓存内完整字符串这一系列复杂的流程——这也意味着资源消耗量得以降低、性能表现迎来显著提升。Redis所支持的其他数据类型，例如Lists以及Sets——也可被用于实现更加复杂的缓存管理模式。

　　Redis的另一大重要优势在于，它所保存的数据具备透明化特性，也就是说服务器能够直接对这些数据进行操作。Redis当中提供160多种可用命令，其中大部分用于实现数据处理操作并通过服务器端脚本将逻辑嵌入至数据存储体系当中。这些内置命令及用户脚本带来了极大的灵活性优势，足以帮助大家直接在Redis内部完成数据处理任务——而不必将数据在网络中的其他专门处理系统之间来回移动。

　　Redis还提供可选而且能够具体调整的数据持久性方案，其设计目的在于在发生规划内停机或者计划外故障之后对缓存内容进行重新引导。虽然我们更倾向于强调缓存内数据的易失性与暂时性，但将数据在磁盘中加以持久保存在某些缓存场景当中仍然极具现实意义。这种机制能够在设备重启之后快速将保存在磁盘上的数据重新载入至缓存当中，从而大大缩短缓存预热周期并根据主数据存储内容对当前缓存内容进行重新评估。

　　最后但也同样重要的一点是，Redis能够提供复制功能。复制功能旨在帮助缓存体系实现高可用性配置方案，从而在遭遇故障的情况下继续为应用程序提供不间断的缓存服务。很明显，一套成熟的缓存方案应该能够在应用程序发生故障时略微甚至完全不给用户体验或者应用程序性能表现带来任何影响，而这种对缓存内容及服务可用性的有力保障在大多数情况下也成为缓存解决方案的一大主要优势。