一、问题:

    数据库表数据量极大(千万条),要求让服务器更加快速地响应用户的需求。
 

二、解决方案:

     1.通过高速服务器Cache缓存数据库数据
     2.内存数据库
 
  (这里仅从数据缓存方面考虑,当然,后期可以采用Hadoop+HBase+Hive等分布式存储分析平台)

三、主流解Cache和数据库对比:

 
     上述技术基本上代表了当今在数据存储方面所有的实现方案,其中主要涉及到了普通关系型数据库(MySQL/PostgreSQL),NoSQL数据库(MongoDB),内存数据库(Redis),内存Cache(Memcached),我们现在需要的是对大数据表仍保持高效的查询速度,普通关系型数据库是无法满足的。而MongoDB其实只是一种非关系型数据库,其优势在于可以存储海量数据,具备强大的查询功能,因此不宜用于缓存数据的场景。
       从以上各数据可知,对于我们产品最可行的技术方案有两种:
         1.Memcached         内存Key-Value Cache
         2.Redis                     内存数据库

四、下面重点分析Memcached和Redis两种方案:

 
4.1 Memcached介绍  
 
     Memcached 是一个高性能的分布式内存对象缓存系统,用于动态Web应用以减轻数据库负载。它通过在内存中缓存数据和对象来减少读取数据库的次数,从而提供动态、数据库驱动网站的速度,现在已被LiveJournal、hatena、Facebook、Vox、LiveJournal等公司所使用。
 
4.2 Memcached工作方式分析
     
     许多Web应用都将数据保存到 RDBMS中,应用服务器从中读取数据并在浏览器中显示。 但随着数据量的增大、访问的集中,就会出现RDBMS的负担加重、数据库响应恶化、 网站显示延迟等重大影响。Memcached是高性能的分布式内存缓存服务器,通过缓存数据库查询结果,减少数据库访问次数,以提高动态Web等应用的速度、 提高可扩展性。下图展示了memcache与数据库端协同工作情况:
 
     
     其中的过程是这样的:
           1.检查用户请求的数据是缓存中是否有存在,如果有存在的话,只需要直接把请求的数据返回,无需查询数据库。

2.如果请求的数据在缓存中找不到,这时候再去查询数据库。返回请求数据的同时,把数据存储到缓存中一份。
           3.保持缓存的“新鲜性”,每当数据发生变化的时候(比如,数据有被修改,或被删除的情况下),要同步的更新缓存信息,确保用户不会在缓存取到旧的数据。

     Memcached作为高速运行的分布式缓存服务器,具有以下的特点:

    • 协议简单
    • 基于libevent的事件处理
    • 内置内存存储方式
    • memcached不互相通信的分布式
 
4.3 如何实现分布式可拓展性?

     Memcached的分布式不是在服务器端实现的,而是在客户端应用中实现的,即通过内置算法制定目标数据的节点,如下图所示:
4.4 Redis 介绍  
 
     Redis是一个key-value存储系统。和Memcached类似,它支持存储的value类型相对更多,包括string(字符串)、 list(链表)、set(集合)和zset(有序集合)。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作,而且这些操作都是原子性的。在此基础上,redis支持各种不同方式的排序。与memcached一样,为了保证效率,数据都是缓存在内存中。区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件,并且在此基础上实现了master-slave(主从)同步,当前 Redis的应用已经非常广泛,国内像新浪、淘宝,国外像 Flickr、Github等均在使用Redis的缓存服务。
 
4.5 Redis 工作方式分析
 
     Redis作为一个高性能的key-value数据库具有以下特征: 
    • 多样的数据模型
    • 持久化
    • 主从同步
     Redis支持丰富的数据类型,最为常用的数据类型主要由五种:String、Hash、List、Set和Sorted Set。Redis通常将数据存储于内存中,或被配置为使用虚拟内存。Redis有一个很重要的特点就是它可以实现持久化数据,通过两种方式可以实现数据持久化:使用RDB快照的方式,将内存中的数据不断写入磁盘;或使用类似MySQL的AOF日志方式,记录每次更新的日志。前者性能较高,但是可能会引起一定程度的数据丢失;后者相反。 Redis支持将数据同步到多台从数据库上,这种特性对提高读取性能非常有益。
     
