缓存的受益与成本
受益
- 加速读写
通过缓存加速读写速度:CPU L1/L2/L3 Cache、Linux page Cache加速硬盘读写、浏览器缓存、Ehcache缓存数据库结果。
- 降低后端负载
后端服务器通过前端缓存降低负载:业务端使用Redis降低后端MySQL负载等。
成本
- 数据不一致:缓存层和数据层有时间窗口不一致,和更新策略有关。
- 代码维护成本:多了一层缓存逻辑
使用场景
- 对高消耗的SQL:join结果集/分组统计结果缓存
- 加速请求响应:利用Redis、Memcache优化IO响应时间
- 大量写合并为批量写:如计数器先Redis累加再批量写DB
缓存更新策略
- LRU、LFU、FIFO算法剔除:例如 maxmemory-policy。
- 超时剔除:例如 expire。
- 主动更新:开发控制生命周期
策略 | 一致性 | 维护成本 |
LRU/LIRS算法剔除 | 最差 | 低 |
超时剔除 | 较差 | 低 |
主动更新 | 强 | 高 |
缓存粒度控制
1、从MySQL获取用户信息:
select * from user where id={id}
2、设置用户信息缓存:
set user:{id} `select * from user where id={id}`
3、缓存粒度:
全部属性:set user:{id} `select * from user where id={id}`
部分重要属性:set user:{id} `select importColumn1...importColumnK from user where id={id}`
三个角度
- 通用性:全量属性更好
- 占用空间:部分属性更好
- 代码维护:表面上全量属性更好
缓存穿透问题—大量请求不命中
正常情况下,当访问到cache,它会把结果返回给request,如果cache没有命中的话,它就会把流量往下引到存储层,如果存储层正常的话,存储层拿到结果,回写到cache,返回给request,当下次request再次访问的时候,就可以直接从cache中获取,那么就不需要访问到存储层了。
但是如果存储层的数据根本就不存在,那会有什么问题?
即它会返回给request为空的结果,当下次再来request请求,再访问cache层,cache层还是没有,还要再访问存储层,所有的流量都被导入到存储层,这就是缓存穿透的一个基本过程,实际上这就已经失去了缓存的意义。
产生的原因
- 业务代码自身问题
- 恶意攻击、爬虫等
如何发现
- 业务的响应时间
- 业务本身问题
- 相关指标:总调度数、缓存层命中数、存储层命中数
解决方法1-缓存空对象
即如果存储层返回的结果为空,那么就把它当作一个结果,存储到cache中。
两个问题
1、需要存储更多的键(更多无效的键)。
2、缓存层和存储层数据“短期”不一致。
示例代码
public String getPassThrough(String key){
String cacheValue=cache.get(key);
if(StringUtils.isBlank(cacheValue)){
String storageValue=storage.get(key);
cache.set(key,storageValue);
//如果存储数据为空,需要设置一个过期时间(300秒)
if(StringUtils.isBlank(storageValue)){
cache.expire(key,60*5);
}
}else {
return cacheValue;
}
return null;
}
解决方法2-布隆过滤器拦截
将所有可能存在的数据哈希到一个足够大的 bitmap 中,一个一定不存在的数据会被这个 bitmap 拦截掉,从而避免了对底层存储系统的查询压力。
缓存雪崩优化
由于cache服务承载大量请求,当cache服务异常/脱机,流量直接压向后端组件(例如DB),造成级联故障。
缓存雪崩-优化方案
1、保证缓存高可用:个别节点、个别机器、甚至是机房。
2、依赖隔离组件为后端限流。
3、提前演练:例如压力测试。
无底洞问题优化
问题描述:
- 2010年,Facebook有了3000个Memcache节点
- 发现问题:“加”机器性能没能提升,反而下降
无底洞问题关键点
- 更多的机器!=更高的性能
- 批量接口需求(mget,mset等)
- 数据增长与水平扩展需求