Memcached和Redis异同
在考虑对应用程序的性能表现进行提升时，缓存机制往往是解决问题的重要起点，而Memcached与Redis则经常被作为初步方案来加以比较。这两套声名显赫的缓存引擎拥有着诸多相似之处，但它们同样也具备大量显著差异。作为二者当中更年轻也更加灵活的方案，Redis被大部分技术人员视为首选目标——但请别掉以轻心，不容忽视的重要例外情况也是客观存在的。
两者的相似之处
Memcached和Redis都属于内存内键值数据存储方案。他们还都属于数据管理方案的NoSql家族，而且都基于键值对的数据模型。双方都选择将数据全部保存在内存中，这使得他们成为理想的缓冲层实现方案。从性能角度来看，两种缓存机制也有诸多的共同性，包括拥有几乎相同的特征表现，而且高度关注工作负载的数据吞吐量和延迟状况。
除了同位内存内键值对存储方案，Memcached和Redis还都具有相当成熟且极具人气的开源项目。
Memcached最初是由Brad Fitzpatrick于2003年开发而成，当时其直接服务对象为LiveJournal交友网站。在此之后，Memcached被重新用C语言进行了 编写(其最初实现方式为Perl语言)且投身于公共领域，并在这里逐步发展为现代Web应用程序的构建基石。Memcached项目的当前开发工作主要关 注其运行稳定性及优化效果方面，而不再积极为其打造更多新型功能。
Redis则由Salvatore Sanfilippo于2009年创建，而且时至今日Sanfilippo仍然担任着该项目的首席开发者以及惟一维护者的角色。Redis有时候会被人们 称为“强化版的Memcached”。考虑到从Memcached身上吸取并借鉴到大量宝贵的经验教训，这样的评价其实并不令人意外。Redis在功能多 样性方面要胜过Memcached，这虽然让者更为强大也更具灵活性、但其复杂程度也较后者为甚。
Memcached与Redis为什么如此受人拥戴?除了二者卓越的实际效果之外，双方各自极为简便的上手难度也是又一大加分项。无论是 Memcached还是Redis，其使用便捷性在开发人员当中都可谓广为人知。只需要几分钟我们就能完成安装工作，并让它们开始与应用程序顺畅协作。换句话来说，只需投入一小部分时间与精力，大家就能获得立竿见影且效果极佳的性能表现提升——具体而言，性能将直接步入新的量级。面对如此简单而又能够带来巨大收益的解决方案，又有谁能抗拒得了它们的诱惑呢?
两者都在什么情况下使用比较合适那？
在Redis大行其道的今天，有两种情况仍然是Memcached的天下。首先是对小型静态数据进行缓存处理，最具代表性的Html代码片段。Memcached的内存管理机制虽然不像Redis那么复杂，不过确更具实际效率，这是因为Memcached在处理元数据的时候消耗的资源更小。作为Memcached所支持的唯一数据类型，字符串非常适合那些只需要进行读取操作的数据，因为这样无需进行进一步的处理。其次，Memcached在横向扩展方面比Redis更具有优势。由于其设计思想上的倾向以及更为简单的功能设置，Memcached在实际扩展比Redis难度小的多。不过据了解，目前已经有多种经过测试且切实有效的方案能够将Redis扩展至多台服务器之上，Redis 3.0版本将包含专门针对横向扩展场景的内置集群化机制。
除了大家需要考虑某种限制性条件（处理传统应用程序）对于Memcached的特殊依赖性，或者上面提到的两种情况，斗则请直接选择Redis加以应用。凭借Redis所带来的卓越缓存机制，我们将拥有强大的处理能力--例如对缓存内容及持久性进行细节调整的能力以及出色的整体执行效率。
Redis几乎在缓存管理工作中的 每一个侧面都表现出显而易见的优越性。这套缓存方案采用所谓数据回收机制，能够将陈旧数据从内存中删除以提供新数据所必需的缓存空间。Memcached 的数据回收机制使用的是LRU(即最低近期使用量)算法，而且往往会比较武断地直接删除掉与新数据体系相近的原有内容。相比之下，Redis允许用户更为 精准地进行细化控制，利用六种不同回收策略确切提高缓存资源的实际利用率。Redis还采用更为复杂的内存管理与回收对象备选方案。
Redis还能为我们带来最大程度的灵活性空间，从而保证管理员在打理缓存对象时拥有充裕的施展平台。在这方面，Memcached将键名限制在250字 节，值也被限制在不超过1MB，且只适用于普通字符串。相比之下，Redis则将键名与值的最大上限各自设定为512MB，且支持二进制格式。Redis 支持六种数据类型，因此能够更加智能地对数据进行缓存处理及操作，这相当于为应用程序开发人员敞开了一道通往无尽可能性的大门。
相对于 将对象保存为序列化字符串，Redis允许开发人员以散列方式将对象域及值加以保存，并利用单一键对其进行管理。Redis散列机制的存在保证开发人员无 需经历获取完整字符串、反序列化、更新值、对象重新序列化并在每次值更新后利用其替代缓存内完整字符串这一系列复杂的流程——这也意味着资源消耗量得以降 低、性能表现迎来显著提升。Redis所支持的其它数据类型，例如Lists以及Sets——也可被用于实现更加复杂的缓存管理模式。
Redis的另一大重要优势在于，它所保存的数据具备透明化特性，也就是说服务器能够直接对这些数据进行操作。Redis当中提供160多种可用命令，其 中大部分用于实现数据处理操作并通过服务器端脚本将逻辑嵌入至数据存储体系当中。这些内置命令及用户脚本带来了极大的灵活性优势，足以帮助大家直接在 Redis内部完成数据处理任务——而不必将数据在网络中的其它专门处理系统之间来回移动。
Redis还提供可选而且能够具体调整的数 据持久性方案，其设计目的在于在发生规划内停机或者计划外故障之后对缓存内容进行重新引导。虽然我们更倾向于强调缓存内数据的易失性与暂时性，但将数据在 磁盘中加以持久保存在某些缓存场景当中仍然极具现实意义。这种机制能够在设备重启之后快速将保存在磁盘上的数据重新载入至缓存当中，从而大大缩短缓存预热 周期并根据主数据存储内容对当前缓存内容进行重新评估。
最后但也同样重要的一点是，Redis能够提供复制功能。复制功能旨在帮助缓存 体系实现高可用性配置方案，从而在遭遇故障的情况下继续为应用程序提供不间断的缓存服务。很明显，一套成熟的缓存方案应该能够在应用程序发生故障时略微甚 至完全不给用户体验或者应用程序性能表现带来任何影响，而这种对缓存内容及服务可用性的有力保障在大多数情况下也成为缓存解决方案的一大主要优势。
开源软件业界一直在不断努力，为我们带来当下技术领域中最为出色的各类解决方案。而在谈到利用缓存机制对应用程序性能表现加以提升这一话题 时，Redis与Memcached作为两款广受赞誉而且久经考验的解决方案、也自然而然地成为完成这项任务的两大首选技术成果。不过从功能多样性以及设 计先进性的角度出发，Redis显然更适合被大家作为通用性的首选方案——除了少部分特殊场景之外。
郑重声明：本站内容如果来自互联网及其他传播媒体，其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享，并不代表本站赞同其观点和对其真实性负责，也不构成任何其他建议。
