缓存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缓存机制系列