缓存1——概念篇

时间:2016-03-18 15:30~16:30
地点:新大楼 A区 504

常见缓存选型

  • 本地缓存(.NET的Cache)
  • Memcached
  • Redis
  • Mongodb
    • 当数据库用
    • 当缓存用

本地缓存

优点:
  • 速度快,无网络损耗
  • 单点故障不影响全局(相对应的缺点就是无法及时同步)
  • 原生代码,使用简单
缺点:
  • 无法及时同步
  • 容量受限制较大(主要看内存多大)
适用场景:
  • 数据量小(500M以内)
  • 更新频率小或基本不更新
  • 各服务器间不需要很强的一致性
  • 访问频率高的情况

某部门的做法:
先放本地缓存,有效时间设置10S或者更短,再放Redis
读数据的时候也是先从本地缓存中get数据,读不到的再去Redis取数据,这样可以每隔10s才访问一次Redis,避免大并发下Redis的卡死
PS:一般没有太高时效性要求的都可以采用本地缓存+Redis的缓存方案
拓展阅读:
CacheManager:–个通用缓存接口抽象类库

Redis

优点:
  • 读写速度快
  • 支持简单的主从,集群模式,能够满足高可用需要
  • 命令简单,易上手
缺点:
  • 大量占用内存,资源消耗大
  • 单线程运行,会由于不当操作,堵塞整个缓存
    因为Redis的单线程,所以Redis不会挂,只会卡,也只会用一个核,要么断网重连,一般无法解决Redis的卡死问题。
  • 高可用模型较简单,无法满足极高要求下的可用性
    Memcached是多线程的。之所以选择Redis是因为Redis支持的数据类型比较多。
    Redis设置了超时时间,过了超时时间数据就不存在了;没有设置超时时间的话,数据会永久存在的。能get到的数据就是命中,不能get到的数据就是丢失,不管要get的数据是否曾经在Redis上存储过。
适用场景:
  • 访问频率高
  • 更新频繁
  • 数据不重要或有备份
  • 分布式场景(生产者/消费者、发布/订阅)
  • 数据量在16G以内
    Redis的数据同步是一件比较危险的事情(网络抖动的情况下)
    一般不希望Redis做计算的处理(因为Redis的单线程)
    扩展阅读:
    NoSQL初探之人人都爱Redis:(4)Redis主从复制架构初步探索

Ardb/ssdb

可以想象成是硬盘上的Redis

优点:
  • 容量大幅提升
  • 兼容Redis协议
  • 数据持久化至硬盘,不会丢失
缺点:
  • 读写速度慢(Redis的1/3)I/O是它的瓶颈
  • 使用不当的情况下会把硬盘塞满
  • 比Redis会更多的耗用CPU资源
适用场景:
  • 数据了较大(500G以内)
  • 更新频繁

Mongodb

优点:
  • 完善的副本集功能,读写分离
  • 持久化在磁盘,存储空间极大,并可扩容
  • 查询方式多样,支持复杂查询
缺点:
  • 读写速度相对较慢
  • 多实例下成本较高,部署复杂
  • 学习成本高,不当查询或操作导致服务堵塞
适用场景:
  • 数据量大
  • 数据重要性高
  • 不能有中断服务
  • 数据结构复杂,查询方式多变

小结

性能排行:

本地缓存>Redis>Ardb>Mongodb

稳定性排行:

Mongodb>Ardb>Redis>本地缓存

选择

没有完美的缓存解决方案;具体场景具体选择;复杂场景下可以融合解决问题

附件

相关文章:
在使用缓存时应该注意哪些问题
十个常见的缓存使用误区及建议
缓存一致性(Cache Coherency)入门
扩展阅读:
Web缓存机制系列

你可能感兴趣的:(缓存1——概念篇)