4.6 Redis如何实现分布式可拓展性?
 
2.8以前的版本:与Memcached一致,可以在客户端实现,也可以使用代理,twitter已开发出用于Redis和Memcached的代理Twemproxy 。

3.0 以后的版本:相较于Memcached只能采用客户端实现分布式存储,Redis则在服务器端构建分布式存储。Redis Cluster是一个实现了分布式且允许单点故障的Redis高级版本,它没有中心节点,各个节点地位一致,具有线性可伸缩的功能。如图给出Redis Cluster的分布式存储架构,其中节点与节点之间通过二进制协议进行通信,节点与客户端之间通过ascii协议进行通信。在数据的放置策略上,Redis Cluster将整个 key的数值域分成16384个哈希槽,每个节点上可以存储一个或多个哈希槽,也就是说当前Redis Cluster支持的最大节点数就是16384
 
     
 

五、综合结论

   
 应该说Memcached和Redis都能很好的满足解决我们的问题,它们性能都很高,总的来说,可以把Redis理解为是对Memcached的拓展,是更加重量级的实现,提供了更多更强大的功能。具体来说:
 
1.性能上:
     性能上都很出色,具体到细节,由于Redis只使用单核,而Memcached可以使用多核,所以平均每一个核上Redis在存储小数据时比

Memcached性能更高。而在100k以上的数据中,Memcached性能要高于Redis,虽然Redis最近也在存储大数据的性能上进行优化,但是比起 Memcached,还是稍有逊色。

 
2.内存空间和数据量大小:
     MemCached可以修改最大内存,采用LRU算法。Redis增加了VM的特性,突破了物理内存的限制。
 
3.操作便利上:
     MemCached数据结构单一,仅用来缓存数据,而Redis支持更加丰富的数据类型,也可以在服务器端直接对数据进行丰富的操作,这样可以减少网络IO次数和数据体积。
 
4.可靠性上:
     MemCached不支持数据持久化,断电或重启后数据消失,但其稳定性是有保证的。Redis支持数据持久化和数据恢复,允许单点故障,但是同时也会付出性能的代价。
 
5.应用场景:
     Memcached:动态系统中减轻数据库负载,提升性能;做缓存,适合多读少写,大数据量的情况(如人人网大量查询用户信息、好友信息、文章信息等)。
     Redis:适用于对读写效率要求都很高,数据处理业务复杂和对安全性要求较高的系统(如新浪微博的计数和微博发布部分系统,对数据安全性、读写要求都很高)。
 

六、需要慎重考虑的部分

1.Memcached单个key-value大小有限,一个value最大只支持1MB,而Redis最大支持512MB
2.Memcached只是个内存缓存,对可靠性无要求;而Redis更倾向于内存数据库,因此对对可靠性方面要求比较高
3.从本质上讲,Memcached只是一个单一key-value内存Cache;而Redis则是一个数据结构内存数据库,支持五种数据类型,因此Redis除单纯缓存作用外,还可以处理一些简单的逻辑运算,Redis不仅可以缓存,而且还可以作为数据库用
4.新版本(3.0)的Redis是指集群分布式,也就是说集群本身均衡客户端请求,各个节点可以交流,可拓展行、可维护性更强大。

