redis缓存的目的、场景、实现、一致性问题

专辑详情和声音详情属于并发量较高的数据，如果每次访问都实时到数据库获取数据，数据库的访问压力太大。而这些信息一般更新的频率比较低，短时间内不会发生改变。因此，我们可以考虑在前台系统中，增加一层缓存，把这些数据缓存起来，请求到来时，不再调用数据接口，而是直接读取缓存中的数据。

1、加缓存的目的（作用）：

1. 提高系统吞吐能力
2. 提高并发：降低每一个请求的响应时间
3. 保护数据库：大部分热门数据可以从缓存中命中并直接返回

2、加缓存的场景：读多写少

1. 读的并发量大
2. 写的频率低

3、加不加缓存的标准：

1. 变化频率低
2. 访问频繁

4、缓存的实现：

1. redis：单线程，支持的数据模型更加丰富（常见5种），redis的性能瓶颈不是CPU计算，而是IO及网路带宽
2. memcache：多线程，只支持kv结构（String数据结构）

5、缓存的实现方案：

1. 编程式：SpringData-Redis、Jedis
2. 声明式：SpringCache提供的一套注解

这里选择编程式方案。

实现步骤：

1. 先查询缓存，如果缓存命中则直接返回
2. 缓存没有命中，则查询数据库并放入缓存

6、缓存的粒度问题

粒度	内存消耗	可复用性	可维护性
整个专辑详情页（ItemVo）	大	差	差
专辑整行（AlbumInfo）	中等	高	高
部分字段（AlbumInfoVo）	小	偏低	偏低

7、缓存的一致性问题

mysql数据更新了，redis需要同步数据，需要数据同步

1. 双写模式：写数据库，写缓存
2. 失效模式：缓存失效（删除缓存），写数据库
3. 双删模式：异步双删、延时双删、定时双删
4. 中间件：maxwell、canal中间件