在考虑对应用程序的性能表现进行提升时,缓存机制往往是解决问题的重要起点,而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显然更适合被大家作为通用性的首选方案——除了少部分特殊场景之外。

 

Memcached和Redis异同的更多相关文章

  1. 第三方缓存软件memcached和redis异同

    memcached和redis相同点:都是以键值对的形式来存储数据,通俗讲就是一个大的hashtable缓存数据都是存在内容中 key-value 不同点:memcached:1.一个key所对应的值 ...

  2. 谈谈Memcached与Redis

    1. Memcached简介 Memcached是以LiveJurnal旗下Danga Interactive公司的Bard Fitzpatric为首开发的高性能分布式内存缓存服务器.其本质上就是一个 ...

  3. 对比Memcached和Redis,谁才是适合你的缓存?

    Memcached vs Redis 近期公司采购软件,评估时,某软件谈到使用了 Memcached 和 Redis 缓存.在本文中,将研究这两个流行的缓存的异同,方便理解和记忆. 1. Memcac ...

  4. Memcached vs Redis

    Memcached和Redis哪一个能有更好的表现? Redis可以看作是Memcached的超集,这让Redis不仅仅可以用来当缓存,也可以作为实际的数据存储. 强大的数据结构以及操作命令. 默认持 ...

  5. Memcached和Redis对比和适用场景

    关于memcached和redis的使用场景,根据大神们的讨论和我在网上查到的资料,总结一下: 两者对比: redis提供数据持久化功能,memcached无持久化: redis的数据结构比memca ...

  6. Memcached、Redis OR Tair

    一.前言 非关系型数据库(NoSQL = Not Only SQL)的产品非常多,常见的有Memcached.Redis.MongoDB等优秀开源项目,相关概念和资料网上也非常丰富,不再重复描述,本文 ...

  7. Memcached 及 Redis 架构分析和比较

    Memcached和Redis作为两种Inmemory的key-value数据库,在设计和思想方面有着很多共通的地方,功能和应用方面在很多场合下(作为分布式缓存服务器使用等) 也很相似,在这里把两者放 ...

  8. Memcached、Redis和MongoDB的区别

    Memcached和Redis都是内存数据库. Memcached是多线程运行的: Redis单线程是单线程运行的: MongoDB是文档型的非关系型数据库..Net:RavenDB.

  9. memcached与redis 对比

    一. 综述 读一个软件的源码,首先要弄懂软件是用作干什么的,那memcached和redis是干啥的?众所周知,数据一般会放在数据库中,但是查询数据会相对比较慢,特别是用户很多时,频繁的查询,需要耗费 ...

随机推荐

  1. C++ 哈希表

    从2011年开始,C++支持非排序的unordered_map和unordered_set(原先的map和set都是通过有序结构实现的) 下面是一些性能上的测试 #include<iostrea ...

  2. ID3算法(决策树)

    一,预备知识: 信息量: 单个类别的信息熵: 条件信息量: 单个类别的条件熵: 信息增益: 信息熵: 条件熵:(表示分类的类,表示属性V的取值,m为属性V的取值个数,n为分类的个数) 二.算法流程: ...

  3. lesson2:java阻塞队列的demo及源码分析

    本文向大家展示了java阻塞队列的使用场景.源码分析及特定场景下的使用方式.java的阻塞队列是jdk1.5之后在并发包中提供的一组队列,主要的使用场景是在需要使用生产者消费者模式时,用户不必再通过多 ...

  4. Android开发之发送短信

    本实例通过SmsManager的sendTextMessage方法实现发送短信关于SmsManager的具体解释大家能够參照:Android开发之SmsManager具体解释 实例执行效果图: 程序代 ...

  5. 关于material和sharedMaterial的问题

    在unity3d中,Renderer组件有两个属性:material和sharedMaterial,它们都可以用来获取Renderer的材质属性.但是它们之间却又很大的区别,下面通过示例来讲解一下. ...

  6. 第三章 Android绘图机制与处理技巧

    1.屏幕尺寸信息 屏幕大小:屏幕对角线长度,单位“寸”:分辨率:手机屏幕像素点个数,例如720x1280分辨率:PPI(Pixels Per Inch):即DPI(Dots Per Inch),它是对 ...

  7. Myself

    每次过来写博客,一定是遇到什么问题,并且自己还解决不来. 并不是单纯的安静下来书写心得体会-->讨厌之余都有点看不起自己. 闲话少说,回归正题. C语言之于我可是骄傲与挫败并存. 当我做程式遇到 ...

  8. Facebook Architecture

    Facebook Architecture Quora article a relatively old presentation on facebook architecture another I ...

  9. WPF控件---Border应用

    内容模型:Border 只能具有一个子元素.若要显示多个子元素, 需要将一个容器元素放置在父元素Border中. <Grid> <Border BorderBrush="B ...

  10. 解决:用PivotGridControl 与 chartControl 配合使用,Series最大只显示10条

    修改 PivotGridControl  控件的 OptionsChartDataSource.MaxAllowedSeriesCount 的值就可以了  默认为10条