memcache、redis原理对比的更多相关文章

  1. 缓存数据库memcache、redis原理对比

    一.问题:     数据库表数据量极大(千万条),要求让服务器更加快速地响应用户的需求. 二.解决方案:      1.通过高速服务器Cache缓存数据库数据      2.内存数据库     (这里 ...

  2. 转: memcache, redis, mongodb 对比

    http://db-engines.com/en/system/Memcached%3BMongoDB%3BRedis

  3. 分布式缓存集群方案特性使用场景(Memcache/Redis(Twemproxy/Codis/Redis-cluster))优缺点对比及选型

    分布式缓存集群方案特性使用场景(Memcache/Redis(Twemproxy/Codis/Redis-cluster))优缺点对比及选型   分布式缓存特性: 1) 高性能:当传统数据库面临大规模 ...

  4. memcache、mongodb、redis的对比区别

    >>Memcached Memcached的优点:Memcached可以利用多核优势,单实例吞吐量极高,可以达到几十万QPS(取决于key.value的字节大小以及服务器硬件性能,日常环境 ...

  5. redis、memcache、mongoDB 对比

    从以下几个维度,对 redis.memcache.mongoDB 做了对比. 1.性能 都比较高,性能对我们来说应该都不是瓶颈. 总体来讲,TPS 方面 redis 和 memcache 差不多,要大 ...

  6. Ignite性能测试以及对redis的对比

    测试方法 为了对Ignite做一个基本了解,做了一个性能测试,测试方法也比较简单主要是针对client模式,因为这种方法和使用redis的方式特别像.测试方法很简单主要是下面几点: 不作参数优化,默认 ...

  7. ehcache memcache redis -- java中的三大缓存

      三个缓存在java代码中用的是较多的,但是它们都有自己的应用场合,和优缺点.  Ehcache 1.初衷:减少数据库操作的高延时而设计.(缓存的目的,好像都是这个吧) 2.Apache Licen ...

  8. memcache的原理和命中率的总结

    详见:http://blog.yemou.net/article/query/info/tytfjhfascvhzxcyt267 1       Memcache是什么Memcache是danga.c ...

  9. 缓存子系统如何设计(Cachable tag, Memcache/redis support, xml config support, LRU/LFU/本地缓存命中率)

    大家对这段代码肯定很熟悉吧: public List<UserInfo> SearchUsers(string userName) { string cacheKey=string.For ...

随机推荐

  1. Docker Compose 容器编排

    1. 前言 Docker Compose 是 Docker 容器进行编排的工具,定义和运行多容器的应用,可以一条命令启动多个容器. 使用Compose 基本上分为三步: Dockerfile 定义应用 ...

  2. Visual Studio 2017 激活密钥 [复制记录]

    Visual Studio 2017(VS2017) 企业版 Enterprise 注册码:NJVYC-BMHX2-G77MM-4XJMR-6Q8QF Visual Studio 2017(VS201 ...

  3. Laravel 常见错误 1071 Specified key was too long

    Laravel 5.5 + Mysql 5.5 ,执行 migrate 时,提示索引长度超过指定的 1000 bytes 原因: Mysql 对索引有一定的长度限制,版本不同长度不同: MyIsAm ...

  4. 注册鼠标右键CMD

    Windows Registry Editor Version 5.00 [-HKEY_CLASSES_ROOT\Directory\shell\runas] [HKEY_CLASSES_ROOT\D ...

  5. OneZero产品视频

    产品视频地址:http://v.youku.com/v_show/id_XMTU1MDMwOTk2OA==.html

  6. 解决从pip上下载的最新flask版本不能运行flaskr和最新特性的问题

    由于在测试flask的单元测试.所以准备弄个环境,查询官方文档发现flask源码里面有一个example文件夹里面有个flaskr应用 可供测试 看了一下readme文档,大致是这样 / Flaskr ...

  7. 浅谈教你如何掌握Linux系统

    linux能做什么?相信绝大数人都有这样的疑问.可以玩吃鸡吗?可以玩lol吗? 如果你是以娱乐的名义来评价linux的可用性,对不起,linux可能不适合你,因为linux是一个工具,他是教你聪明的, ...

  8. ZOJ2836-Number Puzzle-容斥原理

    依次考虑一个数的倍数,两个数的倍数(lcm),三个数的倍数(lcm)... 会发现有这么一个规律,奇数个数时要加上情况数,偶数个数时要减去情况数. 一种只有10个数,用二进制枚举所有情况即可. #in ...

  9. POJ - 3159(Candies)差分约束

    题意: 就是分糖果 然后A觉得B比他优秀  所以分的糖果可以比他多 但最多不能超过c1个, B又觉得A比他优秀.... 符合差分约束的条件 设A分了x个  B分了y个  则x-y <= c1 , ...

  10. 【题解】Atcoder ARC#96 F-Sweet Alchemy

    首先,我们发现每一个节点所选择的次数不好直接算,因为要求一个节点被选择的次数大于等于父亲被选择的次数,且又要小于等于父亲被选择的次数 \(+D\).既然如此,考虑一棵差分的树,规定每一个节点被选择的次 ...