时间：2016-03-18 15:30~16:30
地点：新大楼 A区 504
常见缓存选型
本地缓存
优点：
- 速度快，无网络损耗
- 单点故障不影响全局（相对应的缺点就是无法及时同步）
- 原生代码，使用简单
缺点：
- 无法及时同步
- 容量受限制较大（主要看内存多大）
适用场景：
- 数据量小（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缓存机制系列
