缓存的利于弊及应用场景
这里我们主要讨论以Redis为代表的基于内存的缓存方案。
缓存的优点
提升访问速度，减少后端如数据库存储的时间消耗
减轻后端如数据库的压力
缓存带来的问题
任何系统每增加一个组件，在带来新的特性的同时也必然会带来额外的复杂度，可以说系统的设计过程就是一个折中的过程。缓存的引入也带来了一些需要考虑的问题:
- 数据不一致: 缓存层和存储层的数据存在着一定的时间窗口的不一致性，时间窗口跟缓存更新策略有关
- 代码维护成本： 需要同时处理缓存和存储层的逻辑
- 运维成本: 为了保证redis的可用性和并发性，会引入redis sentinel或redis cluster等架构，这又增加了系统复杂性和运维难度。
应用场景
- 开销大的复杂运算
- 加速请求响应
缓存更新策略
- LRU/LFU/FIFO算法
- 超时剔除
- 主动更新
应用
- 低一致性业务建议：最大内存+淘汰策略
- 高一致性：超时剔除和主动更新
缓存穿透
缓存穿透: 是指查询一个根本不存在的数据， 缓存层和存储层都不会命中。这会造成存储层压力变大。
缓存穿透的发现:
通常可以在程序中分别统计
- 总调用数
- 缓存层命中数
- 存储层命中数
如果发现大量存储层空命中， 可能就是出现了缓存穿透问题。
缓存穿透的解决方案
- 缓存空对象
。占用内存： 原因是为了防止大量空对象(被攻击) 方案是可以设置比较短的过期时间，让其自动剔除 数据不一致:
。原因是存储层添加了数据，但是缓存空对象还没过期， 方案是可以使用消息队列，
- bloomfilter拦截
。 这种方法适用于数据命中不高、 数据相对固定、 实时性低（通常是数据集较大） 的应用场景， 代码维护较为复杂，但是缓存空间占用少。
无底洞优化
由于缓存集群通常会将key进行hash，然后映射到相应的节点上，造成key的分布与业务无关，批量操作通常需要从不同节点上获取，相比于单机批量操作只涉及一次网络操作，分布式批量操作会涉及多次网络时间。
常见的IO优化思路：
- 命令本身的优化，例如优化SQL语句等
- 减少网络通信次数
。pipeline
。mget
- 降低介入成本，例如客户端使用长连/连接池、NIO等
集群客户端优化方案
- 串行IO，把key的请求按照节点分组，然后依次处理
- 并行IO，把key的请求按照节点分组，然后并行处理
- hash_tag实现， 可以将多个key强制分配到一个节点上，它的操作时间=1此网络时间+n次命令时间，性能最高，但是数据维护成本高，数据易倾斜
雪崩优化
雪崩定义：由于缓存层承载着大量请求，有效地保存了存储层，但是如果缓存层由于某些原因不能提供服务，于是所有的请求都会到达存储层，存储层的调用会暴增。
说到底就是缓存扛不住了，把压力冲击到了存储层。
预防和缓解缓存雪崩问题的三个方面
- 保证缓存层服务高可用性，redis提供了Redis Sentinel和Redis Cluster
- 依赖隔离组件为后端限流并降级，降级机制，如Hystrix
- 提前演练，项目上线前，演练缓存层宕掉后，应用及后端的负载情况以及可能出现的问题。
热点key重建优化
缓存+过期时间的策略既可以加速数据读写，又保证数据的定期更新，这种模式基本能够满足绝大部分需求。但有两个问题：
- 热点key，并发量非常大
- 重建缓存不能在短时间完成（长时生成缓存）
热点key重建
互斥锁
永远不过期，但是重建期间会有不一致问题
