缓存设计与优化

缓存的受益与成本

---

受益

• 加速读写

通过缓存加速读写速度：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等）
• 数据增长与水平扩展需求